[Howto] Upgrading CentOS 6 to CentOS 7

CentOS 7 is out. With systemd, Docker integration and many more fixes and new features I wanted to see if the new remote upgrade possibility already works. I’ve already posted the procedure to Vexxhost’s Blog and wanted to share it here as well. But beware: don’t try this on production servers!

CentOS 7 was released only few weeks after Red Hat Enterprise Linux 7, including the same exciting features RHEL ships. Besides the long awaited Systemd and the right now much discussed Docker this release also features the possibility to perform upgrades from version 6 to version 7 automatically without the need of the installation images. And although the upgrade still requires a reboot and thus is not a live upgrade as such, it comes in very handy for servers which can only be reached remotely.

Red Hat has already released and documented the necessary tools. The CentOS team didn’t have time yet to import, test and rebuild the tools but the developers are already on it – and they provide untested binaries.

Please, note: Since the packages are not tested yet you should not, by any means, try these on anything else than on spare test machines you can easily re-deploy and which do not have any valuable data. Do not try this on your production machines!

But if you want to get a first idea of how the tools do basically work, I recommend to set up a simple virtual machine with a fully updated CentOS 6 and as few packages as possible. Next, install the rpms from the CentOS repository mentioned above. Among these is the Preupgrade Assistant, which can be run on a system with no harm: preupg just analyses the system and gives hints what to look out for during an upgrade without performing any tasks. Since I only tested with systems with hardly any services installed I got no real results from preupg. Even a test run on a system with more services installed brought the same output (only showing some examples of the dozens and dozens of lines):

$ sudo preupg
Preupg tool doesn't do the actual upgrade.
Please ensure you have backed up your system and/or data in the event of a failed upgrade
 that would require a full re-install of the system from installation media.
Do you want to continue? y/n
y
Gathering logs used by preupgrade assistant:
All installed packages : 01/10 ...finished (time 00:00s)
All changed files      : 02/10 ...finished (time 00:48s)
Changed config files   : 03/10 ...finished (time 00:00s)
All users              : 04/10 ...finished (time 00:00s)
...
042/100 ...done    (samba shared directories selinux)
043/100 ...done    (CUPS Browsing/BrowsePoll configuration)
044/100 ...done    (CVS Package Split)
...
|samba shared directories selinux          |notapplicable  |
|CUPS Browsing/BrowsePoll configuration    |notapplicable  |
|CVS Package Split                         |notapplicable  |
...

As mentioned above the Preupgrade Assistant only helps evaluating what problems might come up during the upgrade – the real step must be done with the tool redhat-upgrade-tool-cli. For that to work the CentOS 7 key must be imported first:

$ sudo rpm --import http://isoredirect.centos.org/centos/7/os/x86_64/RPM-GPG-KEY-CentOS-7

Afterwards, the actual upgrade tool can be called. As options it takes the future distribution version and a URL to pull the data from. Additionally I had to add the option --force since the tool complained that preupg was not run previously – although it was. As soon as the upgrade tool is called, it starts downloading all necessary information, packages and images, and afterwards asks for a reboot – the reboot does not happen automatically.

$ sudo /usr/bin/redhat-upgrade-tool-cli --force --network 7 --instrepo=http://mirror.centos.org/centos/7/os/x86_64
setting up repos...
.treeinfo                                                                                                                                            | 1.1 kB     00:00     
getting boot images...

After the reboot the machine updates itself with the help of the downloaded packages. Note that this phase does take some time, depending on the speed of the machine, expect minutes, not seconds. However, if everything turns out right, the next login will be into a CentOS 7 machine:

$ cat /etc/os-release 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

Concluding it can be said that the upgrade tool worked quite nicely. While it is not comparable to a real live upgrade if offers a decent way to upgrade remote servers. I’ve tested it with a clean VM and also with a bare metal, remote server, and it worked surprisingly good. The analysis tool unfortunately did not perform how I expected it to work, but that might be due to the untested state or I was not using it properly. I’m looking forward what how that develops and improves over time.

But, again, and as mentioned before – don’t try this on your own prod servers.

First look at cockpit, a web based server management interface [Update]

Only recently the Cockpit project was launched, aiming at providing a web based management interface for various servers. It already leaves an interesting impression for simple management tasks – and the design is actually well done.

I just recently came across the only three month old Cockpit project. The mission statement is clear:

Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser.

The web page also states three aims: beginners friendly interface, multi server management – and that there should be no interference in mixed usage of web interface and shell. Especially the last point caught my attention: many other web based solutions introduce their own magic, thus making it sometimes tricky to co-administrate the system manually via the shell. The listed objectives also make clear that cockpit does not try to replace tools that go much deeper into the configuration of servers, like Webmin, which for example offers modules to configure Apache servers in a quite detailed manner. Cockpit tries to simply administrate the server, not the applications. I must admit that I would always do such a application configuration manually anyway…

The installation of Cockpit is a bit bumpy: besides the requirement of tools like systemd which limits the usage to only very recent distributions (excluding Ubuntu, I guess) there are no packages yet, some manual steps are required. A post at unshut.me highlights the necessary steps for Fedora which I followed: in includes installing dependencies, setting firewall rules, etc. – and in the end it just works. But please note, in case you wanna give it a try: it is not ready for production. Not at all. Use virtual machines!

What I did see after the installation was actually rather appealing: a clean, yet modern web interface offering the most important and simple tasks a sysadmin might need in a daily routine: quickly showing the current health state, providing logs, starting and stopping services, creating new users, switching between servers, etc. And: there is even a working rescue console!

Main login view

Default server overview, showing the possible tasks as well as the current health of the system.

Default server view in wide screen browser

Detail view of host name and system basics

Network traffic – a click onto on of the health statistics brings up a more detailed view.

Listing services – here it becomes obvious how much Cockpit actually is build upon systemd.

The log watcher accesses the systemd journal – once again a reason why systemd is a requirement for Cockpit.

Adding a new server to Cockpit.

Two servers are registered and can be accessed in this Cockpit installation.

New users can be created right out of the web interface. Here you see how a freshly created user appears on the system in /etc/passwd immediately.

The rescue shell is rather basic – but lets you call arbitrary commands.

A system restart was triggered through the web interface – even with system message.

And where ever you click you see quickly what the foundation for Cockpit is: systemd. The logviewer shows systemd journal logs, services are displayed as seen and managed by systemd, and so on. That is the reason why one goal – no interference between shell and web interface – can be rather easily reached: the web interface communicates with systemd, just like a administrator on such a machine would do.  <Update> Speaking about: if you want to get an idea of *how* Cockpit communicates with its components, have a look at their transport graphic. </Update> Systemd by the way also explains why Cockpit currently is developed on Fedora: it ships with fully activated systemd.

But back to Cockpit itself: Some people might note that running a web server on a machine which is not meant to provide web pages is a security issue. And they are right. Each additional service on a server is a potential threat. But also keep in mind that many simple server installations already have an additional web server for example to show Munin statistics. So as always you have to carefully balance the pros of usable system management with the cons of an additional service and a web reachable system console…

To summarize: The interface is slick and easy to use, for simple server setups it could come in handy as a server management tool for example for beginners and accessible from the internal network only. A downside currently is the already mentioned limit to the distributions: as far as I got it, only Fedora 18 and 20 are supported yet. But the project has just begun, and will most certainly pick up more support in the near future, as long as the foundations (systemd) are properly supported in the distribution of your choice. And in the meantime Cockpit might be an extra bonus for people testing the coming Fedora Server. 😉

Last but not least, in case you wonder how server management looks like with systemd, Cockpit can give you a first impression: it uses systemd and almost nothing else for exactly that.

[Howto] Firewalld basics

Firewalld is Fedora’s way to provide dynamic firewall properties in Linux. Thus way changes in the firewall configuration are applied immediately, without the need to restart. Additionally, firewalld supports D-BUS and zone concepts.

Firewalld replaced Fedora’s old firewall mechanism with Fedora 18. One of the main motivations for a new firewall system was that the old solution required a firewall restart and was thus breaking all statefull connections at each change. Additionally, Firewalld supports dynamic zones which comes in handy when using it with mobile devices as laptops: you can have different zones, thus different sets of rules, for your work network and for your home network.

Besides, to better integrate the system firewall with other applications D-BUS support was integrated into Firewalld, and the configuration is eased for the user via a GUI and a command line helper which is covered here.

If you want to use Firewalld, it might be a good idea to check on which zone you actually are running:

firewall-cmd --get-active-zone
home: wlan0

It shows the devices and the given zones.

You can list all available zones by:

# firewall-cmd --get-zones
drop work internal external trusted home dmz public block

So, if you want to change a zone on a network for example because you just started your VPN tunnel to your homenetwork, just do it:

# firewall-cmd --zone=external --change-interface=wlan0

There is no return code shown, unfortunately, but you can query the current zone again to see if it worked.

But since we are talking about dynamic firewall changes, the really interesting part is to open and close ports. Another way to look at it would be to allow or deny the access to services. The difference is that a service can be a list of several ports.

As a result, you can query the enabled services (no ports shown), or enabled ports (no services shown), or list all (everything shown):

# firewall-cmd --zone=home --list-services
mdns ipp-client dhcpv6-client ssh samba-client

The story looks different for a zone like external:

# firewall-cmd --zone=public --list-services
ssh

The port query looks just the same, but includes the actual port and protocol:

# firewall-cmd --zone=external --list-ports
3333/tcp

As mentioned above, the safest bet is to always query everything:

# firewall-cmd --zone=external --list-all
external
  interfaces: wlan0
  services: ssh
  ports: 3333/tcp
  forward-ports: 
  icmp-blocks:

As you probably know anyway, if you want to test that the port is actually reachable from the outside, start nc -l 3333 and try to telnet to that port.

But that’s all nothing without the ability, to open and close ports:

# firewall-cmd --zone=external --add-port=2222/tcp
# firewall-cmd --zone=external --list-ports
3333/tcp 2222/tcp

Closing the port is just as easy:

# firewall-cmd --zone=external --remove-port=2222/tcp
# firewall-cmd --zone=external --list-ports
3333/tcp

As you see the dynamic and zone features of Firewalld work pretty neatly. However, I do not see the benefit of Firewalld for server environments. There you usually have no changing connection trust levels thus no requirement for zones, as far as I see. Also, the dynamics might not be that important, so I wonder if it will play any role at all in the long run on servers.

From a user point of view the dynamic command line helper really comes in handy. It would not hurt to add some more status messages to it, but otherwise it just works. And the zones are partially integrated with NetworkManager, so that in the future different trust levels can be chosen by the user without the need to exactly know what that really means in regard to the actual ports.

Last but not least I am not sure where other distributions stand: will they pick it up? I guess it depends on how tight it will be integrated with tools like NetworkManager or the overall desktop environment…

More information about firewalld can be found in Fedora’s Firewalld documentation.