Upgrading Amavis on Centos 5

Mark Martinec Mark.Martinec+amavis at ijs.si
Fri Aug 31 12:25:40 CEST 2012


Nick,

> As I am using the ancient Amavis version (2.4.5) provided in CentOS 5
> EPEL repos, based on the fact that Amavis is in fact a set of Perl
> scripts (and should not require compilation), in order to avoid changing
> init scripts and current paths of the installation, I am thinking of
> manually replacing files in the current installation with those from the
> 2.8.0 release. (I know this could hardly be considered proper, but
> anyway; life is like that.)
> 
> So, if I would change:
>     amavisd
>     amavisd-agent
>     amavisd-release
> in their current locations, wouldn't this imply a true upgrade to 2.8.0?

... and amavisd-nanny.  Yes, I believe it would.
( but I can see people who do all the package management through
tools to start pulling their hair :)

The config file should be upwards compatible, although you may
consider taking the sample config file from 2.8.0 and adding
the few site-specific settings for a fresh/clean start.

> However, I don't know if new files should be used: amavisd-mc,
> amavisd-services, other?

These are not required, you can continue using Berkeley DB for
amavisd-nanny and amavisd-agent / amavisd-snmp-subagent, or not
using it at all if monitoring is not needed.

The new amavisd-mc, amavis-services, amavisd-status, and
amavisd-snmp-subagent-zmq are only needed if you'd prefer
to use the ZMQ message-passing library for communication
between monitoring components, instead of a libdb.

> Note: CentOS 5.8 uses: file-4.17-21, while in Amavis-2.8.0 Install notes
> I saw that a current version (4.26 at this time) is suggested. Any
> serious issues expected with 4.17? Couldn't find a later "file" RPM for
> el5.

The file(1) utility is constantly evolving, people are contributing
patches and new samples, so generally it is better to use a newer
version. I don't think there were any mayor security concerns
with older versions, just an occasional misclassification.

> Any suggestions/advice on this idea?
> Another (better) option would be to get directions on packaging 2.8.0 as
> an RPM with the same settings/paths used in the current EPEL RPM,

I guess so.

> which
> I don't know how to, by using the spec file provided. If you can point
> me to where I can find such directions, please do. I can produce RPMs
> from SRPMs using ready-made spec files (which I change slightly to
> upgrade versions), but have no experience with Perl / script-based apps.

I hope somebody else can provide some guidelines in this area.

  Mark


More information about the amavis-users mailing list