Archiv der Kategorie: Schule

OpenWRT und VLAN

Den schulischen APs der Reihe nach beizubringen, dass sie nun VLAN können und dass

  • auf Grau der AP verwaltet wird und hierbei seine IP vom grauen DHCP erhält,
  • Blau unser öffentliches Netz ist (HotSpot Authentifizierung),
  • auf Pink irgendwann in ferner Zukunft das Lehrernetz gefunden werden soll (mit Radius-Auth – man darf ja noch träumen)
  • und in Grün das interne Netz für die Laptops läuft, die ihre IP vom Schulserver erhalten,

war die Aufgabe. Dies auf der Oberfläche eines jeden APs einzeln zusammen zu klicken dauert viel zu lange. Also kopiert man sich die Konfiguration von einem funktionierenden AP auf alle anderen, bootet diese insgesamt zwei mal neu und voila – es tut.

Erst einmal VLAN ermöglichen:

opkg install kmod-macvlan

Dann neu booten. Mit ifconfig angesehen soll es am Ende so aussehen:

    br-blue Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fd34:cf26:d77b::1/60 Scope:Global
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:100 errors:0 dropped:0 overruns:0 frame:0
    TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:9114 (8.9 KiB) TX bytes:14396 (14.0 KiB)

    br-green Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fd34:cf26:d77b:10::1/60 Scope:Global
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2354 errors:0 dropped:0 overruns:0 frame:0
    TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:749902 (732.3 KiB) TX bytes:14396 (14.0 KiB)

    br-grey Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet addr:192.168.0.139 Bcast:192.168.0.255 Mask:255.255.255.0
    inet6 addr: fd34:cf26:d77b:20::1/60 Scope:Global
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1847 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1689 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:175780 (171.6 KiB) TX bytes:431449 (421.3 KiB)

    br-pink Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1773 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B) TX bytes:574414 (560.9 KiB)

    eth0 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:9283 errors:0 dropped:167 overruns:0 frame:0
    TX packets:7976 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1947524 (1.8 MiB) TX bytes:5061428 (4.8 MiB)
    Interrupt:4

    eth0.1 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2335 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1729 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:211878 (206.9 KiB) TX bytes:434729 (424.5 KiB)

    eth0.2 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:4566 errors:0 dropped:0 overruns:0 frame:0
    TX packets:801 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:1141302 (1.0 MiB) TX bytes:80814 (78.9 KiB)

    eth0.3 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2208 errors:0 dropped:0 overruns:0 frame:0
    TX packets:3708 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:410171 (400.5 KiB) TX bytes:3944129 (3.7 MiB)

    eth0.4 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1734 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B) TX bytes:569420 (556.0 KiB)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:65536 Metric:1
    RX packets:6 errors:0 dropped:0 overruns:0 frame:0
    TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:288 (288.0 B) TX bytes:288 (288.0 B)

    wlan0 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:595 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2903 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:63160 (61.6 KiB) TX bytes:940426 (918.3 KiB)

    wlan0-1 Link encap:Ethernet HWaddr 66:70:02:78:1D:5F
    inet6 addr: fe80::6470:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:3617 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1995 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:3938021 (3.7 MiB) TX bytes:460510 (449.7 KiB)

Einmal /etc/config/network anpassen:

    config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

    config globals 'globals'
    option ula_prefix 'fd34:cf26:d77b::/48'

    config interface 'grey'
    option ifname 'eth0.1'
    option type 'bridge'
    option proto 'dhcp'
    option ip6assign '60'

    config interface 'green'
    option ifname 'eth0.2'
    option type 'bridge'
    option ip6assign '60'

    config interface 'blue'
    option ifname 'eth0.3'
    option type 'bridge'
    option ip6assign '60'

    config interface 'pink'
    option ifname 'eth0.4'
    option type 'bridge'
    option proto 'dhcp'
    option ip6assign '60'

    config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

    config switch_vlan
    option device 'switch0'
    option vlan '1'
    option vid '1
    option ports '0t 1t 2t 3t 4t 5t'

    config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '2'
    option ports '0t 1t 2t 3t 4t 5t'

    config switch_vlan
    option device 'switch0'
    option vlan '3'
    option vid '3'
    option ports '0t 1t 2t 3t 4t 5t'

    config switch_vlan
    option device 'switch0'
    option vlan '4'
    option vid '4'
    option ports '0t 1t 2t 3t 4t 5t'

Und /etc/config/wireless anpassen:

    config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11ng'
    option path 'platform/ath9k'
    list ht_capab 'SHORT-GI-40'
    list ht_capab 'DSSS_CCK-40'
    option country 'US'
    option txpower '27'
    option channel '4'

    config wifi-iface
    option device 'radio0'
    option network 'green'
    option mode 'ap'
    option ssid 'intern'
    option encryption 'psk2'
    option key 'geheim'

    config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option encryption 'none'
    option ssid 'public'
    option network 'blue'

Die DNS Dienste auf dem AP wegwerfen, weil der DNS zentral läuft (auf Schulserver oder auf dem grauen Server für die Infrastruktur):

/etc/init.d/dnsmasq stop
killall dnsmasq # nur zur Sicherheit
/etc/init.d/dnsmasq disable

Dann noch einmal neu booten und vor Ort testen, nachdem man die VLAN Einstellungen auch auf den Switches so angepasst hat, dass man seinen AP wieder findet.

LDAPs von DokuWiki auf LD-Server

In unser Portfolio sollen nur die Kolleg/innen reinkommen und nicht die Schüler/innen. Also authentifizierte dieses zunächst nur gegenüber dem Lehrermoodle – seit ein paar Tagen jedoch auch gegenüber dem hausinternen LDAP-Server über eine verschlüsselte Verbindung.

DokuWiki, die Basis für das Portfoliosystem, erlaubt hierbei jegliche Mischung aus Authentifizierungsverfahren, sofern man das Plugin AuthChained installiert hat. In unserem Fall lege ich die Administratoren und Redakteure händisch in der DokuWiki eigenen Datenbank an – die nur lesenden Benutzer/innen dürfen über LDAPs kommen. Sie sollen in der Default-Gruppe visitor landen, die im Backend von Dokuwiki so eingerichtet wurde, dass sie nur lesenden Zugriff auf die Portfolio-Seiten erhalten.

Dann wurde die dokuwiki/config/local.php umgestaltet. Hier die Variablen, die am Ende des Config-Marathons endlich die intendierte Wirkung hatten:

$conf['authtype'] = ‘authchained';
$conf['defaultgroup'] = ‘visitor';
$conf['disableactions'] = ‘register';
$conf['plugin']['authldap']['server'] = ‘ldaps://ip.des.servers.tld:636?;
$conf['plugin']['authldap']['port'] = 636;
$conf['plugin']['authldap']['usertree'] = ‘dc=schule,dc=ort,dc=schule-bw,dc=de';
$conf['plugin']['authldap']['userfilter'] = ‘(&(uid=%{user})(objectClass=ldUserAccount)(ldRole=teacher))';
$conf['plugin']['authldap']['version'] = 3;
$conf['plugin']['authchained']['authtypes'] = ‘authldap:authplain';
$conf['plugin']['authchained']['usermanager_authtype'] = ‘authplain';
$conf['auth']['chained']['authtypes'] = ‘ldap,plain';
$conf['auth']['chained']['usermanager_authtype'] = ‘plain';
$conf['auth']['chained']['find_auth_by_password'] = ‘false';
$conf['auth']['ldap']['version'] = ‘3’;

ldUserAccount und ldRole sind spezifisch für MySHN bzw. LogoDidact Systeme. Andere Schulserver-Lösungen haben sicherlich andere Bezeichnungen. Die Einträge in den LDAP von LMN sind in deren Wiki hervorragend dokumentiert und lieferten auch für obige LD-Lösung viele Ideen:

http://www.linuxmuster.net/wiki/anwenderwiki:webapps:portfolio#anpassen_der_grundkonfiguration_des_osp

Anmeldeversuche von SuS werden nun mit der Fehlermeldung “Benutzername und / oder Passwort unbekannt” abgewiesen. Dokuwiki sucht schließlich nicht im LDAP-Baum nach allen Menschen auf ServerG, sondern nur noch nach LuL. Vermutlich ist das overkill, denn im Userfilter steht ja ebenfalls drin, dass nur LuL reindürfen. Aber es funktioniert und scheint mir sicherer zu sein.

Da der schulische LD-Server für LDAPs nur ein self-signed Zertifikat ausliefert kommt noch ein Eintrag in die /etc/ldap/ldap.conf auf dem Dokuwiki-Server

TLS_REQCERT allow

Horde PGP und Thunderbird

Der PGP-verschlüsselnde Mailserver für die Schule läuft, die ersten Nutzer/innen haben ihre Einführungen erhalten und es sieht so aus, als würden sie den Verschlüsselungsdienst sogar nutzen. Es scheint ihnen Spaß zu machen. Gut.

Was mir dabei aufgefallen ist: Horde verschickt verschlüsselte Nachrichten mit einem multipart/encrypted Eintrag für den Content-Type im Mailheader. Thunderbird mit Enigmail tun dies aber nicht. Thunderbird schickt verschlüsselte Mails als multipart/mixed raus … und das kann Horde dann nicht als verschlüsselte E-Mail erkennen. Horde bietet dann im Webfrontend auch keine Funktionen zum Entschlüsseln an, sondern zeigt den Plaintext an.

Was im Ergebnis gut funktioniert ist damit Horde2Horde und Thunderbird2Thunderbird und Horde2Thunderbird. Was überhaupt nicht funktioniert ist Thunderbird2Horde.

Zwei Stellschrauben scheint es zu geben:

tb_enm_pgpmime

Die erste ist in Thunderbird / Enigmail zu finden. Stellt man dort PGP/MIME als Standardverfahren ein, dann schreibt Thunderbird brav Content-Type: multipart/encrypted in den Mailheader und Horde kann die Mail als verschlüsselt erkennen und somit auch die Entschlüsselungs-Funktionen im Webmailer anbieten. Thunderbird selbst kommt auf Empfängerseite damit auch zurecht.

Die zweite Stellschraube ist theoretisch in Hordes IMP zu finden. In /var/www/horde/imp/config/mime_drivers.local.php muss man hierzu PGP Inline aktivieren bzw. die Datei erst erstellen und sich den Inhalt aus der vorhandenen mime_drivers hineinkopieren. Eine Garantie, dass das dann reibungslos und immer funktioniert, scheint es aber nicht geben, haben meine Tests gezeigt. Außerdem frisst es Ressourcen, weil Horde/IMP dann die gesamte E-Mail auf PGP Blöcke durchsehen müssen.

Mailserver von 12.04 auf 14.04

Auf einem Ubuntu 12.04 lauscht Postgrey nur auf IPv6

tcp6 0 0 ::1:10023 :::* LISTEN 0 10265 1191/postgrey.pid –

Auf einem Ubuntu 14.04 lauscht er dann nach dem Upgrade auf IPv4

tcp 0 0 127.0.0.1:10023 0.0.0.0:* LISTEN 0 13562 1331/postgrey.pid –

Dass er sich wie das Fähnchen im Wind gedreht hat, wird nicht mitgeteilt. Eine Anpassung von Postfix mit Neustart von Postfix und Postgrey hilft weiter:

check_policy_service inet:127.0.0.1:10023,
# check_policy_service inet:::1:10023,

Überhaupt: Dovecot und Postfix haben bei mir das Upgrade denkbar schlecht verdaut. Im Grunde musste ich die gesamte Konfiguration der beiden händisch neu vornehmen, weil so ziemlich alles broken war: Einstellungen, Pfade, Zertifikate … you name it.

Zurück: Webserver von 12.04 auf 14.04

Webserver von 12.04 auf 14.04

Nach dem Upgrade von Ubuntu 12.04 auf 14.04 warf Apache 2.4 mit einer ganzen Reihe von Fehlermeldungen nach mir, weil sich die Syntax einiger Konfigurationsdateien geändert hatte. Einen Überblick über die Änderungen liefert diese Seite:

http://httpd.apache.org/docs/2.4/upgrading.html

Lokal kommt man fast allen Problemen auf die Schliche, wenn man nach dem erfolgreichen Upgrade das Apache-eigene Tool apache2ctl einsetzt und dann die ausgeworfenen Fehlermeldungen Stück für Stück abarbeitet. In fast allen Fällen dürfte das Auskommentieren der beanstandeten Zeilen in den Konfigurationsdateien erst einmal ausreichen, um zu einem wieder funktionierenden Webserver zu gelangen:

sudo apache2ctl configtest

Was dann bei mir noch blieb war eine leere Seite, statt eines Logins für phpMyAdmin. In /var/log/syslog steht der Grund:

PHP Fatal error:  require_once(): Failed opening required ‚./libraries/php-gettext/gettext.inc‘ (include_path=‘.‘) in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 395

In der phpmyadmin.conf Datei fehlt hier der entsprechende Eintrag im Abschnitt <IfModule mod_php5.c> und dort in der open_basedir Anweisung

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/

muss ergänzt werden:

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/

Dann den Apachen neu starten und es sollte wieder tun.

phpMyAdmin schimpfte dann, dass ihm die Bibliothek mcrypt fehle, die jedoch installiert war. Ein

php5enmod mcrypt

löste auch dieses Problem.

Apache 2.4 warnt beim Start vor SNI mit der Meldung

Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

das sollte heute aber nur noch für Windows XP und den dortigen IE gelten. Chromium, Rekonq, Konqueror und Firefox funktionieren ohne Zicken.

Weiter: Mailserver 12.04 auf 14.04

ownCloud Passwort

An der Zickigkeit von ownCloud auf Debian hat sich auch mit dem Upgrade auf die Version 6 wenig geändert. Während auf meinen Ubuntuservern das Upgrade schon immer einfach durchlief, maulte ownCloud mit der gleichen Berechenbarkeit am Ende eines jeden Upgrades auf einem Debian rum, dass das Passwort mindestens eines Benutzers nicht mehr funktioniere etc. pp. Meist lag es am Inhalt der .htaccess Dateien im ownCloud Ordner gepaart mit Firefox und seiner für mich schwer durchschaubaren Cache Verwaltung, die mir hier dazwischen kamen. Da half dann oft die Nutzung von Rekonq – oder eben Anpassungen der .htaccess Files. Heute wollte alles nicht helfen – der Bug saß wo anders (und ich weiß noch nicht wo). Also sah ich mich gezwungen, den Versuch eines Passwort Resets für den Benutzer admin auszuprobieren – was mit phpMyAdmin einfach umgesetzt werden kann.

ocusers

Die Tabelle oc_users auswählen und dort beim gewünschten Benutzer – hier: admin – auf „Edit“ klicken.

adminpw

SHA1 auswählen und das neue Passwort im Klartext eingeben. Durch Klick auf GO speichern. Das Passwort für den Benutzer liegt nun ungesalzen in der Datenbank! Deswegen folgt der nächste Schritt.

oc_personal

An ownCloud anmelden (was funktionieren wird) und nach Klick auf den Benutzernamen (rechts oben) zum Passwort-ändern Dialog von ownCloud navigieren. Dort das so eben gesetzte und ein neues Passwort eingeben.

Nur dieser letzte Schritt stellt sicher, dass das Passwort für diesen Benutzer auch gesalzen in der Datenbank landet, was eine kurze Kontrolle in phpMyAdmin auch bestätigt.

Passwortänderung, PuTTY und Kollegen

Damit meine Kollegen ihre Passwörter auf dem schulischen Mailserver selbst ändern können will ich diesen keine Möglichkeit direkt über Horde5 zur Verfügung stellen. Im Kontext von Heartbleed wurde mir klar, dass Aufrufe zur Passwortänderung nämlich von Lehrer/innen schlicht ignoriert werden oder Passwörter gewählt werden, die diesen Namen nicht verdienen.

Ich habe nun vor, die Passwortverwaltung einerseits selbst in der Hand zu halten, so weit es eben geht, und andererseits aber auch nicht zu sehr zu gängeln.

Es wird deswegen die Möglichkeit geben, sich über SSH mit einem Passwort-geschützten Schlüssel am Mailserver anzumelden und dort passwd zu nutzen, das wiederum ein paar Prüfroutinen auf die Eingaben loslässt. Restricted Shell sollte genug Sicherheit bieten. So richtig böse ist keiner und wenn doch, dann ist der Mailserver eben weg.

Will also ein Lehrer sein Passwort selbst verwalten, dann erhält er von mir in einer verschlüsselten Mail einen TrueCrypt Container und das zugehörige Passwort. im Container befinden sich PuTTYPortable.exe, puttygen.exe und seine private Schlüsseldatei im SSH Format. Weiter kommt noch eine Anleitung mit dazu – denn: Die Ersteinrichtung von PuTTY überlasse ich ebenfalls dem Benutzer.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Mit puttygen muss man zuerst den SSH Key über /Conversions /Import key importieren und dann den privaten Schlüssel im PPK Format wieder abspeichern. Beim Import fragt puttygen nach dem Passwort für den Schlüssel.

http://portableapps.com/apps/internet/putty_portable

In PuTTYPortable sind dann die folgenden Einstellungen vorzunehmen:

  • unter /Session sind der Server und der Port einzustellen
  • unter /Connection /Data /Auto-login-username ist der Benutzername einzutragen
  • unter /Connection /SSH /Auth wird über den Schalter /Browse die vorher erstellte PPK Datei mit dem privaten Schlüssel ausgewählt

Ist PuTTY erst einmal zufrieden gestellt, dann speichert man die ganze Geschichte unter /Session ab, so dass man sich dieses Gefrickel in Zukunft sparen kann.

Pam_unix prüft bei entsprechender Konfiguration und in Zusammenarbeit mit pam_cracklib einiges ab, was zu simple Einfälle unmöglich macht. Da muss ich aufpassen, dass ich nicht übertreibe.

Da an keiner Stelle im Prozess der Passwortänderung auch nur Sternchen angezeigt werden, sind die Fehlerquellen sicherlich Legion. Dazu kommt, dass ein solches Verfahren die meisten schlicht abschrecken wird. Schwarze Felder mit blinkenden grünem Strichlein sind die wenigsten gewohnt.

Das ist dann eben so. Ein Kollateralschaden.

Herzblutfolgen

Meine beiden Schuldomains kvfg.net und kvfg.org hatten COMODO Zertifikate, die ich bei PSW aus der Kategorie Lite kaufte und die sich austauschen ließen. Bisher erfolgte die Lieferung derselben zusammen mit allen nötigen Dateien für den Aufbau einer passenden Zertifizierungskette. Dieses mal war dem nicht so.

Ich erhielt von PSW zwar wieder die cert.cabundle Datei – ein Austausch derselben gegen die vorhandene cert.cabundle reichte für Firefox aber nicht aus. Firefox meldete

sec_error_unknown_issuer

Chromium zickte nicht rum, dafür aber auch Rekonq und Konqueror. Nach der Lektüre von gefühlt 100 falschen Anleitungen im Netz und nach etwas herumprobieren, wie ich mir selbst die richtigen Teile einer Zertifizierungskette zusammenkleben könnte, weiß ich nun endlich, wie es geht:

Man besorgt sich hier bei Comodo die nötigen Dateien

  • COMODORSAAddTrustCA.crt
  • COMODORSADomainValidationSecureServerCA.crt
  • ComodoSSL.ca-bundle

und klebt diese mit cat in der folgenden Reihenfolge zusammen:

cat COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt ComodoSSL.ca-bundle > mydomain.bundle

DIese Bundle Datei kommt zur Direktive SSLCertificateChainFile:

SSLEngine On
SSLCertificateKeyFile /etc/apache2/ssl/mydomain/mydomain.key
SSLCertificateFile /etc/apache2/ssl/mydomain/certificate.crt
SSLCertificateChainFile /etc/apache2/ssl/mydomain/mydomain.bundle

Dann den Apachen neu starten, mit Firefox probieren und zur Sicherheit auch noch hiermit überprüfen: http://www.sslshopper.com/ssl-checker.html

Jetzt fehlt noch der Austausch meiner StartSSL Zertifikate, dann die große Passwortänderungsaktion und das Herzbluten wäre überstanden.

Mailman spricht kein Deutsch

mailman_de

Wer auch immer die Pakete für mailman für Ubuntu packt – die deutschen Sprachdateien blieben außen vor. Man kann sich aber behelfen. Erst einmal schaut man nach, welche Mailman-Version sich das eigene Ubuntu gezogen hat:

dpkg -l | grep mailman

Auf einem 12.04 LTS sollte die Antwort sein:

ii mailman 1:2.1.14-3ubuntu0.1

Also holt man sich das entsprechende Sprachpaket hierzu direkt vom Mailman Server:

wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.14-1.tgz

entpackt dieses (hier als root im Verzeichnis /root) und schiebt es an den richtigen Ort:

tar xfz mailman-2.1.14-1.tgz

cd /etc/mailman/

mv /root/mailman-2.1.14-1/templates/de .

Hiernach kann man die Sprache im Backend auswählen.