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.
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
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.
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/>. #
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
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.
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
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
>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
[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
