Re: [cobalt-developers] pop before smtp on RaQ550

[Michael Stauber <devel@xxxxxxxxxxxxxx>]

Hi Jeff,

> Note that the popip.db database (created by POP before SMTP) hasn't
> changed since July 12th, and that the sendmail.cf* files haven't
> changed since September 4, which appears to be (from the creation of
> the *pre-spamfilter" files) the same time the SolarSpeed spamfilter was
> installed.

Well, the problem is finally solved and we have that RaQ550 back afloat - as 
you know. However, while working on that particular problem I noticed more 
than one oddity with the RaQ550 which might be of interest for other 
developers.

So this reply here is mostly for the archives and for people who write 
applications for the RaQ550, too. 

Many of the RPMs on the RaQ550 come straight from the RedHat FTP server and 
aparently  weren't even properly tested by Sun Cobalt, nor recompiled to see 
what oddities might arise, or to see if they work together without problems.

There are quite some small oddities which can make yoru hair stand on end if 
you're not expecting trouble.

The RaQ550 comes with the RPM PERL-5.6.0-9. While I was compiling SpamAssassin 
on the RaQ550 the compiled SpamAssassin regularly blew up in my face - 
despite the fact that it compiled without any warnings. 

Each time when SpamAssassin called the Perl functions related to ndbm (dbm 
/ndbm - a function to access Berkley DB databases), then Perl died with the 
error message "unresolved symbol ndbm_open".

This problem didn't exist on any of the older RaQs, nor was it a Perl-5.6.X 
related issues as I know from extensive prior Perl experience.

I then downloaded the PERL-5.6.0-9 SRPM from the Sun Cobalt FTP server and 
looked at how Sun Cobalt had build their PERL. I quickly discovered that 
their SRPM and the one for RedHat-7.2 were idential down to the last byte.

The problem with that PERL is as follows:

There are three different Berkley DB Database formats available: DB1, DB2 and 
DB3. They're not entirely compatible.

The old PERL-5.005 used DB1, while the newer PERL-5.6.X usually comes with 
support for DB2 and DB3. 

PERL-5.6.0-9 for the RaQ550 comes with a patch which is *supposed* to enable 
both support for DB1 and DB3, but although it allows DB1 support, the DB3 
support is not working at all.

If any PERL script "asks" Perl if it was compiled with DB3 support, then PERL 
says "Sure, I can handle DB3", but then when it tries to access the 
respective library for that stuff it blows up in your face.

Why is that so? Well, the underlying problem is gdbm-1.8.0-3, which installs 
an interface to access Berkley DB databases. However, this RPM on the RaQ550 
is utterly broken. Download the SRPM and try to compile it - it won't compile 
at all. The makefile doesn't shed any light on why it won't compile, but it 
apparently has to do with the two patches which are forced onto the source 
code. 

Anyhow, without a working gdbm installed, the PERL-5.6.0 won't compile with 
proper DB3 support.

So what we've got here is a nice small string of defective RPMs which won't 
compile on a native RaQ550. It's nothing critical, nor does it affect any 
functionality which a regular RaQ550 users might need. However, any developer 
who happens to attempt to shove in some serious third party applications will 
step into a nice minefield. That one can quickly eat up a week of 
developement time during which he has to fix dumb mistakes made by RedHat and 
not discovered by Sun Cobalt. Blindly borrowing defective RPMs from the 
RedHat FTP server isn't proper R&D, nor is it entirely smart to do so (glibc 
anyone? Same sad story, wearing the same red hat!!)

Anyone who has to install scripts or programms on the RaQ550 which use DB2 or 
DB3 database implementations is forced to manually recompile gdbm and has to 
recompile PERL-5.6.X - unless Sun Cobalt comes up with a patch that fixes 
those problems. But don't count on it.

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer