Wenn man eine GSX 1000 unter Linux/PulseAudio in Betrieb nimmt, stellt man fest, dass nur ein „Audio Analog Mono“ Device erkannt wird. Von 7.1 Kanälen keine Spur.
um das zu lösen muss man pulsaudio eine Device-Abhängige config beibigen. Komplett zum download gibt es das hier: github:evilphish/sennheiser-gsx-1000
Danach kann man die Karte voll nutzen.
git fetch upstream git merge upstream/git push git pull --strategy subtree --squash addon master --allow-unrelated-histories git commit -m "[addon] 1.0.2" git push
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"
:
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
openssl pkcs12 -export -out certificate.pfx -inkey newkey.pem -in newcert.pem -certfile cacert.pem
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
Wer bei einem Cyrus mal gelöschte Mails wieder Herstellen muss …
Listed alle gelöschten Nachrichten einer Mailbox
/usr/lib/cyrus-imapd/unexpunge -l [MailBox]
Stellt eine Nachricht wieder her
/usr/lib/cyrus-imapd/unexpunge -udv [MailBox] [Id]
Stellt alle Nachrichten wieder her…
/usr/lib/cyrus-imapd/unexpunge -adv [MailBox]
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),
)
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
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…