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

Samsung Handy disconnected sich ständig.

Bestimmte Android Phones (bei mir eine Samsung A3 2016) scheinen ein Problem mit ihrer 802.11r Implementierung zu haben.

Symptom: Es kann keine Stabile WLAN Verbindung aufgebaut werden. Ständig disconnected/reconnected sich das Device. Bei mir hat es nur eines von 8 Geräten betroffen, deshalb hab ich die AP/Controller Seite Implementierung ausschließen.

Lösung: testhalber mal UAPSD auf dem Netzwerk abschalten

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…

EdgeMax router retten …

Ich hatte die vergangene Woche relativ viel Pech und ich beide meiner EdgeMax-Router (EdgeMax Lire und EdgeMax 5PoE) in einen zustand gebracht, in dem sie nicht mehr ordentlich booteten. Beide Zustände waren selbst verschuldet: Bei einem Router hab ich scheinbar einen wichtigen BootSkript modifiziert, so dass in einem bestimmten Zustand ein Booten nicht mehr möglich war. Bei dem anderen Router hab ich wohl durch „ungünstiges“ Reseten das FileSystem geschrottet.

Es stehen nun zwei Varianten für das Recovery zur Verfügung.

  1. Recovery System vie TFTP booten und Fehler beheben
  2. Router aufschrauben, USB Stick ausbauen, Stick an anderem System mounten und die Reperatur starten

Alles setzt auf dem EdgeMax RecoveryKit auf. Will man via TFTP sein system retten, geht man nach dieser Anleitung vor: https://community.ubnt.com/t5/EdgeMAX/EdgeMax-rescue-kit-now-you-can-reinstall-EdgeOS-from-scratch/td-p/514857

In meinem fall musste ich jedoch nicht alles neu installieren. Wenn man das Rettungs-OS hoch gefahren hat, ist unter /root/w das overlay gemounted. Hat man im EdgeOS irgendein Script oder Config File geändert, taucht es hier auf. Löscht man es, hat man wieder die original Version. Im Zweifelsfall kann man einfach alle Änderungen in einen Sicherungs-Ordner verschieben und von Scratch starten …

Eine andere Hausnummer war der IO Defect. Hier musste ich erst mal den Stick ausbauen und testen. Nach mehrfachen „badblock“ Durchläufen war klar, dass es nur das FileSystem zerschossen hatte. Da nach den Durchlauf von Badblock die PartionsTabelle zerstört wurde muss ich komplett vom scratch aufsetzten.

Mit folgendem script habe ich angefangen: https://github.com/vyos/emrk/blob/master/bin/emrk-reinstall.

Da ich keine Risiko eingehen wollte, habe ich alle befehle einzeln per hand ausgeführt, man kann aber auch einfach die variablen korrekt setzten und das Skript im ganzen ausführen. Anschließend Stick wieder einbauen router hochfahren und neu konfigurieren…