Mirror Server

Yesterday I upgraded our  mirror server to Fedora 17. After having neglected the system for some time it still ran Fedora 14. Fedora 14 was extremely stable and the uptime was almost 1 year. Such large uptimes are usually a sign of a lazy admin because with the frequency of kernel updates the system should have been rebooted much more often and Fedora 14 is now almost half a year EOL. The update to Fedora 17 is the first update I did not want make using yum because of the changes necessary for UsrMove. I burned the DVD (actually Martin did it) and even looked at the installation guide. In the installation guide it says:

Before upgrading to Fedora 17 you should first bring your current version up to date. However, it is not then necessary to upgrade to intermediate versions. For example, you can upgrade from Fedora 14 to Fedora 17 directly.

Great, I was already afraid I had to do two upgrades. After dumping the postgresql Database (I even thought about this) I rebooted using the DVD and it started to search for previous installations. It found a Fedora 14 installation and said that it cannot upgrade Fedora 14 to Fedora 17. Just as I expected it. Now Silvio was so nice to burn a Fedora 16 DVD and I started the Fedora 16 upgraded but this time the installer did not even offer the possibility to upgrade and the only possibility was a new installation. After using the shell the installer offers on another VT I found out that we have to many partitions. Not sure what the installer exactly does but it was not able to handle a separate partition for /var and /var/lib which we have been using. It was not able to find the RPM database and aborted the upgrade process. So I increased the size of the LV containing / and copied /var,/var/lib and /usr (because of UsrMove) to the / partition and finally the upgrade could start. After the upgrade finished I inserted the Fedora 17 DVD this upgraded finished without any problems.

After rebooting in the freshly upgraded Fedora 17 I saw that the upgraded to systemd did not went as smooth as is should have been. All service which were converted to systemd unit files were stopped and disabled. Only the jabber server was running (which is my package and has not been converted to systemd (but it will be for Fedora 18)). So I checked all the configuration files and started and enabled one service after another (has been a good systemd training).

After 6 hours most services were running again and the mirror server was happily serving files.

Notebook

Today I also upgraded my notebook from Fedora 16 to Fedora 17. Using the Fedora 17 DVD from above it upgraded the system without any obvious problems. After rebooting into Fedora 17 I inserted my notebook back into the docking station (two external monitors connected via DVI) and was shocked that the monitors were no longer detected. The gnome-shell process was using 150% of the CPU and the CPU temperature was around 98°C (usually around 55°C). So at first I panicked and wanted Fedora 16 back but then I found at that all I needed was an updated xorg-x11-drv-intel. After a yum update --enablerepo=updates-testing xorg-x11-drv-intel-2.19.0-5.fc17 everything was back as good as Fedora 16 (and better of course).

I finally have mutt configured in such a way that it first tries to display the plain text part of a mail and only the HTML part if there is no plain text available. For years I had mutt configured to display HTML mails using lynx but it was displaying the HTML part even if there was plain text available.

To display HTML mails I was using auto_view text/html in my .muttrc like it is described everywhere with the following corresponding entry in my .mailcap:

text/html;      lynx -dump %s; copiousoutput; nametemplate=%s.html

The problem with this setup is that it displays the HTML part of a mail even if there is a plain text part available. So I had auto_view text/html disabled for most of the time and edited the configuration file manually to enable it again for the rare cases in which I received a HTML only mail.

But as this is mutt and almost everything can be configured I finally searched and found a solution:

auto_view text/html
alternative_order text/plain text/html

If the message has a plain text part and a HTML part mutt shows me the plain text part, but if there is only a HTML part available I get the HTML converted to plain text. Exactly what I always wanted.

Fedora. Nobody expected anything else (of course).

The first one and a half days since the release of Fedora 9 we are maxing out our bandwidth again. Today we already pushed more than 5.5TB and it looks like we will get close to transmitting 7TB on one day. This is much more than during the last Ubuntu release.

With the help of munin I can again provide a nice bandwidth graph:

The small dent, just after the start of the release, is due to the fact that I had to restart apache because of our cache drive. We are using a fast hard disk to reduce the load on our main RAID as cache, but it seems that it somehow cannot handle over a thousand simultaneous accesses and that is why I disabled that cache drive (which should have improved the situation and not worsened it). I can also prove that the Fedora release is the reason for all the traffic:

We always thought our mirror server is connected with 2 GBit/s (two times an e1000 card using bonding mode=6), but the current Ubuntu release proved that somewhere along the way to the Internet there must still be something that limits us to 1 GBit/s. The following diagram shows this pretty clearly:

Now we only need to find out where and if it is something that we can fix or if we need help from our provider.

Maybe we can fix it before the release of Fedora 9 so that we finally can transmit more than 1 GBit/s.

As I wanted to make a new kover release I thought I could try to move my code to git. The first step was to copy the code from cvs to a local git repository:

• git-cvsimport -i -v -d :pserver:adrian@cvs:/cvs/kover -C kover.git kover

I was a bit surprised that the newly created directory kover.git was empty except for a .git directory. Without much knowing what I was doing I typed git-checkout and it listed all available files but my directory was still empty. So I tried git-checkout .. This time there was no output but all my files were now in my directory so that I could start doing changes.
Committing, adding and removing files is easy and works just like expected (git-commit, git-add, git-rm). The steps to publish the git repository, however, were not as easy. The following commands were necessary to make it work for me:

• git clone --bare . git

• touch git/git-daemon-export-ok

• cd git/

• git --bare update-server-info

• chmod a+x hooks/post-update

or with newer versions of git the following mv instead of the chmod

• mv hooks/post-update.sample hooks/post-update

• cd ..

• rsync -avP -e "ssh" git/ lisas.de:/var/www/html/kover/git

From this point on it was now possible to access the repository through http with git clone http://lisas.de/kover/git. To push my changes to the repository on the server I use git-push lisas.de:/var/www/html/kover/git master. It was necessary to install git-core on the server so that git-pushwould work without errors. To pull changes from the online repository I use git-pull http://lisas.de/kover/git master.

There is probably no real reason to use git because up until now kover was mainly developed by me and it will therefore not profit from the distributed features which are the main advantages from git but I wanted to play with the same toys as all the cool kids ;-).