Question What does "set up mailing list server" do?

[nelteren]

Server operating system version

Debian 12

Plesk version and microupdate number

18.0.73.3

I need to do this manually, so I need a complete list of what it does.

I have a server with a bunch of migrated mailing lists but this step is not done correctly nor completely by the migration tool. Backing up the database table, re-installing mailman, and restoring (or re-migrating) also doesn't work: The flag that the mailman has been configured keeps being set.

Another solution would be to manually un-set this flag. I have found no documentation on how or where to do that anywhere on the internet.

For one, there is no 'lists' subdomain configuration in the apache directory. Because the format keeps changing I'd rather not manually touch it lest it gets overwritten with the next update. The lists do exist in the plesk database, but that isn't very useful if the on-disk configuration is incomplete.

 

[nelteren]

I found another way around:

Just running:

plesk repair web -server

will re-generate the apache config properly and include the 'lists' section.

<VirtualHost 127.0.0.1:7080 127.0.0.1:7082>
        DocumentRoot "/var/www/vhosts/default/htdocs"
        ServerName lists
        ServerAlias lists.*
        UseCanonicalName Off

        Alias "/mailman3/favcion.ico" "/var/lib/mailman3/web/static/postorius/img/favicon.ico"
        Alias "/mailman3/static" "/var/lib/mailman3/web/static/"

        <IfModule mod_ssl.c>
                SSLEngine off
        </IfModule>

        <Directory /var/lib/mailman3/web/static/>

                Options FollowSymLinks
                Require all granted
        </Directory>

        <IfModule mod_proxy_uwsgi.c>
                ProxyPass /mailman3/favicon.ico !
                ProxyPass /mailman3/static !
                ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/
        </IfModule>

</VirtualHost>

Useful information below for plesk programmers and power users running into the issue:

The bug can be likely replicated by configuring two plesk servers, A and B. On server A, enable mailman in the plesk update tool, setup mailman via the link in the admin panel (as per the help file), then configure a mail list for a domain D.

Then, on server B, again enable mailman in the plesk update tool, but forget to enable mailman in the admin panel. This is pretty normal for a user that doesn't know that this is necessary doing the migration. This leaves the server in this inconsistent state as per my initial message.

Now migrate D from server A to server B... and you now have a server with a working but non-configurable mailing list (at least except for the CLI).


The code necessary to enable the web-GUI for mailman is generated by what looks like a template in /opt/psa/admin/conf/templates/default/server/mailman.php. I don't know which PHP code file is importing and echoing this template as those are encrypted, but your devs should know.

For a better user experience, the migration manager should check if the mail manager, even if it is installed, has actually been configured. I would recommend two checks:
1) Are there records in the database table psa/MailLists? If it is empty, the mail manager might not be configured.
2) Is the code above added to the apache configuration? (Check for a VirtualHost with the alias Lists* within /etc/apache2/plesk.conf.d/server.conf. If it does not exist, the mail manager is not configured.

If not, either re-generate the web-server configuration after migrating a domain with mailing lists, or re-run the mail manager configuration part of the code.

In addition to that, in general it would be better if there were exposed a method for the user (either via the cli or webGUI) to 're-do' the mail manager configuration. Currently, if 'something goes wrong' you can get your server into this inconsistent state, where plesk thinks that mailman is installed and configured... but it's only been installed, not configured. And there's no easy way to get plesk out of this state. Which is why I've read several reports of users 'fixing' the problem by re-installing the whole server. That isn't ideal.

Perhaps this option should be somewhat hidden, but it should at least be there. The c If this means losing your mailing lists... notify the user of that so they can make a backup of the relevant database table(s) (or a plesk backup of this component) and restore that after reconfiguring.