S I finally decide to sit down and try to figure out why http://www.team.net/mailman/admin and http://autox.team.net/mailman/admin return different results, even though it is the same machine.
Checking on some list configs, I do bin/config_list -o - <listname> and get this from one list, but not others:
[...] # href="?VARHELP=privacy/sender/dmarc_moderation_action"> # dmarc_moderation_action applies to this message with an action other # than Accept, that action rather than this is applied Traceback (most recent call last): File "./config_list", line 364, in <module> main() File "./config_list", line 357, in main do_output(listname, outfile) File "./config_list", line 128, in do_output do_list_categories(mlist, k, None, outfp) File "./config_list", line 180, in do_list_categories value = getattr(mlist, varname) File "/local/mailman/teamnet/Mailman/MailList.py", line 146, in __getattr__ raise AttributeError, name AttributeError: from_is_list
So I go to the admin page for that list and get the "We've hit a bug page."
Fun. Any quick fixes to the config.pck file?
mjb.
As an added bit of info, the first 7 of 67 lists, in alphabetical order all have this problem. Maybe I just need to reinstall 2.1.18-1
mjb.
On 08/16/2014 03:43 PM, Mark J Bradakis wrote:
S I finally decide to sit down and try to figure out why http://www.team.net/mailman/admin and http://autox.team.net/mailman/admin return different results, even though it is the same machine.
See the FAQ at <http://wiki.list.org/x/lYA9>.
Checking on some list configs, I do bin/config_list -o - <listname> and get this from one list, but not others:
[...] # href="?VARHELP=privacy/sender/dmarc_moderation_action"> # dmarc_moderation_action applies to this message with an action other # than Accept, that action rather than this is applied Traceback (most recent call last): File "./config_list", line 364, in <module> main() File "./config_list", line 357, in main do_output(listname, outfile) File "./config_list", line 128, in do_output do_list_categories(mlist, k, None, outfp) File "./config_list", line 180, in do_list_categories value = getattr(mlist, varname) File "/local/mailman/teamnet/Mailman/MailList.py", line 146, in __getattr__ raise AttributeError, name AttributeError: from_is_list
So I go to the admin page for that list and get the "We've hit a bug page."
Fun. Any quick fixes to the config.pck file?
There is an issue with the list's data_version attribute vs. Mailman.Version.DATA_FILE_VERSION. When the from_is_list and other new attributes were added, Mailman.Version.DATA_FILE_VERSION was incremented to make it greater than the list's data_version attribute which in turn will cause the lists to be updated the first time they are instantiated.
Perhaps you had some other patches that incremented Mailman.Version.DATA_FILE_VERSION, so that the list's data_version attribute was not < Mailman.Version.DATA_FILE_VERSION causing the update to be skipped.
The way to fix this is to set Mailman.Version.DATA_FILE_VERSION to a value greater than the data_version attribute of the lists.
First run this bash script
for l in /path/to/mailman/bin/list_lists --bare
do /path/to/mailman/bin/dumpdb /path/to/mailman/lists/$l/config.pck
| grep data_version
done
This will print the data_version for each list. If N is the largest such value, edit Mailman/Version.py to change the line
DATA_FILE_VERSION = 104
to set a value > N. Then visit the listinfo overview page which should update all the lists.
Then so this doesn't happen again, set DATA_FILE_VERSION back to 104 in Mailman/Version.py and create a file containing the single line
mlist.data_version = 104
and run this bash script
cd /path/to/mailman/bin/
for l in ./list_lists --bare
do ./config_list -i /path/to/above/file $l
done
That should fix things.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
There is an issue with the list's data_version attribute vs. Mailman.Version.DATA_FILE_VERSION. When the from_is_list and other new attributes were added, Mailman.Version.DATA_FILE_VERSION was incremented to make it greater than the list's data_version attribute which in turn will cause the lists to be updated the first time they are instantiated.
Perhaps you had some other patches that incremented Mailman.Version.DATA_FILE_VERSION, so that the list's data_version attribute was not < Mailman.Version.DATA_FILE_VERSION causing the update to be skipped.
The way to fix this is to set Mailman.Version.DATA_FILE_VERSION to a value greater than the data_version attribute of the lists.
First run this bash script
for l in
/path/to/mailman/bin/list_lists --bare
do /path/to/mailman/bin/dumpdb /path/to/mailman/lists/$l/config.pck
| grep data_version doneThis will print the data_version for each list. If N is the largest such value, edit Mailman/Version.py to change the line
DATA_FILE_VERSION = 104
to set a value > N. Then visit the listinfo overview page which should update all the lists.
Then so this doesn't happen again, set DATA_FILE_VERSION back to 104 in Mailman/Version.py and create a file containing the single line
mlist.data_version = 104
and run this bash script
cd /path/to/mailman/bin/ for l in
./list_lists --bare
do ./config_list -i /path/to/above/file $l doneThat should fix things.
The problem lists all have 98 as the data_version. Config_list does not work, for input or output.
mjb.
On 08/16/2014 07:20 PM, Mark J Bradakis wrote:
The problem lists all have 98 as the data_version. Config_list does not work, for input or output.
I understood that config_list wouldn't work. That's why I suggested that you need first to fix the lists by changing DATA_FILE_VERSION in Mailman/Version.py and then instantiating the lists to fix them.
However, There would seem to be other issues.
You say the problem lists all have data_version = 98 (Mailman 2.1.14). What do the other lists have? What is DATA_FILE_VERSION in Mailman/Version.py? If it is > 98 an Mailman/versions.py is at least as new as 2.1.16, the lists should get a from_is_list attribute and have data_version updated when they are instantiated.
Perhaps reinstalling 2.1.18-1 would help, as something seems amiss.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
I understood that config_list wouldn't work. That's why I suggested that you need first to fix the lists by changing DATA_FILE_VERSION in Mailman/Version.py and then instantiating the lists to fix them.
I guess I am not understanding what you mean by instantiating existing lists. All the others have version 104, as does the Version.py file.
mjb.
On 08/16/2014 08:04 PM, Mark J Bradakis wrote:
I guess I am not understanding what you mean by instantiating existing lists. All the others have version 104, as does the Version.py file.
Anything you do which accesses a list's config.pck via Mailman/MailList.py (which is pretty much any Mailman process other than bin/dumpdb) will test if Mailman.Version.DATA_FILE_VERSION is greater than the list's data_version and if so, will run Mailman.versions.Update() to update the list configuration, add new attributes, etc.
Clearly this is not happening in your case because the from_is_list attribute is not being added.
Does your Mailman/versions.py contain
PreferStored('author_is_list', 'from_is_list',
mm_cfg.DEFAULT_FROM_IS_LIST)
at lines 317,318?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Anything you do which accesses a list's config.pck via Mailman/MailList.py (which is pretty much any Mailman process other than bin/dumpdb) will test if Mailman.Version.DATA_FILE_VERSION is greater than the list's data_version and if so, will run Mailman.versions.Update() to update the list configuration, add new attributes, etc.
Clearly this is not happening in your case because the from_is_list attribute is not being added.
Indeed. I can go to the listinfo page, click on the archives for the bad lists, browse the archives, no problem. Go to get a password reminder mailed to me, it claims to work but nothing is actually sent out.
Does your Mailman/versions.py contain
PreferStored('author_is_list', 'from_is_list', mm_cfg.DEFAULT_FROM_IS_LIST)
at lines 317,318?
Yes.
mjb.
On 08/16/2014 08:34 PM, Mark J Bradakis wrote:
Indeed. I can go to the listinfo page, click on the archives for the bad lists, browse the archives, no problem.
And after doing this is the list's data_version still 98? If so, I suspect some permissions issue or something like that?
What's in Mailman's 'error' log?
Go to get a password reminder mailed to me, it claims to work but nothing is actually sent out.
This can happen if the email address you entered is not a list member. What's in Mailman's 'mischief' log?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 08/17/2014 06:45 AM, Mark Sapiro wrote:
On 08/16/2014 08:34 PM, Mark J Bradakis wrote:
Indeed. I can go to the listinfo page, click on the archives for the bad lists, browse the archives, no problem.
And after doing this is the list's data_version still 98? If so, I suspect some permissions issue or something like that?
Can you go to the admin page for the list? If so, does the from_is_list setting appear there?
Have you run bin/check_perms?
Does your Mailman web UI go to the right installation?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Can you go to the admin page for the list? If so, does the from_is_list setting appear there?
Sort of. I get the login page for the list just fine, type in the password then get the 'hit a bug' page.
Error log shows:
admin(2802): File "/local/mailman/teamnet/Mailman/MailList.py", line 146, in __getattr__ admin(2802): raise AttributeError, name admin(2802): AttributeError: from_is_list
mjb.
Mark Sapiro wrote:
On 08/16/2014 08:34 PM, Mark J Bradakis wrote:
Indeed. I can go to the listinfo page, click on the archives for the bad lists, browse the archives, no problem.
And after doing this is the list's data_version still 98? If so, I suspect some permissions issue or something like that?
Yes, the data_version remains unchanged. The first thing I did was run check_perms, nothing showed up there.
What's in Mailman's 'error' log?
Actually something did change. Instead of 'from_is_list' the error now is 'dmarc_moderation_action'
Go to get a password reminder mailed to me, it claims to work but nothing is actually sent out.
This can happen if the email address you entered is not a list member. What's in Mailman's 'mischief' log?
I used an address I know is a list member, nothing related to it in mischief log.
The last time I had a really weird problem like this it turned out to be some bad disk blocks in the mailman tree. I may take the machine to single user and do some disk checks.
mjb.
On August 17, 2014 11:32:52 AM PDT, Mark J Bradakis <mark@bradakis.com> wrote:
Mark Sapiro wrote:
On 08/16/2014 08:34 PM, Mark J Bradakis wrote:
Indeed. I can go to the listinfo page, click on the archives for the
bad
lists, browse the archives, no problem.
And after doing this is the list's data_version still 98? If so, I suspect some permissions issue or something like that?
Yes, the data_version remains unchanged. The first thing I did was run check_perms, nothing showed up there.
What's in Mailman's 'error' log?
Actually something did change. Instead of 'from_is_list' the error now is 'dmarc_moderation_action'
Go to get a password reminder mailed to me, it claims to work but nothing is actually sent out.
This can happen if the email address you entered is not a list
member. What's in Mailman's 'mischief' log?
I used an address I know is a list member, nothing related to it in mischief log.
The last time I had a really weird problem like this it turned out to be some bad disk blocks in the mailman tree. I may take the machine to single user and do some disk checks.
This is really weird. A few things come to mind. Perhaps data_version in the file is not a integer but Is a string or something with some white space that compares greater than 10 4.
Maybe there is some hardware or system disk caching problem.
If you installed from a package you might contact the packager.
Otherwise you might compare your Mailman/MailList.py and Mailman/versions.py with the ones in the source tarball.
I am now going off line for 2 weeks.
-- Mark Sapiro <mark@msapiro.net> Sent from my Android phone with K-9 Mail. [Unpaid endorsement]
participants (2)
-
Mark J Bradakis
-
Mark Sapiro