Tag: Free Software

Gentoo on a xSeries 235 Server

Yesterday, one of the harddisks (or was it the SCSI-Controller – it does not matter…) of our very old, self-assembled developement/fileserver went down. As we had backupped the important data and I had a spare PC running Linux (the multimedia machine I wrote about here), getting a working environement was a matter of about two hours (one I used up trying to get the old server to boot again).

Anyway: We deceided that it was time to move away from self-assembled machines to something more professional (and hopefully more reliable), so we ordered a IBM (we really like those machines – great support, long warranty and rock-solid) xSeries 235 machine which arrived today.

I deceided to install Gentoo Linux on the machine as it will mostly be used as my developement server (and as a windows-fileserver for our data), so eventual downtimes do not really matter (but latest versions of the installed software are important) – a nice testbed for this distribution until I roll out production machines running Gentoo.

Besides the hardware-RAID5 the new server had built in, we plugged an old 120GB IDE drive to be used as storage area for not-so-important files (read: music, temporary files,…) – additionally it contained all the current developement work, so I had to copy it’s contents down to the new virtual RAID5 drive.

Installing was quite easy, but unfortunatly, the current gentoo-sources kernel (2.4.20 – heavily patched) does not support the DMA-Mode for IDE-Devices on the onboard chipset (ServerWorks something), so copying about 30 GB of data from the IDE drive to the RAID was not funny and neither was doing anything on the server when transfers to the IDE drive where running. It was slooow!

Installing a current 2.4.22 vanilla-sources kernel solved the DMA-Problem but raised another: The xSeries 235 uses a Broadcom bcm5700 Gigabit Ethernet chipset which is not supported under a vanilla kernel. Of course, I forgot to patch the driver in before I rebooted the newly created kernel which forced me to go down to the basement, compile the driver and go up here again to write this text.

Anyway: The server is now working like a charm. I really look forward to really use it and to take advantage of the greatly increased speed (PII 500 Mhz -> Xenon 2.6 Ghz and more than twice as much RAM than before)

Just another debian install

Today I was going to install Debian Linux on another of those IBM xSeries 345 servers.

I really like those products as they are quite powerful and use only two units in your rack anyway. And they are rack-mountable without screws which makes the whole process quite a pleasure.

The problem when installing those machines is that Debian 3.0 does not support the built in ServeRAID controller. There is an extended boot-floppy on http://people.debian.org/~blade/install/preload/, but unfortuantly, today people.debian.org is down.

My solution was to apt-get install kernel-headers-2.4.18-bf2.4 (on another debian machine), to download vanilla 2.4.18 kernel sources, to copy over /usr/src/kernel-headers-2.4.18-bf2.4/.config to the directory where I unpacked the vanilla sources, to make oldconfig, to make menuconfig, to select Support for IBM ServeRAID in the configuration tool and finally to make modules.

I then copied the compiled ips.o to a blank disk in a directory called /boot. I could later on use this disk in the debian installation process (booted from CDROM with bf42 on the bootprompt) when I can “Load essential modules from disk”.

I did the about same thing for the e1000 driver, the built in ethernet chipset requires:

  • Download it here and uncompress it.
  • Hack src/Makefile to use the kernel-sources above.
  • make
  • ignore the warning that a module not matching the current kernel will be built (because that’s what I want)
  • Copy e1000.o to the disk

    Now it installs flawlessly and I’m quite happy…

LDAP again…

I know… it’s getting boring…

I just wanted to say that I’ve sucessfully fixed two problems:

  1. I had a problem where passwd immediatly failed one another server I just LDAPed: 
    pilif@sen1 ~ % passwd
LDAP Password incorrect
passwd: User not known to the underlying authentication module
pilif@sen1 ~ %

    The problem was a use_first_pass I had in the pam_ldap-line of /etc/pam.d/passwd. When changing the password, it checked the authentity with an empty password (first_pass was empty – I never ever entered one) which failed. If somebody could please tell me the log level to set in slapd.conf to actually get useful logging information describing the problem: step forward!

  2. You have to set rootbinddn in you (pam|nss)_ldap configuration file. This will enable root to change a users password without having to know it first.

    Oh.. both updatedn and updateref where not correctly set in the replicas slapd.conf. I’ve fixed this too.

And on to replication

The show must go on. As our ADSL connection from the office to the internet is not that reliable, I deceided to use OpenLDAPs slurpd to replicate the LDAP tree to an internal LDAP-Server. The setup is quite well described in my LDAP-Book and it did work at the first time I tried it.

At least it sort of worked…

Although changed attributes appeared on the replica, a newly created user was not synchronized. There was no reject on the master either – the data just vanished [sidenote: why is there a replication-rejectlog if data can vanish anyway – this is not reliable behaviour at all].

Reading the syslog finally gave me the idea: The permissions of the replicas data directory where not set correctly: some of the files (and the directory istelf) belonged to root.root while slapd was running as slapd.slapd.

Now it’s working like a charm and I am looking forward to trying to authenticate richards mac against the internal LDAP-Server.

When this works, I’m going to finally convert the SAMBA-installation to a PDC and setup something to synchronize the windows-password with the unix one (both in LDAP – of course).

I’ll keep you updated on my progress…

Fun with OpenLDAP

I bought “LDAP System Administration” because I was interested in LDAP for a long time and I never really understood what one could do with it.

While the reading book is great (it lacks some details here and there, but it’s really nice to read and has very understandable explanations), putting it to work wasn’t:

What I want to acomplish is to have a central user-database for our 3 people company: Two Windows PC’s, one Linux-Router, a Mac OS X workstation, 3 Linux-Servers, my Home-PC – I want to be able to log into all of them with my one password I have in the LDAP-Server. That’s what LDAP is for anyway.

Setting up the server was done in no time (although it required some sweat because I first installed the OpenLDAP Server of debian stable but then deceided to upgrade to the current release (debian is lagging like ever) by using the server from the unstable distribution. I got it to install eventually (after purging the former installation that caused the update-script of the new installation to quit beacuse ldap-utils where not installed [side note: if a packages installation script requires tools from another package: why isn’t this dependency marked in the package?]).

Soon I’ve created my test-account, installed nss_ldap and pam_ldap and it seemd to work.

Actually it crashed my SSH-daemon as soon as I tried to log on to the machine, I could not change the password of LDAP-accounts, su did not work and login was not possible either – despite the fact I was following the clear instructions in the LDAP-Book.

The SSH-Problem got solved by updating to the latest version (uncommenting the LDAP-Support for groups in /etc/nsswitch.conf did help with the older version but this was no alternative. suing eventually began to work without me really changing anything, changing the password required me to edit /etc/pam.d/passwd despite the fact that the in-file documentation of that file states that it is not necessary. Just like the su-problem, the one with login went away eventually.

/bin/passwd requires still requires me to enter the users old password when called as root. Stupid, but can be circumvented by using a LDAP-Admin-Tool. chsh authenticates via PAM and gets the current entries correctly but tries to save back to /etc/passwd. As stupid as the thing with passwd

So the adventure is not even half completed but a day is used and I had to fight problems which are not even supposed to be existing…

Is what I am trying to do really that sophisticated that it sinply does not work? Or am I just plain stupid?

I’ll keep you updated…

A name is a name… or not?

I really saw this mess coming when I read the announcement that Mozilla’s Phoenix will be called Firebird for now: Firebird is a spin off of the once open-sourced Interbase-Database Server by Borland existing for three years now and using the name “Firebird” since then.

As you can imagine, the Firebird (DB)-People were not too happy about this – Phoenix had to be renamed because of a naming conflict and the new solution still creates one – but this time it’s not a commercional product it’s conflicting with – its another Open Source project.

I can understand both sides:

Mozilla
The name Firebird has been checked by Netscapes/AOLs legal departement (why have they not noticed this? or is it maybe that they thought it would not matter?) and another name-change would again involve the legal departement which won’t please neither the BIOS vendor Phoenix not the Mozilla-Team as they will not release another milestone called phoenix.

Firebird
Firebrid already suffers from not really be known in the public. The RDBMS it spun off is known mainly by delphi-developers and neither Interbase nor Firebird were often in the press these days. A more known product with the same name will further divert attention. And the psycological reason: The name Firebird was chosen based on the real political mess around open-sourcing Interbase and is, in my oppinion, a very well chosen name.

Why I can understand the arguments on both sides, I can neither offer a solution pleasing for both projects (besides the question why Phoenix is not to be called simply “Mozilla” – after all, the Browser-Component in the Mozilla Suite is to be replaced by Firebird (the browser) anyway) nor can I understand the way the folks around Firebird (the DB) react to the problem (and here – an entry in Dave Hyatts blog). War is never a solution – never!

MLDonkey

Possibly, you have heard of the eDonkey filesharing program. Since long, there exists a compatible OpenSource-Program called MLDonkey. MLDonkey needs a Unix based system to run (although I think, i’ve heard of a cygwin port). MLDonkey has a nice GUI and generally seems to work better than the original Linux-Client – even more in combination with the Windows-Remote-Control-GUI MLDonkey Watch.

The developer of MLDonkey seems to not longer have time to continue the development, which is a shame as there are still some small problems with the client – some of them making problems on the eDonkey-Servers out there.

Pierre Etchemaite now provides some patches under http://concept.free.free.fr/mldonkey which fix a lot of the problems currently still in the client. If you want to use MLDonkey, you should really apply them.

On the Mailinglist (subscription via the Savannah-Page linked above) the patches and their results are discussed.

Don’t hesitate and give MLDonkey and the Pango-Patches a try!

PostgreSQL 7.3 – it works

I’ve installed the new release of my favourite database, PostgreSQL today and I can happily announce that the upgrade from 7.2.3 went without any problems (a strange thing to announce when having my luk with software in mind ;-).

I’ve not yet had the time to check out all the wonderful new features (Schemas, Domains, a very extended ALTER TABLE and much more), but I will try it somewhere this week.

What I’ve noticed during the update: The current Webmin-Module (1.030) for administering Postgres’ users does not work with the current format of pg_hba.conf but editing the file by hand is quite straightforward – more so because of the very extensive comments in the file.