[Mailman-Users] Hurray! My archive works again... User warning for check_perms!
I'm pleased to report my mailman archive update process is working again. As it turned out, what was keeping the feature from working was ownership and/or permissions on files in /usr/mailman/archives/private/[LISTNAME] and /usr/mailman/archives/private/[LISTNAME]/database directories. Somehow, (I'm not sure how) many -- but not all -- files in those directories were owned by root rather than by mailman and many of them also had permissions of 644 (rw-r--r--) RATHER than 664 (rw-rw-r--). That has been corrected now and ALL files in the mailman directory structure are now owned by mailman PLUS the permissions on virtually all data files are 664 and not 644. This issue apparently goes back to when mailman was first laid down on our old server in the early summer; because a check of the last backup taken from the old server at the end of September shows ALL files in those directories were owned by root and not by mailman. That was CLEARLY caused by some error I made when installing and setting up mailman. I added, the User warning for check_perms because although the perms shown on that final old-server backup were 664 for all mailman files in /usr/mailman/archives/private/mylist directory and 660 for all files in /usr/mailman/archives/private/mylist/database and check_perms reported No Problems Found, check_perms was flat wrong about that. The ownership on ALL those files was wrong but check_perms failed to detect and report that issue. This issue has been reported and should soon be fixed. But in the meantime be cautions about putting too much faith in check_perms in mailman v2.1.11. The data files in those directories must ALL be owned by mailman. In our case they were owned by ROOT! That prevented mailman's ARCHrunner from updating the archive and produced the same errors every day for almost 3 months when mailman tried to update the archive. The errors were recorded each day in the mailman error log (/usr/local/mailman/logs/error); but I never checked the error log! Duhhh! Also, because of those errors the archives were not updated for 3 months and mailman's automatic cleanup process was systematically discarding ALL new posts that hadn't been updated after 7 days. Sadly, neither I nor anyone else was checking the archive either. Double Duhhh!! So, in the end we lost 3 months worth of archive updates. The lessons here are: 1.Just because check_perms reports No Problems Found, don't assume everything is set right or working correctly. CHECK THE ERROR LOG and CHECK THE ARCHIVES! Then, DOUBLE-CHECK both the file and directory permissions and OWNERSHIPs in the archive directories for each of your mailman lists. There is a post in the archives that briefly explains exactly what permissions should be for both files and directories. You'll find that post here: http://mail.python.org/pipermail/mailman-users/2008-October/063748.html. 2. If you don't understand why your list's permissions and ownerships are set the way they are, keep asking questions until you DO understand. Otherwise you may wake up one day as I did and need to explain to your client why 3 months of their conversations have unexpectedly gone missing. :-( A word to the wise. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Seeking qfiles/shunt recovery advice.
Now that my archiver is working again, I have several files in qfiles/shunt that I'd like to recover and convince mailman to insert into my (now working) October archive. If it's possible to do so, I also have a few shunted files from the end of September that I'd like to recover and have included in the September archive as well. Under the circumstances, I'd rather not attack this using a trial and error process. Can anyone point me to a post that explains how to retrieve and recover pck files from the qfiles/shunt directory and convince ARCHrunner to try processing them again? Thanks! -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] message delivery eating disk space ..
Hi, I have a Virtual private server (Fedora, 256 RAM, 10 GB HDD). I'm hosting an announcement list of about 15,000 addresses. I noticed that each time I post a message to the list, the free disk space (command: df -h) is decreasing even after mailman finishes delivering all the messages. I had to reprovision the server and format the hard drive twice and restore my data when the disk is full! is there a kind of temporary files that mailman doesn't cleanup? what can I do? Thanks _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Processing missed digests...
the box had been running our mailman set up died. No problem, I had another box ready to take its place. But the mailman cron jobs didn't run for about a week. Is there a way for get senddigets to send out the digests for the missing days? Or did senddigest send everything since the last digest? Thanks, John -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] mailman archiver not archiving
Problem solved. The root cause turned out to be wrong file ownership of the aliases file in /etc/mailman. James Chapman wrote: I've set up postfix / dovecot / mailman on my server and it works well, except that no messages to mailman lists are archived. The server hosts several domains, though mailman serves only one of the domains. Mail is delivered to mailing list subscribers as expected, but the messages are never added to the mbox archive file. Mailman logs show no errors. I'm using Fedora 9, mailman 2.1.9, python 2.5.1, postfix 2.5.1, all installed from standard f9 RPMs. Archiving is enabled. The aliases for the mailman lists are set up correctly. Regular users have mail delivered in Maildir format. Does this affect mailman? Any suggestions for things to check? Thanks! /james -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Postfix, Mailman, and postfix-to-mailman.py trouble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've searched the archives on this, and haven't come up with a
solution, any tips would be appreciated. I'll begin by describing our
setup.
We run a number of virtual domains on our mailman server. In each
case, we run a separate instance of mailman for each domain. The
handoff from postfix to mailman is done via postfix-to-mailman.py. It
doesn't *feel* like that is relevant to the problem, but in case it
is, here are the relevant bits from master.cf and transport:
master.cf:
mailmancom unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.com/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmanorg unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.org/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmannet unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.net/bin/postfix-to-
mailman.py ${nexthop} ${user}
transport:
lists.example.com mailmancom:
lists.example.org mailmanorg:
lists.example.net mailmannet:
I'm explaining it this way to lay out why we're running things through
the postfix-to-mailman.py script instead of the traditional method.
In the above domains, there are numerous duplication of listnames, and
this seemed the best path to resolution. I realize postfix-to-
mailman.py is not official (or supported), but I'm wondering if anyone
else has come across this issue.
Now, here's the behavior we observe.
If a is sent to multiple lists in a domain, only the first list
(alphabetically) will see it. This includes when multiple lists
within the same domain are defined in the To: line, or in an umbrella
list situation where the member lists live in the same domain.
When looking at the logfiles, we can see the messages go in multiple
times, but only spit out once on the other side.
An example:
/var/log/mail.info:
Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2: to=[EMAIL PROTECTED]
, relay=mailmancom, delay=0, status=sent (lists.example.com)
Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2: to=[EMAIL PROTECTED]
, relay=mailmancom, delay=0, status=sent (lists.example.com)
Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2: to=[EMAIL PROTECTED]
, relay=mailmancom, delay=0, status=sent (lists.example.com)
Then, from /www/lists.example.com/logs/smtp, we see only one come out
the other side:
Oct 27 14:39:23 2008 (2652) [EMAIL PROTECTED]
smtp to core-other for 2 recips, completed in 0.013 seconds
Three messages go in, one comes out the other end.
I did some logging, and found that postfix-to-mailman.py is only
processing *one* message. The script gets the listname from this line:
local = sys.argv[2]
All the docs specify you should put this line in main.cf:
mailman_destination_recipient_limit = 1
I can find no documentation on that particular config, but it seems
like it's telling postfix to only put one recipient per message when
sending to mailman, which would jibe with what the variable setting in
the above script is looking for.
However, it looks like that setting is totally being ignored by our
postfix install. If I type postconf, I do *not* see
mailman_destination_recipient_limit listed in the output. That
seems to me to indicate to me that it's not being honored.
Am I off base here? Has anyone run into this before?
We're running the unbuntu 6.06 version of postfix (2.2.10-1ubuntu),
and all of the mailman instances are installed from source due to our
above virtual list setup.
Any help on this unsupported config is greatly appreciated. :)
==
Craig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkkI+JMACgkQbVNGA3HOzQsa9gCfd31Wn7QqX5z8ns+QT2/mQ6DS
eTwAoIFuYkCzj8kRlsVmzOPWbE0zLGFp
=1PrD
-END PGP SIGNATURE-
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Postfix, Mailman, and postfix-to-mailman.py trouble
* Craig Stacey [EMAIL PROTECTED] wrote:
master.cf:
mailmancom unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.com/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmanorg unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.org/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmannet unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.net/bin/postfix-to-
mailman.py ${nexthop} ${user}
transport:
lists.example.com mailmancom:
lists.example.org mailmanorg:
lists.example.net mailmannet:
/var/log/mail.info:
Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2:
to=[EMAIL PROTECTED] , relay=mailmancom, delay=0, status=sent
(lists.example.com)
Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2:
to=[EMAIL PROTECTED] , relay=mailmancom, delay=0, status=sent
(lists.example.com)
Oct 27 14:39:23 owney postfix/pipe[16420]: 0788A8F6B2:
to=[EMAIL PROTECTED] , relay=mailmancom, delay=0,
status=sent (lists.example.com)
You are sending three messages to three different localparts
([EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) in one domain (lists.example.com), so
Postfix is using the same transport - pretty normal so far.
Then, from /www/lists.example.com/logs/smtp, we see only one come out
the other side:
Oct 27 14:39:23 2008 (2652) [EMAIL PROTECTED]
smtp to core-other for 2 recips, completed in 0.013 seconds
I think the post logfile would be more interesting.
Three messages go in, one comes out the other end.
I did some logging, and found that postfix-to-mailman.py is only
processing *one* message. The script gets the listname from this line:
local = sys.argv[2]
All the docs specify you should put this line in main.cf:
mailman_destination_recipient_limit = 1
I can find no documentation on that particular config, but it seems
like it's telling postfix to only put one recipient per message when
sending to mailman, which would jibe with what the variable setting in
the above script is looking for.
No, since sys.argv[1] should yield the ${nexthop} setting from
master.cf, i.e. the recipient domain (which is ignored by the script).
However, it looks like that setting is totally being ignored by our
postfix install. If I type postconf, I do *not* see
mailman_destination_recipient_limit listed in the output. That
seems to me to indicate to me that it's not being honored.
That's perfectly normal - any custom variables defined in main.cf
don't show in postconf -n output.
Ciao
Stefan
--
Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
Wenn Frauen nicht mehr wissen, was sie tun sollen, ziehen sie sich aus, und das
ist wahrscheinlich das
Beste, was Frauen tun können.
Samuel Beckett
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Postfix, Mailman, and postfix-to-mailman.py trouble
Followup to myself:
* Stefan Förster [EMAIL PROTECTED] wrote:
* Craig Stacey [EMAIL PROTECTED] wrote:
master.cf:
mailmancom unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.com/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmanorg unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.org/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmannet unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.net/bin/postfix-to-
mailman.py ${nexthop} ${user}
[...]
All the docs specify you should put this line in main.cf:
mailman_destination_recipient_limit = 1
Did you do that?
I.e., did you specify:
mailmancom_destination_recipient_limit = 1
mailmanorg_destination_recipient_limit = 1
mailmannet_destination_recipient_limit = 1
Ciao
Stefan
--
Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
The axiom 'An honest man has nothing to fear from the police'
is currently under review by the Axiom Review Board -- Terry Prachett, Men At
Arms
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Postfix, Mailman, and postfix-to-mailman.py trouble
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 30, 2008, at 4:25 PM, Stefan Förster wrote:
Followup to myself:
* Stefan Förster [EMAIL PROTECTED] wrote:
* Craig Stacey [EMAIL PROTECTED] wrote:
master.cf:
mailmancom unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.com/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmanorg unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.org/bin/postfix-to-
mailman.py ${nexthop} ${user}
mailmannet unix - n n - - pipe
flags=FR user=list argv=/www/lists.example.net/bin/postfix-to-
mailman.py ${nexthop} ${user}
[...]
All the docs specify you should put this line in main.cf:
mailman_destination_recipient_limit = 1
Did you do that?
I.e., did you specify:
mailmancom_destination_recipient_limit = 1
mailmanorg_destination_recipient_limit = 1
mailmannet_destination_recipient_limit = 1
This is precisely the magic we were missing. I'm unfamiliar with that
config line and has assumed the mailman portion of it was a mailman
specific thing, not a transport thing. This has solved our problem,
thank you so much!
==
Craig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkkKMQEACgkQbVNGA3HOzQt9nACcDqr0JDgY/oIrf7si70dm1Aqy
fCEAnApvnIcbaRo8QmaFCsO31QQCyWAw
=cn4X
-END PGP SIGNATURE-
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] message delivery eating disk space ..
faisal anif wrote: I have a Virtual private server (Fedora, 256 RAM, 10 GB HDD). I'm hosting an announcement list of about 15,000 addresses. I noticed that each time I post a message to the list, the free disk space (command: df -h) is decreasing even after mailman finishes delivering all the messages. I had to reprovision the server and format the hard drive twice and restore my data when the disk is full! Did you go in and actually check to see which directory hierarchy was using up the disk space? It's kind of hard to solve a problem if you don't actually look to see what the cause is. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
