Last call for ….

I haven’t posted anything in a while on this blog, and now I made the decision that this will not change: it is unlikely that this blog will be updated anytime soon. The reason is actually twofold:

Job

I’m working full time as an Open Source/Linux consultant these days – and after work I do not really have the time nor the energy to invest even more time into Open Source (besides the Fedora packaging).

Company’s Blog

I was successful in convincing enough people in our company to start a blog – and I blog there since then, so when I get home I usually already have blogged about whatever comes to my mind.

That means effectively that you will not receive any more new posts here. It hurts my heart and kills kittens, but you can remove the blogfeed. @planets where I might still be listed at: please remove this blog feed as well.

However, if you *do* want to keep up with my thoughts: credativ’s company blog is working quite nice these days. Btw., in case you don’t know, credativ is an Open Source/Linux company and the one behind the Open Source Support Center (OSSC) and the Open Source Support Card (yeah, “catchy” names, I know). They are focussed on Open Source support (Linux-Support, PostgreSQL-Support, etc.) and have offices in DE, UK, US, etc. So the general topics are pretty close to this blog. If you look close you will recognize my style: short italic introduction, eye catcher on the upper right side, special headline markings for Howtos and Short Tips, and so on. Also, the categories are quite the same, and it is actually available in German and English. Also, I am not the only person writing there – one very active PostgreSQL developer keeps blogging there, if I want it or not.

However – it is a company blog, so you will (!) find information regarding the company itself, or newest marketing things. You are warned!

So this is it: the last post. Thanks everyone for wonderful years full of blogging, discussions, news, Howtos and good tips. So long, and thanks for the fish!

Howto: pre-compile KHelpCenter index

The KDE help center contains the handbooks of all KDE programs. Unfortunately, the index is compiled for each user which is sub-optimal in larger deployments.

The Problem

The KHelpCenter is the central place to access the KDE program handbooks. It also offers an option to index all these data to quickly search through them. However, currently this is done on a per-user base and is offered as a dialog once the KHelpCenter is started the first time.

In larger deployments with several users per machine/server or where you have central login servers you might not want your central server to do the same task again and again, for each new user. Therefore it makes sense to a) pre-compile the data and b) configure all your KDE users to access a central directory.

The Solution

The first task can be accomplished by starting the index process manually and let it write to a system-directory:

khc_docbookdig.pl --indexdir=$SYSTEMDIR --docpath=khelpcenter:kde_application_manuals --identifier=kde_application_manuals

Of course $SYSTEMDIR must be replaced with your preferred system directory which is for example on a NFS/Samba server.

Now the user-KDE configuration need to know about the new index files. Since it might even be that some users have already created an index and some not, so the best is to overwrite their configuration without actually modifying anything in their configuration files – which is not a problem with KDE’s Kiosk. Depending on your distribution, your KDE system configuration is somewhere in /etc/kde/ or similar. There the file khelpcenterrc must be created/modified with the following content:

[Search][$i]
IndexDirectory=$SYSTEMDIR
IndexExists=true
ScopeSelection=0

From now on all users will automatically access the index of the system repository – even if they already have created their own KHelpCenter index.

Closing Words

The KHelpCenter is a ncie program – but needs quite some love. Recently apacheLog identified several problems and was only able to fix some of them. Some slightly larger tasks are an integration with Nepomuk/Strigi and the inclusion of the online documentation: Userbase and Techbase. Last but not least it might be worth a look if KHelpCenter could take advantage of QtAssistant.

Finally a last word about the command mentioned above: it only include the KDE handbooks, the man pages might not be included.

Howto: Pimp your kickstart, Part two

Kickstart can be used to automatically set up Fedora/Red Hat installations, but also deploy larger setups of similar systems. In a recent post it was explained how to use boot parameters to flexibly influence the kickstart installation. This post will expand this idea further via remotely provided configuration files.

Part one explained howto use kickstart with boot parameters. While the advatange of this method is that different setup configurations can be stored in one file it also means that the kickstart file can become quite crowded over the time. A way to avoid this is to use shell scripts provided on a server and launch them depending on the boot options.

A NFS/hostname example

In this example most servers just get the same setup, but only few servers are monitoring servers which require very specific additions. Additionally, a NFS server is already available on the net (maybe to deliver the kickstart files), and the machines are distinguished by their hostname.

First, the specific additions need to be placed in a shell script. The shell script(s) are named after the hostname of the corresponding host and are copied to the NFS share. Second, the kickstart file gets a section to mount the NFS share right after the installation. To avoid problems with NFS support in the newly installed machines, the share is mounted right before the default %post section in a special section which has not changed the root yet:

%post --nochroot
mkdir -p /mnt/sysimage/media/nfsshare
mount myserver.com:/nfsexport /mnt/sysimage/media/nfsshare

Afterwards, the normal %post section follows as usual, but has access to the NFS share in /media/nfsshare.

Next, the kickstart file needs a function in %post to first check if the host name is set, if a file of that name exists on the server, and if yes, copy and launch it. This requires of course the preparations explained in part one to filter for the boot parameters.

if test "${myop_hostname+set}" = set ; then
  if [ -e /media/nfsshare/$myop_hostname ]; then
    cp /media/nfsshare/$myop_hostname /root/.
    chmod +x /root/$myop_hostname
    /bin/sh /root/$myop_hostname
  fi
fi

The kickstart installation can can now be called with the hostname as a boot parameter: linux ks=nfs:/myserver.com/ks.cfg myop_hostname=blueserver. If no hostname is given, host-specific configuration is ignored.

Other ways

Of course there is no need to use a NFS server, or a server it all: the different shell scripts can be provided directly on the installation medium, or on a web server. Also, using host based configuration makes it more difficult again to maintain all the different scripts for all the different servers. If the number of servers grow above a certain number the best way would be to manage all the options, scripts and parameters in a database and export host-based configuration files when needed or provide it via ldap.

Extra: Tiny installation

Quite often it happens that people only need small Fedora/RHEL setups. However, even with no arguments in the %packages section a default installation takes quite some space. This is due to the fact that in the default configuration kickstat installs all packages from the base group. A special flag must be set to avoid that. Together with that flag, a base installation requiring “only” roughly 160 packages looks like:

%packages --nobase
openssh-clients
openssh-server
ntp
yum
dhclient
sendmail
man
-system-config-securitylevel-tui

But beware: such installations are really basic and are missing basic tools like which!

Howto: Pimp your kickstart, Part one

In Fedora and Red Hat/CentOS unattended installations are done via kickstart. It is also the tool of your choice if you want to set up several systems in the exact same way. With some simple tricks it can become even more useful.

The kickstart documentation is very detailed and covers the most important install options and flags. However, it is not really flexible – you can create one kickstart file for several servers, but as soon as some details in the setup need to be changed most people create another kickstart file containing that changes.
This makes it harder to maintain the kickstart files and can easily be avoided.

Parameters via command line arguments

Kickstart is usually launched via the boot command line with a string like linux ks=nfs:/myserver.com/ks.cfg. And the boot command line string can be accessed later on via /proc/cmdline – which you can now process further.

For example, imagine you have one set of machines accessing the internet via a proxy, and one set of machines in another network which don’t. You could now define a boot command line parameter like myop_proxy. If it is set to myop_proxy=yes, the %post section of the kickstart file adds the proxy to yum, if the parameter is set to myop_proxy=no, the proxy is not set. Therefore, first the post section would have to read in the command line, sort after the myop_proxy parameter, put it into a text file and source the text file. As a result, the post section, which works just like a typical shell script, now has the variable myop_proxy set to either yes or no. A simple if statement can now check for the value of the variable and add the proxy configuration:

%post
< /proc/cmdline sed 's/ /\n/g' | grep ^myop_ > /tmp/boot_parameters
. /tmp/boot_parameters

if [[ "$myop_proxy" = "yes" ]]; then
  echo "proxy=http://proxy.myserver.com:8080" >> /etc/yum.conf
elif [[ "$myop_proxy" = "no" ]]; then
  echo 'No proxy configured.' >&2
fi

The first line at the begin of the post section is in so far interesting as it makes sure that all parameters beginning with myop_ are filtered and afterwards sourced. So more parameters for more options can be defined, for example to distinguish normal machines from setups in a DMZ where some packages should be removed after the basic installation:

if [[ "$myop_type" = "DMZ" ]]; then
  yum -y remove httpd *samba*
else
  echo 'This machine is not in the DMZ.' >&2
fi

Extra: Pre-testing additional kickstart commands

The best way to test scripts and commands which should be triggered by the parameters is to launch an installation with the yet unmodified kickstart script, wait until it is finished, and then switch to the terminal on Alt+F2. With a chroot /mnt/sysimage an environment can be created just like the one in the normal post section. Now everything which should find its way into the kickstart script can be tested. This might be handy to avoid too many restarts to test changes to the kickstart routines.

Extra: Extended log file

In case you take advantage of the options you might also want to have a look at the log file. This can easily be done via:

%post
(
echo "Here is the place for usual post commands." >&2
...
) > /root/post_install.log 2>&1

This trick is also mentioned in the above linked RHEL documentation.

Other possible ways

These options are not the only way to dynamically modify and personalize kickstart scripts. Other possible ways are to use ldap: kickstart can query an ldap-server and hand over system data to get back further details, options or scripts. Also, via DHCP kickstart files depending on the IP can be provided, and last but not least kickstart can also query a http server to hand it over a kickstart file fitting to the network MAC address.

Howto: Find matches for udev rules

Recently I bought a new keyboard and wondered if I can trigger actions via udev when the keyboard is plugged in. For that, however, it must be known how to create udev rules matching the keyboard in the first place.

To write udev rules the most important part is to match the device you want to handle with the rules. While hardware fixed in the computer might be easy, the rest usually isn’t. For example, you can trigger something when keyboard xyz of manufacturer abc is plugged in – but for that you must now where to find which information and how to present them to udev.

This can be done with the program udevmonitor. It informs you of newly plugged in hardware detected by udev:

# udevmonitor
...
UEVENT[1217720129.155386] add      /devices/pci0000:00/0000:00:1d.0/usb5/5-1 (usb)
UEVENT[1217720129.155440] add      /class/usb_endpoint/usbdev5.9_ep00 (usb_endpoint)
UEVENT[1217720129.157973] add      /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0 (usb)
UDEV  [1217720129.166782] add      /devices/pci0000:00/0000:00:1d.0/usb5/5-1 (usb)
UDEV  [1217720129.171948] add      /class/usb_endpoint/usbdev5.9_ep00 (usb_endpoint)
...

The next step is to use these info to gather even more information to actually create a rule: the devices path is interesting an contains more information. So we have a look at it with yet another udev tool: udevinfo

# udevinfo -a -p /sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1
...
  looking at device '/devices/pci0000:00/0000:00:1d.0/usb5/5-1':
    KERNEL=="5-1"
    SUBSYSTEM=="usb"
    DRIVER=="usb"
    ATTR{dev}=="189:522"
    ATTR{configuration}==""
    ATTR{bNumInterfaces}==" 2"
    ATTR{bConfigurationValue}=="1"
    ATTR{bmAttributes}=="a0"
    ATTR{bMaxPower}=="100mA"
    ATTR{urbnum}=="1541"
    ATTR{idVendor}=="046a"
    ATTR{idProduct}=="0023"
    ATTR{bcdDevice}=="0032"
...

This shows us several attributes we can use in the udev-rules. The data also match with the data given by lsusb, btw.:

# lsusb
...
Bus 006 Device 001: ID 1d6b:0001
Bus 005 Device 011: ID 046a:0023 Cherry GmbH Cymotion Master Linux Keyboard
Bus 005 Device 001: ID 1d6b:0001
...

So now a udev rule can be created with the data above. In case of the keyboard the rule could for example be:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="046a",ATTRS{idProduct}=="0023",ACTION=="add",RUN+="/usr/local/bin/mykeyboard.sh"

In this case udev launches the program mykeyboard.sh when a the usb subsystem recognizes a device from the vendor 046a with the product id 0023. This can of course be further fine grained, depending on the needs.

The rule itself must afterwards be copied to the right folder and must be given a number according to the priority regarding other rules. On a Fedora system the udev folder is /etc/udev/rules.d, and a typical udev rule name could be 62-keyboard.rules.