Upgrade your SuSE server

I run a SuSE 11 internet server providing some basic services.
I recently had to upgrade to a new version of SuSE (11.3) and it took my quite some time to do so.
Therefore I am listing here the necessary steps, hoping that the next time I will spend less time on such an upgrade…

Services installed

  • dovecot IMAP/IMAPS Mail Server
  • dovecot POP3/POP3S Mail Server
  • postfix SMTP TLS MTA
  • Apache HTTP/HTTPs Webserver
  • Subversion Repository
  • WebDAV online Disk

Preparations and basic setup

  1. Take the server off-line and make sure no mail arrives. The emails will be queued on the alternate MX and delivered later.
  2. Do the backup (rsync including all deletions)
  3. Dump the installed packes to an XML using yast2 Software Management
  4. Install base software from boot ISO over the network
  5. Setup Networking
  6. Restore /etc/passwd
  7. Restore /etc/shadow
  8. Restore /home in the background

Setup Mail Server

  1. Setup postfix (check possibility to restore /etc/sysconfig/postfix from backup), but do not start
  2. Setup dovecot (restore /etc/dovecot/dovecot.conf), but do not start
  3. Check certificate values in /etc/sysconfig/postfix (or restore from backup)
  4. Create postfix certificates and SSL CA using mkpostfixcert
  5. Edit the config file /usr/share/doc/packages/dovecot/dovecot-openssl.cnf (attention, will be overwritten when upgrading dovecot)
  6. Run /usr/share/doc/packages/dovecot/mkcert.sh
  7. Download and install roundcube mail in /srv/www/htdocs

Setup Apache Webserver

  1. Setup apache2 (check possibility to restore /etc/sysconfig/apache2)
  2. Restore /etc/apache2/vhost.d from backup
  3. Restore /etc/apache2/conf.d/subversion.conf from backup
  4. Generate the following certificates for apache using yast2 (mail, svn, disk)
  5. Export the PEM encoded certificates to /etc/apache/ssl.crt|key/

Setup BIND Name Server

  1. Restore /etc/named.conf from backup
  2. Restore /etc/named.d from backup
  3. Restore /var/lib/named/master from backup

Setup MySQL

  1. Restore /etc/my.cnf from backup
  2. Restore /var/lib/mysql from backup

Setup Subversion

  1. If subversion is the same version (or compatible) just restore /srv/svn from backup
  2. If subversion is not compatible anymore use svnadmin load to load the dump from the backup

There’s noting to do for the WebDAV disk 🙂

After all the configuration files etc. have been restored and the settings in /etc/sysconfig have been checked, run SuSEconfig for the last time and test the mail server.
Unplug from the internet and start postfix and dovecot.
Check if a locally created mail is correctly handled by postfix, amavis and successfully delivered with dovecot.
Also check if the IMAP mbox is created in /var/spool/mail.

If this test succeeds we can restore /var/spool/mail from backup and connect to the internet again.

Now use yast2 to edit the runlevel configuration and make sure all the services are started at boot-time.
Also start them now.

Stored e-mails should no be delivered and correctly handled by the mail server.

Test all the virtual apache servers, webmail, subversion and WebDAV.


maven and canoo webtest pitfall

Today, I spent about 2 hours to find out why our canoo webtests didn’t run anymore after adding the webDAV wagon to our maven build.

The problem was that when adding the webDAV-wagon to your build as an extension, you also get the commons-httpclient dependency to the maven runtime classpath. This wouldn’t be too bad, but the 1.0-beta2 version of the webDAV-wagon depends on commons-httpclient version 2.0.2. That’s way too old for canoo webtest and is also deprecated for almost a year now.

I found out that starting with maven 2.0.9 you don’t need to have an explicit reference to the webDAV-wagon as extension anymore.

E voilĂ ! Suddenly it worked. Maven 2.0.9 also seems to work with version 3.1 of commons-httpclient, the same version canoo webtest depends on.

So, if you get a ‘NoSuchMethodFound’ for HttpConnectionManager.getParams() first check if you’re using the webDAV-wagon extension first.


Tuning Gigabit Ethernet on Mac OS X (10.5)

I recently bought a new NAS (Netgear ReadyNAS Duo) and attached it to my gigabit ethernet network. Unfortunately I only got transfer rates at around 10 MB/s which is really poor. I enabled Jumbo Frames (MTU > 1500) but this didn’t help much. So I did a bit more research and found out that the limiting factor was not only the MTU but the send and receive buffers.
This means my CPU was not able to catch up with the speed of the gigabit ethernet. What I did then was to increase the send and receive buffers for TCP/UDP traffic. É voilĂ ! Now I get at least 35 MB/s. Still not the max a gigabit ethernet can offer, but I’m on the right way. I’d like to see something like 80-90 MB/s. Given the Samsung Disk can do at least 175 MB/s to/from buffer this should be possible.

I use the following parameters in my sysctl.conf:


The buffers are probably too high, I know.