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!

Moving on: 64bit Linux, PulseAudio, Fedora 10 and so on

With the release of Fedora 10 I took the opportunity to finally switch over to 64bit Linux – including the proprietary stuff like Flash, Skype, and so on. Also, Fedora 10 itself had several rather pleasing surprises for me.

I already used Fedora 10 since it’s Beta release. However, recently I decided to re-install it, this time in 64bit, and check how that would go. Also, since I had some rather strange problems and performance issues I wondered if a re-install would fix them.

64bit in General

Switching from 32bit to 64bit on an operating system is a huge and complicated task involving effectively all larger applications. This can e a real pain – unless you have an operating system where all software usually supports 64bit anyway. This is the case with most open source operating systems and therefore also with Linux. So grabbing the 64bit image and installing it was just like grabbing the 32bit image. In case of Fedora the download link offered by default was 32bit, but 64bit was just a click away. I wonder when that will change.

There are numerous advantages and disadvantages regarding 32bit and 64bit, for a first introduction start with the Wikipedia article.

Flash

The problems regarding 64bit arise when you deal with non-Open Source software: this might only be provided as 32bit. In case it depends on any other library, the system must provide these libraries in 32bit and 64bit. While on RPM systems this is not a problem at all, this can be rather problematic when browser plugins are 32bit only, because then the browser needs to be 32bit only as well, the same is true then for all other plugins, and so on. There are wrappers to deal with that, but these are sub-optimal.

Luckily, Adobe has now released a 64bit Alpha version of their Flash player. While it is still missing several features and is not even provided as a rpm or deb file, in my first tests it worked without problems. As a side note, the 64bit versions for Windows and Mac OS are still not out there – Linux is a clear technology and development pusher here!

For the sake of completion (and since someone would point it out in a comment anyway), there are also free (as in FLOSS) alternatives to the Flash player – which are available in 64bit for quite some time now, of course.

Skype

Another issue is Skype – this is not provided as a 64bit version at all (bug report). For Ubuntu users there is at least a 32bit version modified for easy installation on 64bit systems. Btw., hardly anyone seems to know that, even the German Ubuntu wiki doesn’t mention that at all.

Anyway, that doesn’t help the Fedora community anyway – but since Fedora runs on RPM installing all the compatibility libraries is just a question of hard disk space:

yum --nogpgcheck localinstall skype*rpm
yum install alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386

That’s it. In my tests Skpe indeed worked, even a video test image was shown although I haven’t actually made a real video call. Also, I had problems with the microphone, but that might be due to problems with PulseAudio. I appreciate any tips on that issue.

PulseAudio

Well, PulseAudio is a difficult thing. It has a rather strong community and people are making sure it comes up everywhere and works everywhere like it should. However, while I read all the rather long papers and documents why I should need PA, nothing of these papers really stuck, and I always wonder why it is really needed – apart from the more esoteric reasons that Alsa is not suitable for the future. Besides, I do wonder if the Alsa guys would say the same.
Additionally, in my first tests PA worked just fine – under Gnome, but not in KDE. So my first step after installing Fedora since my first contact with PA was always to remove PA.

But I always tend to give things another try, and this time I didn’t remove it. And indeed, almost everything works, and I haven’t even met a delay yet. It all just works, even on KDE with its Phonon!

So it looks like PA finally fits in well. Now what I only need some ideas what to do with it Seriously, what I would appreciate to see is a simple one sheet drawing with all the usual suspects of the Linux audio blob (from Phonon over xine down to Alsa) to see where PA fits in and what it does there.

KDE, Nvidia and performance

Fedora 10 now includes KDE 4.1.3 (included in the updates), and together with RPM Fusion Nvidia drivers are just a

yum install kmod-nvidia

away. While I had trouble with this way with the beta version, and general serious performance problems with the drivers installed manually, it turned out that with Fedora 10 final everything works like a charm – fast and snappy!

I am slightly surprised and wonder what was wrong with my Fedora 10 Beta setup. But on the other hand, my work machine is running Kubuntu 8.10 and there the performance is similar fast. So to me it looks like the days of slow KDE 4.x on Nvidia hardware are finally over, given that the drivers are the newest stable ones and KDE is of version 4.1.3.

Fedora’s encryption

This time I decided to not go with a full hard disk encryption, but rather with a home disk encryption. And while I still dislike Fedora’s disk druid for not letting me chose the disk setup in detail I appreciate that clicking a checkbox was all I had to do to activate the home partition encryption. It is even nicely integrated with the boot process.

Overall impression

The overall impression of Fedora 10 is very good. Most bugs I encountered running the Beta version are fixed – except for a strange coding problem, but I will survive that one.

Also, my first move into the lands of 64bit are also far less complicated than expected. Your mileage may vary, depending on the used proprietary software, but then again kvm might be a solution to work around that problem.

RPM Fusion enters testing state

RPM Fusion, a merge of several former Fedora 3rd party repositories providing licence/patent problematic packages, has entered the public testing state. Fedora Rawhide users can now start using it, and the brave among the Fedora 9 and Fedora 8 users can also help testing.

RPM Fusion was announced more than a year ago and is the attempt to merge several of the many existing 3rd party repositories for Fedora (Dribble, Freshrpms,. livna). The idea of the common repository is to enhance the compatibility as well as avoid duplication – in the former time many packages were provided by more than one repository. The aim of the new RPM Fusion is however just the same as it was for the original repos: provide high quality packages of software which cannot be part of Fedora due to licence/patent problems.

There was a lot of development going on in the background, but RPM Fusion wasn’t ready for Fedora 9 unfortunately – there was just too much to do: importing the packages, sorting out incompatibilities, creating a common build- and mirror-system, etc. Now most of the work is done and the new repository is ready for testing – more details can be found in Thorsten Leemhuis’ blog post. There you will also find ready-to-install repository packages.

With the new repository the situation for users regarding mixed repositories and the possible incompatibilities will hopefully improve a lot. Also, new users don’t have to make a choice between the repositories. And last but not least, with a common and clear infrastructure RPM Fusion will hopefully attract more users to submit their packages to the project so that RPM Fusion grows even more.

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.