Kleine und große Linux AHAs
bash
Asterisk Projekt: Season 12 – Snoms Registriert Euch!!! Jetzt!!!
03. Mai
Folgendes Szenario: Der Asterisk Prozess schmiert aus irgendeinem Grund ab. Der Dienst wird wieder hochgefahren und die Telefone sind nicht mehr registriert. Was nun? Klar, nach einer gewissen Zeit erneuern die Geräte ihre Registrierung und sind wieder erreichbar. Aber bis dahin? Und wie lange dauert das?
Kurz und dreckig – ich will dass sie das jetzt tun!
Ok, wir sprechen hier über Snom Telefone. Diese können per Remote bedient werden und das machen wir uns zu Nutze. Wir simulieren einfach den Klick auf “Re-Registrieren” der Weboberfläche. Dazu nutzen wir wget.
Aber
Normalerweise nutze ich um die Telefone anzusprechen die IP aus der Datenbank. Leider ist in dem Fall in der Datenbank auch kein IP Eintrag – Telefon ja nicht registriert
Also was anderes. Mir kam die Idee das ganze über den ARP Cache zu machen. OMG! Warum das denn?
Naja eigentlich ganz einfach. Anhand der MAC kann man Snom Geräte bestimmen. Damit ich dann wirklich nur Snom Geräte mit dem Befehl anspreche muss ich lediglich alle MAC Adressen nehmen die mit 00:04:13 beginnen. Damit hab ich alle IPs die ich ansprechen muss.
Das Script dazu
#!/bin/bash
#
# Scan ARP Cache for Snom Devices and send a re-register to them
#
SNOM_USER="webloginUser"
SNOM_PASSWORD="webloginpw"
for IP in `grep "00:04:13" /proc/net/arp | cut -f1 -d " "`</p>
do
wget --no-proxy --post-data="REREGISTER:1=Re-Registrieren" http://${SNOM_USER}:${SNOM_PASSWORD}@${IP}/line_login.html >/dev/null 2>&1;
print "Did ${IP}";
}
Nachdem das Script gelaufen ist sollten sich wieder alle Telefone am Asterisk Server angemeldet haben.
Asterisk Projekt: Season 11 – Asterisk <-> MySQL UTF8
30. Apr
Um unseren Asterisk möglichst flexibel zu halten wurde Asterisk mit MySQL Schnittstelle installiert. Das bringt uns in die Lage recht einfach Konfigurationsänderungen vorzunehmen – nämlich in der Datenbank und damit ohne Neustart des Dienstes. Nun leben wir in Deutschland und in Deutschland gibt es Umlaute. Umlaute sind immer so eine Sache in Datenbanken, Programmen, Scripten etc..
Auch unser Asterisk kann per Default nichts mit Umlauten anfangen – wenigstens nicht aus der Datenbank so wie wir sie aufgesetzt haben. Server als auch Client (MySQL & Asterisk) müssen auf einen passenden Zeichensatz gebracht werden um ohne Verluste miteinander sprechen zu können – es empfiehlt sich UTF8.
Woran sieht man ob es überhaupt Probleme gibt? Naja, man lege eine Nebenstelle an. Die CallerID (Name) lautet “Max Müller”. Was kommt beim Angerufenen an? Ich schätze Sonderzeichen stehen im Display anstatt “Max Müller”. Das ganze ebenfalls bei der Queue – wenn man diese aus der Datenbank bedient. Schaut man sich dann die Mitglieder der Queue an und hat ein Mitglied mit Sonderzeichen im Namen, so ist das weniger hübsch
Wie wird das ganze korrigiert?
Hat man nun einen Asterisk mit MySQL Anbindung in Betrieb, so kann man wie folgt vorgehen:
- Anpassen der MySQL Konfiguation
- Dump der Datenbank(en)
- Restart von MySQL
- Anpassen des Dumps
- einspielen des Dumps in die DB (ersetzen der alten DB)
- Neustart von Asterisk
en Detail
Anpassen der MySQL Konfiguration (/etc/mysql/my.cnf oder /etc/my.cnf):
im Bereich [Client] folgendes hinzufügen:
default-character-set=utf8
im Bereich [mysqld] dieses:
default-character-set=utf8 default-collation=utf8_general_ci character-set-server=utf8 collation-server=utf8_general_ci
mysqldump
mysqldump -uroot -pasterisk -c -e --default-character-set=utf8 --single-transaction --skip-set-charset --add-drop-database -B asterisk_db > /tmp/asterisk_db.sql cp /tmp/asterisk_db.sql /tmp/asterisk_db_utf8.sq
Anpassen des Dumps
sed -i 's/DEFAULT CHARACTER SET latin1/DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci/' /tmp/asterisk_db_utf8.sql sed -i 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' /tmp/asterisk_db_utf8.sql sed -i 's/CHARACTER SET latin1/CHARACTER SET utf8/' /tmp/asterisk_db_utf8.sql
Durch diese sed Befehle werden alle latin1 Character Sets durch UTF8 ersetzt. Dadurch wird beim Import für MySQL die Datenbank und alle Tabellen/Spalten auf UTF8 gesetzt.
Als Script sieht das ganze dann so aus:
#!/bin/bash # Dump the DB mysqldump -uroot -pasterisk -c -e --default-character-set=utf8 --single-transaction --skip-set-charset --add-drop-database -B asterisk_db > /tmp/asterisk_db.sql /etc/init.d/mysql restart # make copy cp /tmp/asterisk_db.sql /tmp/asterisk_db_utf8.sql # update table and column definitions sed -i 's/DEFAULT CHARACTER SET latin1/DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci/' /tmp/asterisk_db_utf8.sql sed -i 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/' /tmp/asterisk_db_utf8.sql sed -i 's/CHARACTER SET latin1/CHARACTER SET utf8/' /tmp/asterisk_db_utf8.sql mysql -uroot -pasterisk < /tmp/asterisk_db_utf8.sql sleep 1 /etc/init.d/asterisk restart
Wann durchführen?
Da das Script quasi alles macht und die Datenbank im Normalfall nicht so wahnsinnig groß ist, kann man das “Zwischendurch” machen. Je nach Umgebung sollte natürlich eine Zeit gewählt werden, in der wenig bis gar nichts los ist. Das Script braucht nur wenige Sekunden. Bisschen Mut gehört dazu
Wichtig zu wissen ist, dass sich die Telefone neu registrieren müssen bevor sie wieder Gespräche annehmen können.
Unleserliches debuggen, oder: Fehlersuche in verschlüsselten Protokollen
03. Mai
Immer mehr Datenverkehr wird verschlüsselt. Einerseits natürlich richtig und gut. Andererseits ein Problem. Früher konnte man mit Hilfe von Tools wie Wireshark (Ethereal) oder tcpdump relativ schnell Probleme (z.B.) in der Kommunikation zwischen Programm und Server herausfinden. Einfach den Netzwerkverkehr mitschneiden, ansehen / auswerten und es zeigten sich Fehler die man im Programm möglicherweise nicht zu Gesicht bekommen hat.
Mittlerweile sind die Pakete weitestgehend verschlüsselt und man kann nicht mehr einfach so “mit schreiben” – naja, man kann natürlich; aber lesen kann man es nicht. Also fällt ein mitschreiben – einfach mal so – flach.
Eine andere Möglichkeit die Kommunikation zwischen Programmen zu debuggen ist, sich einfach manuell zu verbinden und die Kommandos direkt einzugeben um zu prüfen ob der Server richtig reagiert. Dazu nahm man früher telnet … Auch telnet ist kein Kandidat mehr für verschlüsselte Protokolle.
Verbindung zu einem SSL geschützten Dienst
Eine Möglichkeit sich auf einen solchen Dienst zu verbinden bietet der Befehl
openssl s_client -connect <Zielrechner>:<Port>
Mit diesem Befehl kann man sich beispielsweise direkt auf einen per SSL geschützten IMAP Server (Port 993) verbinden und manuell Kommandos absetzen. Das ganze über eine SSL geschützte Verbindung – die nicht mitgeschnitten werden kann
Ganz wie früher mit telnet *freu*
Schizophrene Router überwachen
25. Mrz
Es geht um redundante Internetanbindungen. Bekommt man diese von seinem Provider installiert, so hat man zwei Router in seinem Rechenzentrum stehen. Beide Router haben eine IP Addresse und halten eine weitere, virtuelle Addresse dei das Gateway darstellt.
Unterschiedliche Bandbreiten
Nun ist es so, dass man nur selten zweimal mit der identischen Bandbreite angebunden wird. Beispielsweise – auch je nach Standort – kann es sein, dass man nur 10% der normalen Leistung auf dem Backupmedium hat. So ist es natürlich wichtig zu wissen wenn die Hauptleitung ausfällt um einerseits das Problem zu melden und auch andererseits vielleicht diverse Dienste abzuschalten. Nur wie kann man erkennen welcher Router gerade aktiv ist? SNMP Zugriff ist meist auf Providerrouter nicht möglich – warum auch immer.
Welcher ist aktiv?
Wir hatten dann zuerst geplant die MAC Addresse über ARP zu prüfen – wenn sie sich ändert wäre der Router umgeschaltet worden. Leider nimmt HSRP (Hot-Standby-Routing-Protocoll) die MAC Addresse mit. Also ging das auch nicht. Was dann ging ist das ganze per traceroute zu machen. Traceroute zeigt als einen Hop eine der festen IPs der Router. Auf diese Weise kann man also bestimmen welcher Router gerade aktiv ist.
Das Script dazu
#!/bin/bash
# Dieses Script prueft per traceroute welcher
# Router gerade aktiv ist.
#
# Da wir keinen Zugriff auf die Router haben
# (snmp oder anders) musste das so gemacht werden.
#
# Ronny Becker, 03.2011
# Gateway IPs
PRI_GW=""
SEC_GW=""
# HOPs to GW
GW_HOPCOUNT="2"
# Check Target(s)
TEST_TARGET="www.heise.de www.google.de"
# Do your job
for TARGET in $TEST_TARGET
do
# run trace
TRACE=$(traceroute -m $GW_HOPCOUNT $TARGET 2>&1)
if [ $? != 0 ]
then
continue
fi
# check if primary matches
if [[ $TRACE =~ $PRI_GW ]]
then
echo "Primary Gateway active"
exit 0
fi
# check if secondary matches
if [[ $TRACE =~ $SEC_GW ]]
then
echo "Seconday Gateway active"
exit 1
fi
done
echo "Unknown Gateway status"
exit 2
Das Script ist so gemacht, dass es von Nagios genutzt werden muss. Wer das ganze auf Mail umstellen möchte muss halt ein paar Änderungen vornehmen.
[Update] Und heute im Ü-Ei: Advanced Disclaimer für Postfix
10. Mrz
In meinem Artikel zum Advanced Disclaimer für Postfix mit Hilfe von altermime haben sich ein paar kleine Fehler eingeschlichen. Ich habe die Fehler nun korrigiert und den Artikel (den Script Teil) überarbeitet.
Fehler 1:
Die Empfängeraddresse wurde nicht richtig bestimmt
REC_DOMAIN=${2##*@}
muss heißen
REC_DOMAIN=${4##*@}
Fehler 2:
Durch diesen Fehler kann es passieren, dass Mails teilweise ganz abgeschnitten ankommen, bzw. auch teilweise “nur” der Anhang fehlt. Das ganze ist darauf zurückzuführen, dass sich in der Mail – wenigstens dann wenn sie von altermime bearbeitet wurde – eine Zeile mit lediglich einem Punkt befindet. Dies wird von Postfix bei der Rückgabe als “ende” interpretiert. Daher muss der sendmail Aufruf innerhalb des Scripts angepasst werden (3x).
Aus
$SENDMAIL "$@" <in.$$
wird also
$SENDMAIL -i "$@" <in.$$



