I'm working on upgrading this old (2.1.12) mailman installation so I can start addressing DKIM (etc.) related problems with delivery.
I've downloaded 2.1.23. To make sure I was in good shape, I ran configure and make (not 'make install'). They both worked after I installed dnspython.
However, the instructions in UPGRADING say
run 'configure' with the same options you used in your previous install
I don't know, nor does anyone else at this org, what options may have been used to configure the 2.1.12 install. Is there a way to figure it out? Or some way to determine what I might want? If I get them wrong, is there a way to know that and recover?
Thank you, Matt
On 12/06/2016 09:21 AM, Matt Morgan wrote:
run 'configure' with the same options you used in your previous install
I don't know, nor does anyone else at this org, what options may have been used to configure the 2.1.12 install. Is there a way to figure it out? Or some way to determine what I might want? If I get them wrong, is there a way to know that and recover?
The most likely options that might have been other than defaults are --prefix, --with-var-prefix, --with-mail-gid, --with-cgi-gid, --with-mailhost and --with-urlhost.
You can run './configure --help' for the full list.
You can tell what to set for --prefix and maybe --with-var-prefix if different by looking at where things are in your current install.
--with-mailhost and --with-urlhost set the values of DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST respectively in Defaults.py.
--with-mail-gid and --with-cgi-gid set the expected groups that the MTA will invoke the mail wrapper with and the web server will invoke the web CGIs with respectively. See <https://wiki.list.org/x/4030645>. You can run strings on your existing mail/mailman and cgi-bin/* wrappers to get a clue if you don't know.
If your web urls are like http://example.com/mailman/listinfo.ext instead of just http://example.com/mailman/listinfo, you need '--with-cgi-ext=.ext'
If by any chance you have the original unpack directory, the command was logged in config.log
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, Dec 6, 2016 at 1:45 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 12/06/2016 09:21 AM, Matt Morgan wrote:
run 'configure' with the same options you used in your previous install
I don't know, nor does anyone else at this org, what options may have
been
used to configure the 2.1.12 install. Is there a way to figure it out?
You can tell what to set for --prefix and maybe --with-var-prefix if different by looking at where things are in your current install.
Thanks. --prefix is the standard, but there's nothing in /var apart from mailman's crontab. What's an example of a file that I could 'locate' to figure out what mailman is using instead of /var? Or is there another way to determine what it is?
--with-mailhost and --with-urlhost set the values of DEFAULT_EMAIL_HOST
and DEFAULT_URL_HOST respectively in Defaults.py.
Got these, thanks.
--with-mail-gid and --with-cgi-gid ...
You can
run strings on your existing mail/mailman and cgi-bin/* wrappers to get a clue if you don't know.
I tried strings on those files, and either it wasn't helpful or I am not clueful enough in the first place to know what to look for in the output. Can you offer any additional suggestions here? In case it's meaningful, I don't see any unusual-looking groups in /etc/group. There is a 'mailman' group but no users are in it. There is a 'mail' group with user 'mail' in it.
Thank you so much for your help.
--Matt
On 12/09/2016 02:27 PM, Matt Morgan wrote:
Thanks. --prefix is the standard, but there's nothing in /var apart from mailman's crontab. What's an example of a file that I could 'locate' to figure out what mailman is using instead of /var? Or is there another way to determine what it is?
Where are the archives/, data/, lists/, locks/, logs/, qfiles/ and spam/ directories. If they are in the same directory as the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories, then you don't need --with-var-prefix at all because it is the same as $prefix. If different, then the containing directory is what you need for --with-var-prefix.
If the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories are all in /usr/local/mailman, you don't need --prefix because that's the default.
Finally, if the cgi-bin/ directory is in $prefix, you don't need --exec-prefix. Otherwise, --exec-prefix is the path that contains the cgi-bin/ directory.
--with-mail-gid and --with-cgi-gid ... You can run strings on your existing mail/mailman and cgi-bin/* wrappers to get a clue if you don't know.I tried strings on those files, and either it wasn't helpful or I am not clueful enough in the first place to know what to look for in the output. Can you offer any additional suggestions here? In case it's meaningful, I don't see any unusual-looking groups in /etc/group. There is a 'mailman' group but no users are in it. There is a 'mail' group with user 'mail' in it.
Is there is a 'mailman' user? Look in your existing Defaults.py for the definitions of
MAILMAN_USER = and MAILMAN_GROUP =
If these are not 'mailman' you will need --with-username and --with-groupname options to configure to specify what they are.
The strings output is tricky because the order of things depends very much on the C compiler that built the wrappers.
Basically, --with-mail-gid is the group with which the MTA invokes the wrapper. If the MTA is Postfix and delivery is via aliases, this is the primary group of the user that owns the .db file in which the aliases are found. With the recommended Postfix-Mailman integration, this is normally 'mailman'. --with-cgi-gid is the group with which the web server invokes CGIs. This is usually something like 'www-data' or 'nobody' or 'apache'.
It's easy enough to test. If you get it wrong, you'll get group mismatch errors and the error message will tell you what you need to do.
For mail group mismatches, both the bounce message and the system mail log will have a message explaining what the group should be. E.g.
(Command died with status 2: "/var/MM/21/mail/mailman post list1". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "mark", but the system's mail server executed the mail script as group "nogroup". Try tweaking the mail server to run the script as group "mark", or re-run configure, providing the command line option `--with-mail-gid=nogroup'. )
says provide --with-mail-gid=nogroup to configure (this is a contrived test - it usually wouldn't be 'nogroup')
For CGI group mismatches a similar error message is displayed by the web browser and is written in the web server error log or maybe syslog.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
When you go to http://mail.mydomain.com/ <http://mail.mydomain.com/>, where do you wind up? I.e., whats the URL in the address bar of your browser, and is the resultant page an actual page or a 404?
I end up at https://mail.mydomain.com/listinfo <https://mail.mydomain.com/listinfo>
What happens if you go to https://mail.mydomain.com/? <https://mail.mydomain.com/?> I end up at https://mail.mydomain.com/ <https://mail.mydomain.com/>
In /etc/apache2/sites-available I have mailman.con which contains a number of redirects as follows:
<VirtualHost *:80> ServerName yugi ServerAdmin gigs@mydomain Redirect / https://mydomain/ <https://mydomain/> </VirtualHost>
<VirtualHost *:80> ServerName mydomain.us <http://mydomain.us/> ServerAdmin gigs@amydomain.com <mailto:gigs@amydomain.com> Redirect / https://mydomain.us/ <https://mydomain.us/> </VirtualHost>
<VirtualHost *:80> ServerName www.mydomain.us <http://www.mydomain.us/> ServerAdmin gigs@amydomain.com <mailto:gigs@amydomain.com> Redirect / https://mail.mydomain.us/ <https://mail.mydomain.us/> </VirtualHost>
<VirtualHost *:80> ServerName mail.mydomain.us <http://mail.mydomain.us/> ServerAdmin gigs@mydomain.com <mailto:gigs@mydomain.com> Redirect / https://mail.mydomain.us <https://mail.mydomain.us/>
ErrorLog /var/log/apache2/mailman-error.log CustomLog /var/log/apache2/mailman-access.log combined
<Directory /var/lib/cgi-bin/mailman> Options FollowSymLinks AllowOverride All Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Require all granted </Directory>
</VirtualHost>
and aliases as follows:
Alias /AUP /var/www/html/AUP Alias /pipermail/ /var/lib/mailman/archives/public/ Alias /postfixadmin /var/www/html/postfixadmin Alias /roundcube /var/www/html/roundcube Alias /images/mailman/ /usr/share/images/mailman/ ScriptAlias /admin /usr/lib/cgi-bin/mailman/admin ScriptAlias /admindb /usr/lib/cgi-bin/mailman/admindb ScriptAlias /confirm /usr/lib/cgi-bin/mailman/confirm ScriptAlias /create /usr/lib/cgi-bin/mailman/create ScriptAlias /edithtml /usr/lib/cgi-bin/mailman/edithtml ScriptAlias /listinfo /usr/lib/cgi-bin/mailman/listinfo ScriptAlias /options /usr/lib/cgi-bin/mailman/options ScriptAlias /private /usr/lib/cgi-bin/mailman/private ScriptAlias /rmlist /usr/lib/cgi-bin/mailman/rmlist ScriptAlias /roster /usr/lib/cgi-bin/mailman/roster ScriptAlias /subscribe /usr/lib/cgi-bin/mailman/subscribe ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/ ScriptAlias / /usr/lib/cgi-bin/mailman/listinfo
On Dec 9, 2016, at 3:41 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 12/09/2016 02:27 PM, Matt Morgan wrote:
Thanks. --prefix is the standard, but there's nothing in /var apart from mailman's crontab. What's an example of a file that I could 'locate' to figure out what mailman is using instead of /var? Or is there another way to determine what it is?
Where are the archives/, data/, lists/, locks/, logs/, qfiles/ and spam/ directories. If they are in the same directory as the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories, then you don't need --with-var-prefix at all because it is the same as $prefix. If different, then the containing directory is what you need for --with-var-prefix.
If the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories are all in /usr/local/mailman, you don't need --prefix because that's the default.
Finally, if the cgi-bin/ directory is in $prefix, you don't need --exec-prefix. Otherwise, --exec-prefix is the path that contains the cgi-bin/ directory.
--with-mail-gid and --with-cgi-gid ...
You can run strings on your existing mail/mailman and cgi-bin/* wrappers to get a clue if you don't know.
I tried strings on those files, and either it wasn't helpful or I am not clueful enough in the first place to know what to look for in the output. Can you offer any additional suggestions here? In case it's meaningful, I don't see any unusual-looking groups in /etc/group. There is a 'mailman' group but no users are in it. There is a 'mail' group with user 'mail' in it.
Is there is a 'mailman' user? Look in your existing Defaults.py for the definitions of
MAILMAN_USER = and MAILMAN_GROUP =
If these are not 'mailman' you will need --with-username and --with-groupname options to configure to specify what they are.
The strings output is tricky because the order of things depends very much on the C compiler that built the wrappers.
Basically, --with-mail-gid is the group with which the MTA invokes the wrapper. If the MTA is Postfix and delivery is via aliases, this is the primary group of the user that owns the .db file in which the aliases are found. With the recommended Postfix-Mailman integration, this is normally 'mailman'. --with-cgi-gid is the group with which the web server invokes CGIs. This is usually something like 'www-data' or 'nobody' or 'apache'.
It's easy enough to test. If you get it wrong, you'll get group mismatch errors and the error message will tell you what you need to do.
For mail group mismatches, both the bounce message and the system mail log will have a message explaining what the group should be. E.g.
(Command died with status 2: "/var/MM/21/mail/mailman post list1". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "mark", but the system's mail server executed the mail script as group "nogroup". Try tweaking the mail server to run the script as group "mark", or re-run configure, providing the command line option `--with-mail-gid=nogroup'. )
says provide --with-mail-gid=nogroup to configure (this is a contrived test - it usually wouldn't be 'nogroup')
For CGI group mismatches a similar error message is displayed by the web browser and is written in the web server error log or maybe syslog.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/mailinglist%40samsi.us
On Fri, Dec 9, 2016 at 6:41 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 12/09/2016 02:27 PM, Matt Morgan wrote:
Thanks. --prefix is the standard, but there's nothing in /var apart from mailman's crontab. What's an example of a file that I could 'locate' to figure out what mailman is using instead of /var? Or is there another way to determine what it is?
Where are the archives/, data/, lists/, locks/, logs/, qfiles/ and spam/ directories. If they are in the same directory as the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories, then you don't need --with-var-prefix at all because it is the same as $prefix. If different, then the containing directory is what you need for --with-var-prefix.
If the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories are all in /usr/local/mailman, you don't need --prefix because that's the default.
Finally, if the cgi-bin/ directory is in $prefix, you don't need --exec-prefix. Otherwise, --exec-prefix is the path that contains the cgi-bin/ directory.
(snipping a lot of that)
configure and make install seemed to work. I got a CGI error and corrected it, just like you said would happen.
Unfortunately, local delivery is failing for all (as far as I can tell) list addresses. What have I done? Any advice welcome.
Thanks, Matt
On Wed, Dec 21, 2016 at 10:02 PM, Matt Morgan <minxmertzmomo@gmail.com> wrote:
On Fri, Dec 9, 2016 at 6:41 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 12/09/2016 02:27 PM, Matt Morgan wrote:
Thanks. --prefix is the standard, but there's nothing in /var apart from mailman's crontab. What's an example of a file that I could 'locate' to figure out what mailman is using instead of /var? Or is there another way to determine what it is?
Where are the archives/, data/, lists/, locks/, logs/, qfiles/ and spam/ directories. If they are in the same directory as the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories, then you don't need --with-var-prefix at all because it is the same as $prefix. If different, then the containing directory is what you need for --with-var-prefix.
If the bin/, cron/, icons/, mail/, Mailman/, messages/, pythonlib/, scripts/ and tests/ directories are all in /usr/local/mailman, you don't need --prefix because that's the default.
Finally, if the cgi-bin/ directory is in $prefix, you don't need --exec-prefix. Otherwise, --exec-prefix is the path that contains the cgi-bin/ directory.
(snipping a lot of that)
configure and make install seemed to work. I got a CGI error and corrected it, just like you said would happen.
Unfortunately, local delivery is failing for all (as far as I can tell) list addresses. What have I done? Any advice welcome.
Thanks, Matt
Looks like I need --with-mail-gid=mail. Working on that now.
On 12/21/2016 07:14 PM, Matt Morgan wrote:
On Wed, Dec 21, 2016 at 10:02 PM, Matt Morgan <minxmertzmomo@gmail.com> wrote:
Unfortunately, local delivery is failing for all (as far as I can tell) list addresses. What have I done? Any advice welcome.
Thanks, Matt
Looks like I need --with-mail-gid=mail. Working on that now.
I'm guessing from these that you determined that delivery to list addresses was failing because of group mismatch error from the mail wrapper and you are addressing that.
Let us know if you need further help.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks, yes, I looked at the maillog and it was clear about what I needed to do.
I'm going to put that configure command with all its options in the org's keepass now :-).
Overall I'm really happy with how humane (fast, straightforward, understandable) this upgrade method is. Thanks!
On Thu, Dec 22, 2016 at 12:54 AM, Mark Sapiro <mark@msapiro.net> wrote:
On 12/21/2016 07:14 PM, Matt Morgan wrote:
On Wed, Dec 21, 2016 at 10:02 PM, Matt Morgan <minxmertzmomo@gmail.com> wrote:
Unfortunately, local delivery is failing for all (as far as I can tell) list addresses. What have I done? Any advice welcome.
Thanks, Matt
Looks like I need --with-mail-gid=mail. Working on that now.
I'm guessing from these that you determined that delivery to list addresses was failing because of group mismatch error from the mail wrapper and you are addressing that.
Let us know if you need further help.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/ mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/ minxmertzmomo%40gmail.com
On 12/22/2016 04:47 AM, Matt Morgan wrote:
I'm going to put that configure command with all its options in the org's keepass now :-).
Also, if you keep the source directory, the config command is recorded in the config.log file.
Overall I'm really happy with how humane (fast, straightforward, understandable) this upgrade method is. Thanks!
I'm glad it worked well for you.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Caesar Samsi -
Mark Sapiro -
Matt Morgan