Short Tip: Kill all user processes

I use the kill command quite often to kill processes left over – the most common usage is actually when I log into a machine via ssh -X and start a KDE 3.5.x program. Quite some processes will remain running afterwards (dcop, kdeinit, etc.) and will not shut down for quite some while.

I’m used to ps -aux|grep kde in such a case to get the process numbers and kill these with kill -9 PID usually, but for several processes this might take some time. It’s faster to kill just all processes which belong the the user of the kill signal:

kill -9 -1

Keep in mind that you will also kill the konsole you are in right now!

Yet again a tip to make an every day job just a little bit easier.

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.

Short Tip: htop, a top alternative

Everyone administrating Linux needs the program top once in a while. However, I never really grew accustomed to that program and always found it hard to use. Recently, I came across a very usable but still simple alternative: htop.

What I actually liked most is that – in contrast to top – you can navigate up and down the process list with the arrow keys. Additionally, the most important configurations can be accessed with the keys F1-F10 – and the function of each key is also displayed. The program is in general very self-explanatory and there will hardly be the need to open the help files.

Last but not least it has cool bars showing the system performance – you don’t have to look at long numbers to get the idea

The program is available on Fedora and almost all other Linux distributions.

VirtualBox 2.0

SUN released a new major release of their virtual machine software VirtualBox. Highlights in this release are 64bit guest support, a new GUI and also an enterprise subscription model.

The new release was announced today and follows the bugfix version 1.6.6 which was released just days ago. According to the changelog the main highlights are:

• 64 bits guest support (64 bits host only)
• New native Leopard user interface on Mac OS X hosts
• The GUI was converted from Qt3 to Qt4 with many visual improvements
• New-version notifier
• Guest property information interface
• Host Interface Networking on Mac OS X hosts
• New Host Interface Networking on Solaris hosts
• Support for Nested Paging on modern AMD CPUs (major performance gain)
• Framework for collecting performance and resource usage data (metrics)
• Added SATA asynchronous IO (NCQ: Native Command Queuing) when accessing raw disks/partitions (major performance gain)
• Clipboard integration for OS/2 Guests
• Created separate SDK component featuring a new Python programming interface on Linux and Solaris hosts
• Support for VHD disk images

A main part of this release seems to be Mac OS X support, which is a bit surprising given that it is not the first or second OS usually used in larger virtualization setups.
Besides it seems to be a bit strange to code a native Leopard interface when Qt 4 is used anyways: Qt 4 has close-to-perfect integration with Mac OS X, and since it is used for the Windows- and the Linux-Version it would make live much easier to use it for the Mac OS X version as well. I wonder what the reasons behind that decision are.

Anyway, the release also comes along with a couple of fixes so a download makes pretty much sense. Btw., the manual was also updated and is as usual worth a look.