Must remember to check these things *before* I submit a package...

SRPM URL: http://ftp.kspei.com/pub/steve/rpms/amavisd-new-2.3.3-1.src.rpm

* Thu Sep 01 2005 Steven Pritchard <steve> 2.3.3-1
- Update to 2.3.3
- Remove explicit dependencies on core perl modules

I need to bump the perl(Compress::Zlib) requirement to >= 1.35, or remove the
check from the code so we can use it on FC-[34] without an update to
perl-Compress-Zlib.

*sigh*

An update to Compress::Zlib was pushed to Core some time ago, so please review.

http://ftp.kspei.com/pub/steve/rpms/amavisd-new-2.3.3-2.src.rpm

* Fri Sep 02 2005 Steven Pritchard <steve> 2.3.3-2
- Requires: perl(Compress::Zlib) >= 1.35

the demo programs amavisd-{agent,nanny} need a patch to look the db in the
proper directory (/var/spool/amavisd/db)

I'll attach it.

Created attachment 118977 [details]
Correct the db directory for amavisd-agent and amavisd-nanny

I've applied the patch.  Thanks.

http://ftp.kspei.com/pub/steve/rpms/amavisd-new-2.3.3-3.src.rpm

and what about adding the amavisd-release program ?
It allow to resend quarantined mail, the author explains how to use it, 
cf.
http://groups.google.com/group/mailing.unix.amavis-user/browse_frm/thread/50640aa9c5f182bb/a12b4488cba1cd8d#a12b4488cba1cd8d
(I hope the link will work...)

Even if it's included enabling quarantine is probably a bad idea for Fedora. Tag
suspicious mail, ask sender to retry if you've got a doubt, and dump everything
else.

Quarantine is IMHO inadequate for small systems. Big organisations can justify
quarantine management and will enable it in the conf file but the Fedora default
should be off.

Thank you very much for this package. I've been testing it (on x86-64, FWIW) and
it works well.

I note that /etc/amavisd/amavisd.conf mentions:
#   see amavisd.conf-default for a list of all variables with their defaults;
#   see amavisd.conf-sample for a traditional-style commented file;

These files are provided in the tar.gz in the src.rpm, but are not included in
the RPM.

Personally, I'd prefer to see them in the RPM (they do provide worthwhile
documentation), but some sort of consistency might be nice.

Thanks,

James.

BTW I've been testing with selinux disabled (for other reasons). Is this package
selinux-safe ? Anyone tested it with the new security rules wich landed in
rawhide recently ?

http://ftp.kspei.com/pub/steve/rpms/amavisd-new-2.3.3-4.src.rpm has a couple of
extra %doc entries (TODO and amavisd.conf-*).

As for selinux, I have no idea.  It has been broken enough in FC4 that I am
running all my servers either in permissive mode or with selinux disabled
entirely, unfortunately.

That's why I asked about this. I fear no one is testing it and people will need
it to work later.

Unfortunately, one of the things that stops me from going into enforcing mode is
I haven't figured yet how to authorize the fact my postfix listens on port 24,
so if I go into enforcing mode postfix goes down (and I can't test amavis)

I think that the kind guys from fedora-selinux list may assist you on modifying
the policy so as to allow running postfix on port 24.

If you have selinux-policy-targeted-sources installed, try adding a line to
/etc/selinux/targeted/src/policy/net_contexts

portcon tcp 24 system_u:object_r:smtp_port_t

and then do:

make -C /etc/selinux/targeted/src/policy load

Thanks for the tip.
However I fear I may have other selinux problems lurking (squirrelmail) so I
won't touch it before I have the time to put everything right.

Also, I'd rather understand the system before meddling with the security policies ;)

I'm running a pretty unmodified (but "yum update"d) FC4 with current (FC4)
SELinux enabled in enforcing targeted mode. I haven't configured Postfix beyond
installing amavisd and changing some of the main.cf parameters.

As I say, it's all working well for me.

Well I switched postfix from port 24 to 587 which is more traditional and
victory it's in the default redhat selinux policy

*HOWEVER* selinux still blocked postfix this time when it tried to bind on the
port used to talk to amavis (port 10026 on my box, dunno if your current package
makes the same choice)

So it seems amavisd is not selinux safe in fedora devel

(In reply to comment #17)
> Well I switched postfix from port 24 to 587 which is more traditional and
> victory it's in the default redhat selinux policy
> 
> *HOWEVER* selinux still blocked postfix this time when it tried to bind on the
> port used to talk to amavis (port 10026 on my box, dunno if your current package
> makes the same choice)
> 
> So it seems amavisd is not selinux safe in fedora devel

You need to take this to fedora-selinux-list now. Dan Walsh hangs out there and
will probably work with you to get the Fdeora SELinux policy fixed so that this
works. That's how I got SELinux support for my Extras pptp package included in
Fedora Core.

I've just applied the latest selinux-policy-targeted-1.27.1-2.1 from FC4
updates. And it's broken my amavisd install...

Selinux problems are fixed in Raw Hide. Package works very well for me so far.
Are there no perl gurus available to approve it ?

(In reply to comment #19)
> I've just applied the latest selinux-policy-targeted-1.27.1-2.1 from FC4
> updates. And it's broken my amavisd install...


Its fixed in rawhide. Report to this to bugzilla and request a policy update.

Starting amavisd: Problem in the Amavis::Unpackers code: Archive::Zip version
1.14 required--this is only version 1.12 at (eval 46) line 20.
BEGIN failed--compilation aborted at (eval 46) line 20.

Just as a start  i havent done a full check on the package yet.

Latest selinux-policy-targeted-1.27.1-2.14.noarch fixes it: thanks.

A new perl-Net-Server will be pushed to FE soonish. Please test

And while I'm a it, I've updated perl-Convert-UUlib too

(still happily running Steve's original package 24h/24 7j/j since last september
at least without any hitch - can't anyone approve this?)

Since there are no obvious showstoppers in this bug ticket, I'll review this:

Good:

- rpmlint checks return:
E: amavisd-new non-standard-uid /var/spool/amavisd/db amavis
E: amavisd-new non-standard-gid /var/spool/amavisd/db amavis
E: amavisd-new non-standard-dir-perm /var/spool/amavisd/db 0700
W: amavisd-new dangling-relative-symlink /usr/sbin/clamd.amavisd clamd
E: amavisd-new non-standard-uid /var/spool/amavisd amavis
E: amavisd-new non-standard-gid /var/spool/amavisd amavis
E: amavisd-new non-standard-dir-perm /var/spool/amavisd 0700
E: amavisd-new non-standard-uid /var/run/amavisd amavis
E: amavisd-new non-standard-gid /var/run/amavisd amavis
E: amavisd-new non-standard-uid /var/spool/amavisd/tmp amavis
E: amavisd-new non-standard-gid /var/spool/amavisd/tmp amavis
E: amavisd-new non-standard-dir-perm /var/spool/amavisd/tmp 0700
E: amavisd-new init-script-name-with-dot /etc/rc.d/init.d/clamd.amavisd
E: amavisd-new no-status-entry /etc/rc.d/init.d/clamd.amavisd
W: amavisd-new no-reload-entry /etc/rc.d/init.d/clamd.amavisd
E: amavisd-new subsys-not-used /etc/rc.d/init.d/clamd.amavisd
E: amavisd-new incoherent-subsys /etc/rc.d/init.d/amavisd ${prog_base}

I think all of these are safe to ignore.

- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file

APPROVED.

(In reply to comment #25)
> (still happily running Steve's original package 24h/24 7j/j since last september
> at least without any hitch - can't anyone approve this?)

You know you could have done that yourself, right?

Thanks Tom.

Ville: I'm not going to approve a perl package which processes insecure data. At
least not before taking a few perl tutorials/courses first. You can call me
paranoïd if you like, but perl is very low in my trust scale, and I don't know
it enough to do an educated evaluation.

(and yes I'm ready to trust my own data to a package I wouldn't approve - but
then I've been running rawhide for more years I care to remember now)

when updating from your first to your last rpm, I noticed amavisd is restarted
twice:

[root@cdc ~]# rpm -Uhv /usr/src/redhat/RPMS/noarch/amavisd-new-2.3.3-4.noarch.rpm
Preparing...                ########################################### [100%]
   1:amavisd-new            warning: /etc/amavisd/amavisd.conf created as
/etc/amavisd/amavisd.conf.rpmnew
########################################### [100%]
Shutting down amavisd: Can't SIGTERM amavisd[1337]: No such process at
/usr/sbin/amavisd line 8983., can't stop the process
[FAILED]

Starting amavisd: Pid_file "/var/run/amavisd/amavisd.pid" already exists. 
Overwriting!
[  OK  ]

Stopping clamd.amavisd: [  OK  ]
Starting clamd.amavisd: [  OK  ]
[root@cdc ~]#

More importantly, amavisd never starts for me. It goes through a lot of good
messages and then ends with an error:
Jan 20 01:54:19 cdc amavis[1588]: Found decoder for    .zoo  at /usr/bin/zoo
Jan 20 01:54:19 cdc amavis[1588]: Found decoder for    .lha  at /usr/bin/lha
Jan 20 01:54:19 cdc amavis[1588]: Found decoder for    .cab  at /usr/bin/cabextract
Jan 20 01:54:19 cdc amavis[1588]: No decoder for       .tnef tried: tnef
Jan 20 01:54:19 cdc amavis[1588]: Internal decoder for .tnef
Jan 20 01:54:19 cdc amavis[1588]: Found decoder for    .exe  at /usr/bin/unrar;
/usr/bin/lha; /usr/bin/unarj
Jan 20 01:54:19 cdc amavis[1588]: Using internal av scanner code for (primary)
ClamAV-clamd
Jan 20 01:54:19 cdc amavis[1588]: Found secondary av scanner ClamAV-clamscan at
/usr/bin/clamscan
Jan 20 01:54:19 cdc amavis[1588]: TROUBLE in pre_loop_hook: db_init: BDB bad db
env. at /var/spool/amavisd/db: Invalid argument, . at (eval 37) line 244.

[root@cdc amavisd]# ls -al /var/spool/amavisd/db/
total 8
drwx------  2 amavis amavis 4096 Jan 20 01:48 .
drwx------  5 amavis amavis 4096 Jan 20 01:49 ..

This is a FC4-updated machine.

[root@cdc amavisd]# rpm -V amavisd-new
[root@cdc amavisd]# rpm -q amavisd-new
amavisd-new-2.3.3-4

I haven't seen that error before.  Had you been using the old rpm, or did you
just have it installed?

For that matter, do you know which old rpm you were using?

How about pushing the current version to FE so everyone can use the same
reference package ? Then we can forget about the pre-inclusion versions

I used the first rpm you put up, had that error and then found your latest rpm,
and did a rpm -U.

An strace ends with problems for BDB and "Destroy". But I did install the FE
BerkeleyDB rpm as well.

My guess was this could be some missing perl dependancy, but I cannot figure out
the package that would be missing.

One additional note, I don't think it should matter, but this is within a xen2
FC4 xenu

I'm still trying to debug this and get amavisd-new running. Looking a bit
further into my db error, I noticed:

 ["DBI:SQLite:dbname=$MYHOME/sql/mail_prefs.sqlite", '', ''] );

Howeverm there is no 'sql' directory included with amavisd-new in the rpm.
Perhaps either the sqlite depedancy needs to be dropped, or this file needs to
be included?

also, there is a note saying: 

#NOTE: create directories $MYHOME/tmp, $MYHOME/var, $MYHOME/db manually

However, $MYHOME/var is not created by the rpm.

I finally found the reason for my failure, which is the following line:

$enable_db = 1 

checking the build shipped config file shows:

[root@cdc amavisd]# grep enable_db
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf*
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf:$enable_db = 1;           
  # enable use of BerkeleyDB/libdb (SNMP and nanny)
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf:$enable_global_cache = 1; 
  # enable use of libdb-based cache if $enable_db=1
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf-default:# $enable_db = 0;
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf-sample:$enable_db = 1;    
         # enable use of BerkeleyDB/libdb (SNMP and nanny)
/usr/src/redhat/BUILD/amavisd-new-2.3.3/amavisd.conf-sample:$enable_global_cache
= 1;    # enable use of libdb-based cache if $enable_db=1

So I believe it did ship with $enable_db=1

So either this functionality is broken, or more likely, something else needs to
happen that I have not yet done, but which was already dont on the server of the
rpm builder.

Please open a new bug if you can reproduce the problem with 2.3.3-5 when it
comes out of the build system.

Package Change Request
======================
Package Name: amavisd-new
New Branches: 
Owners: jorti steve kanarip
InitialCC: perl-sig

steve is unresponsive, so I want to take over the package. See:
https://lists.fedoraproject.org/pipermail/devel/2014-February/195318.html
https://lists.fedoraproject.org/pipermail/devel/2014-January/194940.html

Git done (by process-git-requests).

Package Change Request
======================
Package Name: amavisd-new
New Branches: f20 f19 el5 el6 epel7
Owners: jorti steve kanarip
InitialCC: perl-sig

I already have the ownership of the devel branch, I ask to take the ownership of the remaining branches. In epel, the user janfrode has commit rights, please, keep them.
https://fedorahosted.org/fesco/ticket/1233

Git done (by process-git-requests).