Ansible package moved from EPEL to extras

A few days ago the Ansible package was removed from EPEL and many ask why that happened. The background is that Ansible is now provided in certain Red Hat channels.

What happened?

In the past (pre-2017-10) most people who were on RHEL or CentOS or similar RHEL based systems used to install Ansible from the EPEL repository. This way the package was updates regularly and it was ensured that it met the quite high packaging standards of the EPEL project.

However, a few days ago someone noticed that the EPEL repositories no longer contain an Ansible rpm package:

I'm running RHEL 7.3, and have installed the latest epel-release-latest-7.noarch.rpm. However, I'm unable to install ansible from this repo.

This caused some confusion and questions about the reasons behind that move.

EPEL repository policy

To better understand what happened it is important to understand EPEL’s package policy:

EPEL strives to never replace or interfere with packages shipped by Enterprise Linux.

While the idea of EPEL is to provide cool additional packages for RHEL, they will never replace anything that is shipped.

Change at Red Hat Enterprise Linux

That philosophy regularly requires that the EPEL project removes packages: each time when RHEL adds a package EPEL needs to check if they are providing it, and removes it.

And a few weeks ago exactly that happened: Ansible was included in RHELs extras repository.

The reasons behind that move is that the newest incarnation of RHEL now comes along with so called system roles – which require Ansible to execute them.

But where to get it now?

Ansible is now directly available to RHEL users as mentioned above. Also, CentOS picked up Ansible in their extras repository, and there are plenty of other ways available.

The only case where something actually changes for people is when the EPEL repository is activated – but the extras repository is not.

[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.

[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.