[Mailman-Users] mailman 2.1: lotsa language options problems...

[Chuq Von Rospach]

first of the month, and my password sending errored out again. I've 
been spending some time debugging.

it boiled down to problems with some of the language codecs, the 
multi-byte languages. So evidently that isn't really fixed on OS X, but 
I'll deal with that later.

debugging this is tough, since there's not a lot of info. I finally 
figured out that the key error listed here pointed back to a language:

[plaidworks:/Users/chuqui] mailman% /usr/bin/python -S 
/usr/local/mailman/cron/mailpasswds
Traceback (most recent call last):
   File "/usr/local/mailman/cron/mailpasswds", line 216, in ?
     main()
   File "/usr/local/mailman/cron/mailpasswds", line 200, in main
     text, poplang)
   File "/usr/local/mailman/Mailman/Message.py", line 198, in __init__
     charset = Charset(Utils.GetCharSet(lang))
   File "/usr/local/mailman/Mailman/Utils.py", line 591, in GetCharSet
     return mm_cfg.LC_DESCRIPTIONS[lang][1]
KeyError: ja

which I probably should have figured out faster, but what the heck. 
It'd be a lot easier if I could figure out which list or user record is 
affected...

But in starting to deal with all of this, I ran into other issues.

Among others:

If you change the set of supported languages for a list, it doesn't 
update user records. So even if I turn off "japanese" as an option, 
users already set up to use it get to keep it.

Worse, if you look the user up in the membership roles on the admin web 
site, the web pages report the first language in the list (on my site, 
czech or german); you have to dump the database to find out they're 
still set to ja. The system really needs to catch this change and reset 
their language to the default.

and it gets worse. I went into Defaults.py and turned off the languages 
completely, so they couldn't be turned on again accidentally until I'm 
sure they're fixed, and:

If you would like to help us identify the problem, please email a copy 
of this page to the webmaster for this site with a description of what 
happened.  Thanks!

Traceback:


Traceback (most recent call last):
   File "/usr/local/mailman/scripts/driver", line 87, in run_main
     main()
   File "/usr/local/mailman/Mailman/Cgi/admin.py", line 192, in main
     show_results(mlist, doc, category, subcat, cgidata)
   File "/usr/local/mailman/Mailman/Cgi/admin.py", line 515, in 
show_results
     form.AddItem(show_variables(mlist, category, subcat, cgidata, doc))
   File "/usr/local/mailman/Mailman/Cgi/admin.py", line 524, in 
show_variables
     options = mlist.GetConfigInfo(category, subcat)
   File "/usr/local/mailman/Mailman/MailList.py", line 413, in 
GetConfigInfo
     value = gui.GetConfigInfo(self, category, subcat)
   File "/usr/local/mailman/Mailman/Gui/Language.py", line 42, in 
GetConfigInfo
     langnames = [_(Utils.GetLanguageDescr(L)) for L in langs]
   File "/usr/local/mailman/Mailman/Utils.py", line 587, in 
GetLanguageDescr
     return mm_cfg.LC_DESCRIPTIONS[lang][0]
KeyError: big5

bang. a list still configured for big5 is now dead... I can't get into 
the admin pages at all for that list. Off to unedit defaults, restart, 
and clean up the hard way...

Basic summary: the code surrounding languages is intolerant of errors 
or changes. If there's a problem, it dies (in general, while it needs 
to flag this to the admin, I'd argue it ought to fallback to the list 
default and continue, not core dump). If things change so a user's 
choice isn't there, it shouldn't cause errors, it should regress 
gracefully to the list default -- not show random values and coredump 
cron jobs... (FWIW, anyone who has list-admin capabilities can shut 
down large parts of a mailman site by turning on a language, setting a 
language value for a subscription, and turn it off again. That's a 
security problem unless you trust all your admins).

and if the underlying defaults change, the systme can really break. all 
of this code assumes nothing is ever turned off or taken away. If it 
does, really bad things happen...







-- 
Chuq Von Rospach, Architech
chuqui at plaidworks.com -- http://www.plaidworks.com/chuqui/blog/