Stephans Blog

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 ?

Dies ist ein Beispiel für eine .htaccess ,die ein Passwort verlangt, ausser man kommt von bestimmten IPs.

Order deny,allow
Deny from all
AuthName "htaccess password prompt"
AuthUserFile /var/www/.htpasswd
AuthType Basic
Require valid-user
Allow from 217.10.14.27
Allow from 127.0.0.1
Satisfy Any


This is an example for an .htaccess ,which request a Password besides the request is comming from IP 127.0.0.1 or 217.10.14.27

Order deny,allow
Deny from all
AuthName "htaccess password prompt"
AuthUserFile /var/www/.htpasswd
AuthType Basic
Require valid-user
Allow from 217.10.14.27
Allow from 127.0.0.1
Satisfy Any

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]

Nachdem S21 immer teurer und unpopulärer wird habe ich in einer Fernsehsendung des SWR [1] über eine super Alternative gehört: SO21

Was ist SO21?
Es wird ein zusätzlicher neuer Ostbahnhof in Untertürkheim gebaut.
Fernzüg nach Stuttgart enden weiterhin im HBF, Fernzüge nach Ulm fahren über die Güterumgehung direkt in den Ostbahnhof. Von dort wird die Strecke durch einen Tunnel nach Wendlingen geführt. Kosten ca. 25 % , keine Behinderung durch Jahrelange Baustellen und am Ende hat Stuttgart 2 Fernbahnhöfe.

[1]
http://www.ardmediathek.de/swr-fernsehen/eisenbahn-romantik/stuttgart-nach-21-alternativen-zu-dem-mammutprojekt?documentId=13503762

Nehmen wir an das unsere Zivilisation unter geht.
Nehmen wir weiterhin an , das in 1000 Jahren eine hoffentlich fortschritlichere Zivilisation Ausgrabungen bei den Neogermanen macht.
Was würde diese Zivilisation über das Ende der Welt denken wenn sie einen Adventskalender findet ??

[Lang_de]
So, nun ist endlich so weit und die Suche dieses Blogs wird durch meinen Apache Solr Suchsserver betrieben
[/lang_de]
[lang_en]
After a long time I finished Integrating my blog into an Apache Solr Search Server
[/lang_en]

[lang_de]
Wie man ein Zertifkat einer CA in einen tomcat integriert, da gibt es im Internet verschiedene Varianten, die sich zum Teil sogar wiedersprechen. Daher möchte ich meinen Weg vorstellen in der Hoffnung jemandem zu helfen der vor den gleichen Situation steht

Wir generieren den key
keytool -genkey -v -alias tomcat -keyalg RSA -keysize 2048
Als nächstes generieren wir den csr, mit dem wir bei der Zertifizierungsstelle das Zertifikat beantragen.

keytool -certreq -keyalg RSA -alias tomcat -file tickets.lightwerk.com.csr -keystore .keystore

Wenn das Zertifikat fertig ist müssen nun drei Zertifikate in den Keystore des Tomcat importiert werden.
Dies sind ein Root- , ein Zwischen-, und das neune Server Zertifikat.

keytool -import -trustcacerts -alias root -file thawte_Server_CA.pem
keytool -import -trustcacerts -alias digicert -file SSL123_SecondaryCA.pem
keytool -import -trustcacerts -alias tomcat -file my.domain.com.crt

und danach der Tomcat Neugestartet
[/lang_de]
[lang_en]
Howto integrate a certifcate of a certificate authority in into a tomcat , there are many howtos at the Internet , sometimes even conflicting. I want to show you my way.

we generate the key
keytool -genkey -v -alias tomcat -keyalg RSA -keysize 2048
Next we generate the csr, to get the certifikate from the certificate authority.

keytool -certreq -keyalg RSA -alias tomcat -file tickets.lightwerk.com.csr -keystore .keystore

When we get the certifikate from the CA , we had to import three certifikates into the keystore of the Tomcat Server.
These are a root- , an intermediate- , and the new server certifikate.

keytool -import -trustcacerts -alias root -file thawte_Server_CA.pem
keytool -import -trustcacerts -alias digicert -file SSL123_SecondaryCA.pem
keytool -import -trustcacerts -alias tomcat -file my.domain.com.crt

restart the tomcat

[/lang_en]