Voytek Eymont wrote:
> On Sat, July 19, 2008 5:32 pm, MrC wrote:
>> Voytek Eymont wrote:
> # service amavisd start
> Starting Mail Virus Scanner (amavisd): [ OK ]
> #
>
> thanks !!!!!
>
Good news, you're welcome.
>> In general, it is a bad idea to mix-n-match CPAN with your disto
>> packages, unless you understand the the interdependencies of the parallel
>> module trees that get created under site_perl and vendor_perl.
>
> I see...
> nope, not only I don't understand, I don't even have a clue...
>
> so what do you think went wrong ?
> (I think I should keep better records, too...)
Well, this is a tough call. You're using a distro with a stability
policy, but CPAN is all about latest and greatest. So, if you need
stability, stay with your distros packages and just update for security
issues. If you want more recent software, that's manageable, but you
have to take on the responsibility of managing the interdependencies,
and in the case of perl modules, this requires getting to known the perl
modules trees.
I'll suggest that before any perl software updates, since this is an
area that has presented troubles for you in the past, make a (tar)
backup of the entire lib/perl5 directory, so that should something go
wrong, you can just move the broken directory out of the way, and
restore from your backup. Then, you can examine the differences and
changes without the stress of your server being down.
[ even more off topic - cpan and distro packages ]
The various Zlib modules cause issues when mixing CPAN modules with a
distro's packages or modules.
To understand why this occurs, you need to understand how perl modules
are located and where they are installed. Your distro's perl modules
are placed in one directory tree, and CPANs are placed into another.
So, you can end up with conflicting sets of modules, and this is
particularly problematic when a module requires compiled objects.
Take a look at your perl INC path:
perl -e '$"="\n"; print "@INC\n"'
Mine looks like:
/usr/pkg/lib/perl5/site_perl/5.8.0/i386-netbsd-thread-multi
/usr/pkg/lib/perl5/site_perl/5.8.0
/usr/pkg/lib/perl5/site_perl
/usr/pkg/lib/perl5/vendor_perl/5.8.0/i386-netbsd-thread-multi
/usr/pkg/lib/perl5/vendor_perl/5.8.0
/usr/pkg/lib/perl5/vendor_perl
/usr/pkg/lib/perl5/5.8.0/i386-netbsd-thread-multi
/usr/pkg/lib/perl5/5.8.0
Some things to notice here:
1) site_perl contains modules I've installed independent of my distro.
CPAN modules go here.
2) vendor_perl contains modules installed by my vendor; packages such as
RPM, pkgsrc, etc. go here.
3) the non-{vendor_perl,site_perl} directories are included with Perl
itself.
4) the *-thread-multi directories contain compiled objects.
5) each of the site_perl, vendor_perl, *-thread-multi, base Perl
directories are essentially.
6) directories are searched for modules in the order listed in INC, as
shown ordered above.
This makes essentially three trees of modules (its even a bit more
complicated, I'm simplifying), which can all appear somewhat (and may
be) identical. Further complicating this is that the *-thread-multi
directories will contain module components that may be companions to
those in the corresponding non *-thread-multi directory. One final
detail - there is an directory named "auto" in the *-thread-multi
directories. This is where the compiled module components are located,
again, in the now familiar tree structure. A module may have two
implementations, one binary version compiled for performance, and
another pure-perl fall back. This is a good time for you to go examine
those trees, and discover which of the multiple versions are actually
being used (this was a question you had back in March on the mailing
list). The INC list output on your system will help you see which
modules are no longer in use because they've been superseded by newer
CPAN versions.
When you use CPAN to install a module, your CPAN modules are found and
used first because your INC path is set to do so (site_perl before
vendor_perl). Any dependencies this module has are also found using the
same INC path. But the dependency list in the CPAN build instructions
do not perfectly match the actual dependencies that the code requires.
In the case of Compress::Zlib, it depends upon the module Scalar::Util,
but the software when running actually not only requires Scalar::Util
the module, but a particular variable (dualvar) within that module
use Scalar::Util qw(dualvar);
So while the build dependencies are satisfied, due to the partial dual
implementation of Scalar::Util, the build succeeds, but running the
software fails.
The fix? Manually update Scalar::Util.
If you want more gory details of this particular issue, see:
http://forums.whirlpool.net.au/forum-replies-archive.cfm/843943.html
and more here:
http://www.perlmonks.org/?displaytype=print;node_id=594914
This is a very subtle, but nasty issue.
MrC
>
> I really panicked, as, this morning, Apache went down;
> it restarted OK, but, I started thinking what's up (or, down)
> then Cacti didn't work (that's next to look at); then, I saw stuff queing
> up in mailq, amavis down, panic galore
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
