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 | přečteno 26410×
Our first goal was to have minimal system with
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/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/sdb2 for swaps.
/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
/dev/sdb3. Then we create
the RAID-1 array over them and use this array for LVM. We create one volume
vg0) and inside it the logical volumes
var. We left some space in
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.
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
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
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
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
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
/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
the LVM hasn't activated. It should have been activated by
/etc/rc.sysinit. After a brief diagnostics we have discovered,
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.
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
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
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
thought, that only suitable driver for our network devices is
bcm5700, so we had to modify
After manual removal of this kernel module the system collapsed, so we
rebooted the system once more.
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:
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).
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.
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).
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.
Putting Mandrake Linux for AMD64 on server has some advantages and
disadvantages. Its indisputable advantage is quite advanced frontend for
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.