I have run across a few people who are perplexed by
firewalld and I must admit that I was for a while until I did some reading and experimentation. What is
firewalld? It is basically a replacement for the ancient
iptables service on RHEL and Fedora systems. So many of us were just used to manually editing
/etc/sysconfig/iptables and then coping that file from system to system as desired, that the switch to
firewalld was a bit scary. I mean, who wants to learn something new, right?
Another thing that is scary about
firewalld is the complexity of the rules it shows when you do something like:
While the configuration, tools and output has dramatically changed... really
firewalld makes things easier and more manageable. Really. One of the problems with Linux across distros is that there really hasn't been a standardized way to handle the host-based firewall. Each distro seems to have their own way of doing it... and popular packages like Shorewall have been around for years. I think
firewalld tries for a happy medium somewhere between simple and complex and a standard that distros can choose to adopt.
Anyway, here are some basics (as root or via sudo) but if you want more be sure and check out the documentation:
Main documentation: www.firewalld.org/documentation/
Fedora Documentation: fedoraproject.org/wiki/FirewallD
RHEL Documentation: access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html
firewall-cmd --list-all(shows human readable firewall settings)
firewall-cmd --add-service=sshd --permanent(opens up port 22 which is sshd and saves to config)
firewall-cmd --add-service=http --permanent(opens up port 80 which is http and saves to config)
firewall-cmd --add-service=https --permanent(opens up port 443 which is https and saves to config)
firewall-cmd --remove-service=https --permanent(closes port 443 and saves to config)
If you want don't want your changes saved just leave off --permanent.
Want to open arbitrary ports for some service (like voxelands-server for example)? That is easy too:
firewall-cmd --add-port=30000/tcp --permanent
Want UDP? Ok:
firewall-cmd --add-port=30000/udp --permanent
After your changes it doesn't hurt to verify again with:
Want to manage firewalld via a config management system? There is a formula for SaltStack here and supposedly Ansible also supports firewalld.
Want to edit a file instead of running
firewall-cmd? That's possible too.
firewalld stores everything somewhere under /etc/firewalld/. In particular the changes listed above would get written to
/etc/firewalld/zones/public.xml. Yeah, it's an "xml" file but make a change or two via firewall-cmd and see what it adds or removes from it and you'll see that it is very easy to monkey-see-monkey-do for those that want to edit the file directly. After updating or replacing any of firewalld's configuration files you want to make firewalld aware of the change with:
systemctl reload firewalld
If you are brave enough to manually edit the config just be aware that you are responsible for your typos.
I've only touched the tip of the iceburg for the most common stuff. Need more info? Yeah, there is a ton of documentation including a couple of man pages.
Looking forward to 2015, we have very exciting news to share on the future on OpenVZ. But first, let's take a quick look into OpenVZ history.
Linux Containers is an ancient technology, going back to last century. Indeed it was 1999 when our engineers started adding bits and pieces of containers technology to Linux kernel 2.2. Well, not exactly "containers", but rather "virtual environments" at that time -- as it often happens with new technologies, the terminology was different (the term "container" was coined by Sun only five years later, in 2004).
Anyway, in 2000 we ported our experimental code to kernel 2.4.0test1, and in January 2002 we already had Virtuozzo 2.0 version released. From there it went on and on, with more releases, newer kernels, improved feature set (like adding live migration capability) and so on.
It was 2005 when we finally realized we made a mistake of not employing the open source development model for the whole project from the very beginning. This is when OpenVZ was born as a separate entity, to complement commercial Virtuozzo (which was later renamed to Parallels Cloud Server, or PCS for short).
Now it's time to admit -- over the course of years OpenVZ became just a little bit too separate, essentially becoming a fork (perhaps even a stepchild) of Parallels Cloud Server. While the kernel is the same between two of them, userspace tools (notably vzctl) differ. This results in slight incompatiblities between the configuration files, command line options etc. More to say, userspace development efforts need to be doubled.
Better late than never; we are going to fix it now! We are going to merge OpenVZ and Parallels Cloud Server into a single common open source code base. The obvious benefit for OpenVZ users is, of course, more features and better tested code. There will be other much anticipated changes, rolled out in a few stages.
As a first step, we will open the git repository of RHEL7-based Virtuozzo kernel early next year (2015, that is). This has become possible as we changed the internal development process to be more git-friendly (before that we relied on lists of patches a la quilt but with home grown set of scripts). We have worked on this kernel for quite some time already, initially porting our patchset to kernel 3.6, then rebasing it to RHEL7 beta, then final RHEL7. While it is still in development, we will publish it so anyone can follow the development process.
Our kernel development mailing list will also be made public. The big advantage of this change for those who want to participate in the development process is that you'll see our proposed changes discussed on this mailing list before the maintainer adds them to the repository, not just months later when the the code is published and we'll consider any patch sent to the mailing list. This should allow the community to become full participants in development rather than mere bystanders as they were previously.
Bug tracking systems have also diverged over time. Internally, we use JIRA (this is where all those PCLIN-xxxx and PSBM-xxxx codes come from), while OpenVZ relies on Bugzilla. For the new unified product, we are going to open up JIRA which we find to me more usable than Bugzilla. Similar to what Red Hat and other major Linux vendors do, we will limit access to security-sensitive issues in order to not compromise our user base.
Last but not least, the name. We had a lot of discussions about naming, had a few good candidates, and finally unanimously agreed on this one:
Please stay tuned for more news (including more formal press release from Parallels). Feel free to ask any questions as we don't even have a FAQ yet.
Merry Christmas and a Happy New Year!
Since Russia has 10 days of holidays in January, I really don't expect anything to be released until late January or more likely in February. One major change in the upcoming RHEL7-based Virtuozzo Core release is the move from the internal chkpoint code to CRIU. Although there are a lot more details and specifics to come, overall I see this as a very possitive move.
This was released by the Linux Foundation yesterday and I thought I'd share. Enjoy!
Lennart Poettering gave a presentation for NLUUG on Nov. 20th, 2014 entitled, "Security Features in systemd". I think veteran system admins would be interested in this stuff. :) Enjoy!
Direct download link: 5_Lennart_Poettering_-_Systemd.webm
Jordan Hubbard... should need no introduction but if you don't know who he is, look him up... anyway, Mr. Hubbard spoke recently at the MeetBSD 2014 conference giving a presentation entitled, "FreeBSD: The next 10 years".
One thing I want to point out is his section on the init system. Here's a direct link to that section that I couldn't figure out to get to with the embedded video. Anyway, in the embedded video feel free to move the play head to about 27 minutes and 32 seconds into it manually if you don't want to watch the whole thing.
So FreeBSD may very well be moving to an init system modeled after Apple's Mac OS X's launchd... and since systemd also borrowed some ideas from launchd (as well as a few other systems)... systemd haters can move to FreeBSD... but how long before it also changes in ways they don't like? Oh, and I like the way Mr. Hubbard refers to systemd. :)
Here's some choice bullet points from one of his slides:
Argh, I am *SO* tired of seeing various sites linking to the inflammatory and factually incorrect articles by the following three guys:
- Jim Lynch (ITworld)
- Sam Varghese (iTWire)
- Paul Venezia (InfoWorld)
I would give examples but I just want to forget about them. Don't feed the trolls.
Here is a video I've been waiting for by Jike Song from Intel. The KVM Forum 2014 was held in conjunction with the recent LinuxCon Europe and someone (from the Linux Foundation or the KVM Forum) has been processing and posting presentation videos to YouTube in a staggered fashion. About 13 hours ago this video appeared. When I noticed the topic on the KVM Forum schedule (along with the slide deck [PDF]) a week or two before the event, I was really looking forward to learning more.
The current implementation, so far as basic features go, seems to be fairly complete but it is currently targeted specifically at the Intel Haswell architecture using the i915 video driver. The presenter says that the approach taken should be adaptable to other GPU architectures beyond Intel. Their initial goal is to get the code released (it is under a dual GPL/MIT license) and to work with the KVM development community to get it upstreamed and part of KVM proper... and to work on more advanced feature implementation. As it stands now the basic features are present: hardware assisted GPU functionality for VMs in a shared fashion that offers 80-90% of native speed. Near the end of the presentation is a demo video that shows two Linux KVM VMs each running GPU intensive software (one game, one benchmark). As I understand it, when a GPU-driven application is displayed it is full-screen and there isn't currently a windowed mode to show more than one VM at a time. I do wonder how well 3D accelerated graphics would display over a remoting protocol like SPICE? Enjoy!
I found the link to this video (Getting Ready for systemd) on the systemd documentation page. It is a Red Hat "Customer Portal Exclusive" and "Not for Distribution" but it is ok for me to provide a picture that links to it... that looks like a video-ready-to-play. :) Enjoy.
There has been so much negative stuff about systemd on teh Interwebs lately. It is so sad. Quite a few distros picked systemd because they liked a lot of the features it has. Why do the people who like systemd actually like it? Sure, if you look hard enough, you can find those answers... but I remembered a video where the man himself explains it.
The only problem with the original video on YouTube is that the volume is sort of low so you have to crank it up... and then there is coughing that blows your eardrums... so I took the time to edit out the coughing. The A/V sync isn't great and the sound leaves a bit to be desired... but it is still worthwhile viewing for anyone who wants to better understand why systemd. Enjoy!
If you want the coughing, you can find the original here.
Here's Linus with Intel's Chief Linux and Open Source Technologist, Dirk Hohndel on the next 12 months of the Linux kernel:
Here's a kernel panel hosted by LWN's Jon Corbet featuring Grant Likely, Linaro; Borislav Petkov, SUSE; Thomas Gleixner, linutronix GmbH; Julia Lawall, Inria; Frédéric Weisbecker, Red Hat.