Stephans Blog

Building a raspberry pi as a door sensor

build a real rack out of IKEA s Lack tables

[lang_en]
this morning websphere client of one of the cluster I manage stopped working with the following error.
Cannot connect to vCenter Single Sign On server. https://(FQDN or IP address of SSO):7444/ims/STSService.

The Reason was simple and curious.
The SSO Service was running a year an needs a restart because of a expired temporary certifcate.

Here is the KB article
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2122788

[/lang_en][lang_de]
diesen Morgen stellte the websphere client eines der Cluster sienen Dienst mit folgender Fehlermeldung ein.
Cannot connect to vCenter Single Sign On server. https://(FQDN or IP address of SSO):7444/ims/STSService.

Dert Grund ist simpel aber seltsam.
Der SSO Service lief seit einem Jahr und musste wegen eines tempoären,abgelaufenen Zertifikates neugestartet werden

Hier ist der KB Artikel:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2122788

[/lang_de]

Old Systems which are vunerable because wikipedia
shellshock aren’t that easy to update. One method is compilling bash manually ( stolen from ubuntu )

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #build and install ./configure --prefix=/ && make && make install cd .. cd .. rm -r src

Ältere Systeme die von Shellshock
wikipedia
betroffen sind lassen sich nicht direkt updaten. Eine Option ist das selber Kompilieren ( geklaut bei ubuntu )
mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #build and install ./configure --prefix=/ && make && make install cd .. cd .. rm -r src

Symptom

Mysqlserver beendet sich selber . Auch nach einem Neustart beendet sich der Server nach wenigen Sekunden selbst

In /var/log/daemon.log befinden sich lange mysql Hexdumps sowie die Anmerkung das vermutlich die Datenbank auf Platte korrumpiert ist

Voraussetzung zur Behebung

Für solche Notfälle sollte man immer einen aktuellen mysqldump aller Datenbanken zur Hand haben. Wenn nicht kann man die Datenbank nicht ohne Datenverliste reparieren.

Lösung

Mysql mit dem dem Parameter

innodb_force_recovery = 4

starten.

So lange alle Datenbanken dropen ( mit drop Database ) bis mysql wieder ohne diesen Parameter startet.

Wenn alle Datenbanken betroffen sind muss die komplette Datenbank neuinstalliert werden . Vorher sollte /var/lib/mysql gelöscht oder umbenannt werden

Läuft die Datenbank wieder normal kann das Backup wieder eingespielt werden

Symptom

Mysqlserver is suddenly stopping (crashing) . Even after a restart the server ist stopping after a few seconds again.

In /var/log/daemon.log there are large mysql Hexdumps as well as the assumtion that the database is physically corrupt.

prerequirement for a successfull repair

In case of such an emergncy you need an uptodate mysqldump of all databases. If not, you have no change to fix the database without the loss of data

solution

restart Mysql with the Parameter

innodb_force_recovery = 4

drop your databases ( with drop Database ) as long till mysql starts normaly

If all Databases are part oft the problem, then you have to deinstall mysql , purge /var/lib/mysql , an then install mysql again.

At the latest mysql should run normal now. Time to use the dump to restore your databases.

Symptom

There are two NFS exports in the /etc/exports file on the NFS server. Regardless of which export is mounted, only the first export actually gets mounted.

The /etc/exports looks like this

#cat /etc/exports
/exports/export1 *(rw,sync,insecure,root_squash,no_subtree_check,fsid=0)
/exports/export2 *rw,sync,insecure,root_squash,no_subtree_check,fsid=0)

Solution

Reason for this stange behaviour is the Duplicate fsid setting. You can only have one fsid=0 per NFS Server. Change the second fsid to a small integer and everything is working as designed

# cat /etc/exports
/exports/export1 *(rw,sync,insecure,root_squash,no_subtree_check,fsid=0)
/exports/export2 *rw,sync,insecure,root_squash,no_subtree_check,fsid=1)

Symptom

Es sind zwei NFS exports in der /etc/exports auf dem NFS server konfiguriert. Egal, welchen Mountpoint man mounted, es wird immer der Inhalt des ersten angezeigt.

Die /etc/exports sieht folgendermassen aus

#cat /etc/exports
/exports/export1 *(rw,sync,insecure,root_squash,no_subtree_check,fsid=0)
/exports/export2 *rw,sync,insecure,root_squash,no_subtree_check,fsid=0)

Lösung

Grund für dieses selstame Verhalten ist die identische Konfiguration für die fsid. Die fsid muss einzigartig sein.
Wenn man nun die zweite fsid in eine kleine Zahl ungleich 0 ändert dritt dieses Problem nicht mehr auf
# cat /etc/exports
/exports/export1 *(rw,sync,insecure,root_squash,no_subtree_check,fsid=0)
/exports/export2 *rw,sync,insecure,root_squash,no_subtree_check,fsid=1)

In einer Fortbildung mit Kollegen haben wir heute die in unseren Augen die 5 wichtigsten Paradigmen bei der Fehlersiche in technischen Systemen zusammengeschrieben.

1.) Welche Komponenten sind alles beteiligt ?
2.) Kann ich den Fehler reproduzieren, wenn nein , warum ?
3.) Welche Komponenten kann ich systematisch ausschliessen?
4.) Wenn ich nicht zum Ziel komme müssen alle Prämissen geprüft werden.

und in einem Systemn, an dem mehr wie ein Techniker beteilgt ist sollte folgende Frage nicht fehlen:

Wer kann mich unterstützen ?

Einen spannenden Fall, den ich vor kurzem via Twitter gelesen hatte , möchte ich hier weiterreichen.
Es geht um die riesigen Wirtschaftsinteressen, die hinter dem kostenlosen Browserplugin ad-block plus stehen.

http://www.mobilegeeks.de/adblock-plus-undercover-einblicke-in-ein-mafioeses-werbenetzwerk/

[lang_de]
für ein korrektes Agent Forwarding in einer sudoers Umgebung müssen zwei Voraussetzungen
erfüllt sein

1.) In der /etc/sudoers muss
Defaults env_keep = „SSH_AUTH_SOCK“
konfiguriert sein
2.) Aufruf von sudo NICHT mit
„sudo su -“
[/lang_de]
[lang_en]
[/lang_en]for a correct agent forwarding in a sudoers environment you need two prerequesites

1.) In /etc/sudoers you need
Defaults env_keep = „SSH_AUTH_SOCK“

2.) DON’T call sudoers this way
„sudo su -“
[/lang_en]

[lang_en]
Heartbeat Based Clusters are a fine thing but even clusters can crash. In this case you may have to bring up the ressources manually. With

ip -f inet addr add 192.168.1.1/24 brd 192.168.1.255 dev eth1

you can add the VIP manually but you have to clean the ARP Caches manually to have sucess. You clean the ap caches with this command:

arping -c 4 -A -I eth1 192.168.1.1


[/lang_en][lang_de]
Heartbeat basierende Cluster sind eine wunderbare Sache. Doch es mag sein das man im Katastrophenfall die Ressourcen des Clusters manuell zur Verfügung stellen muss.
Mit

ip -f inet addr add 192.168.1.1/24 brd 192.168.1.255 dev eth1

lässt sich die Virtuelle IP manuell an ein Interface binden aber erreichbar ist die IP erst , wenn mit folgendem Befehl die ARP Caches im ganzen Netz upgedated werden.

arping -c 4 -A -I eth1 192.168.1.1

[/lang_de]

[lang_de]
Nach einem etwas längeren Umzug eines rdiff_backup repositories lieferte das Backup folgenden Fehler:

[03/20/13 13:31:44] Exception 'Found too many current_mirror incs!' raised of class
'':
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 304,
in error_check_Main
[03/20/13 13:31:44] try: Main(arglist)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 324,
in Main
[03/20/13 13:31:44] take_action(rps)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 280,
in take_action
[03/20/13 13:31:44] elif action == "backup": Backup(rps[0], rps[1])
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 337,
in Backup
[03/20/13 13:31:44] backup_final_init(rpout)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 501,
in backup_final_init
[03/20/13 13:31:44] checkdest_if_necessary(rpout)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 916,
in checkdest_if_necessary
[03/20/13 13:31:44] need_check = checkdest_need_check(dest_rp)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 907,
in checkdest_need_check
[03/20/13 13:31:44] assert len(curmir_incs) == 2, "Found too many current_mirror incs!"

Was war geschehen ? Durch den langen Kopiervorgang waren mehrere current_mirror Statusdateien mitgesynct worden.
In der obigen Fehlermedlung waren es zwei statt einer.
Wie lösen ?
Einfach in allen rdiff_datenverzeichnissen alle current_mirror* bis auf die neuste löschen und das Backup läuft wieder .
[/lang_de][lang_en]
After a longer migration of rdiff_backup repository (4 Weeks) I got this strange error

[03/20/13 13:31:44] Exception 'Found too many current_mirror incs!' raised of class
'':
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 304,
in error_check_Main
[03/20/13 13:31:44] try: Main(arglist)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 324,
in Main
[03/20/13 13:31:44] take_action(rps)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 280,
in take_action
[03/20/13 13:31:44] elif action == "backup": Backup(rps[0], rps[1])
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 337,
in Backup
[03/20/13 13:31:44] backup_final_init(rpout)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 501,
in backup_final_init
[03/20/13 13:31:44] checkdest_if_necessary(rpout)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 916,
in checkdest_if_necessary
[03/20/13 13:31:44] need_check = checkdest_need_check(dest_rp)
[03/20/13 13:31:44] File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line 907,
in checkdest_need_check
[03/20/13 13:31:44] assert len(curmir_incs) == 2, "Found too many current_mirror incs!"

What happened ? Because of the very long Migration of the repository more than one current_mirror Statusfiles had been synced.
In the errormessage above it had been two files .
how to solve ?
Simply delete in all rdiff_datadirs all current_mirror* files except the newest one and your rdiff_backup is running again
[/lang_en]