First-time installation: Are steps missing from the documentation?

[UnixRonin]

I am endeavoring to migrate a couple of small private mailing lists from Mailman to Sympa for technical reasons. I've gotten most of the way through installation without major problems, but run into a roadblock at initializing the database. Database permissions are working, and sympa.pl --health_check correctly created the sympa schema. I'm at the point of starting sympa for the first time, but it will not start, insisting that I must run sympa.pl --upgrade first. However, sympa.pl --upgrade fails — badly — because it has no old version to upgrade from.

minbar:root:~:2 # sympa.pl --upgrade notice main:: Sympa 6.2.56 Started notice main:: Upgrade process... Use of uninitialized value $options{"from"} in string eq at /usr/sbin/sympa.pl line 861. notice main:: Upgrading from to 6.2.56... Use of uninitialized value $v2 in split at /usr/lib64/sympa/Sympa/Upgrade.pm line 2215. Use of uninitialized value $tab2[0] in pattern match (m//) at /usr/lib64/sympa/Sympa/Upgrade.pm line 2228. Use of uninitialized value $tab2[0] in pattern match (m//) at /usr/lib64/sympa/Sympa/Upgrade.pm line 2230. Use of uninitialized value in string eq at /usr/lib64/sympa/Sympa/Upgrade.pm line 2234. Use of uninitialized value in numeric lt (<) at /usr/lib64/sympa/Sympa/Upgrade.pm line 2240. Use of uninitialized value $v1 in split at /usr/lib64/sympa/Sympa/Upgrade.pm line 2214. ...

It appears that what is missing is a step to initially populate the new, empty sympa database for the first time. Is this something that sympa.pl --upgrade or sympa.pl --health_check SHOULD be doing, but isn't? Or is there a step missing from the install documentation?

Either way, it appears the --upgrade option does not include any check for a valid "old" version and fails on an empty database.

[racke]

On 10/27/20 6:22 PM, Phil Stracchino wrote:

I am endeavoring to migrate a couple of small private mailing lists from Mailman to Sympa for technical reasons. I've gotten most of the way through installation without major problems, but run into a roadblock at initializing the database. Database permissions are working, and sympa.pl --health_check correctly created the sympa schema. I'm at the point of starting sympa for the first time, but it will not start, insisting that I must run sympa.pl --upgrade first. However, sympa.pl --upgrade fails — badly — because it has no old version to upgrade from.

minbar:root:~:2 # sympa.pl --upgrade notice main:: Sympa 6.2.56 Started notice main:: Upgrade process... Use of uninitialized value $options{"from"} in string eq at /usr/sbin/sympa.pl line 861. notice main:: Upgrading from to 6.2.56... Use of uninitialized value $v2 in split at /usr/lib64/sympa/Sympa/Upgrade.pm line 2215. Use of uninitialized value $tab2[0] in pattern match (m//) at /usr/lib64/sympa/Sympa/Upgrade.pm line 2228. Use of uninitialized value $tab2[0] in pattern match (m//) at /usr/lib64/sympa/Sympa/Upgrade.pm line 2230. Use of uninitialized value in string eq at /usr/lib64/sympa/Sympa/Upgrade.pm line 2234. Use of uninitialized value in numeric lt (<) at /usr/lib64/sympa/Sympa/Upgrade.pm line 2240. Use of uninitialized value $v1 in split at /usr/lib64/sympa/Sympa/Upgrade.pm line 2214. ...

It appears that what is missing is a step to initially populate the new, empty sympa database for the first time. Is this something that sympa.pl --upgrade or sympa.pl --health_check SHOULD be doing, but isn't? Or is there a step missing from the install documentation?

Either way, it appears the --upgrade option does not include any check for a valid "old" version and fails on an empty database.

If you install Sympa for the first time, it creates the necessary tables but no records are added. This happens when you login as listmaster or interact from the commandline (e.g. creating a new list).

It also adds a file with the current version (usually /etc/sympa//etc/data_structure.version). This is used for future upgrades.

So apparently this file is missing or it is not readable by the user executing sympa.pl.

Certainly you should not use root to execute sympa.yml.

Aside from that it looks like a bug to me that Sympa doesn't bailed out when it cannot determine the "from" version.

Regards Racke

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sympa-community/sympa/issues/1026, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABDCPQ7SAKJRE3Z5LEHMSDSM3XVNANCNFSM4TBCCW2A.

-- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.

[UnixRonin]

OK, I see an /etc/sympa/data_structure.version file. It has the following contents:

# This file is automatically created by sympa.pl after installation
# Unless you know what you are doing, you should not modify it
6.2.56

and has mode 640 sympa:sympa. (/etc/sympa has mode 0755 sympa:sympa.)

So everything looks correct that far.

[racke]

Ok can you share the verbatim errors if you start sympa? Which distribution do you use?

[UnixRonin]

I'm running on Gentoo. And .... huh. This time the service seems to have started up successfully:

minbar:root:/etc/sympa:7 # rc-service sympa start
 * Caching service dependencies ...                                                                                                                                  [ ok ]
Starting Sympa subsystems:
 * Starting Sympa module sympa_msg.pl:  ...                                                                                                                          [ ok ]
 * Starting Sympa module bulk.pl:  ...                                                                                                                               [ ok ]
 * Starting Sympa module archived.pl:  ...                                                                                                                           [ ok ]
 * Starting Sympa module bounced.pl:  ...                                                                                                                            [ ok ]
 * Starting Sympa module task_manager.pl:  ...                                                                                                                       [ ok ]
minbar:root:/etc/sympa:8 # pgrep -alf sympa
19189 /usr/bin/perl /usr/sbin/sympa_msg.pl

I don't know what's different between this time and the last time I tried to start it. I haven't changed anything that I think is relevant.

Now I think I just need to check that the Postfix integration is set up correctly and working, and I MIGHT be all set.

[UnixRonin]

I think it's working, but I need to test more. SHOULD there be any problem with using lmdb: maps instead of hash: maps, or does sympa really need them to be hash: ?

[UnixRonin]

So far so good: Postfix still functioning, Sympa web interface not functioning yet.

[UnixRonin]

OK then, sympa itself appears to be running but its fcgi service is failing to start correctly. I'm getting the following error:

[Tue Oct 27 15:54:49.802044 2020] [proxy:error] [pid 6247:tid 140493455345408] (111)Connection refused: AH02454: FCGI: attempt to connect to Unix domain socket /var/run/sympa/wwsympa.socket (*) failed

It looks as though the fastcgi process is starting up and spawning children, then silently dying. It also looks as though the line:

            pid=`cat ${FCGI_PID_DIR}/wwsympa.pid | perl -pe0777 'chomp $_; s/\s+/|/g'`

in /etc/init.d/wwsympa does not work. The wwsympa.pid file exists and contains five process IDs, none of which are running. I've tried configuring fcgi to run as sympa:sympa and as apache:apache and both behave the same way.

[ikedas]

Hi @UnixRonin ,

... I'm at the point of starting sympa for the first time, but it will not start, insisting that I must run sympa.pl --upgrade first. ...

Could you please share (1) the actual procedure you performed to "start sympa for the first time" and (2) the verbatim errors "insisting that you must run sympa.pl --upgrade first" ?

[UnixRonin]

Hi @UnixRonin ,

... I'm at the point of starting sympa for the first time, but it will not start, insisting that I must run sympa.pl --upgrade first. ...

Could you please share (1) the actual procedure you performed to "start sympa for the first time" and (2) the verbatim errors "insisting that you must run sympa.pl --upgrade first" ?

@ikedas, thanks for weighing in. I GLADLY would, but having seemingly progressed beyond that failure (though I don't profess to understand why it suddenly went from not-working to working), I don't wish to backtrack. The command used on Gentoo to start the Sympa service itself is 'rc-service sympa start', and now it starts without issue.

The point I'm currently at is that everything SEEMS to be working EXCEPT for fastcgi, which is dying on launch and leaving behind its pidfile and no other clues whatsoever. According to the documentation fastcgi is required for the web UI. (I'm running on Apache 2.4.46 and Perl 5.30.3 with the backing database on mariaDB 10.4.13.)

I haven't tested Sympa itself from cli without going through the web UI; I was hoping to have the web UI working before I started testing in earnest.

[UnixRonin]

The best answer I have to the 'exact procedure' question is that I followed the documented install instructions in the Sympa Administration Manual directly from github, following the branches for Apache 2.4+, MySQL, and sysvinit (actually, I'm running OpenRC, but sysvinit is close enough), up to the section 'start mailing list service', which was not working but now mysteriously is. It's only now that the sympa service is started that I discovered that fastcgi is not working.

[ikedas]

@UnixRonin , it's not the best. Because, as the manual describes, there are more than one ways to setup Sympa. Could you please share the links to pages and sections you followed? And because you must have to modify description in the manual to fit with your machine ("Wow, what the hell is this $EXECCGIDIR?"). Could you please share the actual content of configuration files for Sympa, HTTP server and so on?

[UnixRonin]

Sure. As best I recall. Package installation - well,you don't have a Gentoo section. I managed to find the slonko overlay, added that, and then just had to 'emerge -avuDN net-mail/sympa', which also auto-installed all of the Perl packages as dependencies. I checked the installation per https://sympa-community.github.io/manual/install/install-dependent-modules.html anyway. On to https://sympa-community.github.io/manual/install/generate-initial-configuration.html from there. My /etc/sympa/sympa.conf:

########################################################################
# Initial configuration
# See https://sympa-community.github.io/manual/install/generate-initial-configuration.html
########################################################################

domain              caerllewys.net
listmaster          phils@caerllewys.net,alaric@caerllewys.net
#lang               en-US

########################################################################
# Setup database
# See https://sympa-community.github.io/manual/install/setup-database.html
########################################################################

db_type             MySQL
db_name             sympa
db_host             localhost
db_port             3307
db_user             sympa
db_passwd           SympaTHIGHS
#db_env

########################################################################
# Configure system log
# See https://sympa-community.github.io/manual/install/configure-system-log.html
########################################################################

#syslog              LOCAL1
#log_socket_type     unix

########################################################################
# Configure mail server
# See https://sympa-community.github.io/manual/install/configure-mail-server.html
########################################################################

sendmail_aliases    /etc/sympa/sympa_aliases
aliases_program     postmap
aliases_db_type     lmdb
#sendmail            /usr/sbin/sendmail
#sendmail_args       (if you use sendmail(1), this need not change)

########################################################################
# Configure HTTP server
# See https://sympa-community.github.io/manual/install/configure-http-server.html
########################################################################

#mhonarc             /usr/bin/mhonarc
#log_facility        LOCAL1

# If you chose single domain setting, you may have to define following
# parameters in this sympa.conf file.  Otherwise, if you chose virtual
# domain setting (recommended), you should define them in robot.conf by
# each domain.

wwsympa_url         https://www.caerllewys.net/sympa/

########################################################################
# Customizing Sympa
# You can customize Sympa, its web interface and/or SOAP/HTTP service
# defining more parameters in this file sympa.conf or robot.conf by each
# domain.
# For more details see https://sympa-community.github.io/manual/customize.html
########################################################################

queuebounce /var/spool/sympa/qbounce

# Upgrade from  to 6.2.56
# 27 Oct 2020 at 12:17:06
shared_feature on

From there, onward to https://sympa-community.github.io/manual/install/setup-database-mysql.html Followed by https://sympa-community.github.io/manual/install/configure-system-log.html

# Sympa
local1.*            -/var/log/sympa.log

Then https://sympa-community.github.io/manual/install/configure-mail-server-postfix.html

Relevant config sections from master.cf:

sympa   unix    -       n       n       -       -       pipe
   flags=hqRu null_sender= user=sympa argv=/usr/libexec/sympa/queue ${nexthop}
sympabounce unix -      n       n       -       -       pipe
  flags=hqRu null_sender= user=sympa argv=/usr/libexec/sympa/bouncequeue ${nexthop}

And main.cf:

local_recipient_maps =      unix:passwd.byname
                            $alias_maps

alias_maps =                lmdb:/etc/postfix/aliases
                            lmdb:/var/lib/mailman/data/aliases
                            lmdb:/etc/sympa/sympa_aliases

alias_database =            lmdb:/etc/postfix/aliases
                            lmdb:/var/lib/mailman/data/aliases
                            lmdb:/etc/sympa/sympa_aliases

transport_maps =            lmdb:/etc/postfix/transport
                            lmdb:/etc/sympa/transport.sympa
                            lmdb:/etc/sympa/sympa_transport

relay_recipient_maps =      lmdb:/etc/postfix/relay_recipients

virtual_alias_maps =        lmdb:/etc/sympa/virtual.sympa

virtual_mailbox_domains =   lmdb:/etc/sympa//transport.sympa

virtual_mailbox_maps =      lmdb:/etc/sympa/transport.sympa
                            lmdb:/etc/sympa/sympa_transport
                            lmdb:/etc/sympa/virtual.sympa

Then to https://sympa-community.github.io/manual/install/configure-http-server.html and https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html

httpd.conf section:

<IfDefine PROXY>
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
</IfDefine>

vhost section:

        SetHandler "proxy:unix:/var/run/sympa/wwsympa.socket|fcgi://"
        Require all granted
    </Location>

    <Location /static-sympa>
        Require all granted
    </Location>

    Alias /static-sympa /var/spool/sympa/static_content

I used https://sympa-community.github.io/manual/examples/initscripts/wwsympa to start the service, with the following configuration section:

FCGI_CHILDREN=5
FCGI_USER=apache
FCGI_GROUP=apache
FCGI_PID_DIR=/run/sympa
FCGI_OPTS='-s /run/sympa/wwsympa.socket -M 0640 -U apache'
if [ -e /etc/sysconfig/sympa ]; then
    . /etc/sysconfig/sympa
fi

/etc/sysconfig does not exist on Gentoo, I did not touch that section. I have tried both apache and sympa as the user and group.

From there I went on to https://sympa-community.github.io/manual/install/start-mailing-list-service.html, where step 3 was not working, but now is. I'm now on step 4, but it's not working because I cannot get wwsympa.fcgi to start and not immediately die. So I seem to have progressed from having a sympa.pl problem to having a fastcgi problem. It is possible that I may have to start fastcgi differently on Gentoo instead of using the wwsympa initscript. I'm investigating that now.

[ikedas]

1. Did you happen to install systemd to your Gentoo? If you did, follow the instruction with systemd.

2. Check if you successfully invoked wwsympa.fcgi, doing:

    # ps -ef | grep wwsympa.fcgi

3. If wwsympa.fcgi has been invoked, check configuration of HTTP server. httpd.conf contains:

            SetHandler "proxy:unix:/var/run/sympa/wwsympa.socket|fcgi://"

   but init script contains:

    FCGI_OPTS='-s /run/sympa/wwsympa.socket -M 0640 -U apache'

   You have to tweak this, modifying initscript or creating /etc/sysconfig/sympa.

[UnixRonin]

No, I am not using systemd. And yes, I've already verified that wwsympa.fcgi is not launching. The startup reports the PIDs, I check the process list immediately afterwards, and there are no wwsympa.fcgi processes running. The socket is left behind, orphaned.

Gentoo does not use /etc/sysconfig; I think that would map to /etc/conf.d.

On current Gentoo profiles, /var/run is a symbolic link to /run. So those two lines are actually functionally referencing the same location. (I think Gentoo did it that way because /var might not be mounted when the first tasks needing a piddir start. On my system /var is on the same filesystem as / so it makes no difference.)

What should be in /etc/sysconfig/sympa? That might give me some clues as to what changes I may need to make to /etc/conf.d/spawn-fcgi.sympa.

[ikedas]

Ok, wwsympa.fcgi has not been invoked.

Try invoking it manually by doing as root:

/usr/bin/spawn-fcgi -F 5 -P /var/run/sympa/wwsympa.pid \
    -u sympa -g sympa -s /var/run/sympa/wwsympa.socket -M 0600 -U nginx -- \
    /usr/libexec/sympa/wwsympa.fcgi

and see what will happen.

[UnixRonin]

OK, that spawned five processes:

minbar:root:~:1 # /usr/bin/spawn-fcgi -F 5 -P /var/run/sympa/wwsympa.pid -u sympa -g sympa -s /var/run/sympa/wwsympa.socket -M 0600 -U apache /usr/libexec/sympa/wwsympa.fcgi spawn-fcgi: child spawned successfully: PID: 23074 spawn-fcgi: child spawned successfully: PID: 23075 spawn-fcgi: child spawned successfully: PID: 23076 spawn-fcgi: child spawned successfully: PID: 23077 spawn-fcgi: child spawned successfully: PID: 23078

And two seconds later, ps ax reports that none of those processes exist:

22805 ? Rs 0:00 sshd: root@pts/4 22807 pts/4 Ss 0:00 -bash 23190 ? I 0:00 [kworker/u16:0-events_unbound] 23249 pts/4 R+ 0:00 ps ax 23647 ? S 0:00 inet_gethost 4 24106 ? I 0:00 [kworker/2:2-events] 26777 ? I 0:00 [kworker/1:2-xfs-conv/sda2]

[ikedas]

Could you please show the log of Sympa from when you spawned wwsympa.fcgi processes to when you realised they no longer was running?

[UnixRonin]

That's easy. Nothing gets logged in that less-than-two-seconds.

I just tried to manually start the fcgi again exactly as in the previous example. Here's the tail of sympa.log:

Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spindle::ProcessTask::_execute() The task Sympa::Task <date=1603997588;label=ACTION;model=purge_spools;context=*> is now useless. Removing it
Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spindle::ProcessTask::_execute() Running task Sympa::Task <date=1603997588;label=ACTION;model=purge_tables;context=*>
Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spindle::ProcessTask::do_purge_tables() 0 rows removed in tracking table
Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spindle::ProcessTask::do_next() line 5 of purge_tables: next(1604083995, ACTION)
Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spool::store() Sympa::Task <date=1604083995;label=ACTION;model=purge_tables;context=*> is stored into Sympa::Spool::Task as <1604083995.ACTION.purge_tables.sympa@caerllewys.net>
Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spindle::ProcessTask::do_next() --> new task Sympa::Task <date=1604083995;label=ACTION;model=purge_tables;context=*>
Oct 29 14:53:15 minbar task_manager[1643]: notice Sympa::Spindle::ProcessTask::_execute() The task Sympa::Task <date=1603997588;label=ACTION;model=purge_tables;context=*> is now useless. Removing it

It hasn't been written to in six and a half hours.

I'm presuming you were expecting to see wwsympa.fcgi log something to sympa.log? If so, it never gets that far. It's dying before its first log entry.

[ikedas]

... It's dying before its first log entry.

I think so, too. Perhaps it doesn't start up properly.

Please show the output by following things:

1. sympa_wizard.pl --check

2. perl -wc /usr/libexec/sympa/wwsympa.fcgi

[UnixRonin]

Huh. Well, first up, sympa_wizard flagged CGI::Fast as not installed. I'd SWEAR I saw the sympa ebuild pull that in as a dependency. Several other packages were missing that are apparently not in the dependency list in the sympa ebuild. I'm manually installing them now and will retest when done.

[ikedas]

@UnixRonin , you would be better to come back to https://sympa-community.github.io/manual/install/install-dependent-modules.html where how to check the dependent modules is described.

[UnixRonin]

OK, after fixing the module dependencies and a few minor details in the service start script for wwsympa, Sympa appears to be working. I'm proceeding on top create a test list now. Apparently the fundamental problem was that the dependency list in the ebuild was incomplete — necessarily so, because about three of the Perl packages do not exist as Gentoo ebuilds and had to be manually installed via CPAN. That's a maintenance headache I'll solve later.

Thank you for your patience in walking me through this. I thought I had all the dependencies installed and did not realize some were missing from the 95 dependency packages that net-mail/sympa pulled in.

I will contact the author and make sure he is aware that there are missing dependencies.

[UnixRonin]

Possibly the author considered them unnecessary because they are not technically required for the Sympa CORE ...

[ikedas]

Thanks for sharing your experiences!

[racke]

OK, after fixing the module dependencies and a few minor details in the service start script for wwsympa, Sympa appears to be working. I'm proceeding on top create a test list now. Apparently the fundamental problem was that the dependency list in the ebuild was incomplete — necessarily so, because about three of the Perl packages do not exist as Gentoo ebuilds and had to be manually installed via CPAN. That's a maintenance headache I'll solve later.

Thank you for your patience in walking me through this. I thought I had all the dependencies installed and did not realize some were missing from the 95 dependency packages that net-mail/sympa pulled in.

I will contact the author and make sure he is aware that there are missing dependencies.

Good, we would like to add Gentoo to our installation documentation.

[UnixRonin]

@racke, It's ... not trivial on Gentoo, because there is only an unofficial ebuild and it does not strike me as being fully complete yet.

I'm not completely out of the woods yet; some things work (the Login button for instance), but most (for instance the First Login link, the list search form, the Home button) yield only blank pages. I presume this is a sign I misconfigured something. What is it most likely that I missed?

[UnixRonin]

Actually, hold that thought, I just spotted a USE flag in the ebuild that I missed because when i STARTED, I did not realize it was important.

[UnixRonin]

OK, so the overlooked USE flag I found pulls in a couple of the packages I had already found missing, but by no means all of them.

Marcin Deranek notes that his Apache configuration instructions are badly outdated since he switched some time ago to nginx. He has no assistance to offer on what the current Apache configuration instructions should be.

My Apache configuration section is currently as follows:

    <IfDefine SYMPA>
        ScriptAlias /sympa /usr/libexec/sympa/wwsympa.fcgi
        Alias /static-sympa /var/spool/sympa/static_content

        <Location /sympa>
            SetHandler "proxy:unix:/var/run/sympa/wwsympa.socket|fcgi://"
            Options +ExecCGI
            Require all granted
        </Location>

        <Location /static-sympa>
            Require all granted
        </Location>
    </IfDefine>

At this point the front page https://www.caerllewys.net/sympa/ loads, and functions that do not change that URL work. Functions that require navigating to a different page (such as https://www.caerllewys.net/sympa//firstpasswd or https://www.caerllewys.net/sympa//search_list_request) return only blank pages. These do not appear to be actually throwing any logged errors, and the behavior does not appear to be browser-dependent.

What does this behavior suggest is most likely to be wrong? I presume I have a configuration error somewhere, but I have not been able to identify it.

[UnixRonin]

Ah, new detail noticed: functions such as firstpassword are throwing a 421 "misdirected request" result.

...
10.24.32.10 - - [30/Oct/2020:14:59:35 -0400] "GET /static-sympa/icons/logo_sympa.png HTTP/1.1" 200 24009 "https://www.caerllewys.net/sympa/" "Mozilla/5.0 (X11; Linux x86_64; rv:68.9) Gecko/20100101 Goanna/4.7 Firefox/68.9 PaleMoon/28.15.0"
10.24.32.10 - - [30/Oct/2020:14:59:35 -0400] "GET /static-sympa/icons/favicon_sympa.png HTTP/1.1" 200 5383 "https://www.caerllewys.net/sympa/" "Mozilla/5.0 (X11; Linux x86_64; rv:68.9) Gecko/20100101 Goanna/4.7 Firefox/68.9 PaleMoon/28.15.0"
10.24.32.10 - - [30/Oct/2020:14:59:37 -0400] "GET /sympa//firstpasswd HTTP/1.1" 421 1 "https://www.caerllewys.net/sympa/" "Mozilla/5.0 (X11; Linux x86_64; rv:68.9) Gecko/20100101 Goanna/4.7 Firefox/68.9 PaleMoon/28.15.0"
10.24.32.10 - - [30/Oct/2020:14:59:37 -0400] "GET /sympa//firstpasswd HTTP/1.1" 421 1 "https://www.caerllewys.net/sympa/" "Mozilla/5.0 (X11; Linux x86_64; rv:68.9) Gecko/20100101 Goanna/4.7 Firefox/68.9 PaleMoon/28.15.0"

It appears this is often encountered as an SSL-related error when a single SSL certificate is used for multiple domains. But my certificate covers only a single domain, albeit multiple hosts:

OCSP response for certificate /etc/letsencrypt/live/www.caerllewys.net/cert.pem is signed by the certificate's issuer.
OCSP certificate status for /etc/letsencrypt/live/www.caerllewys.net/cert.pem is: OCSPCertStatus.GOOD

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: www.caerllewys.net
    Serial Number: 4973ea6a3801833c33ec2034fdaaf83eff2
    Domains: www.caerllewys.net chat.caerllewys.net jabber.caerllewys.net smtp.caerllewys.net
    Expiry Date: 2020-12-25 18:40:07+00:00 (VALID: 55 days)
    Certificate Path: /etc/letsencrypt/live/www.caerllewys.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.caerllewys.net/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I've checked all relevant configuration and I APPEAR to be doing everything correct as far as I can tell.

[UnixRonin]

just enabled http/2 in hopes of fixing the problem. No joy.

[racke]

OK, so the overlooked USE flag I found pulls in a couple of the packages I had already found missing, but by no means all of them.

Marcin Deranek notes that his Apache configuration instructions are badly outdated since he switched some time ago to nginx. He has no assistance to offer on what the current Apache configuration instructions should be.

My Apache configuration section is currently as follows:

    <IfDefine SYMPA>
        ScriptAlias /sympa /usr/libexec/sympa/wwsympa.fcgi
        Alias /static-sympa /var/spool/sympa/static_content

        <Location /sympa>
            SetHandler "proxy:unix:/var/run/sympa/wwsympa.socket|fcgi://"
            Options +ExecCGI
            Require all granted
        </Location>

        <Location /static-sympa>
            Require all granted
        </Location>
    </IfDefine>

At this point the front page https://www.caerllewys.net/sympa/ loads, and functions that do not change that URL work. Functions that require navigating to a different page (such as https://www.caerllewys.net/sympa//firstpasswd or https://www.caerllewys.net/sympa//search_list_request) return only blank pages. These do not appear to be actually throwing any logged errors, and the behavior does not appear to be browser-dependent.

What does this behavior suggest is most likely to be wrong? I presume I have a configuration error somewhere, but I have not been able to identify it.

This configuration snippet looks good to me as well. Using Nginx in most cases though.

[UnixRonin]

On 10/31/20 4:21 AM, Stefan Hornburg (Racke) wrote:

My Apache configuration section is currently as follows:

|<IfDefine SYMPA> ScriptAlias /sympa /usr/libexec/sympa/wwsympa.fcgi
Alias /static-sympa /var/spool/sympa/static_content <Location
/sympa> SetHandler
"proxy:unix:/var/run/sympa/wwsympa.socket|fcgi://" Options +ExecCGI
Require all granted </Location> <Location /static-sympa> Require all
granted </Location> </IfDefine> |

[...] What does this behavior suggest is most likely to be wrong? I presume I have a configuration error somewhere, but I have not been able to identify it.

This configuration snippet looks good to me as well. Using Nginx in most cases though.

I think at this point it's an Apache problem, not a Sympa problem.

-- Phil Stracchino Babylon Communications phils@caerllewys.net phil@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958

[ikedas]

At this point the front page https://www.caerllewys.net/sympa/ loads, and functions that do not change that URL work. Functions that require navigating to a different page (such as https://www.caerllewys.net/sympa//firstpasswd or https://www.caerllewys.net/sympa//search_list_request) return only blank pages. These do not appear to be actually throwing any logged errors, and the behavior does not appear to be browser-dependent.

What does this behavior suggest is most likely to be wrong? I presume I have a configuration error somewhere, but I have not been able to identify it.

Ther value of wwsympa_url parameter in sympa.conf would be better not to have trailing solidus (/), though I don't know whther it is related to this problem or not, such as:

wwsympa_url         https://www.caerllewys.net/sympa

[UnixRonin]

Woohoo! I missed that. That appears to have fixed the 421 error that I had become certain at this point was an Apache problem.

Good catch! Probably worth documenting somewhere that that trailing slash may cause HTTP 421 errors in Apache. I had assumed that it was coming out of a minor error in my Apache configuration, NOT out of Sympa itself, and that the resulting // was cosmetic and got parsed out during URL resolution.

Confirmed that everything is now working.

[UnixRonin]

...Well, except that I can't deliver to Sympa list addresses. That's probably something in my Postfix configuration. Unless...

Does Sympa understand lmdb: maps, or is hash: a hard requirement? If so I'll have to re-enable BDB in Postfix to enable plain hash support.

[UnixRonin]

(I reconfigured to re-enable hash:, but still working on list delivery. Probably a Postfix configuration problem.)

[UnixRonin]

I've so far created a single test list, and sympa_aliases contains:

#--- caerllewys-test@caerllewys.net: list transport map created at 02 Nov 2020
caerllewys-test@caerllewys.net sympa:caerllewys-test@caerllewys.net
caerllewys-test-request@caerllewys.net sympa:caerllewys-test-request@caerllewys.net
caerllewys-test-editor@caerllewys.net sympa:caerllewys-test-editor@caerllewys.net
caerllewys-test-subscribe@caerllewys.net sympa:caerllewys-test-subscribe@caerllewys.net
caerllewys-test-unsubscribe@caerllewys.net sympa:caerllewys-test-unsubscribe@caerllewys.net
caerllewys-test-owner@caerllewys.net sympabounce:caerllewys-test@caerllewys.net

Newaliases complains that these names must be local. sympa_transport, transport.sympa, and virtual.sympa are empty. Should they be?

[UnixRonin]

SOLVED

My delivery problem was that without realizing it, I had somehow managed to mix together PART of the single-domain configuration and PART of the multiple-domain virtual configuration. In completely shocking news, this failed to work.

Once I realized that, I tore out the entire integration configuration and started over, making sure I was following ONLY the single-domain instructions. This time it took me about ten minutes to get everything working.

[ikedas]

There seems no straightforward way to use LMDB for Postfix. If you want to do, modify the instruction as below (Note that I didn't verify settings below):

• Create a shell script wrapping postmap. postmap-lmdb.sh:

  #!/bin/sh
  /usr/sbin/postmap lmdb:${1%.lmdb}
  exit $?

  and make it executable.

• Modify configuration of Sympa: sympa.conf:

  sendmail_aliases $SYSCONFDIR/sympa_transport.lmdb
  aliases_program /path/to/postmap-lmdb.sh

• At the first time create sympa_transport.lmdb instead of sympa_transport.

  touch $SYSCONFDIR/sympa_transport.lmdb
  chmod 644 $SYSCONFDIR/sympa_transport.lmdb

[UnixRonin]

Well, actually, the use for Postfix is pretty straightforward. It was Sympa that I was concerned about — whether Sympa can (or needs to) read lmdb files.

What you just said suggests that it can. I'll test it tomorrow now that I have my Postfix configuration issue solved.

[UnixRonin]

And the answer is it seems to work fine.

What I did: — Change aliases_db_type to lmdb in /etc/sympa.conf — Change /etc/postfix/main.cf alias_maps and alias_database entries from hash:/etc/sympa/sympa_aliases to lmdb:/etc/sympa/sympa_aliases — (Already done previously: Add user postfix to group sympa)

And that's it. it Just Worked.

[UnixRonin]

Oh, and of course I ran postalias lmdb:sympa_aliases the first time, and deleted sympa_aliases.db.

[UnixRonin]

OK, so. This is the short list of my notes on installing for Gentoo.

1. Add the slonko portage overlay to get net-mail/sympa: eselect repository enable slonko

2. Enable the net-mail/sympa package in /etc/portage/package.accept_keywords

3. (recommended) Set USE flags to enable wwsympa in /etc/portage/package.use: Minimum to enable wwsympa only: net-mail/sympa fastcgi Recommended to enable all features plus DKIM support: net-mail/sympa dkim fastcgi soap Add additional USE flags as appropriate to your environment

4. emerge -avuDN net-mail/sympa If it did not already get merged and you want to use the web interface, emerge -avuDN www-servers/spawn-fcgi

5. Run sympa_wizard.pl; you will PROBABLY need to select and add some additional Perl packages. Some of them will have Gentoo ebuilds; for these it is recommended you add them using emerge. For those that do not, you will have to use CPAN or g-cpan.

6. It is strongly advised that you add your mail transport user (for example postfix) to the sympa group.

7. It appears you can use any db type for the Sympa aliases that is supported by your mail transfer agent. For Postfix, at least hash and lmdb are known to work as long as Postfix is configured for them. (For example: lmdb requires USE=lmdb. hash requires USE=berkdb.) You should probably just use whatever you are using with your MTA now.

8. Gentoo starts fastcgi in a different way than Sympa expects. You have two options for dealing with this. (a) Start spawn-fcgi Gentoo's way, creating /etc/init.d/spawn-fcgi.sympa and /etc/conf.d/spawn-fcgi.sympa, and modify Sympa's webserver configuration directives to use the socket name resulting from Gentoo's spawn-fcgi. (b) Use Sympa's provided systemd service definitions or sysvinit script for wwsympa. It is recommended you use this option unless you are really sure you know what you are doing with Gentoo fastcgi configuration.

[UnixRonin]

Also, if you are interested, I have a modified version of /etc/init.d/wwsympa that I find to work better. IDEALLY a new OpenRC service script should be written, and I will look into doing that.

[ikedas]

@UnixRonin , sorry for delayed response.

Also, if you are interested, I have a modified version of /etc/init.d/wwsympa that I find to work better. IDEALLY a new OpenRC service script should be written, and I will look into doing that.

It's good idea to write it. I'm looking forward to see it.

And if you'd like, you can contribute documentation for Gentoo.

[paulmenzel]

@UnixRonin, what is the status of this issue?

[UnixRonin]

@paulmenzel, I've not really made any progress on converting the wwsympa init script to OpenRC. I don't understand OpenRC well enough.

This is the modified wwsympa script that is working for me on Gentoo:

#!/bin/bash
#
# wwsympa                       Sympa Web Interface
#
# Written by IKEDA Soji  2011-10-20
#
# chkconfig: 345 95 05
# description: sympa is a powerful mailing lists management system.

if [ -f /etc/rc.d/init.d/functions ]; then
    # Source function library.
    . /etc/rc.d/init.d/functions

    ## Set a flag
    use_functions=1
fi

# WWSympa parameters
# WWSympa binaries directory
sympafcgidir="/usr/libexec/sympa"

# Sympa config files directory
sympaconf="/etc/sympa/sympa.conf"

FCGI_CHILDREN=5
FCGI_USER=sympa
FCGI_GROUP=sympa
FCGI_PID_DIR=/var/run/sympa
FCGI_OPTS='-s /var/run/sympa/wwsympa.socket -M 0600 -U apache'
if [ -e /etc/sysconfig/sympa ]; then
    . /etc/sysconfig/sympa
fi

# Current state of WWSympa
wwsympa_status() {
    if [ ${use_functions} ]; then
        status wwsympa
    else
        if [ -f ${FCGI_PID_DIR}/wwsympa.pid ]; then
            pids=$(echo $(cat ${FCGI_PID_DIR}/wwsympa.pid))
            ret=0
            if [ -n "${pids}" ]; then
                for pid in ${pids} ; do
                    running=`ps -A | egrep "$pid"`
                    if [ "$running" != "" ]; then
                        echo "fcgi process ${pid} is active..."
                    else
                        echo "fcgi process ${pid} died, pid file remains."
                        ret=1
                    fi
                done
            fi
            if [ $ret == 1 ] ; then return 1 ; fi
        fi
        [[ $ret == 1 ]] && echo "wwsympa is stopped."
        return 3
    fi
}

# Start WWSympa
wwsympa_start() {
    wwsympa_status > /dev/null
    rc=$?
    case "$rc" in
    3)
        echo -n "Starting wwsympa: "
        ;;
    1)
        echo "Starting wwsympa, overwriting old pid file."
        ;;
    0)
        echo "WWSympa seems active. No action will be taken."
        echo "Try \"wwsympa status\" or \"wwsympa restart"\".
        return
    esac

    /usr/bin/spawn-fcgi -F ${FCGI_CHILDREN} -P ${FCGI_PID_DIR}/wwsympa.pid \
    -u ${FCGI_USER} -g ${FCGI_GROUP} ${FCGI_OPTS} -- \
    ${sympafcgidir}/wwsympa.fcgi
}

# Stop WWSympa
wwsympa_stop() {
    if [ -f ${FCGI_PID_DIR}/wwsympa.pid ]; then
        runcount=0
        pids=$(echo $(cat ${FCGI_PID_DIR}/wwsympa.pid))
        if [ -n "${pids}" ]; then
            for pid in ${pids}; do
                killcount=0
                running=`ps -A | grep "$pid ..* wwsympa"`
                while [ "$running" != "" ]; do
                    if [ $killcount -gt 10 ]; then
                        if [ ${use_functions} ]; then
                            failure
                        else
                            echo 'failure'
                        fi
                        return 3
                    fi

                    kill -TERM $pid >/dev/null 2>&1
                    running=`ps -A | grep "$pid ..* $1\\.pl"`
                    if [ "$running" = "" ]; then
                        runcount=`expr $runcount + 1`
                        break
                    fi
                    sleep 2
                    running=`ps -A | grep "$pid ..* $1\\.pl"`
                    if [ "$running" = "" ]; then
                        runcount=`expr $runcount + 1`
                        break
                    fi
                    killcount=`expr $killcount + 1`
                done
            done
        fi
        if [ $runcount -gt 0 ]; then
            if [ ${use_functions} ]; then
                success
            else
                echo 'success'
            fi
        else
            echo 'died'
        fi
        echo
    else
        echo "Module $1.pl not running"
    fi
    return 0
}

# Check config files
[ -d $sympafcgidir ] || exit 0
[ -f $sympaconf ] || exit 0

# See how we were called.
case "$1" in
start)
    if [ ! -f /var/lock/wwsympa ]; then
        echo "Starting WWSympa: "
        wwsympa_start
        touch /var/lock/wwsympa
        echo
    else
        echo "WWSympa seems active. No action will be taken."
        echo "Try \"wwsympa status\" or \"wwsympa restart"\".
    fi
    ;;
stop)
    echo "Stopping WWSympa: "
    wwsympa_stop
    if [ -f /var/lock/wwsympa ]; then
        rm -f /var/lock/wwsympa
    fi
    ;;
status)
    echo "Status of WWSympa: "
    wwsympa_status 
    ;;
restart)
    echo "Restarting WWSympa: "
    $0 stop && $0 start
    echo
    ;;
*)
    echo "Usage: $0 {start|stop|status|restart}"
    exit 1
    ;;
esac

exit 0

[paulmenzel]

Thank you. The issue is about missing steps in the installation though. Are there any missing? If not, could you close this issue, and create a new one for creating an OpenRC file? That’d be great.

[UnixRonin]

@paulmenzel , the best I can offer on that front with regard to additional steps/caveats for installing on Gentoo is the entry https://github.com/sympa-community/sympa/issues/1026#issuecomment-721317470 above. That is the most complete list I have of items necessary to get a working install on Gentoo that are not in the existing documentation.

Since I was discovering it as I went along, I do not know whether following those steps from the start addresses the issue I found of the initial sympa DB schema not being created during installation.

[UnixRonin]

I think the installation is complete TO THE BEST OF MY KNOWLEDGE with the notes above. As requested I will open a new issue for the wwsympa init file.