RSylog GELF (Graylog) Format verwenden

Graylog bietet einen einfach zu konfigurierenden Syslog-Input an. Leider kommt es jeh nach verwendeten „Loglayout“ dann zu parsing Fehlern. Bei mir hat es z. B. hauptsächlich die Genauigkeit des Zeitstempels betroffen.

Am leichtesten löst man das Problem indem man RSyslog dazu bringt, im GELF Format zu loggen. Dies ist ein einfaches JSON Format und ohne Probleme vie RSyslog-Template umzusetzten:

template(name="gelf" type="list") {
    constant(value="{\"version\":\"1.1\",")
    constant(value="\"host\":\"")
    property(name="hostname")
    constant(value="\",\"facility\":\"")
    property(name="syslogfacility-text")
    constant(value="\",\"facility-num\":\"")
    property(name="syslogfacility")
    constant(value="\",\"syslogtag\":\"")
    property(name="syslogtag")
    constant(value="\",\"priority\":\"")
    property(name="syslogpriority-text")
    constant(value="\",\"message\":\"")
    property(name="msg" format="json")
    constant(value="\",\"timestamp\":")
    property(name="timegenerated" dateformat="unixtimestamp")    
    constant(value=".")
    property(name="timegenerated" dateformat="subseconds")    
    constant(value=",\"level\":\"")
    property(name="syslogseverity")
    constant(value="\",\"severity\":\"")
    property(name="syslogseverity-text")
    constant(value="\"}")
}

action(type="omfwd" target="deepdraft.aqua" port="12201" protocol="udp" template="gelf")

Unifi Controller – Mailversand schlägt fehl

Der Unifi Controller unterstützt mittlerweile nicht nur das StartTLS sonder prüft auch das Zertifikat des Mail Servers. Was erstmal in die Kategorie „Captain Obvious“ fallen sollte, wird interessant, weil frühere Versionen das nicht gemacht haben und die Zertifikatsprüfung auch gemacht wird, wenn man 127.0.0.1 als Mailserver verwendet.

Konkret: auch wenn man in der Controller-Config angibt, dass der Mailserver ohne SSL/TLS anzusprechen ist, wird beim Verbindungsaufbau ein StartTLS gesendet und das Zertifikat geprüft. Das Zertifikat muss zur verwendeten MailServer-Addresse passen. Wer den MailServer lokal betreibt oder direkt mit IP anspricht, muss das Zertifikat entsprechend anpassen oder die korrekte DNS-Adresse verwenden.

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%