Unterschiede zwischen den Revisionen 1 und 28 (über 27 Versionen hinweg)
Revision 1 vom 2018-01-10 21:23:43
Größe: 918
Autor: anonym
Kommentar:
Revision 28 vom 2018-01-19 22:50:49
Größe: 12210
Autor: phil
Kommentar: Apache als Webserver
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 1: Zeile 1:
 * Listmaster kann Listen verwalten --> /etc/sympa/sympa/sympa.conf eintragen
 * https://www.sympa.org/manual_6.2/web-interface#logging_in_as_listmaster
## page was renamed from Sympa
Diese Seite beschreibt die Installation und Einrichtung von [[https://sympa.org|Sympa]], Postfix und Nginx/Apache unter [[https://debian.or|Debian]] Stretch.
Zeile 4: Zeile 4:
= NGINX =
 * https://kradalby.no/sympa.html
<<TableOfContents>>
Zeile 7: Zeile 6:
= Authentifizierung =
Sympa (wws) kann mehrere Quellen zur Authentifizierung nutzen.
 * https://www.sympa.org/manual/authentication
= Installation von Sympa =
Ab 6.1.22 bringt Sympa [[https://www.sympa.org/manual/dmarc|DMARC]]-Funktionalität mit - diese Version ist erst in Buster enthalten. Gleich welche Version es ist:{{{
apt install sympa}}}
Bei der Installation wird gleich die Datenbank mit eingerichtet. Dies kann auch [[https://www.sympa.org/manual/database|manuell]] durchgeführt werden.
Zeile 11: Zeile 11:
= Postfix =
 * https://www.sympa.org/faq/postfix_howto
 * https://www.sympa.org/faq/postfix
 * sympa.conf:
  * sendmail_aliases /etc/sympa/sympa_aliases
  * aliases_program postalias
 * {{{
## The full path to the Message Transfer Agent program (default is Sendmail 8.7
## or above)
sendmail /usr/sbin/sendmail
# correct
# this binary is locating in the same directory as postfix
# sendmail /usr/sbin/postfix
# (incorrect : must use Postfix to Sendmail compatibility interface)
= Postfix einrichten =
Im Internet gibt es [[https://www.sympa.org/faq/postfix_howto|verschiedene]] [[https://www.sympa.org/faq/postfix|Seiten]], [[https://www.sympa.org/manual/mail-aliases|die]] [[http://www.folly.org.uk/sympa/sympa_config_03.html|die]] [[https://tribut.de/blog/sympa-and-postfix/|Postfix]]-Einrichtung beschreiben. Leider sind diese teilweise unübersichtlich, veraltet oder unvollständig.

Prinzipiell gibt es zwei Möglichkeiten, wie Sympa mit Postfix zusammen arbeiten kann:
 * Alias maps: für jede Liste werden eigene Alias-Einträge konfiguiert
 * Transport maps: lediglich allgemeine Konfiguration der Listendomain

Die Nutzung der transport map vereinfacht die Konfiguration also erheblich. Diese wird im Folgenden auch beschrieben.:

 * Anpassen der {{{master.cf}}}:{{{
sympa unix - n n - - pipe
  flags=R user=sympa argv=/usr/lib/sympa/lib/sympa/queue ${recipient}
sympabounce unix - n n - - pipe
  flags=R user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue ${user}
}}}
 * In der {{{sympa.conf}}} wird der Pfad zum MTA festgelegt - wichtig ist hier, das "Postfix to Sendmail compatibility interface" zu nutzen und nicht {{{/usr/sbin/postfix}}}:{{{
sendmail /usr/sbin/sendmail}}}
 * Zur Nutzung der Transport maps wird die alias-Funktionalität von Sympa deaktiviert - {{{sympa.conf}}}:{{{
sendmail_aliases none}}}
 * Folgende Einstellungen gehören nun in die {{{main.cf}}}:{{{
sympa_destination_recipient_limit = 1
sympabounce_destination_recipient_limit = 1
recipient_delimiter = +
virtual_mailbox_domains = listen.example.org
virtual_alias_maps = regexp:/etc/postfix/sympa_virtual_alias
transport_maps = regexp:/etc/postfix/sympa_transport}}}
 * Maps für Aliasnamen festlegen<<FootNote(Das Mapping ist notwendig, da Mails an {{{$LISTE-owner}}} an die bouncequeue als {{{$LISTE@listen.example.org}}} durchgereicht werden müssen)>> - {{{/etc/postfix/sympa_virtual_alias}}}:{{{
/^(.*)-owner\@listen\.example\.org$/ $1+owner@listen.example.org}}}
 * Die definierte transport-map-Tabelle wird nun gefüllt - {{{/etc/postfix/sympa_transport}}}:{{{
/^.*+owner\@listen\.example\.org$/ sympabounce:
/^.*\@listen\.example\.org$/ sympa:
}}}
 * Anschließend:{{{
postmap /etc/postfix/sympa_transport
postmap /etc/postfix/sympa_virtual_alias
service postfix reload}}}
 * Jede neue Maildomain benötigt dann nur noch zwei entsprechende Eintrage in {{{/etc/postfix/sympa_transport}}} und einen in {{{/etc/postfix/sympa_virtual_alias}}}

= Webserver einrichten =
Apache als Webserver für Sympa scheint um einiges performanter als ein Setup mit Nginx zu sein. Zudem gibt es einen [[https://github.com/sympa-community/sympa/issues/155|Bug]], der in der folgenden Nginx-Konfiguration aufgritt, bei Apache hingegen nicht.

== Nginx ==
[[https://www.sympa.org/manual/web-interface|WWSympa]], die Weboberfläche für Sympa, ist ein Perl-CGI-Skript. Zur Beschleunigung kann Fastcgi genutzt werden. Da Nginx lediglich Fastcgi unterstützt, wird zusätzlich DebianPackage:Fcgiwrap benötigt.
 * Installation der Pakete:{{{
apt install nginx-light fcgiwrap}}}
 * Fastcgi in {{{/etc/sympa/sympa/sympa.conf}}} aktivieren:{{{
use_fast_cgi 1}}}
 * Allgemeine Fastcgi-Konfiguration unter {{{/etc/nginx/snippets/sympa_fcgi.conf}}} anlegen:{{{
gzip off;
        fastcgi_pass unix:/run/fcgiwrap.socket;
        fastcgi_split_path_info ^(/sympa)(.+)$;
        fastcgi_param QUERY_STRING $query_string;
        fastcgi_param REQUEST_METHOD $request_method;
        fastcgi_param CONTENT_TYPE $content_type;
        fastcgi_param CONTENT_LENGTH $content_length;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name;
        fastcgi_param REQUEST_URI $request_uri;
        fastcgi_param DOCUMENT_URI $document_uri;
        fastcgi_param DOCUMENT_ROOT $document_root;
        fastcgi_param SERVER_PROTOCOL $server_protocol;
        fastcgi_param GATEWAY_INTERFACE CGI/1.1;
        fastcgi_param SERVER_SOFTWARE nginx;
        fastcgi_param REMOTE_ADDR $remote_addr;
        fastcgi_param REMOTE_PORT $remote_port;
        fastcgi_param SERVER_ADDR $server_addr;
        fastcgi_param SERVER_PORT $server_port;

        # According to RFC3875 (https://tools.ietf.org/html/rfc3875#section-4.1.14) in SERVER_NAME
        # we should put an actual hostname user came to. For nginx it is in $host
        # This will allow to run sympa multihost instances
        fastcgi_param SERVER_NAME $host;
        fastcgi_param REMOTE_USER $remote_user;
        fastcgi_param SCRIPT_FILENAME $document_root/wwsympa-wrapper.fcgi;
        fastcgi_param HTTP_HOST $http_host;
        fastcgi_intercept_errors on;
}}}
 * Seiten-Konfiguration unter {{{/etc/nginx/sites-available/sympa}}} anlegen:{{{
server {
    server_name listen.example.org;
    root /usr/lib/cgi-bin/sympa;
    access_log /var/log/nginx/sympa.access.log;
    error_log /var/log/nginx/sympa.error.log;
    error_page 403 500 502 503 504 /50x.html;

    # While configuring sympa, you should specify wwsympa_url for each robot.
    # if you do not do so, sympa will generate wwsympa_url as ${robot_name}/sympa.
    # So to prevent non-active urls for robots without wwsympa_url, we do this redirect:

    rewrite ^/sympa/(.*)$ /$1 permanent;
    
    location ^~ /static-sympa/ {
        alias /var/lib/sympa/static_content/;
        access_log off;
    }
    location /50x.html {
        root /usr/share/nginx/html;
    }
    location ~* \.(php|pl|py|jsp|asp|sh|cgi|bin|csh|ksh|out|run|o)$ {
        deny all;
    }
    location ~ /\.ht {
        deny all;
    }
    location / {
    include /etc/nginx/snippets/sympa_fcgi.conf;
    }
}
}}}
 * Anschließend Seitenkonfiguration aktivieren und Nginx neu laden.

== Apache ==
Eine Konfigurationsdatei für Sympa ist im Debian-Paket bereits enthalten, so dass diese nur in der Seitenkonfiguration eingebunden werden muss. Diese könnte {{{/etc/apache2/sites-enabled/listen.example.org}}} so aussehen<<FootNote(Die SSL-Konfiguration ist in diesem Beispiel nicht aufgeführt)>>:{{{
<VirtualHost *:80>
        ServerName listen.example.org
        DocumentRoot /usr/lib/cgi-bin/sympa
        ErrorLog /var/log/apache2/listen.example.org.log
        include /etc/apache2/conf-available/sympa.conf
</VirtualHost>}}}

Soll Sympa unter der Domain ohne Pfad erreichbar sein (also listen.example.org statt listen.example.org/sympa) muss der !ScriptAlias in {{{/etc/apache2/conf-available/sympa.conf}}} angepasst werden:{{{
#ScriptAlias /sympa /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi
ScriptAliasMatch ^/(.*) /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi/$1
Zeile 27: Zeile 136:
= Multidomain =
 * https://www.sympa.org/manual/virtual-hosts
= Authentifizierung in der Weboberfläche =
Sympa kann mehrere Quellen zur [[https://www.sympa.org/manual/authentication|Authentifizierung]] nutzen. Diese werden in {{{/etc/sympa/auth.conf}}} definiert.
 * Im folgenden Beispiel erfolgt die Authentifizierung bei Nutzer mit einer example.org-Mailadresse per LDAP, alle anderen Nutzer werden über die interne Datenbank authentifiziert:{{{
# LDAP authentication
ldap
        regexp example\.org
        host ldap.example.org
        timeout 20
        suffix sc=mailAccount,ou=People,o=ldap,dc=example,dc=org
        get_dn_by_uid_filter (cn=[sender])
        get_dn_by_email_filter (mail=[sender])
        email_attribute mail

# Internal authentication by email and password
user_table
        negative_regexp example\.org
}}}
 * Anmeldungen mit einem LDAP-Account sind sowohl nur mit Nutzername ({{{get_dn_by_uid_filter}}}), als auch mit der vollständigen Mailadresse ({{{get_dn_by_email_filter}}}) möglich.
 * Volle Administrationsrechte für die Weboberfläche erhalten alle Accounts, die unter {{{listmasters}}} in {{{/etc/sympa/sympa/sympa.conf}}} geführt werden. Listmaster haben auf alle Robots volle Rechte.

= Multidomain-Unterstützung =
Eine Sympa-Instanz kann beliebig viele [[https://www.sympa.org/manual/virtual-hosts|Listen-Domains]] bedienen. Für die Weboberfläche werden dann, ähnlich zu Apache, virtuelle Host (Robots genannt) eingerichtet.
 * MX-Einträge und CNAME einrichten
 * Listenverzeichnis erstellen und Besitzer ({{{sympa:sympa}}}) ändern:{{{
mkdir /var/lib/sympa/list_data/ml.example.org}}}
 * Konfigurationsverzeichnis erstellen und Besitzer ändern:{{{
mkdir /etc/sympa/ml.example.org}}}
 * Konfigurationsdatei für den neuen Robot anlegen - {{{/ect/sympa/ml.example.org/robot.conf}}} und Besitzer ändern:{{{
http_host ml.example.org
wwsympa_url ml.example.org
email ml.example.org
title Listenverwaltung 2}}}
 * Damit die Nutzeranmeldung funktioniert, muss die {{{auth.conf}}} nach {{{/ect/sympa/ml.example.org}}} kopiert werden
 * Eigene Webserver-Seitenkonfiguration anlegen

= Nutzern die Listenerstellung erlauben =
Ziel ist es, dass nicht nur Admins Listen erstellen können, sondern auch ausgewählte reguläre [[https://www.sympa.org/manual_6.2/list-creation#who_can_create_lists_on_the_web_interface|Nutzer*innen]]. Dazu werden alle berechtigten Nutzer*innen in einem [[https://www.sympa.org/manual/authorization-scenarios|Scenario]] aufgelistet.
 * Zuerst wird in der {{{sympa.conf}}} festgelegt, welches Scenario die Rechte für die Listenerstellung definiert:{{{
create_list list_creators}}}
 * Nun wird ein entsprechendes Scenario angelegt. Bei nur einem Robot liegt sie unter {{{/etc/sympa/scenari}}}. Bei verschiedenen Robots unter {{{/ect/sympa/$ROBOT/scenari}}}. Der Dateiname muss eine Kombination aus value.wert entsprechend der {{{sympa.conf}}} sein - in diesem Fall also create_list.list_creators:{{{
title Users that can create lists
equal([sender], 'foo@example.org') md5 -> listmaster
}}}
 * Das Scenario definiert also, dass eine bestimmte Nutzerin ({{{equal([sender], 'foo@example.org'}}}) nach der Anmeldung im Webinterface ({{{md5}}}) entsprechende Rechte ({{{--> listmaster}}}) erhält.
 * Nach dem selben Schema können nun weitere Nutzer*innen definiert werden
 * Mit der Definition von {{{create_list}}} verlieren die listmaster die Möglichkeit, Listen anzulegen - deshalb kann das ursprüngliche Scenario am Ende des neuen Scenarios eingebunden werden<<FootNote(Für das Scenario gilt: First match wins)>>:{{{
title Users that can create lists
equal([sender], 'foo@example.org') md5 -> listmaster
include create_list.listmaster
}}}
 * Da der erwartete Dateiname nun {{{include.create_list.listmaster}}} ist, muss noch ein Symlink erstellt werden:{{{
ln -s /usr/share/sympa/default/scenari/create_list.listmaster /etc/sympa/scenari/include.create_list.listmaster}}}
 * Abschließend muss Sympa neu gestartet werden

= Fussnoten und Hinweise =
 * https://www.sympa.org/manual/dmarc
 * https://www.sympa.org/manualtest/conf-parameters/part3#loop_prevention --> stille Verweigerung von Listenmails (bspw. leiche Message-ID)
 * [[https://kradalby.no/sympa.html|Nginx-Konfiguration]]
 * [[https://wiki.debian.org/Sympa/Nginx|Nginx-Konfiguration im Debian-Wiki]]
 * [[https://www.sympa.org/faq/postfix#managing_aliases_directly_in_the_postfix_transport_table|Sympa und Postfix transport map]]
 * [[https://www.grenode.net/Services/Listes_de_diffusion/|Sympa, Postfix, Apache]]
 * Topics anpassen: /etc/sympa/topics.conf

Diese Seite beschreibt die Installation und Einrichtung von Sympa, Postfix und Nginx/Apache unter Debian Stretch.

Installation von Sympa

Ab 6.1.22 bringt Sympa DMARC-Funktionalität mit - diese Version ist erst in Buster enthalten. Gleich welche Version es ist:

apt install sympa

Bei der Installation wird gleich die Datenbank mit eingerichtet. Dies kann auch manuell durchgeführt werden.

Postfix einrichten

Im Internet gibt es verschiedene Seiten, die die Postfix-Einrichtung beschreiben. Leider sind diese teilweise unübersichtlich, veraltet oder unvollständig.

Prinzipiell gibt es zwei Möglichkeiten, wie Sympa mit Postfix zusammen arbeiten kann:

  • Alias maps: für jede Liste werden eigene Alias-Einträge konfiguiert
  • Transport maps: lediglich allgemeine Konfiguration der Listendomain

Die Nutzung der transport map vereinfacht die Konfiguration also erheblich. Diese wird im Folgenden auch beschrieben.:

  • Anpassen der master.cf:

    sympa      unix  -       n       n       -       -       pipe
      flags=R user=sympa argv=/usr/lib/sympa/lib/sympa/queue ${recipient}
    sympabounce unix -       n       n       -       -       pipe
      flags=R user=sympa argv=/usr/lib/sympa/lib/sympa/bouncequeue ${user}
  • In der sympa.conf wird der Pfad zum MTA festgelegt - wichtig ist hier, das "Postfix to Sendmail compatibility interface" zu nutzen und nicht /usr/sbin/postfix:

    sendmail        /usr/sbin/sendmail
  • Zur Nutzung der Transport maps wird die alias-Funktionalität von Sympa deaktiviert - sympa.conf:

    sendmail_aliases  none
  • Folgende Einstellungen gehören nun in die main.cf:

    sympa_destination_recipient_limit = 1
    sympabounce_destination_recipient_limit = 1
    recipient_delimiter = +
    virtual_mailbox_domains = listen.example.org
    virtual_alias_maps = regexp:/etc/postfix/sympa_virtual_alias
    transport_maps = regexp:/etc/postfix/sympa_transport
  • Maps für Aliasnamen festlegen1 - /etc/postfix/sympa_virtual_alias:

    /^(.*)-owner\@listen\.example\.org$/    $1+owner@listen.example.org
  • Die definierte transport-map-Tabelle wird nun gefüllt - /etc/postfix/sympa_transport:

    /^.*+owner\@listen\.example\.org$/ sympabounce:
    /^.*\@listen\.example\.org$/       sympa:
  • Anschließend:

    postmap /etc/postfix/sympa_transport
    postmap /etc/postfix/sympa_virtual_alias
    service postfix reload
  • Jede neue Maildomain benötigt dann nur noch zwei entsprechende Eintrage in /etc/postfix/sympa_transport und einen in /etc/postfix/sympa_virtual_alias

Webserver einrichten

Apache als Webserver für Sympa scheint um einiges performanter als ein Setup mit Nginx zu sein. Zudem gibt es einen Bug, der in der folgenden Nginx-Konfiguration aufgritt, bei Apache hingegen nicht.

Nginx

WWSympa, die Weboberfläche für Sympa, ist ein Perl-CGI-Skript. Zur Beschleunigung kann Fastcgi genutzt werden. Da Nginx lediglich Fastcgi unterstützt, wird zusätzlich Fcgiwrap benötigt.

  • Installation der Pakete:

    apt install nginx-light fcgiwrap
  • Fastcgi in /etc/sympa/sympa/sympa.conf aktivieren:

    use_fast_cgi 1
  • Allgemeine Fastcgi-Konfiguration unter /etc/nginx/snippets/sympa_fcgi.conf anlegen:

    gzip off;
            fastcgi_pass   unix:/run/fcgiwrap.socket;
            fastcgi_split_path_info ^(/sympa)(.+)$;
            fastcgi_param  QUERY_STRING       $query_string;
            fastcgi_param  REQUEST_METHOD     $request_method;
            fastcgi_param  CONTENT_TYPE       $content_type;
            fastcgi_param  CONTENT_LENGTH     $content_length;
            fastcgi_param  PATH_INFO          $fastcgi_path_info;
            fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
            fastcgi_param  REQUEST_URI        $request_uri;
            fastcgi_param  DOCUMENT_URI       $document_uri;
            fastcgi_param  DOCUMENT_ROOT      $document_root;
            fastcgi_param  SERVER_PROTOCOL    $server_protocol;
            fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
            fastcgi_param  SERVER_SOFTWARE    nginx;
            fastcgi_param  REMOTE_ADDR        $remote_addr;
            fastcgi_param  REMOTE_PORT        $remote_port;
            fastcgi_param  SERVER_ADDR        $server_addr;
            fastcgi_param  SERVER_PORT        $server_port;
    
            # According to RFC3875 (https://tools.ietf.org/html/rfc3875#section-4.1.14) in SERVER_NAME
            # we should put an actual hostname user came to. For nginx it is in $host
            # This will allow to run sympa multihost instances
            fastcgi_param  SERVER_NAME        $host;
            fastcgi_param  REMOTE_USER        $remote_user;
            fastcgi_param  SCRIPT_FILENAME    $document_root/wwsympa-wrapper.fcgi;
            fastcgi_param  HTTP_HOST           $http_host;
            fastcgi_intercept_errors on;
  • Seiten-Konfiguration unter /etc/nginx/sites-available/sympa anlegen:

    server {
        server_name  listen.example.org;
        root         /usr/lib/cgi-bin/sympa;
        access_log   /var/log/nginx/sympa.access.log;
        error_log    /var/log/nginx/sympa.error.log;
        error_page   403 500 502 503 504 /50x.html;
    
        # While configuring sympa, you should specify wwsympa_url for each robot.
        # if you do not do so, sympa will generate wwsympa_url as ${robot_name}/sympa.
        # So to prevent non-active urls for robots without wwsympa_url, we do this redirect:
    
        rewrite ^/sympa/(.*)$ /$1 permanent;
        
        location ^~ /static-sympa/ {
            alias /var/lib/sympa/static_content/;
            access_log off;
        }
        location /50x.html {
            root /usr/share/nginx/html;
        }
        location ~* \.(php|pl|py|jsp|asp|sh|cgi|bin|csh|ksh|out|run|o)$ {
            deny all;
        }
        location ~ /\.ht {
            deny all;
        }
        location / {
        include /etc/nginx/snippets/sympa_fcgi.conf;
        }
    }
  • Anschließend Seitenkonfiguration aktivieren und Nginx neu laden.

Apache

Eine Konfigurationsdatei für Sympa ist im Debian-Paket bereits enthalten, so dass diese nur in der Seitenkonfiguration eingebunden werden muss. Diese könnte /etc/apache2/sites-enabled/listen.example.org so aussehen2:

<VirtualHost *:80>
        ServerName      listen.example.org
        DocumentRoot    /usr/lib/cgi-bin/sympa
        ErrorLog        /var/log/apache2/listen.example.org.log 
        include         /etc/apache2/conf-available/sympa.conf
</VirtualHost>

Soll Sympa unter der Domain ohne Pfad erreichbar sein (also listen.example.org statt listen.example.org/sympa) muss der ScriptAlias in /etc/apache2/conf-available/sympa.conf angepasst werden:

#ScriptAlias /sympa /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi
ScriptAliasMatch ^/(.*) /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi/$1

Authentifizierung in der Weboberfläche

Sympa kann mehrere Quellen zur Authentifizierung nutzen. Diese werden in /etc/sympa/auth.conf definiert.

  • Im folgenden Beispiel erfolgt die Authentifizierung bei Nutzer mit einer example.org-Mailadresse per LDAP, alle anderen Nutzer werden über die interne Datenbank authentifiziert:

    # LDAP authentication
    ldap
            regexp  example\.org
            host    ldap.example.org
            timeout 20      
            suffix  sc=mailAccount,ou=People,o=ldap,dc=example,dc=org
            get_dn_by_uid_filter    (cn=[sender])
            get_dn_by_email_filter  (mail=[sender])
            email_attribute         mail
    
    # Internal authentication by email and password
    user_table
            negative_regexp example\.org
  • Anmeldungen mit einem LDAP-Account sind sowohl nur mit Nutzername (get_dn_by_uid_filter), als auch mit der vollständigen Mailadresse (get_dn_by_email_filter) möglich.

  • Volle Administrationsrechte für die Weboberfläche erhalten alle Accounts, die unter listmasters in /etc/sympa/sympa/sympa.conf geführt werden. Listmaster haben auf alle Robots volle Rechte.

Multidomain-Unterstützung

Eine Sympa-Instanz kann beliebig viele Listen-Domains bedienen. Für die Weboberfläche werden dann, ähnlich zu Apache, virtuelle Host (Robots genannt) eingerichtet.

  • MX-Einträge und CNAME einrichten
  • Listenverzeichnis erstellen und Besitzer (sympa:sympa) ändern:

    mkdir /var/lib/sympa/list_data/ml.example.org
  • Konfigurationsverzeichnis erstellen und Besitzer ändern:

    mkdir /etc/sympa/ml.example.org
  • Konfigurationsdatei für den neuen Robot anlegen - /ect/sympa/ml.example.org/robot.conf und Besitzer ändern:

    http_host  ml.example.org
    wwsympa_url  ml.example.org
    email  ml.example.org
    title  Listenverwaltung 2
  • Damit die Nutzeranmeldung funktioniert, muss die auth.conf nach /ect/sympa/ml.example.org kopiert werden

  • Eigene Webserver-Seitenkonfiguration anlegen

Nutzern die Listenerstellung erlauben

Ziel ist es, dass nicht nur Admins Listen erstellen können, sondern auch ausgewählte reguläre Nutzer*innen. Dazu werden alle berechtigten Nutzer*innen in einem Scenario aufgelistet.

  • Zuerst wird in der sympa.conf festgelegt, welches Scenario die Rechte für die Listenerstellung definiert:

    create_list     list_creators
  • Nun wird ein entsprechendes Scenario angelegt. Bei nur einem Robot liegt sie unter /etc/sympa/scenari. Bei verschiedenen Robots unter /ect/sympa/$ROBOT/scenari. Der Dateiname muss eine Kombination aus value.wert entsprechend der sympa.conf sein - in diesem Fall also create_list.list_creators:

    title Users that can create lists
    equal([sender], 'foo@example.org') md5 -> listmaster
  • Das Scenario definiert also, dass eine bestimmte Nutzerin (equal([sender], 'foo@example.org') nach der Anmeldung im Webinterface (md5) entsprechende Rechte (--> listmaster) erhält.

  • Nach dem selben Schema können nun weitere Nutzer*innen definiert werden
  • Mit der Definition von create_list verlieren die listmaster die Möglichkeit, Listen anzulegen - deshalb kann das ursprüngliche Scenario am Ende des neuen Scenarios eingebunden werden3:

    title Users that can create lists
    equal([sender], 'foo@example.org') md5 -> listmaster
    include  create_list.listmaster
  • Da der erwartete Dateiname nun include.create_list.listmaster ist, muss noch ein Symlink erstellt werden:

    ln -s /usr/share/sympa/default/scenari/create_list.listmaster /etc/sympa/scenari/include.create_list.listmaster
  • Abschließend muss Sympa neu gestartet werden

Fussnoten und Hinweise

  1. Das Mapping ist notwendig, da Mails an $LISTE-owner an die bouncequeue als $LISTE@listen.example.org durchgereicht werden müssen (1)

  2. Die SSL-Konfiguration ist in diesem Beispiel nicht aufgeführt (2)

  3. Für das Scenario gilt: First match wins (3)


Creative Commons Lizenzvertrag
This page is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.