Re: [Mailman-Users] Installing Mailman on OS X El Capitan--can’t find source of erroneous call of binary at /usr/share/mailman/mail/mailman

2016-10-13 Thread Dominik Hoffmann
/usr/local/mailman/bin/genaliases did do the trick. Thanks so much, Mark!

> On Oct 12, 2016, at 3:10 PM, Dominik Hoffmann  wrote:
> 
> I think, actually, that that may have done the trick. I started getting some 
> test messages I had sent to the list earlier, which must have been queued. I 
> will have to do more testing later, when I have time.
> 
>> On Oct 12, 2016, at 11:36 AM, Dominik Hoffmann  
>> wrote:
>> 
>> /usr/local/mailman/bin/genaliases did not produce any output. Does this mean 
>> that it didn't change anything or simply did so silently?
> --
> Mailman-Users mailing list Mailman-Users@python.org
> https://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: 
> https://mail.python.org/mailman/options/mailman-users/dhoffmann%40uwalumni.com

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


[Mailman-Users] Cron has issues with gate_news

2016-10-13 Thread Dominik Hoffmann
There are still a few of things to mop up, after an otherwise successful 
installation of Mailman on OS X El Capitan with Server 5.2.

Every 5 min my admin user account on the server gets an email from the Cron 
Daemon that has this line:

IOError: [Errno 13] Permission denied: 
'/usr/local/mailman/locks/gate_news.lock.ipheion.hoffmann.homeunix.net.54220.0'

Here are my observations:

1. I currently have no file at /usr/local/mailman/locks/ whose name starts with 
"gate_news".

2. My root Crontab has these lines:

# Every 5 mins, try to gate news to mail. You can comment this one out
# if you don't want to allow gating, or don't have any going on right 
now,
# or want to exclusively use a callback strategy instead of polling.
# 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S 
/usr/local/mailman/cron/gate_news

   In other words, the gate_news cron job is commented out.

3. I have run /usr/local/mailman/bin/check_perms -f, but that has had no impact.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Cron has issues with gate_news

2016-10-13 Thread Dominik Hoffmann
Another observation:

4. Moving the Crontab from root to _mailman had no effect.

> On Oct 13, 2016, at 11:43 AM, Dominik Hoffmann  wrote:
> 
> There are still a few of things to mop up, after an otherwise successful 
> installation of Mailman on OS X El Capitan with Server 5.2.
> 
> Every 5 min my admin user account on the server gets an email from the Cron 
> Daemon that has this line:
> 
> IOError: [Errno 13] Permission denied: 
> '/usr/local/mailman/locks/gate_news.lock.ipheion.hoffmann.homeunix.net.54220.0'
> 
> Here are my observations:
> 
> 1. I currently have no file at /usr/local/mailman/locks/ whose name starts 
> with "gate_news".
> 
> 2. My root Crontab has these lines:
> 
>   # Every 5 mins, try to gate news to mail. You can comment this one out
>   # if you don't want to allow gating, or don't have any going on right 
> now,
>   # or want to exclusively use a callback strategy instead of polling.
>   # 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S 
> /usr/local/mailman/cron/gate_news
> 
>   In other words, the gate_news cron job is commented out.
> 
> 3. I have run /usr/local/mailman/bin/check_perms -f, but that has had no 
> impact.

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] one mailing list shunting messages

2016-10-13 Thread Mark Sapiro
On 10/13/2016 09:51 AM, Knight, Eric wrote:
> I am not sure what to do about this message in error log, any help 
> appreciated.
> 
> 
> Oct 13 11:47:30 2016 (12368) SHUNTING: 
> 1476372076.1651051+54a50f9eb22730094aba33728b8cee7136dad7e2
> Oct 13 11:47:30 2016 (12368) Uncaught runner exception: local variable 
> 'bodylen' referenced before assignment
> Oct 13 11:47:30 2016 (12368) Traceback (most recent call last):
>   File "/usr/server/sulists/Mailman/Queue/Runner.py", line 119, in _oneloop
> self._onefile(msg, msgdata)
>   File "/usr/server/sulists/Mailman/Queue/Runner.py", line 190, in _onefile
> keepqueued = self._dispose(mlist, msg, msgdata)
>   File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 130, in 
> _dispose
> more = self._dopipeline(mlist, msg, msgdata, pipeline)
>   File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 153, in 
> _dopipeline
> sys.modules[modname].process(mlist, msg, msgdata)
>   File "/usr/server/sulists/Mailman/Handlers/Hold.py", line 187, in process
> if bodylen/1024.0 > mlist.max_message_size:
> UnboundLocalError: local variable 'bodylen' referenced before assignment
> 
> Oct 13 11:47:30 2016 (12368) SHUNTING: 
> 1476376331.709368+f252c549b5b457fe876963e4dba623dd2047e456


What Mailman version is this? Are there any local modifications to
/usr/server/sulists/Mailman/Handlers/Hold.py?

You can run Mailman's bin/unshunt to process the shunted messages, but
only after fixing the issue in Hold.py (I'm sure this issue doesn't
exist in any version distributed by the GNU Mailman project). Or, you
can set the list's max_message_size to 0 (meaning unlimited) to avoid this.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Cron has issues with gate_news

2016-10-13 Thread Mark Sapiro
On 10/13/2016 08:56 AM, Dominik Hoffmann wrote:
> Another observation:
> 
> 4. Moving the Crontab from root to _mailman had no effect.


Good you moved it, but see below.


>> On Oct 13, 2016, at 11:43 AM, Dominik Hoffmann  
>> wrote:
>>
>> There are still a few of things to mop up, after an otherwise successful 
>> installation of Mailman on OS X El Capitan with Server 5.2.
>>
>> Every 5 min my admin user account on the server gets an email from the Cron 
>> Daemon that has this line:
>>
>> IOError: [Errno 13] Permission denied: 
>> '/usr/local/mailman/locks/gate_news.lock.ipheion.hoffmann.homeunix.net.54220.0'


cron/gate_news is trying to create the lock and has no permission to do so.


>> Here are my observations:
>>
>> 1. I currently have no file at /usr/local/mailman/locks/ whose name starts 
>> with "gate_news".


Normally, the lock would only exist during the few (milli)seconds that
gate_news was running, but in your case it isn't even created.


>> 2. My root Crontab has these lines:
>>
>>  # Every 5 mins, try to gate news to mail. You can comment this one out
>>  # if you don't want to allow gating, or don't have any going on right 
>> now,
>>  # or want to exclusively use a callback strategy instead of polling.
>>  # 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/python -S 
>> /usr/local/mailman/cron/gate_news
>>
>>   In other words, the gate_news cron job is commented out.


OK, but there is another crontab somewhere running gate_news.

Also, Mailman's cron jobs should run as the Mailman user (usually
_mailman in FreeBSD/Darwin), not as root.

Since the gate_news entry in the crontab entry you are looking at is
commented out, there must be another crontab somewhere.

You may have a system crontab in /etc/cron.d/ or another user crontab.
Note that the format of system crontabs is different. There is an
additional field between the times/days and the command for the user to
run as.


>> 3. I have run /usr/local/mailman/bin/check_perms -f, but that has had no 
>> impact.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


[Mailman-Users] one mailing list shunting messages

2016-10-13 Thread Knight, Eric
I am not sure what to do about this message in error log, any help appreciated.


Oct 13 11:47:30 2016 (12368) SHUNTING: 
1476372076.1651051+54a50f9eb22730094aba33728b8cee7136dad7e2
Oct 13 11:47:30 2016 (12368) Uncaught runner exception: local variable 
'bodylen' referenced before assignment
Oct 13 11:47:30 2016 (12368) Traceback (most recent call last):
  File "/usr/server/sulists/Mailman/Queue/Runner.py", line 119, in _oneloop
self._onefile(msg, msgdata)
  File "/usr/server/sulists/Mailman/Queue/Runner.py", line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 130, in 
_dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/server/sulists/Mailman/Queue/IncomingRunner.py", line 153, in 
_dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/server/sulists/Mailman/Handlers/Hold.py", line 187, in process
if bodylen/1024.0 > mlist.max_message_size:
UnboundLocalError: local variable 'bodylen' referenced before assignment

Oct 13 11:47:30 2016 (12368) SHUNTING: 
1476376331.709368+f252c549b5b457fe876963e4dba623dd2047e456




E.S. Knight
Sr. Systems Programmer
Technology Services
205-726-2594 | office
eskni...@samford.edu
www.samford.edu
800 Lakeshore Drive, Birmingham, AL 35229

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


[Mailman-Users] Administrative requests page for migrated lists uses wrong old server fqdn for data submission

2016-10-13 Thread Dominik Hoffmann
My mailing lists were migrated from a machine running Mac OS X Server 10.6 
(Snow Leopard) [let's refer to it by the fdqn old-server.domain.com], where 
mailman was supplied and supported out of the box. The destination was an OS X 
Server 10.11 (El Capitan) system running Server 5.2 [let's refer to it by the 
fdqn new-server.domain.com], which required the manual installation of mailman 
from source.

I copied the requisite directories archives, data, lists and qfiles from 
/var/mailman/ to /usr/local/mailman/. I then ran

/usr/local/mailman/bin/check_perms -f

which made sure that these were given the proper permissions for the new system.

Let's say my mailing list is named "family." I can now bring up

https://new-server.domain.com/mailman/admin/family

I can change all settings to my heart's content, and they all take. However, 
when I try to "Tend to pending moderator requests" and click on the Submit All 
Data button on

https://new-server.domain.com/mailman/admindb/family

it directs me to

http://old-server.domain.com/mailman/admindb/family

which has been decommissioned.

When editing the list settings, there were references to 
"old-server.domain.com" in the host_name field on the General Options page, and 
I changed that to "new-server.domain.com".

What do I need to fix, in order for the button submission to go through 
properly?
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Administrative requests page for migrated lists uses wrong old server fqdn for data submission

2016-10-13 Thread Dominik Hoffmann
Great! Thanks, Mark!

I ran

/usr/local/mailman/bin/withlist -l -a -r fix_url

and now all my lists actually show up on the "Overview of all 
new-server.domain.com mailing lists" page.

One thing that still doesn't work is submission of the pending moderator 
requests. When I hit Submit All Data, the page simply reloads without any of 
the moderation directives having been taken into account.

Getting really close to having this thing up and running completely.

> On Oct 13, 2016, at 4:38 PM, Mark Sapiro  wrote:
> 
> On 10/13/2016 12:19 PM, Dominik Hoffmann wrote:
>> 
>> When editing the list settings, there were references to 
>> "old-server.domain.com" in the host_name field on the General Options page, 
>> and I changed that to "new-server.domain.com".
>> 
>> What do I need to fix, in order for the button submission to go through 
>> properly?
> 
> 
> You need to run Mailman's fix_url. See this FAQ
> .
> 
> -- 
> Mark Sapiro The highway is for gamblers,
> San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Administrative requests page for migrated lists uses wrong old server fqdn for data submission

2016-10-13 Thread Mark Sapiro
On 10/13/2016 01:51 PM, Dominik Hoffmann wrote:
> 
> One thing that still doesn't work is submission of the pending moderator 
> requests. When I hit Submit All Data, the page simply reloads without any of 
> the moderation directives having been taken into account.


See .

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org


Re: [Mailman-Users] Administrative requests page for migrated lists uses wrong old server fqdn for data submission

2016-10-13 Thread Mark Sapiro
On 10/13/2016 12:19 PM, Dominik Hoffmann wrote:
> 
> When editing the list settings, there were references to 
> "old-server.domain.com" in the host_name field on the General Options page, 
> and I changed that to "new-server.domain.com".
> 
> What do I need to fix, in order for the button submission to go through 
> properly?


You need to run Mailman's fix_url. See this FAQ
.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org