Is the reason that no info file is sent to new list owners simply because
one has not yet been written, or has it also not been coded for?
If a file just needs to be written, then I'll quite happily volunteer for
the task of writing a draft copy for the list members to discuss, edit, etc.
Also, is it possible to use the access_rules variable to prevent
non-subscribers from being able to post to the list? If so, how?
As for my virtuser database dilemma, I have a somewhat rudimentary solution.
I have created a text file that contains the commands for each vut database
to be rebuilt... like so:
makemap hash /etc/mail/mj-vut-mercury1.net.db < mj-vut-mercury1.net
makemap hash /etc/mail/mj-vut-wwd.org.db < mj-vut-wwd.org
the file is called rebuild and it lives in the /etc/mail directory. I have
created the following cron job:
* * * * * /etc/mail/rebuild
It is apparently supposed to run the job every minute... doesn't quite
accomplish that, but it does rebuild the databases periodically (not yet
sure how often).
Anyway, I still think that if Majordomo could somehow call that file
whenever modifications are made to vut files instead of running a cron job
to accomplish this, then it would be a better fix. It would be nicer if
Sendmail would have an autorebuild virtuser featuer... but it doesn't (I
have suggested it to them though... actually I also suggested an
AutoRebuildAllDatabases option since there are quite a few uses for
databases within sendmail). But if MTAConfig.pm could call the
/etc/mail/rebuild file then it wouldn't be Majordomo rebuilding the
databases, it would be makemap... same as you would use on the command
line... would this break majordomo, cause any security concerns, or
interfere with sendmail's normal operation... or would it just make life a
little easier? Constantly running this cron job is pointless since new
lists obviously aren't created every minute, but the cron job still needs to
be scheduled for every minute since there is no way to tell when someone
will want to create a new list and to be able to get it functional in a
timely manner without running the job every minute. Furthermore, since I
implemented the cron job, I'm occassionally having difficulty logging into
my POP accounts on this server... trouble getting a lock it says.
As for my prior suggestion as to Majordomo's cron jobs... in light of this
successful experiment with putting commands in a text file, 1 per line as I
have done for the makemap to rebuild vut databases, I think I have a
workaround that would enable administrators to simply create 1 cron job and
never have to edit it regardless of how many new domains get set up. It
would go like this:
Here's the cron job:
0 0 * * * /usr/local/majordomo2/cron.daily
0 * * * * /usr/local/majordomo2/cron.hourly
And the files:
/usr/local/majordomo2/bin/mj_trigger -d mercury1.net -t daily
/usr/local/majordomo2/bin/mj_trigger -d wwd.org -t daily
# Daily and hourly triggers for wwd.org
/usr/local/majordomo2/bin/mj_trigger -d mercury1.net -t hourly
/usr/local/majordomo2/bin/mj_trigger -d wwd.org -t hourly
Whenever a new domain is added, Majordomo needs only write to cron.daily and
cron.hourly, putting the appropriate entries on the next line, the actual
cron job gets set up once and once only and is still able to run the
appropriate functions for each domain.