This site will turn read-only at the end of September 2017.

XML Logo

Posted by jparrella on Wed 9 Nov 2005 at 16:41
Tags: none.

Hey there, everybody. Yesterday I had to handle a bunch of problems in our Mail Server. Just for the record, we're runnning Sarge with 2.6.8-1-686-smp from Debian and OpenWebMail 2.41-9 in Apache 1.3.33-6-sarge1, and so on. No strange packages installed. This machine had 250 days of uptime.

Suddenly, one of the users (specifically, The Boss) had trouble logging in to OpenWebMail. After he logged in, it derived in a Server Error message. He could, however, download and send mail using POP/SMTP.

So, checking the logs, I found that:
gdbm fatal: read error [Wed Nov 9 08:07:18 2005] [error] [client 172.16.0.1] Premature end of script headers: /usr/lib/cgi-bin/openwebmail/openwebmail-main.pl

So, the trouble was in libgdbm3, apparently. I checked out bugs against this package and found out that several people are getting this error frequently while using updatedb and man. I contributed with my case, since it seems to be an ugly coding of this library.

I tried Steve Langasek's patch, but this didn't work. I tried changing my kernel to 2.6.8-2-686, but this didn't work either. So I guessed it was about file corruption and that kind of stuff, so I fscked the /home partition (which is the place where OpenWebMail stores stuff) and rebooted with the new kernel.

Stop here and take into account that I work in a government office which opens from 0800 to 1630, and I usually work remotely. The fsck against the /dev/md0 (my RAID0 array for incoming mail -> /var/spool/mail) somehow failed and the system was hanged. Woo-hoo and wait until tomorrow.

So this morning I rebooted and had to re-create the RAID0 using mdadm:
mdadm -C /dev/md0 --level=raid0 --raid-devices=2 /dev/sda7 /dev/sdb1

After this, I remounted. This solved a new problem, but not the original one. So I decided to do it the hard way. I copied /var/spool/mail/user and /home/user, deleted him with deluser, added him again and copied over all his files. Now it's working ok.

Conclusion: libgdbm will definitely fail again. This is not solved. This is just the beggining.

 

Posted by jparrella on Sun 30 Oct 2005 at 18:33
Tags: none.

Greetings there.

Yesterday I installed WebGUI 6.7.7 (gamma) in a Debian Sarge installation. Specs are: Intel Pentium IV 1.7 GHz., 256 Mb. RAM, single 40 Gb. DD.

WebGUI's documentation are Fedora Core-based. Personally, I consider this being disrespectful with the users, since they are presuming you are using this or that distribution, and they don't even give you some points of information for handling errors in other situations. This is what happened to me.

Installation of Perl CPAN modules that they recommend (LWP, DBI, etc.) was OK, so was the downloading of the .tar.gz. Then problems started: they insist in their whole documentation to install WebGUI under /data. I think of this as being completely aestethical (maybe it's even not FHS-compliant?) as I use to install software under /usr/local. This meant a lot of .pl files modificated.

They also insist in using the old NCSA HTTP Server owner nobody while my Apache uses www-data. APT said that I had libapache2-mod-perl2, but I didn't have /etc/apache2/mods-available/perl.conf file, so I reinstalled and everything was OK. Modifications to the apache2.conf were also OK.

The terrible problems came when I tried to force-reload Apache. Apache refused to get up due to missing *.pm files. This had something to do with the preload.perl file that is Required into Apache when you follow WebGUI's website documentation. So I saw that there were missing modules. Using CPAN, I reinstalled almost all of them, and I had two more problems.

The first one was installing Image::Magick. Perlmagick (a.k.a. Image::Magick in CPAN) needs to be version-concurrent with Imagemagick. As I was using the latest CPAN files, but installing Imagemagick with aptitude, there was a huge version mismatch. So there were two solutions: the first one was to compile a recent Imagemagick, and the second was to install and older Perlmagick, which I did (aptitude install perlmagick).

The second problema came with Date::Manip, which refused to know about the current Timezone. Reading documentation I found out that this module takes timezone information from the TZ environment variable, from the files /etc/timezone and /etc/TIMEZONE, from the date Unix command and preferently on two variables in the Manip.pm file. I chose this last approach, since setting and exporting TZ was not working. BTW, Date::Manip only accepts some timezone definitions. VET (which is the Venezuelan Timezone) is not accepted on Date::Manip. I had to use EST (hopefully there'll be no DST problems).

I also had a smaller problem with CPAN while installing XML::Simple which required XML::SAX and XML::NamespaceSupport. It compiled dependencies OK, then XML::Simple refused to compile due to an unexisting Makefile. Solution was cleaning, restarting CPAN's shell and reinstalling XML::Simple. Worked Ok. Generally, CPAN's shell worked OK the whole process, except for one or two test errors which I forced out. Somebody told me that using dh-make-perl would be better, and finally I guess that using the stabler Debian packages would've been nice.

Finally, WebGUI is up and running OK. Seems to be a great piece of software. Took me almost an hour to get it up and running. Hope you guys have better experiences with this CMS.

 

Posted by jparrella on Fri 21 Oct 2005 at 02:53
Tags: none.

Following kuba's post on Debian on Alpha, I'm reporting my latest Sarge installation on a Compaq Alphaserver DS20.

cpu : Alpha
cpu model : EV6
cpu variation : 7
cpu revision : 0
system type : Tsunami
system variation : Goldrush
system revision : 0
platform string : AlphaServer DS20 500 MHz

DS20 is a Tsunami/Goldrush (family/variation) Alpha machine that runs 500 MHz. It has 512 Mb. RAM. It has a magnetic tape unit, and we installed a new CD-ROM drive and three new SCSI disks. It hosts our webpage (currently running Mambo, migrating to Metadot) and two databases (MySQL, PostgreSQL).

With Debian Woody it had an uptime of almost a year, running kernel 2.2.20. We migrated to Sarge, but stayed with kernel 2.2.20. The end of this came a week ago, when we switched to another server and reinstalled Sarge with a 2.6 kernel.

Sarge installation is completely painless. There was no aboot record in our system, so Debian Installer was kind enough to create it for us. It automatically partitioned our disks, but we made slight changes on that.

The main deal with this Alphaserver is that SRM console is poorly documented in the equipment documentation. And, even if it were, there's no such thing as Compaq's support for Linux on DS20.

So we've to deal with the SRM console (which, as of now, is kind of interesting and we've taken the way around this) and the aboot kernel loader. This last one is curious, since it has reminiscents of grub (yet it has different syntax).

I was able to compile a 2.6.12 vanilla kernel by hand on the DS20, but this kernel didn't work. I did it a-la-Debian:

make menuconfig
fakeroot make-kpkg clean
fakeroot make-kpkg --revision=custom-1.0 kernel_image
sudo -
dpkg -i ../kernel-image....deb

But this didn't work. I don't know if it was my fault compiling, or aboot's fault booting. I'm unable to find good guides to kernel configuration on Alpha systems, since alphalinux.org says last stable kernel is 2.2.19. I would really appreciate some feedback on docs I can read on compiling vanilla kernels on Alpha.

Have a nice day everyone at d-a.org