Archiv des Autors: hermann

die täglichen Gefahren eines Systemadministrators

In jedem Beruf gibt es gewissen Gefahrenquellen, dem Maurer kann ein Stein auf den Kopf fallen, der Postbote wird vom Hund gebissen und der Seemann geht über die Reeling. Auch beim Beruf des Systemadministrators gibt es Gefahrenquellen, die hier natürlich total übertrieben und ein wenig ausgedacht dargestellt werden.

– als erstes wäre die Strangulation im Patchschrank (Netzwerkschrank)
– Schnittverletzungen durch billige und schlecht verarbeitete Computergehäuse
– Getränkepackungen ( inkl. Restinhalt) die seit Wochen neben oder auf dem Rechner stehen und so aufgebläht sind, das sie bei der nächsten Berührung platzen könnten
– blaue Flecke durch Tritte die man evtl bekommt. wenn man unterm Tisch einen Rechner anschließt und dabei übersehen wird

Für letzteres gibt es jetzt einen kleinen Aufsteller

admin-work

admin-work1

[IIS] Request format is unrecognized for URL unexpectedly ending in ‚/jsdebug‘.

Beim installieren einer Anwendung auf einem Windows 2008 R2 Server die den IIS voraussetzt, verlief die Installation ohne Probleme. Grundvoraussetzung der Anwendung war die vorherige Installation vom .NET Framework 4.0 .
Nach der Installation war die Anwendung per URL Aufruf erreichbar, jedoch fehlten unter einigen Menüpunkten Inhalte.

In der Ereignissanzeige von Windows stand folgendes:

Exception type: InvalidOperationException
Exception message: Request format is unrecognized for URL unexpectedly ending in '/jsdebug'.
at System.Web.Services.Protocols.WebServiceHandlerFactory.CoreGetHandler(Type type, HttpContext context, HttpRequest request, HttpResponse response)
at System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler(HttpContext context, String verb, String url, String filePath)
at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Thread Information

Stack trace: at System.Web.Services.Protocols.WebServiceHandlerFactory.CoreGetHandler(Type type, HttpContext context, HttpRequest request, HttpResponse response)
at System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler(HttpContext context, String verb, String url, String filePath)
at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Lösung

ASP net muss noch im IIS registriert werden, dafür muss
folgendes auf der Kommandozeile ausgeführt werden:
c:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis.exe -i

Als Ausgabe erhält man folgendes:
Start installing ASP.NET (4.0.30319).
......
Finished installing ASP.NET (4.0.30319).

Im Anschluss konnte die Anwendung ohne Probleme genutzt werden und die Fehlermeldung stand ebenfalls nicht mehr in der Ereignissanzeige.

Weitere Informationen gut es hier:
http://msdn.microsoft.com/de-de/library/k6h9cz8h(v=vs.80).aspx

[Raspberry Pi] erster Schritt zur Hausautomation

Genial was alles mit dem Raspberry Pi möglich ist. Ursprünglich wollte ich mit dem FHEM Steckdosen aus der FS20 Reihe schalten, es geht jedoch auch einfacher bzw günstiger.

Hierfür kauft man sich einen kleinen 433 MHz Sender, der kann hier bestellt werden.

Um den Sender mit dem Raspberry Pi zu verbinden, habe ich Kabel aus einem altem PC Gehäuse genommen. Die Stecker die normalerweise z.B. den Resetschalter mit dem Mainboard verbinden, passen ebenfalls auf die Pins des Raspberry Pi. Ansonsten kann auch ein Floppykabel verwendet werden und als letzte Möglichkeit könnte man die Kabel direkt anlöten.

Die Anschlüsse des Senders sind ANT, VCC, DATA, GND. Als Antenne habe ich ein Kabel von 17 cm länge verwendet. An die anderen Anschlüsse habe ich die zuvor erwähnten Kabel aus dem PC Gehäuse gelötet.

Der Sender wird mit folgenden Pins verbunden:
ANT 17cm langes Kabel (grün)
VCC => Pin 2 5 V (rot)
DATA => Pin 11 GPIO 17 (weiß)
GND => Pin 6 GND (schwarz)

433 MHz Sender

433 MHz Sender


Eine Übersicht der Ports gibt es hier:http://wiki.laub-home.de/wiki/Raspberry_Pi_Sensoren_auslesen

Bevor alles weitere per git heruntergeladen und kompiliert werden kann, müssen ein Programme nachinstalliert werden.
apt-get update
apt-get install git gcc python-dev python-setuptools

Unter Raspbmc musste ich zusätzlich noch make installieren.

Dann müssen folgende Kommandos unter dem Benutzer root ausgeführt werden:

cd /usr/local/src
apt-get install git-core
git clone git://git.drogon.net/wiringPi
cd wiringPi
./build

git clone https://github.com/WiringPi/WiringPi-Python.git
cd WiringPi-Python
git submodule update --init
python setup.py install

Beim clone unter raspbmc von https://github.com habe ich folgende Fehlermeldung erhalten:

Cloning into 'WiringPi-Python'...
error: Problem with the SSL CA cert (path? access rights?) while accessing https://github.com/WiringPi/WiringPi-Python.git/info/refs
fatal: HTTP request failed

Das Problem konnte ich mit Hilfe von git config --global http.sslVerify false lösen.

Damit der pi Benutzer auf die GPIO17 zugreifen darf, müssen noch Rechte in der /etc/rc.local angepasst werden. Vor der Zeile exit 0 habe ich sudo -u pi /usr/local/bin/gpio export 17 out hinzugefügt und den Raspberry Pi neugestartet.

Als nächstes habe ich den Code für elro_wiringpi.py hier kopiert und in einer Datei gespeichert. Seinen Hauscode gibt man in der Zeile 96 an.

Dann ein chmod 755 elro_wiringpi.py und mit elro_wiringpi.py nummer ein/aus können die Funksteckdosen geschaltet werden.
Nummer = A=1 B=2 C=4 D=8 E=16
ein = 1
aus = 0

Ausprobiert habe ich es bislang mit den Funksteckdosen von Elro und Brennenstuhl.

Als ich das Script das erste Mal ausführen wollten, brach das Script mit einem Fehler ab.
./elro_writing.py 1 0
File "./elro_writing.py", line 36
import time
^
IndentationError: unexpected indent

Das Problem war, das beim kopieren des Codes in eine mit vi geöffnete Datei sich Leerzeichen und Tabs eingeschlichen hatten. Python ist an dieser Stelle sehr empfindlich.

Ich hatte das ganze ursprünglich unter Raspbmc ausprobiert. Als ich mit dem „rumspielen“ fertig war startete das xbmc nicht mehr, ob es einen Zusammenhang gibt kann ich nicht sagen. Jetzt habe mir jetzt eine zweite SD Karte zugelegt und auf dieser wheezy installiert und darüber schalte ich nun die Funksteckdosen. Als nächstes werde ich das ganze unter FHEM einbinden.

[cronjobs] werden mit falscher Zeichenkodierung ausgeführt

Angenommen ein Server hat die Zeichenkodierung de_DE.UTF-8, ein auszuführendes Shellscript muss jedoch mit der Zeichenkodierung de_DE.ISO-8859-1 laufen.

Die Lösung ist sehr einfach. In dem auszuführenden Script muss folgende Zeile am Anfang stehen:

export LANG=de_DE.ISO-8859-1

Cronjobs
Wenn ein oder mehrere Shellscripte als cronjob gestartet werden, kann die Zeichenkodierung auch in der /etc/environment hinterlegt werden. Damit entfällt die Angabe der Zeichenkodierung in dem Shellscript.

Den eigenen Webauftritt sichern

Es soll den ein oder anderen geben, der seine Daten zwischendurch auf externe Medien wie Festplatte oder DVD sichert. Hierfür gibt es unzählige kostenpflichtige oder auch kostenlose Tools, manchmal reicht auch ein kleines Script um eine Sicherung seiner Daten anzulegen. Nur wie oft wird die eigene Internetseite gesichert? Natürlich kann man sich auf die backups seines Hostingproviders verlassen, nur kommt man da notfalls schnell ran und vor allem auch kostenlos? Für wordpress, contao etc gibt es Plugins die den Auftritt sichern, ich habe mir jedoch ein eigenes kleines Script geschrieben.

Die folgenden Variablen müssen hierfür befüllt werden:

# ftp Zugangsdaten
USERNAME=<username> //willi
PASSWORD=<passwort> //sogeheim
SERVER=<server> //www.meineseite.de
# aufruf der per htaccess php Datei
USER=<user>  // lieschen
PASSWORD2=<passwort> // auchgeheim
URL=<url zum Aufruf ohne dump.php Angabe> // www.meineseite.de/geheim
DATEIPFAD=<Pfad zur dump.php per ftp> // geheim

Hier werden die lokalen Backups abgelegt.

TARGET=/backup/${SERVER}/${DATE}

Als erstes wird der unter TARGET angegebene Ordner erstellt, im Anschluss werden alle Dateien per FTP heruntergeladen. Um Platz zu sparen werden die heruntergeladenen Dateien gepackt.
Damit ein mysqldump erstellt werden kann, muss die Datei dump.php auf der Internetseite hinterlegt werden. (Die dump.php muss per htaccess geschützt werden.) In dem Script wird die Datei über lynx aufgerufen, nach dem Aufruf wird der sqldump per ncftpget heruntergeladen. Der Abruf per ncftpget ist so gesetzt, das der sqldump nach erfolgreichem download gelöscht wird.

In der dump.php sind die Zugangsdaten für die Mysql Datenbank hinterlegt. Wenn mehrere Datenbanken unter dem Webhostingpaket verwendet werden, kann der php Code zum erstellen des Dumps auch öfters angegeben werden.

Download:Script