Mailman 3 October 1998 - Mailman-Developers

SMTPHOST can come in very handy
by Scott 31 Oct '98

31 Oct '98

I've got about 30 sizable lists running on mailman, all of which are majordomo converts <grin>. Though most of the listowners miss the old majordomo feature of notifying the administrator when subscribes or unsubscribes occur, they like alot of the other features alot, like automatic bounce processing, web archiving, etc. Some of the features they dont even know they like, like the fact that the site admin can define SMTPHOST. little story, that might come in handy for others one day. last night a disk problem on our main mail hub left us without what is by far our most powerful mail server. i had to set up 3 linux mail exchangers to take its place while we worked on it, and one of them was doing the outgoing mail for these 30 or so recently converted lists. So i renamed the SMTPHOST to something else and created round robbin A records for that very something else, so that whenever mailman requested delivery of outgoing mail, it randomly chose the services of 4 different machines. were i not able to do that.

1 0

Re: [Mailman-Developers] observation from a bystander :) [long and boring]
by Tomas Fasth 30 Oct '98

30 Oct '98

Peter, as a bystander myself I can certainly understand your frustration and have sometimes found myself in similar situations. But I also think you might have to lower your expectations on other people's urge to please you. Here's some basic guidelines when dealing with free software: * Don't expect someone else to do more than yourself. * Improvements are done through working code, not fancy suggestions. * Be humble to the fact that active developers are sacrificing their free time. * Your situation is of common interest only if it results in a collective benefit. * Always share your experiences, but never expect other to do the same. * The more you contribute, the more respect and honor you will receive. * If you are to criticize, make it factual and constructive. * If you want improvements, use constructive suggestions, not complains. * If your suggestions are not addressed, implement them yourself, or try to fill your needs with a different piece of software, never demand it from others. * If you get no response from the community, there is always a good reason. * Be patient. Tomas

3 2

call_scrips: wrong dir..?
by Peter Gervai 28 Oct '98

28 Oct '98

Hello, I'm fighting (with no luck, let me comment) with Oct 29 01:36:05 1998 admin: [----- Traceback ------] admin: Traceback (innermost last): admin: File "/var/lib/mailman/scripts/driver", line 97, in run_main admin: main() admin: File "../Mailman/Cgi/subscribe.py", line 96, in main admin: call_script('options', [list._internal_name, member]) admin: File "../Mailman/Cgi/subscribe.py", line 66, in call_script admin: list.Unlock() admin: AttributeError: Unlock and reached Cgi/subscribe.py, line 66 and 96, and I can't see why does it reference SCRIPTS_DIR when the supposed-to-call (i think) 'options' module isn't in there but in Mailman/Cgi/ ... Still I can't figure it out what this attr error is, as unlock works at line 95-96... and can't really see what happens there. :) (Helping hands, anyone? I'm fighting with this one all last week...) bye, g.

1 0

Re: [Mailman-Users] Bug Message
by Ken Manheimer 28 Oct '98

28 Oct '98

On Wed, 28 Oct 1998, Alvin Gunkel wrote: > I have installed mailman and Python 1.5.1 per instructions. When > trying to access the subscribe program I get the following: > > We're sorry, we hit a bug! > [...] > Traceback (innermost last): > File "/u1/mailman/scripts/driver", line 97, in run_main > main() > File "../Mailman/Cgi/subscribe.py", line 30, in main > path = os.environ['PATH_INFO'] > File "/usr/local/lib/python1.5/UserDict.py", line 12, in __getitem__ > def __getitem__(self, key): return self.data[key] > KeyError: PATH_INFO > > Environment variables: > [...] The environment variables listed, in fact, lack a PATH_INFO variable, which mailman depends upon. (What HTTP server are you using?) There is what may be an alternative: > SCRIPT_NAME > /mailman/subscribe which we could use as an alternative in our scripts for PATH_INFO, if it really is a substitute. Funny thing is, the variable either does not serve as i expect, or the value indicates that you entered an incorrect path, somewhere. My question for you is, how you are trying to get at the subscribe script? It is not supposed to be visited directly - you should be coming to it from a listinfo page for the list to which you're trying to subscribe. E.g., when subscribing to mailman-users(a)python.org, one visits: http://www.python.org/mailman/listinfo/mailman-users and enters the subscription info, then they hit the 'Subscribe' button. A that point the 'subscribe' script is visited - and then PATH_INFO should be set. If not, we'll look for a fallback setting - but i expect i would have heard of this problem before if the PATH_INFO is at all commonly left out... (In any case we may want to fix mailman so the script handle the situation better, directing the user to the right place instead of faulting.) Ken Manheimer klm(a)python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # <http://www.python.org/psa/>. #

2 1

New release of my patches
by Balazs Nagy 28 Oct '98

28 Oct '98

Hiyas, It seems I have to repatch new versions day-to-day waiting for someone who apply 'em. I would be glad if someone applies my patches - at least cmdhandler and cgiext patches. FYI cmdhandler enables administrator commands by email and cgiext handles the extensions of CGI programs (as you can read it in README but doesn't work). The third one (MTA patch) is experimental, it works for me - at home, but I didn't try it out at kva.hu. Please apply'em. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8

3 3

observation from a bystander :) [long and boring]
by Peter Gervai 27 Oct '98

27 Oct '98

Hello, As half of this day was spent exclusively with mailman I thought I finally enter this list and submit some comments. I am really disappointed that nobody reads the mailman-user list who is able to answer so complex questions that "what this and that error means". (The volume isn't THAT high there.) Since I do not know Python, don't work with it, I had almost no chance to find bugs. Since nobody helped (as later turned out: very basic!) my problems I had to waste almost a day learning Python basics, realising that I have to change code, figure out syntax, etc etc You know the story. Then inserting debug points into the program (it's hard to debug when you don't know how, remember?), and to find the problems (most of them), and realizing that it was almost the same as the one was mentioned as 'duplicate mails' at the beginning this month (apart from lots of permission problems). This could be solved in 2 minutes by someone who at least had the idea what Python is... khm. Anyway, this got solved, so excuse me my rants. However my mail on mailman-user list contained maybe some hints or ideas would have been nice to be read by at least one developer to decide whether it worths mentioning... I still hope SOMEONE will take that 2 minutes. So I realized that Scott fixed that race problem around processQueue (see? I'm a mailman pro in less than 8 hours :-)), but I don't really see why anyone would use sticky (or any special) bits for locking. Why don't use lockfiles? A simple queue.LOCKED would do fine. And this reminds me to mention that I hope that other files are locked as well, including list and subscription databases. Locking is easy. And if anyone needs ideas I could advice to see Exim mailer's locking which is rock stable even when deliveries were aborted by system freeze... Worths an inspection, if anyone needs multiple-record-locking. Oh, and for those who won't read that mail of mine out there I mention that I asked about which files and directories should be writable by cgi uid, mailman uid or both. I welcome the idea of a script checking directory and file ownership, permissions (and setting them, actually). The whole problem of mine started as I want to use mailman with Exim, and more-or-less I solved the problem, and even put a little howto on users mailing list (though nobody seem to care). This means I don't use wrappers but I'm very picky about permissions and ownerships, and things tend to die horribly when I don't figure out which dir and file should be owned who and with what permissions (unless of course I let 0666 files and 0777 dirs all over the place - which I don't). Especially rude to create a mailman.root owned rw-rw-r-- file which needs to be modified/deleted by the cgi.cgi user. I loved the permissions of the logs or the lists directory, for example. :-) Oh, and why didn't I want to write the mail here? Because I ain't no developer (um, I wasn't so far), and because I don't know Python (didn't know so far). Um, that's all. Sorry if it was too long. And I even kept it short. :) bests, grin ps: constructive criticism welcome, and flames as well by PERSONAL email. I fear that the effect will be the same as on mailman-users: silence.

1 0

confusing post requirements policy
by Scott 23 Oct '98

23 Oct '98

Recently i added an option to mailman to make it so that the list of posters that are allowed to post sans approval would or would not include the list members automatically. I have several lists using this option, and just discovered that a good deal of confusion was created over the fact that there are 3 interrelated questions on the admin cgi (and corresponding variables) that could be summed up in 2: 1) variable member_posting_only. 2) variable posters 3) posters_includes_members currently, there is not only confusion, but a problem. specifically, if member_posting_only is set, posters has some addresses in it, and posters_includes_members is set to yes, then it doesn't allow posting from non members in the posters list. It seems like it would be much more clear if there were 2 variables: member_posting (in place of member_posting_only and posters_includes_members) posters if member_posting is set to true, the addresses in posters gets added to the subscriber list to form the list of all approved posts. if member_posting is set to false, the addresses in posters are the only ones that can post without approval. this seems much simpler and more clear to me. how do people feel about this? scott

2 3

Re: [Mailman-checkins] CVS: mailman/Mailman MailList.py
by Balazs Nagy 23 Oct '98

23 Oct '98

On Tue, 20 Oct 1998, Ken Manheimer wrote: > First of all, yesterday i was confused about what the "norcv" option > is - it sounds too much like what the "nomail" option is for, and i > forgot about the "receive one's own postings" option - had to scramble > around to figure it out. I suggest something like "rcvmine" Maybe 'metoo' -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8

3 2

mm_cfg.py overwrite when upgrading intentional?
by Harald Meland 21 Oct '98

21 Oct '98

>From Mailman/Makefile.in: 44 MODULES= *.py [...] 64 install: 65 for f in $(MODULES); \ 66 do \ 67 $(INSTALL) -m $(FILEMODE) $$f $(PACKAGEDIR); \ 68 done This means that Mailman/mm_cfg.py is copied over the existing mm_cfg.py when upgrading. I don't think this is intentional, as the next lines in Makefile.in are: 69 $(INSTALL) -m $(FILEMODE) mm_cfg.py $(PACKAGEDIR)/mm_cfg.py.dist 70 if test ! -f $(PACKAGEDIR)/mm_cfg.py; \ 71 then \ 72 $(INSTALL) -m $(FILEMODE) mm_cfg.py $(PACKAGEDIR); \ 73 fi The bug is giving me problems because I'm not compiling Mailman on the same host that's running it, and therefore each upgrade messes up my DEFAULT_HOST_NAME and DEFAULT_URL. The below patch (well, hack really :) should fix this. A cleaner fix would be to rename the distributed "mm_cfg.py.in" into "mm_cfg.py.dist.in" (and thereby avoid the overwriting due to the name not ending in ".py"), but I'll leave the implementation of that to someone else. --- Mailman/Makefile.in.orig Wed Oct 21 21:26:16 1998 +++ Mailman/Makefile.in Wed Oct 21 21:26:37 1998 @@ -64,7 +64,7 @@ install: for f in $(MODULES); \ do \ - $(INSTALL) -m $(FILEMODE) $$f $(PACKAGEDIR); \ + test "$$f" = mm_cfg.py || $(INSTALL) -m $(FILEMODE) $$f $(PACKAGEDIR); \ done $(INSTALL) -m $(FILEMODE) mm_cfg.py $(PACKAGEDIR)/mm_cfg.py.dist if test ! -f $(PACKAGEDIR)/mm_cfg.py; \ -- Harald

1 0

Re: CVS: mailman/Mailman MailList.py Archiver.py
by Harald Meland 21 Oct '98

21 Oct '98

[scott(a)chronis.pobox.com] > Update of /export/public/cvsroot/mailman/Mailman > In directory anthem:/tmp/cvs-serv5888/Mailman > > Modified Files: > MailList.py Archiver.py > Log Message: > code cleanup: > moved the archivery directory checking code to > Archiver.Archiver.CheckHTMLArchiveDir() and call that from > MailList.Save(). As I'm not very familiar with python yet (and thus probably shouldn't be running bleeding edge CVS versions of Mailman :), I'm not positive that this is what's biting me. Still, here goes: When submitting changed archiving options from web_page_url/admin/<listname>/archive I get traces like this one: Traceback (innermost last): File "/local/Mailman/scripts/driver", line 103, in run_main main() File "../Mailman/Cgi/admin.py", line 159, in main ChangeOptions(lst, category, cgi_data, doc) File "../Mailman/Cgi/admin.py", line 799, in ChangeOptions lst.Save() File "/local/Mailman/Mailman/MailList.py", line 645, in Save self.CheckHTMLArchiveDir() File "/local/Mailman/Mailman/Archiver.py", line 249, in CheckHTMLArchiveDir self.LogMsg("CheckHTMLArchiveDir: error getting archive mode for %s!: %s\n", File "/local/Mailman/Mailman/MailList.py", line 675, in LogMsg logf.write("%s\n" % (msg % args)) TypeError: not all arguments converted on the first submit. Additional submits work OK. The options actually get changed on the first submit, but the tracebacks are kinda annoying :) I have glanced at the code in question, but the only thing that looked suspicious to my untrained python eyes was at the end of Mailman/Archiver.py: 236 if self.archive_private: 237 if mode != 0770: 238 try: 239 ou = os.umask(0) 240 os.chmod(self.archive_directory, 02770) Doesn't this imply that the chmod is done even if the mode already is 02770? If so, the same goes for public archives, too. BTW, is there any easy way of renaming a Mailman list (i.e. not in the MTA aliases)? -- Harald

1 0