ARCHIV

Experience from installation Mandrake 10.0 Official on AMD Opteron

We have decided to test several available distributions on our dual-opteron server (details e.g. here. One of the distributions we have chosen to test was Mandrake 10.0 Official pro AMD64.

5.10.2004 17:00 | Petr Houštěk | Články autora | přečteno 29406×

Preparation

Our first goal was to have minimal system with urpmi operational on specific (and a little exotic) disk layout. The next step we wanted to have security updates functional, so that we could install and configure services.

First, I will describe the disk layout. We have not a hardware RAID controller, so we use the linux software raid. We put the root partition to the RAID-1 array created on the first partitions of two identical SCSI disks (/dev/sda1, /dev/sdb1). The swap partitions follow. Unfortunately it is not possible to put them on software RAID-1, because it may cause a kernel deadlock (the physical memory is full, it is necessary to swap, but to do this the MD driver needs some memory). So we use /dev/sda2 and /dev/sdb2 for swaps.

We put /home and /var to special partitions. To make backups easy and to ensure the flexibility we want to put them in the LVM over RAID-1. So we allocate the remaining space on the SCSI disks to partitions /dev/sda3 and /dev/sdb3. Then we create the RAID-1 array over them and use this array for LVM. We create one volume group (vg0) and inside it the logical volumes home and var. We left some space in vg0 in order to create snapshots, resize existing volumes (if needed), etc. The third disk in the system is a big IDE disk intended for the backups and storage of large and rarely used data.

Let's see how this layout can be realized in Mandrake 10.0.

Installation

You can get Mandrake 10.0 Official for AMD64 by buying the boxed version or by downloading the official images of installation CDs, which are available for members of Mandrake club (silver and better). Thus the installation was done from the CDs. In the beginning of the installation we could choose from graphical, text and expert graphical installation methods.

We don't possess a mouse at our server, so we have chosen the text installation method. Unfortunately it failed completely during the disk partitioning (the text version of program DiskDrake crashed each time). So we had to try the expert graphical method. Now the graphical version of DiskDrake worked properly. However after the creation of root partition over RAID-1 array we were notified, that no bootloader can handle that and the special /boot partition has to be created.

Don't be confused, this screenshot was taken on MandrakeLinux 10.0 Official, but the name Community remained.

Of course, this is not necessary, for example lilo has an excellent support for it. Nevertheless we have temporarily changed one swap partition to /boot partition. After partitioning the disk you can have the partitions formatted. As far as you haven't got any special requirements it is fine, otherwise you have to switch to a text virtual console and reformat the partitions (you can do this after the first format by DiskDrake, because before it mkfs.* is not loaded into memory). Then we have selected the minimal selection of packages with urpmi and the installator began to copy the packages. Unfortunately the process was interrupted, so we were forced to repeat all steps.

However during the second installation DiskDrake announced error "Illegal division by zero" while attempting to create LVM. Then the system halted. After several unsuccessful trials we have abandoned the idea of creating LVM during the installation and we installed the system on the root partition.

After successful start of the new-installed system we have created LVM manually. First we initialised /dev/md1 as a physical volume and afterwards we founded the volume group vg0 on it.

pvcreate -M2 /dev/md1
vgcreate -M2 vg0 /dev/md1
vgchange -a y

Finally we created sections home and var on vg0 and filesystems there.

lvcreate -L 13G -n home vg0
lvcreate -L 13G -n var vg0
mkfs.xfs -L home -i size=512 /dev/vg0/home
mkfs.xfs -L var -i size=512 /dev/vg0/var

Then we modified /etc/fstab and moved the content of /var and /home to LVM sections. Next problem happened when we attempted to get rid of devfs. (This feature has never worked, is now obsolete and will be replaced by udev in future). However after switching off devfs the LVM hasn't activated. It should have been activated by /etc/rc.sysinit. After a brief diagnostics we have discovered, that without devfs the command vgmknodes ends with non-zero exit code, so that the needed command to initialise the LVM vgchange -a y doesn't execute. After removing the useless command vgmknodes the LVM were initialised. However it is elusive, that this bug wasn't discovered during the QA tests.

Updates and local repository

We have managed to install the base system, so we have started to configure urpmi and to make updates working. The Mandrake 10.0 Official binary packages for AMD64 are available on no mirror and we don't want to change CDs during the installation of additional packages, so we have copied all packages to harddisk, where we have created a local urpmi repository with the help of genhdlist command. Next we have replaced the CDs by the local repository and have added official updates (we used official czech mirror mandrake.contactel.cz). Update passed almost with no problems (during the first run of urpmi --update --auto-select an error occurred, but we failed to reproduce it). The we have updated the kernel, rebooted the system and shut down unneeded services (like hardware autodetection).

Kernel

Time for first more serious test :) Let's try to compile the linux kernel. We do this mostly for curiosity, but with a bit effort we can find even some more rational reasons -- e.g. we want to get rid of initrd, compile MD driver static and remove a lot of things from distribution kernel we don't need. This test was successful -- we downloaded the up-to-date version of distribution kernel, configured it, compiled it (make -j 4), installed it, created /boot on the root partition and rebooted the server. The boot from lilo, RAID autodetection and other magic connected with boot passed with no errors. There were only one accident. We wanted to replaced 3rd-party driver bcm5700 for our Gbit network devices with kernel driver tg3, but the network configuration tool (apparently with "help" of lspcidrake) thought, that only suitable driver for our network devices is bcm5700, so we had to modify /etc/modprobe.conf. After manual removal of this kernel module the system collapsed, so we rebooted the system once more.

Services

After successful recompilation of kernel, we have started to test basic network services. Some services were already configured and worked without any serious troubles, other started to work after some specific actions. Among the services we tested and were working with no problems belonged these services:

• mail transport agent postfix 2.1.0
• ftp server vsftpd 1.2.1
• ssh server openssh 3.6.1p2
• super server xinetd 2.3.13
• current version system cvs 1.11.11
• dns server bind 9.2.3

Basic configuration of these daemons were sufficient, we were pleased, that bind were started under non-privileged user and configuration counted with running in chroot.

On the other hand some services weren't quite problems-proof. E.g. both tested databases - MySQL and Postgresql had some troubles. To be concrete - during the installation of Postgresql the initialisation of database ring failed. During following manual installation all went fine and the database worked perfectly. MySQL worked after installation, however there were no supplied configuration file (not even commented), which is in the least remarkable.

One of the key server services is certainly Apache http server (in Mandrake Linux masked under pathetic name Advanced extranet server or ADVX). The goal of this project is to prepare apache and connected software in a form, that can be used in all possible situations. This comes with rather specific compilation with maximal use of modules, modular configuration (many things can be affected only by presence of specific file). That is the fair-minded description. (In my personal opinion I wonder why Mandrake considers its work so important and gives a new name to Apache, when all the distributors do almost the same adjustments. Marketing is omnipresent ...)

We tested ADVX on several virtual servers with static pages, dynamic generated pages by php, mod_perl and generic cgi scripts. Unfortunately there were crashes of several workers and during one test even the whole server crashed. The crashes occurred when the server was fully loaded and the reasons were various - from configuration defects to quite grave memory leaks in ADVX. We were successful in eradicating most of the problems, however the priority of Mandrake developers is now preparing of version 10.1 and support (of actual official version) is only the secondary priority (I am not referring to the security updates. They work very well).

Software out of distribution

Owing to fact, that Mandrake Linux is designed to be a desktop oriented distribution, some server related software is missing in official resources. First one checks contrib. However it has some disadvantages - e.g. the binary contrib packages for AMD64 are not available. Then Mandrake has essentially no support for contrib and quality of packages is very various. There are more unofficial sources, but most packages from these sources are compiled only for i386. It is possible (but in certain cases with some problems) to recompile SRPM packages designed for other distributions. If one gives over the packaging system, one can use software directly from mainstream. Surprisingly it is in some cases easier and faster way than recompilation of contrib packages and their debugging.

From the software out of the official distribution we have user e.g. GNU Arch (the package is called tla). We have with no problems rebuilt it from contrib. On the other hand tomcat5 from contrib was not usable and instead of searching its imperfections we have decided to use mainstream version. For testing purposes we wanted to install FirebirdSQL database. Unfortunately there are almost no packages for it and in the current version (before project Vulcan is finished and integrated) Firebird in SuperServer mode works only in 32bit mode and uses only one CPU. However we managed to rebuilt it (with these limitations). This could be done because Mandrake is so-called bi-arch (there are present utilities and libraries for both AMD64 and x86 applications).

Java

In distribution there is Java RE and SDK in version 1.4.2 by Blackdown, which was in the time of the distribution release only available version suitable for AMD64. Unfortunately there is not a stable release of Java yet, so it is not suitable for run of large applications (like mentioned tomcat). It works well only with various 64-bits java-applets in 64-bits mozilla. With 32-bits version of Sun Java tomcat was running with no problems.

Conclusion

Putting Mandrake Linux for AMD64 on server has some advantages and disadvantages. Its indisputable advantage is quite advanced frontend for rpm - urpmi, that really makes administration of packages easier. On the other hand the short lifetime (the development is 6 months long) is a big disadvantage for server purposes. Than the support is quite short as well (only one year, but you can buy a corporate version, which has longer support). The figure of problems, that need manual solving, is (comparing to server standard) quite big. It is done because Mandrakesoft often chooses not quite debugged and tested new versions instead of older versions. On the other hand you get a distribution with actual software and well working security updates.

Verze pro tisk