Friday, September 23, 2011

RPM dependency trees

Recently I wondered what the dependency tree for Aeolus looked like in Fedora. I knew we had a whole host of dependencies, but I thought it would be instructive to see it visually.

This has been mentioned in other blog posts in the past, but the basic procedure to do this on Fedora is:

# yum install rpmorphan graphviz
$ rpmdep -dot aeolus.dot aeolus-all
$ dot -Tsvg aeolus.dot -o aeolus.svg

The rpmorphan provides the rpmdep binary. The rpmdep binary is a perl script that runs through the RPM dependency information, outputting one digraph node per-line. Then we use dot (part of the graphviz package) to take that digraph information and generate an image out of it. In the above example I made it generate an SVG, but you can have it output PNG, JPEG, PDF, etc. The full list of what dot can do is here: http://www.graphviz.org/doc/info/output.html

Thursday, September 15, 2011

Oz 0.7.0 release

I'm pleased to announce release 0.7.0 of Oz. Oz is a program for doing automated installation of guest operating systems with limited input from the user.

Release 0.7.0 is a bugfix and feature release for Oz. Some of the highlights between Oz 0.6.0 and 0.7.0 are:

  • Ability to use the "direct initrd injection" method to install Fedora/RHEL guests. This is an internal implementation detail, but can significantly speed up installs for Fedora or RHEL guests. (thanks for the tip from Kashyap Chamarthy)

  • Support for Fedora-16 (thanks to Steve Dake for help in making this work)

  • Use the serial port to announce guest boot, rather than a network port. This makes it so we no longer have to manipulate iptables, and gets us one step closer to having Oz run as non-root

  • (for developers) Re-written unittests in python for speedier execution

  • (for developers) Additional methods in the TDL class to merge in external package lists (thanks to Ian McLeod)


A tarball of this release is available, as well as packages for Fedora-14, Fedora-15, and RHEL-6. Note that to install the RHEL-6 packages, you must be running RHEL-6.1 or later. Instructions on how to get and use Oz are available at http://aeolusproject.org/oz.html

If you have any questions or comments about Oz, please feel free to contact aeolus-devel@lists.fedorahosted.org or me (clalance@redhat.com) directly.

Thanks to everyone who contributed to this release through bug reports, patches, and suggestions for improvement.

Thursday, September 8, 2011

New required kickstart line in Fedora 16

Just a quick note for anyone looking at Fedora-16. From Fedora-16 forward, you need a new line in your kickstart that looks like:
part biosboot --fstype=biosboot --size=1

I'm honestly not sure what this is exactly needed for, but unattended kickstart installs will not start without it. There is a bit more information at https://fedoraproject.org/wiki/Anaconda/Kickstart

Tuesday, September 6, 2011

Services and systemd

I spent some time last week poking around systemd and trying to figure out how certain things work. I can't claim to be an expert yet, but I did uncover some things that I found to be very useful.

If you try to start a service on a machine with systemd (Fedora-15, for instance), it actually looks different then with a traditional SysV style init.

SysV:

[root@localhost ~]# service mongod start
Starting mongod: [ OK ]
[root@localhost ~]# service mongod stop
Stopping mongod: [ OK ]
[root@localhost ~]# /etc/init.d/mongod start
Starting mongod: [ OK ]
[root@localhost ~]# /etc/init.d/mongod stop
Stopping mongod: [ OK ]
[root@localhost ~]#

Systemd:

[root@localhost ~]# service mongod start
Starting mongod (via systemctl): [ OK ]
[root@localhost ~]# service mongod stop
Stopping mongod (via systemctl): [ OK ]
[root@localhost ~]# /etc/init.d/mongod start
Starting mongod (via systemctl): [ OK ]
[root@localhost ~]# /etc/init.d/mongod stop
Stopping mongod (via systemctl): [ OK ]
[root@localhost ~]#

"(via systemctl)" is a small but important change to how services are launched. With SysV-style scripts, the scripts are executed more-or-less directly from the bash shell they are launched from (the "service" binary does a little more in terms of cleaning up the environment, but it still ends up exec'ing the script in the end).

With systemd this all changes. One of the first things nearly all initscripts do is to source /etc/init.d/functions. On a systemd-enabled system, the very first thing that /etc/init.d/functions does is to execute systemctl and then exit (ignoring the rest of the initscript). What systemctl does is to put a message on dbus asking for the service you specified to be started. systemd itself is listening on dbus; when it sees a message like this, it picks up the message and proceeds to act on it. It first looks to see if there is a native systemd unit file for this service; if there is, it starts the service according to the native unit file and returns status to systemctl, which returns status to service. If there is no native systemd unit file, it then looks in /etc/init.d for a legacy script. If one is found, then it fork and exec's that script, and returns the status to systemctl, which returns to service.

This leads to one of the most visible issues with systemd, in that there is no output if the initscript fails. That is, if you are using a legacy style initscript and you are used to certain output being shown when something fails, it may not be shown anymore since that output was consumed by systemd itself and not returned to systemctl.

One way to deal with this is to skip the redirect from service to systemctl. There are different ways to do this depending whether you are using the "service" binary or if you are executing the script directly. If you are using the service binary, it understands a new flag to skip redirection to systemd:
service --skip-redirect foo start
If you are directly executing the initscript, you need to pass an environment variable:
SYSTEMCTL_SKIP_REDIRECT=1 /etc/init.d/foo start