I think neither mailman ebuild does all it's needed to be done in order to manage to get mailman to work nor documentation provides all the information. After emerging it and configuring apache (with "ebuild /usr/portage/net-mail/mailman/mailmain-xxx.ebuild config" -- only the first time you install it), this is what you must do (only some of this things are included in README.gentoo.gz): 1) Add "-D MAILMAN" in APACHE_OPTS at /etc/conf.d/apache 2) Become mailman: "su - mailman" 3) Add the crontabs: cd cron; crontab crontab.in; cd .. 4) Still as mailman, create the site pass: bin/mmsitepass and main list: bin/newlist mailman 5) Add this to /etc/mail/aliases (and see point 9 for notes): mailman: "|/usr/local/mailman/mail/mailman post mailman" mailman-admin: "|/usr/local/mailman/mail/mailman admin mailman" mailman-bounces: "|/usr/local/mailman/mail/mailman bounces mailman" mailman-confirm: "|/usr/local/mailman/mail/mailman confirm mailman" mailman-join: "|/usr/local/mailman/mail/mailman join mailman" mailman-leave: "|/usr/local/mailman/mail/mailman leave mailman" mailman-owner: "|/usr/local/mailman/mail/mailman owner mailman" mailman-request: "|/usr/local/mailman/mail/mailman request mailman" mailman-subscribe: "|/usr/local/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/usr/local/mailman/mail/mailman unsubscribe mailman" and then run newaliases. 6) As root, copy the web icons: cp /usr/local/mailman/icons/* /home/httpd/icons 7) Start the mailman daemon: /etc/init.d/mailman start and add it to default runlevel (optional but recommended): rc-update add mailman default 8) For each list created (either with web interface or with bin/newlist) this must be added to /etc/mail/aliases (see point 9 for notes): <list-name>: "|/usr/local/mailman/mail/mailman post <list-name>" <list-name>-admin: "|/usr/local/mailman/mail/mailman admin <list-name>" <list-name>-bounces: "|/usr/local/mailman/mail/mailman bounces <list-name>" <list-name>-confirm: "|/usr/local/mailman/mail/mailman confirm <list-name>" <list-name>-join: "|/usr/local/mailman/mail/mailman join <list-name>" <list-name>-leave: "|/usr/local/mailman/mail/mailman leave <list-name>" <list-name>-owner: "|/usr/local/mailman/mail/mailman owner <list-name>" <list-name>-request: "|/usr/local/mailman/mail/mailman request <list-name>" <list-name>-subscribe: "|/usr/local/mailman/mail/mailman subscribe <list-name>" <list-name>-unsubscribe: "|/usr/local/mailman/mail/mailman unsubscribe <list-name>" of course, <list-name> must be replaced with the name of the list. Then run newaliases. 9) Important: If you are using srmsh with sendmail (if you use sendmail, you are surely using srmsh) you must note that sendmail won't run any program outside of EBINDIR. I tried to change EBINDIR using define(`confEBINDIR', `/usr/local/mailman/mail')dnl in sendmail.mc but it didn't work, so mailman must be placed in EBINDIR, which in Gentoo is /usr/adm/sm.bin, so you must run as root: ln -s mailman /usr/adm/sm.bin/mailman and then, these lines in /etc/mail/aliases which refer to /usr/local/mailman/mail/mailman must be changed to mailman: <list-name>: "|mailman post <list-name>" <list-name>-admin: "|mailman admin <list-name>" <list-name>-bounces: "|mailman bounces <list-name>" <list-name>-confirm: "|mailman confirm <list-name>" <list-name>-join: "|mailman join <list-name>" <list-name>-leave: "|mailman leave <list-name>" <list-name>-owner: "|mailman owner <list-name>" <list-name>-request: "|mailman request <list-name>" <list-name>-subscribe: "|mailman subscribe <list-name>" <list-name>-unsubscribe: "|mailman unsubscribe <list-name>" I don't know if there is any other problem with other MTAs because I only use Sendmail I think I didn't forget anything. See you.
Well, of course, when I said ln -s mailman /usr/adm/sm.bin/mailman I meant ln -s /usr/local/mailman/mail/mailman /usr/adm/sm.bin/mailman
The README.gentoo has been updated. Please let me know if i have any errors.
I am currently unable to resolve the dreaded mailman GID problem (using 2.1.2, r1 doesn't seem to be in the portage tree for me yet); after following this step: ln -s /usr/local/mailman/mail/mailman /usr/adm/sm.bin/mailman and subsequently (for good measure): chown root:mailman /usr/adm/sm.bin/mailman chmod 2775 /usr/adm/sm.bin/mailman I am still getting the following error when posting to a list: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "mailman", but the system's mail server executed the mail script as group "daemon". Try tweaking the mail server to run the script as group "mailman", or re-run configure, providing the command line option "--with-mail-gid=daemon". Interestingly, I attempted the following command (as root): /usr/local/mailman/mail/mailman request mailman And received a similar message (but complaining about GID=root) su - mailman /usr/local/mailman/mail/mailman request mailman Behaves as expected....but wait! I thought the purpose of the set-gid bit was to get around this? Is there something wrong with my understanding of set-gid, or the way in which the mailman wrapper is determining the group? Alternatively, are there other ways to force the GID on sendmail smrsh targets? It seems to me that each MTA has a preferred GID and if you fix the mailman package specifically for sendmail it will then break somewhere else. :( Assuming no obvious permanent fix, can someone add some quick instructions for how to recompile the mailman package manually? Also, regarding the part in the howto about "confEBINDIR", the default of "/usr/adm/sm.bin" is hardcoded into smrsh (I'm sensing a pattern here).
> chown root:mailman /usr/adm/sm.bin/mailman > chmod 2775 /usr/adm/sm.bin/mailman Have you realized that doing this you are chowning the symlink? Try to do it with /usr/local/mailman/mail/mailman > su - mailman > /usr/local/mailman/mail/mailman request mailman > > Behaves as expected Did you mean that it works fine? This is not the expected if mailman isn't a member of daemon group, it may only work for daemon group users, such us daemon user. > I thought the purpose of the set-gid bit was to get around this? Is there > something wrong with my understanding of set-gid, or the way in which the > mailman wrapper is determining the group? I also though so. It seems that both you and me are wrong, aren't we? ;)
Hello. I have an annoying problem too. It is explained here. http://bugs.gentoo.org/show_bug.cgi?id=24527#c6 Any help would be much appreciated.
mailman-2.1.3 has been released. I will be re-working the ebuild for this new build and hopefully resolving this issue finally. :) If anyone wants to get the jump on this one and make an ebuild that works with sendmail/postfix/exim/*, go right ahead :)
After following the directions in mailman-2.1.2-r1.ebuild here are the things that I had to change to get this running properly (I hope) with postfix and apache. I'm sure there is a better way than this but this worked. I hope this helps catch some problems before the next ebuild. Here's a tweak for the README 2.5 cd /usr/local/mailman Also i had to change the startup script to find the executable here: /usr/local/mailman/bin/mailmanctl I also had to change the ebuild to include: --with-mail-gid=nobody Finally I had to change mailman.conf to: ScriptAlias /mailman/ "/usr/local/mailman/cgi-bin/" <Directory "/usr/local/mailman/cgi-bin/"> AllowOverride None Options None Order allow,deny Allow from all </Directory> Alias /pipermail/ "/usr/local/mailman/archives/public/" <Directory "/usr/local/mailman/archives/public/"> AllowOverride None Options ExecCGI FollowSymLinks Order allow,deny Allow from all </Directory>
After following the directions in mailman-2.1.2-r1.ebuild here are the things that I had to change to get this running properly (I hope) with postfix and apache. I'm sure there is a better way than this but this worked. I hope this helps catch some problems before the next ebuild. Here's a tweak for the README 2.5 cd /usr/local/mailman Also i had to change the startup script in init.d to find the executable here: /usr/local/mailman/bin/mailmanctl I also had to change the ebuild to: --with-mail-gid=nobody Finally I had to change mailman.conf to: ScriptAlias /mailman/ "/usr/local/mailman/cgi-bin/" <Directory "/usr/local/mailman/cgi-bin/"> AllowOverride None Options None Order allow,deny Allow from all </Directory> Alias /pipermail/ "/usr/local/mailman/archives/public/" <Directory "/usr/local/mailman/archives/public/"> AllowOverride None Options ExecCGI FollowSymLinks Order allow,deny Allow from all </Directory>
Is there a missing dependancy? root # cd /usr/local/mailman mailman # bin/mmsitepass Traceback (most recent call last): File "bin/mmsitepass", line 44, in ? import paths File "bin/paths.py", line 55, in ? import japanese ImportError: No module named japanese Emerging cjkcodecs didn't seem to help. ebuild 2.1.3
japanesecodecs is probably the one you want. however, it is masked and will probably be superceded by cjkcodecs.
Aye. I emerged cjkcodecs after digging around and seeing japanese codecs was masked. Clearly cjkcodecs is not itself sufficient. Will try emerging the masked build.
mailman requires both koreancodecs and japanesecodecs. While there may be cjk equivalents, it'd probably require, I imagine, either interface for import korean and import japanese, or patching mailman. For now, commented out those in package.mask
i've just been emailing the author for cjkcodecs. he's pointed me to this thread that says the newest cjkcodecs should work as a drop in replacement for japanesecodecs and that the newest mailman (maybe it is cvs) has this japanesecodecs/koreancodecs problem fixed. http://mail.python.org/pipermail/email-sig/2003-November/000041.html http://mail.python.org/pipermail/email-sig/2003-December/000043.html
http://sourceforge.net/tracker/index.php?func=detail&aid=852347&group_id=5470&atid=105470 actually, to clarify my last comment, mailman can be made to work with cjkcodecs, and a patch is waiting to be applied to the latest mailman.
oops sorry, ignore the last comment i made. i believe the required code is in the latest mailman, the sourceforge link was for a python-proper patch. that was my domain.
so what to do now with this bug ?
*** Bug 32647 has been marked as a duplicate of this bug. ***
for japanese error see also bug #34727
all fixed in cvs with 2.1.4
