This one tool me some time. I lately installed a new sever with debian-jessie and I install the logcheck-packages, allways. So it happend I get mails over mails with one repeating logline:
Feb 19 08:32:43 websrv snmpd[20382]: error on subcontainer 'ia_addr' insert (-1)
I knew this one, because I saw this before. I remembered just changeing something in /etc/default/snmpd
, but this time it doesn't help. Every 30 Seconds new lines like the one above in the syslogs.
After spending some time on dockduckgo I found this workaround in the debian bugtrackers: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684721#30
So the reason this surfaced again recently may be that with systemd in Debian Testing, /etc/default/snmpd is completely ignored. So any changes to the SNMPDOPTS setting in that file have no effect anymore.
Instead editing /etc/default/snmpd
I had to change the file /lib/systemd/system/snmpd.service
(the one systemd is reading)
Changed this line:
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f
to
ExecStart=/usr/sbin/snmpd -Ls6d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f
After reloading systemd (systemctl daemon-reload
) and restarting snmpd (systemctl restart snmpd.service
) the messages went away.
I've been workin with ionic the last days and when starting on an machine with multiple network interfaces you get a nice looking selectmenu. Found that far more beatiful than having that via ncurses, etc.
I've thought about this nearliy the whole day. And startet to work on an bash script to get a simple menu working.
After reading some SO questions and manuals I've ended up with this:
#!/bin/bash
# Copyright (C) 2017 Ingo Hollmann - All Rights Reserved
# Permission to copy and modify is granted under the Creative Commons Attribution 4.0 license
# Last revised 2017-09-08
declare -a menu=("Option 1" "Option 2" "Option 3" "Option 4" "Option 5" "Option 6")
cur=0
draw_menu() {
for i in "${menu[@]}"; do
if [[ ${menu[$cur]} == $i ]]; then
tput setaf 2; echo " > $i"; tput sgr0
else
echo " $i";
fi
done
}
clear_menu() {
for i in "${menu[@]}"; do tput cuu1; done
tput ed
}
# Draw initial Menu
draw_menu
while read -sN1 key; do # 1 char (not delimiter), silent
# Check for enter/space
if [[ "$key" == "" ]]; then break; fi
# catch multi-char special key sequences
read -sN1 -t 0.0001 k1; read -sN1 -t 0.0001 k2; read -sN1 -t 0.0001 k3
key+=${k1}${k2}${k3}
case "$key" in
# cursor up, left: previous item
i|j|$'\e[A'|$'\e0A'|$'\e[D'|$'\e0D') ((cur > 0)) && ((cur--));;
# cursor down, right: next item
k|l|$'\e[B'|$'\e0B'|$'\e[C'|$'\e0C') ((cur < ${#menu[@]}-1)) && ((cur++));;
# home: first item
$'\e[1~'|$'\e0H'|$'\e[H') cur=0;;
# end: last item
$'\e[4~'|$'\e0F'|$'\e[F') ((cur=${#menu[@]}-1));;
# q, carriage return: quit
q|''|$'\e')echo "Aborted." && exit;;
esac
# Redraw menu
clear_menu
draw_menu
done
echo "Selected item $cur: ${menu[$cur]}";
It looks nice and works as I'd like to have it. Here a little screencast while running:
Found information here:
Und wieder mal eine tolle Geschichte.
Da ich kürzlich meinen Server gewechselt habe, musste ich auch nochmal sicherstellen, das alles läuft. Bei den gehosteten Seiten ist auch mein Fotblog dabei. Dieses läuft (leider) auf Wordpress und konnte soweit schnell auf dem neuen Server eingerichtet werden. Es lief alles, zumindest auf dem ersten Blick. Als ich ein neues Foto posten wollte merkte ich aber, das nicht alles so war wie ich es gern gehabt hätte. Die Liste mit allen meinem Posts lieferte eine leere Seite, nichts, einfach nur weiß ohne Code.
Nun, kein Problem, auf dem Server eingeloggt und in die error-logs geschaut. Und siehe da, im apache2/error.log habe ich folgendes gefunden:
[Tue Jan 19 21:09:52.388355 2016] [core:notice] [pid 13632] AH00052: child pid 13651 exit signal Segmentation fault (11)
Tja, da schmiert mit also das Apache-Kindchen ab ohne weitere Hinweise zu geben. Also hab ich mal versucht core-dumps für den Apache zu erhalten, gdb etc. installiert und diverse Einstellungen im apache versucht. Aber einfach keinen Core-Dump bekommen.
Beim Suchen nach Lösungen im Internet bin ich dann darüber gestolpert, das der Fehler evtl von php-ssh2 Modul ausgelöst werden könnte. Dieses habe ich dann mal deaktiviert. Hat aber nichts geholfen, das Problem bestnad weiter.
Erst nach stundenlanger Sucherei und Probiererei habe ich dann das hier gefunden: "How to troubleshoot a PHP script that causes a Segmenation Fault?". Tja, das hat mir zwar bei meinem core-dump nicht weitergeholfen, aber mich dazu gebracht auf dem Server mal xDebug zun installieren. Und Zack - Die Seite ging wieder. Das RecursionLimit von xDebug hat das segfault verhindert.
Beim Anschauen der Seite habe ich dann gesehen, das dort ein als Entwurf gespeicherter Beitrag in der Liste war, der nur den Titel und "Entwurf" in der Zeile gelistet hat. Hier fehlten dem Wordpress wohl weiter Infos, die evtl. beim Umzug draufgegangen sind. Zumindest habe ich den Beitrag dann mal gellöscht und alles ist gut. Ich habe dann mal zum Spass versucht das ganze zu reproduzieren, es aber nicht so einfach hinbekommen.
Ende gut, alles gut. Nur core-dumps im Apache habe ich immer noch nicht :(
]]>Kommen wir mal zu einem komischen Verhalten das ich mir lange nicht erklären konnte. da wir Webseiten schaffen, nutzen wir für Datenspeicherung, wie viele andere auch, mySql. Ob das nun gut oder schlecht ist, darüber kann man lange streiten, tut hier aber nichts zur Sache.
Damit das Problem ersichtlich wird, hier mal ein kurzer Anriss unseres Szenarios. Wir sammeln ein paar Statistikdaten in der Datenbank, damit wir hier nicht zuviel Müll ansammeln, werden automatisiert alte Daten entfernt (per DELETE). Als Datenbank-Layer verwenden wir PDO mit einigen eigenen Erweitereungen für Debugging und Caching.
Nun zum eigentlichen Problem, Wir hatten auf einmal keine Aktuellen Statistikdaten mehr. Die Daten waren älter und wir haben keine neuen erhalten. Klingt erstmal noch Platte voll oder sowas, also Platte und Tabellen gechecked. Alles in Ordnung. Tabelle hatte nur noch ca. 1Mio Einträge (alte Einträge werden ja gelöscht).
Statistikscript erneut angeschrieben mit pdo->errorinfo() ausgabe. Und siehe da... kein Fehler, angeblich hat alles funktioniert :(
Als nächstes dann mal versucht einen Eintrag manuell in der Datenbank anzulegen. Und endlich, hier ein Fehler: Duplicated Key. ... Moment mal habe ich mir gedacht, wie geht das den, der Primary Key ist doch autoincrement. Tja, aber nur als INT definiert gewesen. Wir hatten mittlerweile über 2147483647 Einträge in der Tabelle gehabt und wieder gelöscht. Dadurch hat das autoincrement immer den größt-möglichen Wert angenommen und damit einen Duplicate Key Fehler ausgelöst.
Um diesen Fehler jetzt zu beheben und vorzubeugen, habe ich unser Aufräum-Script ein wenig geändert. Statt alte Datensätze zu löschen, fügen wir nun die aktuellen Daten, die wir weiter verwenden wollen in eine neue Tabelle ein mit neuem Autoicrement-Wert. Dadurch wird der Zähler nach jedem Aufräumen quasi resettet und wir laufen nicht nochmal in das Problem.
]]>Die Initiative Let's Encrypt hat die Beta-Phase des Projekts jetzt öffentlich gemacht. Dies ist für mich natürlich ein Grund das ganze mal zu testen.
Daher gibt es mein Blog nun unter https und mit Verschlüßelung über die Zertifakte von Let's Encrypt. Wie einfach das war und was dazu gemacht werden muss, beschriebe ich hier dann mal später.
Einige Tage später... um genau zu sein fast einen Monat, habe ich jetzt endlich mal die Zeit gefunden, den Eintrag hier fertig zu schreiben.
Da die komplett automatisierte Einrichtung bei mir nicht komplett funktioniert hat, habe ich einige Schritte manuell durchführen müssen. Hier jetzt eine Schritt für Schritt Anleitung.
git clone https://github.com/letsencrypt/letsencrypt
apt-get install python-augeas python3-dialog
./letsencrypt-auto
gestartet werden./etc/letsencrypt/live/www.bughunter2k.de/
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/www.bughunter2k.de/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.bughunter2k.de/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/www.bughunter2k.de/fullchain.pem
Sinnvoll ist es, die http-Anfragen direkt uaf https Umzuleiten, damit alle Kommunikation über ssl abläuft, dazu einen neuen VirtualHost anlegen:
<VirtualHost _default_:80>
ServerName bughunter2k.de
ServerAdmin bughunter2k@bughunter2k.de
Redirect permanent / https://www.bughunter2k.de
</VirtualHost>
So, das wars. Wenn das Zertifikat abgelaufen ist, kann dieses mit dem letsencrypt-client auch wieder erneuert werden.
PS: Wer den Client nicht nutzen möchte, der kann auch manuell die Zertifikate Anfordern und Validieren, dazu hat sich wer die Mühe gemacht https://gethttpsforfree.com/
]]>Wir haben in diversen Projekten einen memcached für das Zwischenspeichern von häufig auftretenden Datenbank-Abfragen im einsatz. In einigen Fällen ändern sich die Grunddaten der Server zweimal am Tag. Damit wir jetzt keine alten Daten mehr ausliefeern, mussd der memcached natürlich geleert werden.
Dafür hatte ich ursprünglich ein einfaches cronscript geschrieben mit folgendem Inhalt:
echo flush_all >/dev/tcp/127.0.0.1/11211
Nun hat sich dies auf einem anderen (älteren) Server als nicht brauchbar erwiesen, da hier kein /dec/tcp existiert. Die alternative über netcat
mit
echo "flush_all" | nc localhost 11211
Dies hat aber das Problem, das der Befehl nicht korrekt terminiert, da kein quit
gesendet wird. Hier habe ich auf serverfault den Vorschlag gefunden, das quit
gleich mitzusenden über
printf "flush_all\nquit\n" | nc -q -1 127.1 11211
Auch war hier ein Hinweis auf die memcachedtools zu finden. In dieser Sammlung befindet sich unter anderem das tool memcflush
, welches genau das macht, was ich möchte. Dadurch ist mein cronjob jetzt ganz einfach auf
memcflush --servers=localhost:11211
geschrumpft und durch die Namensgebung des Tools sieht man auch gleich was hier passiert. schöne Sache.
]]>Nachdem ich nun ein wenig mit Grav gespielt habe, muss ich sagen das mir nach einer sehr kurzen Einarbeitung das Schreiben und Erstellen von Artikeln recht schnell und einfach von der Hand geht.
Aktuell arbeite ich fast ausschliesslich auf der Konsole mittels der CLI- Interfaces von Grav und mit vi. Da das ganze Dateibasiert ist, hab ich auch keine großen befürchtungen, da was kaputt zu machen.
Als gute Lektüre hat sich die Dokumentation und die Anleitungen auf der Grav-Seite erwiesen, hier findet man allerlei hilfreiche Informationen. Ansonsten ist im Github Repository einiges bei den Issues zu finden was dann auch mal helfen kann.
Ich werde in den nächsten Tage wohl noch weiter experimententieren und Tests machen und vielleicht auch programmieren. Dabei werden wohl dann noch ein paar keinere oder grössere Artikel entstehen.
]]>Da meine alte Homepage -- basierend auf dem leider nicht mehr weiter gepflegten phpMyForum -- nun schon seit Jahren brach liegt, habe ich mich entschlossen mal hier was neues zu machen und einen Blog zu starten. Hier werde ich immer mal wieder einige Tipps, Tricks oder Kniffe präsentieren, über die ich so im Arbeitsalltag stolpere.
Beruflich programmiere ich Webseiten in php mit mysql, javascript/jQuery und html5/css3. Da es hier des öfteren kleine und größere Stolpersteine gibt die bewältigt werden müssen, werde ich mich bemühen, die Lösungen dazu hier zu beschrieben. Primär für mich als Nachschalgewerk, aber warum sollte ich nicht andere auch daran teilhaben lassen?
]]>