[Mailman-Users] Nightly Messages Show Problems

[Mark Sapiro]

On 07/04/2015 08:27 AM, Steve Matzura wrote:
> 
> On Sat, 04 Jul 2015 07:45:07 -0700, Mark Sapiro <mark at msapiro.net>
> wrote:
> 
>> These occur because you have installed a crontab which has been
>> formatted as a system crontab and intended to be installed in a place
>> like /etc/cron.d/mailman as a user contab somewhere in /var/spool/cron.
> 
> Interesting. I followed the directions at
> http://www.gnu.org/software/mailman/mailman-install/node41.html which
> say:


This is just one of many reasons for the advice in the FAQ at
<http://wiki.list.org/x/12812344>.

Packagers do various things that don't always align with what we
recommend. In short, If you install from source, follow our docs; if you
install a package, follow the packager's docs.

In your case, the RedHat package has modified Mailman's crontab.in to be
a system crontab and already installed it in /etc/cron.d/.

Thus it was wrong to follow our manual and try to install it ads the
Mailman user's crontab.


> If your version of crontab supports the -u option, you must be root to
> do this next step. Add $prefix/cron/crontab.in as a crontab entry by
> executing these commands: 
> 
>     % cd $prefix/cron
>     % crontab -u mailman crontab.in


To correct this, just do

sudo crontab -u mailman -r


> Should I remove the mailman ones and install it as root instead?


Remove the 'mailman' one as above. The system one was already installed
by the package.


...
> The two in /etc/cron.d and /var/spool/cron are identical. Here's the
> contents with the comment lines removed:
> 
> MAILTO=sm at noisynotes.com
> 0 8 * * * mailman /usr/lib/mailman/cron/checkdbs
> 0 9 * * * mailman /usr/lib/mailman/cron/disabled
> 0 12 * * * mailman /usr/lib/mailman/cron/senddigests
> 0 5 1 * * mailman /usr/lib/mailman/cron/mailpasswds
> 27 3 * * * mailman /usr/lib/mailman/cron/nightly_gzip
> 30 4 * * * mailman /usr/lib/mailman/cron/cull_bad_shunt


The one in /etc/cron.d/ is fine as is. The other should be removed as
above. Since the system one runs as 'mailman' and has permission issues
and check_perms reports no problems, I suspect the permission issues are
SELinux related.

Disabling SELinix may help, but you may not want to do that. Otherwise,
you'd need to address this via SELinux policies, and I don't know what
would need to be changed. This is interesting because the motivation for
RedHat's file location changes to be FHS compliant was at least in part
to make their Mailman package work well with SELinux.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan