Bird unter Debian

Im Rahmen eines Router-Upgrades durfte habe ich den BIRD unter debian-stretch installiert. Dabei kam es während der Installation zu einem Fehler. In der Datei „/usr/lib/bird/prepare-environment“ wird das chown mit einem „–silent“ parameter abgesetzt, den es unter debian-stretch nicht (mehr?) gibt.

wenn man das ganze wie folgt umbaut, klappt es auch mit der installation und anschließendem start.

#!/bin/sh
set -eu

BIRD_RUN_DIR=/run/bird
. /etc/bird/envvars


mkdir --parents "$BIRD_RUN_DIR";

if [ -n "$BIRD_RUN_USER" ]; then
    if ! getent passwd $BIRD_RUN_USER >/dev/null; then
        echo "Configured user '$BIRD_RUN_USER' doesn't exist."
        exit 1
    fi
fi

if [ -n "$BIRD_RUN_GROUP" ]; then
    if ! getent group $BIRD_RUN_GROUP >/dev/null; then
        echo "Configured group '$BIRD_RUN_GROUP' doesn't exist."
        exit 1
    fi
fi

chown "$BIRD_RUN_USER:$BIRD_RUN_GROUP" "$BIRD_RUN_DIR"
chmod 775 "$BIRD_RUN_DIR"

:

uacctd unter systemd

Wer „aus Gründen“ einen uacctd auf einem System einsetzt, bei dem zwar der systemd zum einsatz kommt, aber das uacct-packet kein Service-File mitliefert, hier ein excampel:

[Unit]
Description=uacctd daemon providing Netflow collection service
Wants=network.target
After=network.target
ConditionPathExists=/config/uacct/uacctd.conf

[Service]
Type=forking
ExecStart=/usr/sbin/uacctd -f /config/uacct/uacctd.conf

[Install]
WantedBy=multi-user.target

Kolab Postfix stellt google mails nicht zu.

Wenn man postfix mit einem Kolab backend betreibt kommt vor dem Zustellen der Mails das Python-Script kolab_smtp_access_policy zum Einsatz.

Dieses prüft ob Sender- oder Empfänger-Adresse im LDAP hinterlegt ist. Das Prüfergebnis wird anschließend gecached. Und hier fängt der Ärger an. Das Script als auch das DB-Design sehen 64 Zeichen für eine E-Mail-Adresse vor. 254 Zeichen dürfen es aber sein. Google verwendet für die Verification Mail nun aber mehr als 90 Zeichen.

Um den Fehler zu beheben muss man zuerst in der kolab-Datenbank die tabelle policy_result bearbeiten. Die Spalten sender und recipient müssen auf 254 erweitert werden.

alter table policy_result modify sender varchar(254);
alter table policy_result modify recipient varchar(254);

anschließend muss man das /usr/lib/postfix/kolab_smtp_access_policy bearbeiten. Dort muss man den Eintrag policy_result_table wie folgt anpassen.

policy_result_table = Table(
        'policy_result', metadata,
        Column('id', Integer, Sequence('seq_id_result'), primary_key=True),
        Column('key', String(16), nullable=False),
        Column('value', Boolean, nullable=False),
        Column('sender', String(254), nullable=True),
        Column('recipient', String(254), nullable=False),
        Column('sasl_username', String(64)),
        Column('sasl_sender', String(64)),
        Column('created', Integer, nullable=False),
        Column('data', PickleType, nullable=True),
    )

kolab_smtp_access_policy exit status 1

Wer einen Kolabserver auf einem Ubuntuserver hochzieht, wird aktuell irgendwann (beim Versand oder Empfang von Mails) auf den Fehler „kolab_smtp_access_policy exit status 1“ stoßen. Alle Maßnahmen das logging aufzudrehen, greifen ins leere und man ist verzweifeln …

In diesem Fall sollte man doch einfach das script per hand aufrufen. Wichtig dabei, postfix verwendet pyhton2.7…

python2.7 /usr/lib/postfix/kolab_smtp_access_policy

Mit hoher Warscheinlichkeit kann das Module pymysql nicht geladen werden. Einfach das Modul nachinstallieren und schon kann es mit dem Mail-Empfang losgehen.

apt-get install python-pymysql

kolab_smtp_access_policy debugen

Ich betreibe seit ein paar Tagen eine Kolab-Server und bin dabei über die ein oder andere Baustelle gestolpert. Am meisten probleme hat mit die kolab_smtp_access_policy bereitet.

Diese wird vom postfix aufgerufen um zu prüfen ob eine Mail angenommen werden darf. Bei kolab_smtp_access_policy handelt es sich um ein Python Script, das ohne weiteres schwer von der Console aufgerufen werden kann.

Leider logt das Script standartmäßig nichts. Um das Logging zuzuschalten muss man unter /etc/postfix/master.conf dem scritpaufruf parameter mitgeben.

recipient_policy_incoming unix  -       n       n       -       -       spawn
    user=kolab-n argv=/usr/lib/postfix/kolab_smtp_access_policy --verify-recipient --allow-unauthenticated -l debug -d 9

Das „-l debug -d 9“ sorgt dafür, dass das Logfile /var/log/kolab/pykolab.log gefüllt wird. Jetzt kann man mit der Fehlersuche beginnen…

Änderungen bei LVM

Wer wie ich regelmäßig einen Raid 1 (Mirror) mit LVM aufbaut/betreibt, wird seit neusten (zu mindestens wenn er auf den aktuellen Ubuntu LTS setzt) in folgendes Problem laufen. Der bisher gültige Befehl führt nicht mehr zum gewünschten Ergebnis:

lvconvert -m 1 volumeGroup/logicalVolume  --corelog
  Insufficient free space: 1 extents needed, but only 0 available

Das ganze liegt daran, dass sich die art wie LVM jetzt einen Raid aufbaut wohl geändert haben soll. Ich bin da nicht tiefer hinabgestiegen. Schlussendlich muss man einfach noch den Typ mit angeben, dann klappt es wieder.

lvconvert -m 1 volumeGroup/logicalVolume  --corelog --type mirror
  volumeGroup/logicalVolume: Converted: 0,0%
  ...
  volumeGroup/logicalVolume: Converted: 100,0%

ExpireDate von Zertifikat überwachen.

Wer, wie ich, eine eigene (private) CA betreibt, wird irgendwann mal überrascht feststellen, dass auch das Root-Zertifikat ausläuft. Standardmäßig nach 4 Jahren. Wenn plötzlich der Radius keine Clients mehr ins Netz lässt, wenn jede interne HTTPS-Verbindung auf Warnung läuft und man sich plötzlich wieder mit Notfall-Passwörtern anmelden muss, weiß man, dass man vergessen hat, sein Root-Zertifikat rechtzeitig zu erneuern.

Was bei einzelnen Clients noch mit vertretbaren Aufwand zu beheben ist, nervt beim Zwangs erneuern der CA doch ziemlich, besonders wenn man gerade etwas anderes vor hatte.

Für diesen Zweck hab ich mir ein kleines Script gebastelt, das via Munin alle Cert-Restlaufzeiten ermittelt und rechtzeitig Alarm schlägt.

wie immer unter GPL hier zu beziehen: Check Expire Date

OpenVPN – TLS-Server-Check bestehen

OpenVPN liefert gleich eine ganze BuildChain mit um sich Zertifikate zu generieren und zu signieren. Leider hat man meist schon eine Infrastruktur (CA) im Feld mit der man seine Zertifikate signiert und verteilt. Bei mir habe ich das immer über das in Ubuntu mitgelieferte CA.pl Skript gemacht und die so erzeugten Zertifikate funktionieren gerade nicht in OpenVPN. Es kann zwar eine Verbindung aufgebaut werden aber ein TLS-Server-Check schlägt fehl. Um gültige Zertifikate zu erzeugen muss man folgendes machen.

in der /etc/ssl(openssl.cnf muss man eine neue Sektion anlegen. Am besten mit dem Namen „Server“ oder „OpenVPNHost“

[ server ]
basicConstraints=CA:FALSE
nsCertType          = server
nsComment           = "Some comment"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
extendedKeyUsage=serverAuth
keyUsage = digitalSignature, keyEncipherment

anschließend muss man das certifiacte wie folgt erzeugen:

openssl req -days 365 -nodes -new -keyout newkey.pem -out newreq.pem -extensions server -config /etc/ssl/openssl.cnf
openssl ca -days 1095 -extensions server -in newreq.pem -policy policy_anything -out newcert.pem

Das so erzeugte Zertifikat besteht auch einen TLS-Server-Check