Hello,
Our server recently had hard drive problems, and the system was copied to another drive where it seems to be more or less happy.
But we're having a strange Mailman problem (Mailman 2.1.5 on OSX Server 10.4.10): the lists are running, mail is being delivered, but no archiving is taking place and nothing is being written to the log files. The last change date for all log files is the day the original drive died, as is the date of the last archived messages to our lists. Otherwise all seems to be well...
Can someone help me with some ideas of where to start looking? I've run out of ideas at this point. Permissions seem to be fine. Nothing is in our system logs indicating a problem. I run:
roar:/var/mailman/logs root# /usr/share/mailman/bin/mailmanctl stop Shutting down Mailman's master qrunner roar:/var/mailman root# /usr/share/mailman/bin/mailmanctl start Starting Mailman's master qrunner.
With no problems, but as mentioned, the stop/start does not appear in the logs.
Any ideas?
thanks, douglas
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
Partially answering my own question: I've just realized that when the system was copied over some essential links were replaced by normal files. So I ended up with both a /private/var and a /var (normally on OSX server /var points to /private/var). So my logs/archives/etc are being stored in /private/var, rather than /var.
For future reference I finally figures this out by running:
lsof -u mailman
which showed me that mailman was busy writing to long files on /private/var, as expected. But seeing the explicit path /private/var instead of the normal /var got me thinking, and lead me to the problem.
best, douglas
douglas repetto wrote:
Hello,
Our server recently had hard drive problems, and the system was copied to another drive where it seems to be more or less happy.
But we're having a strange Mailman problem (Mailman 2.1.5 on OSX Server 10.4.10): the lists are running, mail is being delivered, but no archiving is taking place and nothing is being written to the log files. The last change date for all log files is the day the original drive died, as is the date of the last archived messages to our lists. Otherwise all seems to be well...
Can someone help me with some ideas of where to start looking? I've run out of ideas at this point. Permissions seem to be fine. Nothing is in our system logs indicating a problem. I run:
roar:/var/mailman/logs root# /usr/share/mailman/bin/mailmanctl stop Shutting down Mailman's master qrunner roar:/var/mailman root# /usr/share/mailman/bin/mailmanctl start Starting Mailman's master qrunner.
With no problems, but as mentioned, the stop/start does not appear in the logs.
Any ideas?
thanks, douglas
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
douglas repetto wrote:
Partially answering my own question: I've just realized that when the system was copied over some essential links were replaced by normal files. So I ended up with both a /private/var and a /var (normally on OSX server /var points to /private/var). So my logs/archives/etc are being stored in /private/var, rather than /var.
Partially or completely? I am unable to see an unresolved issue remaining. Is there one?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Sorry, I should have said that the mailman part of the question is solved. Now I have to deal with a few other issues as a result, like the fact that some mail was lost (or is floating around somewhere in an imap database and doesn't want to come home)!
It turned out to not be a Mailman problem at all.
Thanks, douglas
Mark Sapiro wrote:
douglas repetto wrote:
Partially answering my own question: I've just realized that when the system was copied over some essential links were replaced by normal files. So I ended up with both a /private/var and a /var (normally on OSX server /var points to /private/var). So my logs/archives/etc are being stored in /private/var, rather than /var.
Partially or completely? I am unable to see an unresolved issue remaining. Is there one?
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
Hello,
We've been getting many many strange mailman-bounces. It seems that somewhere the mailman-bounces address is mis-configured. It should be mailman-bounces@music.columbia.edu, but mail seems to be sent as mailman-bounces@music.columbia.ed (note missing "u"). That's causing bounces to bounce all over the place...in our mail log we get messages like:
Jul 19 12:02:50 roar postfix/smtp[18535]: 9F86883BE24: to=<mailman-bounces@music.columbia.ed>, relay=none, delay=0, status=bounced (Host or domain name not found. Name service error for name=music.columbia.ed type=A: Host not found)
but also:
Jul 19 12:02:54 roar postfix/qmgr[10647]: E969F83BE2C: from=<mailman-bounces@music.columbia.edu>, size=4419, nrcpt=1 (queue active)
So both the correct address and the incorrect address are being used...I've poked around in all of our configs and I can't find the incorrect address anywhere. My suspicion at this point is that there's a virus somewhere on a users computer that is propagating the incorrect address and that many of the messages are the result of spoofed mail. Can anyone help me to understand what's going on? Or suggest where I might look to see if the mailman-bounces address is in fact mis-configured? In mm_cfg.py we have:
mm_cfg.py:DEFAULT_EMAIL_HOST = 'music.columbia.edu' mm_cfg.py:DEFAULT_URL_HOST = 'music.columbia.edu'
so that seems correct...
thanks, douglas
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
douglas repetto wrote:
We've been getting many many strange mailman-bounces. It seems that somewhere the mailman-bounces address is mis-configured. It should be mailman-bounces@music.columbia.edu, but mail seems to be sent as mailman-bounces@music.columbia.ed (note missing "u"). That's causing bounces to bounce all over the place...in our mail log we get messages like:
Jul 19 12:02:50 roar postfix/smtp[18535]: 9F86883BE24: to=<mailman-bounces@music.columbia.ed>, relay=none, delay=0, status=bounced (Host or domain name not found. Name service error for name=music.columbia.ed type=A: Host not found)
but also:
Jul 19 12:02:54 roar postfix/qmgr[10647]: E969F83BE2C: from=<mailman-bounces@music.columbia.edu>, size=4419, nrcpt=1 (queue active)
So both the correct address and the incorrect address are being used...I've poked around in all of our configs and I can't find the incorrect address anywhere.
The domain comes from the host_name attribute of the mailman list (visible on the mailman list's admin->General Options page).
My suspicion at this point is that there's a virus somewhere on a users computer that is propagating the incorrect address and that many of the messages are the result of spoofed mail.
I think this is likely. Presumably the mail that causes this
Jul 19 12:02:50 roar postfix/smtp[18535]: 9F86883BE24: to=<mailman-bounces@music.columbia.ed>, relay=none, delay=0, status=bounced (Host or domain name not found. Name service error for name=music.columbia.ed type=A: Host not found)
originates from within your network from someone or some thing connecting to postfix on your server to send this mail. If it came from outside, it would never get to your domain in the first place. What are the other log entries with the same 9F86883BE24 id. They may give you a clue as to the source of this message.
It is not at all unusual for 'harvested' email addresses to be truncated.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I found the problem. The address was defined correctly in mm_config.py, but for some reason it was truncated in Defaults.py. I don't really understand the mechanism by which changes in mm_config.py are propagate to Defaults.py...but something went wrong!
I edited Defaults.py and restarted MM and am monitoring our logs. So far I don't see any more errors.
thanks, douglas
Mark Sapiro wrote:
douglas repetto wrote:
We've been getting many many strange mailman-bounces. It seems that somewhere the mailman-bounces address is mis-configured. It should be mailman-bounces@music.columbia.edu, but mail seems to be sent as mailman-bounces@music.columbia.ed (note missing "u"). That's causing bounces to bounce all over the place...in our mail log we get messages like:
Jul 19 12:02:50 roar postfix/smtp[18535]: 9F86883BE24: to=<mailman-bounces@music.columbia.ed>, relay=none, delay=0, status=bounced (Host or domain name not found. Name service error for name=music.columbia.ed type=A: Host not found)
but also:
Jul 19 12:02:54 roar postfix/qmgr[10647]: E969F83BE2C: from=<mailman-bounces@music.columbia.edu>, size=4419, nrcpt=1 (queue active)
So both the correct address and the incorrect address are being used...I've poked around in all of our configs and I can't find the incorrect address anywhere.
The domain comes from the host_name attribute of the mailman list (visible on the mailman list's admin->General Options page).
My suspicion at this point is that there's a virus somewhere on a users computer that is propagating the incorrect address and that many of the messages are the result of spoofed mail.
I think this is likely. Presumably the mail that causes this
Jul 19 12:02:50 roar postfix/smtp[18535]: 9F86883BE24: to=<mailman-bounces@music.columbia.ed>, relay=none, delay=0, status=bounced (Host or domain name not found. Name service error for name=music.columbia.ed type=A: Host not found)
originates from within your network from someone or some thing connecting to postfix on your server to send this mail. If it came from outside, it would never get to your domain in the first place. What are the other log entries with the same 9F86883BE24 id. They may give you a clue as to the source of this message.
It is not at all unusual for 'harvested' email addresses to be truncated.
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
douglas repetto wrote:
I found the problem. The address was defined correctly in mm_config.py, but for some reason it was truncated in Defaults.py. I don't really understand the mechanism by which changes in mm_config.py are propagate to Defaults.py...but something went wrong!
This is subtle, but here it is. The values in Defaults.py for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST come from the configure options --with-urlhost= and --with-mailhost=. Defaults.py also contains
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
which adds this entry to the VIRTUAL_HOSTS dictionary.
Then you put correct settings for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST in mm_cfg.py. This overrides the settings from Defaults.py. You may even put
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
in mm_cfg.py which puts the correct entry in the VIRTUAL_HOSTS dictionary, but if the mm_cfg.py value of DEFAULT_URL_HOST is different from the Defaults.py value, this DOES NOT remove or replace the original entry in the VIRTUAL_HOSTS dictionary.
Thus, we suggest that whenever you change DEFAULT_*_HOST in mm_cfg.py, you do
DEFAULT_URL_HOST = ... DEFAULT_EMAIL_HOST = ... VIRTUAL_HOSTS.clear() add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
I edited Defaults.py and restarted MM and am monitoring our logs. So far I don't see any more errors.
If you put all 4 of the above lines in mm_cfg.py, it wouldn't matter what was in Defaults.py. This is a gray area as far as editing Defaults.py is concerned. Normally, you should never edit Defaults.py as your edits will go away if you re-install or upgrade Mailman, but in this case, the 'error' in Defaults.py was caused by a bad configure option which might be corrected the next time you run configure, so it's not clearly wrong to fix Defaults.py.
Still, if you fix mm_cfg.py as above, you don't have to worry about mis-typing the configure options.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks for the explanation, Mark. I made the suggested changes to mm_cfg.py. I'll let you know if there is any additional strangeness...
best, douglas
Mark Sapiro wrote:
douglas repetto wrote:
I found the problem. The address was defined correctly in mm_config.py, but for some reason it was truncated in Defaults.py. I don't really understand the mechanism by which changes in mm_config.py are propagate to Defaults.py...but something went wrong!
This is subtle, but here it is. The values in Defaults.py for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST come from the configure options --with-urlhost= and --with-mailhost=. Defaults.py also contains
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
which adds this entry to the VIRTUAL_HOSTS dictionary.
Then you put correct settings for DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST in mm_cfg.py. This overrides the settings from Defaults.py. You may even put
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
in mm_cfg.py which puts the correct entry in the VIRTUAL_HOSTS dictionary, but if the mm_cfg.py value of DEFAULT_URL_HOST is different from the Defaults.py value, this DOES NOT remove or replace the original entry in the VIRTUAL_HOSTS dictionary.
Thus, we suggest that whenever you change DEFAULT_*_HOST in mm_cfg.py, you do
DEFAULT_URL_HOST = ... DEFAULT_EMAIL_HOST = ... VIRTUAL_HOSTS.clear() add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
I edited Defaults.py and restarted MM and am monitoring our logs. So far I don't see any more errors.
If you put all 4 of the above lines in mm_cfg.py, it wouldn't matter what was in Defaults.py. This is a gray area as far as editing Defaults.py is concerned. Normally, you should never edit Defaults.py as your edits will go away if you re-install or upgrade Mailman, but in this case, the 'error' in Defaults.py was caused by a bad configure option which might be corrected the next time you run configure, so it's not clearly wrong to fix Defaults.py.
Still, if you fix mm_cfg.py as above, you don't have to worry about mis-typing the configure options.
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
douglas repetto wrote:
I found the problem. The address was defined correctly in mm_config.py, but for some reason it was truncated in Defaults.py. I don't really understand the mechanism by which changes in mm_config.py are propagate to Defaults.py...but something went wrong!
I edited Defaults.py and restarted MM and am monitoring our logs. So far I don't see any more errors. ---------------- End original message. ---------------------
That makes no sense. The file you need to edit is mm_cfg.py NOT mm_config.py and DEFINITELY NOT Defaults.py
The values in Defaults.py are used only if not overridden by a corresponding value in mm_cfg.py
You DO NOT want to edit Defaults.py, it even says so in the comments in that file. This is because when you build and install a new version of Mailman, it will get overwritten.
From Defaults.py:
# NEVER make site configuration changes to this file. ALWAYS make them in # mm_cfg.py instead, in the designated area. See the comments in that file # for details.
mm_cfg.py is where you put your site specific configuration. Only values appearing in Defaults.py that are listed as capable of being overriden will have any effect when put in mm_cfg.py
Once you do make changes to mm_cfg.py, you will need to restart Mailman for them to take effect. However, anything that affects list default settings will not propagate into any list configurations, they will only be used when a new list is created. If you wish to change them for existing lists you must do that through the web interface or a withlist script.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
Sorry, I mis-typed, I meant mm_cfg.py. Mark's previous reply explained the problem.
thanks, douglas
Dragon wrote:
douglas repetto wrote:
I found the problem. The address was defined correctly in mm_config.py, but for some reason it was truncated in Defaults.py. I don't really understand the mechanism by which changes in mm_config.py are propagate to Defaults.py...but something went wrong!
I edited Defaults.py and restarted MM and am monitoring our logs. So far I don't see any more errors. ---------------- End original message. ---------------------
That makes no sense. The file you need to edit is mm_cfg.py NOT mm_config.py and DEFINITELY NOT Defaults.py
The values in Defaults.py are used only if not overridden by a corresponding value in mm_cfg.py
You DO NOT want to edit Defaults.py, it even says so in the comments in that file. This is because when you build and install a new version of Mailman, it will get overwritten.
From Defaults.py:
# NEVER make site configuration changes to this file. ALWAYS make them in # mm_cfg.py instead, in the designated area. See the comments in that file # for details.
mm_cfg.py is where you put your site specific configuration. Only values appearing in Defaults.py that are listed as capable of being overriden will have any effect when put in mm_cfg.py
Once you do make changes to mm_cfg.py, you will need to restart Mailman for them to take effect. However, anything that affects list default settings will not propagate into any list configurations, they will only be used when a new list is created. If you wish to change them for existing lists you must do that through the web interface or a withlist script.
Dragon
Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/douglas%40music.columbi...
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
-- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto....... http://works.music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas
participants (3)
-
douglas repetto -
Dragon -
Mark Sapiro