Stephans Blog

Building a raspberry pi as a door sensor

build a real rack out of IKEA s Lack tables

ALter post von meiner Homepage

Wichtige Dinge im Vorraus. Um keine Probleme mit libraries zu bekommen und um Platz zu sparen mussten die meisten Programme statisch kompiliert werden. Wo es ging habe ich das Programm gegen die dietlibc, einen hervoragenden libc Ersatz von Felix von Leitner kompiliert.

Der Link

www.fefe.de/dietlibc/

Wir benötigen für unser embedded system

einnen kernel

busybox (multi binary tool)

optional

ssh
bash
netcat
kernel

läuft momentan noch ein Fremdkernel soll aber bald ersetzt werden.

busybox

downloadlink: www.busybox.net/downloads/busybox-1.1.0.tar.gz

tar xzvf busybox-1.1.0.tar.gz
cd busybox-1.1.0/

Die busybox ist ein binary das die meisten Linux/Unix Kommondos emuliert sowie eine ash als shell. Die Konfiguration erfolgt nach einem make menuconfig über eine der Linuxkernelkonfiguration nicht unähnliches Menü.

Wichtig : statisch Kompilieren!!

Im Netzwerkbereich habe ich noch den webserver ausgwählt, dafür aber telnet nicht da ich mir ja noch ein ssh kompileren will.

du -h busybox

1.2M busybox

bash

Die bash ist nur optional da ja mit der busybox eine ash mitgeliefert wird, kann aber aufgrund des grösseren Befehlssatzen und Komforts von Vorteil sein

Ich musste dazu die alte bash herunterladen da sich die neue nicht statisch kompilieren liess

ftp.gnu.org/gnu/bash/bash-2.05.tar.gz

dann

tar xzvf bash-2.05a.tar.gz
cd bash-2.05a/
./configure CC="diet gcc" --enable-static=yes
make
strip bash

wenn wir nun das ergebnis mit einem

/bash-2.05a > du -h bash überprüfen haben wir nun

496K bash eine bash mit 496k

SSH

chrootssh.sourceforge.net/download/openssh-4.2p1-chroot.tar.gz

Es war fast keine Version im Netz zu finden die funktionierte und sich statisch Kompilieren liess ausser der obigen.

tar xzvf openssh-4.2p1-chroot.tar.gz
cd openssh-4.2p1-chroot/
./configure LDFLAGS=-static
make


Bei mir wurden die absoluten Pfade des Kompilierungssystem fest miteingebunden weswegen ich noch als prefix

/opt/bin/

angeben musste(Das ist dann auch der Pfad auf dem thinclient)

netcat

Um das ganze ein bischen aufzubohren wollte ich netcat (mächtiges Netzwerktool) haben,

osdn.dl.sourceforge.net/sourceforge/netcat/netcat-0.7.1.tar.gz

(Server sehr langsam)

Dann das übliche

tar xzvf netcat-0.7.1.tar.gz
cd netcat-0.7.1/
./configure LDFLAGS=-static CC="diet gcc -nostdinc"
make

falls keine dietlibc vorhanden ist dann

./configure LDFLAGS=-static

Zusammenbauen des Systems

Dazu braucht man erstmal ein Grundgerüst für ein Unixsystem. Ich habe meins von hier

ftp://www6.software.ibm.com/software/developer/library/l-lwl1/skeleton.tar.gz

heruntergeladen.

Dieses mit

tar xzvf skeleton.tar.gz

entpacken

Das wichtigste ist die /etc/init.d/rcS, die den ganzen startprozess regelt. Die Kommentare solten alles erklären

#!/bin/bash
# Defaultshell ist die bash
/bin/mount -n -t proc /proc /proc

# standartprompt
echo loading keys
loadkeys /de-latin1.map
# Laden der Keymap
echo syncronyzing time
netdate -v 192.168.1.1
hwclock –systohc
# Wir stellen die Zeit über unseren Zeit
echo remounting root
mount -o remount -o rw /dev/root /
# root wird neu gemountet ( so brauchen wir keine fstab)
echo starting httpd
httpd -h /webroot/
# Der Webserver der busysbox wird mit den entsprechendem webroot gestartet
echo starting ssh
/sbin/sshd
# der sshdämon auch

Die zwei Dateien braucht man auch noch
/etc # cat HOSTNAME
danube.ds9

/etc # cat resolv.conf
nameserver 192.168.1.1
nameserver 194.25.2.129
nameserver 193.101.111.10

[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 ?

[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]