Sonntag, 26. Januar 2014

Shell-Scripte mit vielen Optionen

Link zu diesem Artikel

Komplexe Shell-Scripte, welche ein Unix-Tool mit unzähligen Optionen aufrufen, muss man ab und zu debuggen. Damit dies möglichst einfach funktioniert, habe ich mir angewöhnt, die Optionen so zu notieren, damit ich jede einzelne Option mit einem Tastendruck auskommentieren kann:

...
OPTS=""
OPTS="$OPTS --verbose"
OPTS="$OPTS --archive"
OPTS="$OPTS --no-owner"
OPTS="$OPTS --no-group"
#OPTS="$OPTS --delete" # WILL DESTROY EVERYTHING! DO NOT UNCOMMENT
OPTS="$OPTS --progress"
...
rsync $OPTS "$SOURCE" "$DESTINATION"
...

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Das Mac OS X Home-Verzeichnis mit rsync über SSH auf eine Synology Diskstation sichern

Link zu diesem Artikel

Nachdem ich den schlüsselbasierten Login hingekriegt hatte, stand ich bereits wieder vor dem nächsten Problem: Mein rsync-Script zur Sicherung meines Mac OS X Home-Verzeichnis in einen Unterordner auf meinem Home-Verzeichnis auf dem Synology NAS brach mit folgender Fehlermeldung ab:

...
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
ERROR: module is read only
...

Wieso denn das? Mit dem Synology-Konto meines Raspberry Pi klappt die ganze Chose problemlos!

Mit den Hinweisen unter Rsync over ssh: “ERROR: module is read only” suddenly appeared wurde ich auf den richtigen Pfad gelenkt: Ich musste meinem Benutzer mittels des Synology Web-GUIs Schreibrechte auf den Homes-Ordner geben:

  1. Control Panel
  2. Users
  3. %BENUTZER% auswählen
  4. Edit
  5. Privileges Setup
  6. homes
  7. [x] Read/Write
  8. OK

Seither klappt die rsync-Synchronisierung. Ob ich aber damit eine Sicherheitslücke geöffnet habe?

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Sich schlüsselbasiert per SSH auf einer Synology Diskstation einloggen

Link zu diesem Artikel

Im Grunde ein einfaches Unterfangen, welches im Internet auf unzähligen Seiten dokumentiert ist. Kurzfassung: Auf dem eigenen Arbeitsrechner einen privaten und öffentlichen Schlüssel erstellen, auf der Synology Diskstation den SSH-Zugang aktivieren, eine Login-Shell einrichten und dort dann unter ~/.ssh/authorized_key den öffentlichen Schlüssel ablegen.

Was ich vor einigen Monaten mit meinem Raspberry Pi erfolgreich und innert kurzer Zeit hingebracht habe, wollte mich gestern während eineinhalb Stunden auf Trab halten. Neu wollte ich auch meinen persönlichen Account mit einem schlüsselbasierten SSH-Zugang ausstatten. Doch während der schlüsselbasierte Login mit dem Raspberry Pi-Konto problemlos funktionierte, wollte es mit dem privaten Konto einfach nicht klappen, obwohl die Konfiguration identisch war.

Lösung

Die nach unzähligen Pröbelversuchen eruierte Ursache: Das Home-Directory meines Benutzers war nicht mit den korrekten Berechtigungen versehen:

VAULT> ls -l /volume1/homes/     
...
drwxrwxrwx    6 mario    users         4096 Jan 26 10:42 mario
...

Nachdem ich folgenden Befehl ausgeführt hatte, klappte es plötzlich:

$ chmod 755 /volume1/homes/mario

Hierbei handelt es sich um eine im Grunde gut gemeinte Sicherheitsvorkehrung auf Unix-Systemen. Denn wenn andere Benutzer den Public Key eines anderen Benutzers ersetzen könnten, könnten sie sich anschliessen unter dessen Kontext einloggen.

Siehe auch der Beitrag SSH and home directory permissions auf Stackexchange.

Hintergründe

Ein grosses Problem dieser Synology-Box ist es, dass auf ihr ein abgespecktes Linux läuft, welches einerseits die gängigsten Debug-Optionen nicht zur Verfügung stellt (bspw. ein sauberes Logging der Aktivitäten von sshd), andererseits über eine schier unüberschaubare verschachtelte Konfiguration verfügt.

sshd_config

Insgesamt habe ich auf der Kiste drei sshd_config Konfigurationsdateien gefunden:

  • /etc/ssh/sshd_config
  • /etc.defaults/ssh/sshd_config
  • /usr/syno/etc.defaults/ssh/sshd_config

Welche ist nun die richtige? Und welche bleibt auch bei einem Update oder Neustart mit meinen Konfigurationsanpassungen bestehen? Ich weiss es bis heute nicht.

sshd neu starten

Auch hierfür gibt es mehrere Möglichkeiten. Im Netz habe ich zwei Befehle gefunden:

  • # killall sshd
  • # /usr/syno/etc.defaults/rc.d/S95sshd.sh restart

Wenn ich diese Befehle ausgeführt habe, bin ich natürlich schnurstracks aus der SSH-Session geflogen — logisch. Doch bei der Verwendung von killall hat man sich soeben gerade vollständig vom NAS ausgesperrt.

Glücklicherweise gibt es über das Web-GUI des NAS die Möglichkeit, SSH wieder zu starten:

  1. Control Panel
  2. Terminal
  3. [x] Enable SSH service

Was ich zudem auch realisiert habe: Wenn ich SSH über das GUI neu starte, wird /etc/ssh/sshd_config neu eingelesen. Wenn ich es mit den Kommandozeilenbefehlen neu starte, wird die Konfigurationsdatei irgendwie nicht beachtet …

Verschachtelte Start-Scripts

Wie genau wird nun aber SSH gestartet? Die Synology-Ingenieure haben sich wohl gesagt: „Wieso einfach, wenn es auch kompliziert geht?“ und sich einige verschachtelte Scripts geleistet:

/usr/syno/etc.defaults/rc.d/S95sshd.sh liest einerseits /etc.defaults/rc.subr als auch /usr/syno/etc.defaults/rc.ssh.subr ein. Gestartet wird der SSH-Daemon dann aber, indem das Script /usr/syno/etc.defaults/rc.ssh aufgerufen wird. Dieses Script sourced das bereits erwähnte /usr/syno/etc.defaults/rc.ssh.subr erneut.

Konfigurationsdatei forcieren

Als mir das Debugging zu blöd wurde, habe ich mich entschieden, die Konfigurationsdatei ein für allemal in das eigentliche Startscript /usr/syno/etc.defaults/rc.ssh hartzukodieren:

...
$SSHD -f /etc/ssh/sshd_config
...

Debugging in syslog? Fehlanzeige

Wer denkt, dass einem folgende Zeilen beim Debugging in /etc/ssh/sshd_config weiterhelfen, liegt falsch:

...
SyslogFacility AUTH
LogLevel DEBUG
...

In /var/log/messages, der einzigen von zwei Log-Dateien in diesem Verzeichnis, welche bisher am heutigen Tag aktualisiert wurden, finden sich keine weiterführenden Infos, wieso sich der Benutzer mario nicht Schlüsseln einloggen darf.

Tags: , , , , , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Montag, 13. Januar 2014

Das PHP Error-Log von einem Cyon-Server täglich per E-Mail zusenden

Link zu diesem Artikel

Ein guter Web-Entwickler hält das PHP Error-Log seiner Web-Sites und -Applikationen stets im Auge. Ich persönlich habe mir zum Ziel gesetzt, dass nur ein leeres Log ein gutes Log ist. Dies bedeutet demzufolge, dass man auf Produktivsystemen sauberen Code ausliefert. Und sollten doch einmal Fehlermeldungen, Warnungen und Infos im PHP Error-Log auftauchen, gilt es diese zeitnah zu beheben.

Damit man eine Web-Präsenz, welche auf einem Cyon-Server mit SSH-Zugang läuft, überwachen kann, sind folgende Anpassungen nötig:

php.ini

Bei meinen Hostings befindet sich diese Konfigurationsdatei unter ~/etc/php_settings/default/php.ini. In dieser Datei sollten die folgenden Parameter gesetzt sein:

...
error_log = /home/%CYON-ACCOUNT%/var/log/php.err
...
error_reporting = E_ALL # Allenfalls auch & ~E_DEPRECATED
...

Dabei sollte man sicherstellen, dass das Verzeichnis /home/>benutzernamen>/var/log/ existiert und schreibbar ist.

mail-php-error-log.sh

Nachfolgendes Script sorgt dafür, dass der Inhalt der heutigen php.err per E-Mail an eine frei definierbare E-Mail-Adresse gesendet wird. Nach dem Versand wird die php.err kopiert und das Original danach gelöscht. Dem Dateinamen der Kopie wird dabei der aktuelle Tag des Jahres (1 bis 365) angehängt, womit wir eine Art automatisiertes logrotate durchführen:

#!/bin/sh

LOG="/home/%CYON-ACCOUNT%/var/log/php.err"

if [ ! -f "$LOG" ]
then
        echo "File '$LOG' not found"
        exit 1
fi

LINES=`cat "$LOG" | wc -l`

if [ $LINES -lt 1 ]
then
        exit 0
fi

#echo "Since log file is not empty ($LINES lines) I'm now posting its content to the webmaster"
cat "$LOG" | mail -s "php.err" logger@domain.tld
#echo "Would now be sending mail"

# Secret Sauce
DAYOFYEAR=$(date +%j)
cp "$LOG" "$LOG.$DAYOFYEAR"
rm "$LOG"

exit 0

Dieses Script habe ich in meinem Home-Folder abgelegt und mittels chmod 700 für meinen Benutzer ausführbar gemacht.

crontab

Schlussendlich richtet man sich noch einen Eintrag in crontab ein, damit das Script automatisiert einmal im Tag aufgerufen wird:

$ crontab -e

Der Inhalt dieser Datei lautet:

MAILTO="logger@domain.tld"
...
12 23 * * * /home/%CYON-ACCOUNT%/mail-php-error-log.sh

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 19. Dezember 2013

Hochzeit-Fotos von ichwuensche.ch automatisiert herunterladen

Link zu diesem Artikel

Heuer war es wieder mal soweit — Bekannte, welche im September 2013 geheiratet und an deren Hochzeit Stephanie und ich teilgenommen haben, haben die Fotos über ichwuensche.ch zugänglich gemacht. Da es mir zu blöd war, mich durch die 12 Web-Seiten voller Hochzeitsbilder zu klicken, habe ich mir ein kleines PHP-Script geschrieben, welches mir die URLs der Fotos generiert. Dafür benötige ich die fortlaufende Nummer des ersten sowie letzten Bildes der Serie; das Script generiert anschliessend automatisiert alle URLs.

<?php
    $base = 'http://www.ichwuensche.ch/images/gallery/';
    $start = 1269245;
    $end = 1269774;
    $suffix = '_l.jpg';
    
    $counter = 0;
    for($i = $start; $i <= $end; $i++) {
        $counter++;
        
        // $middle = 4/4/2/9/6/ if JPEG basename is 1269245
        $middle = strrev($i);
        $middle = substr($middle,0,5);
        $middle = implode('/',str_split($middle)) . '/';
        
        $url = $base . $middle. $i . $suffix;
        echo $url . "\n";
    }
    
    echo "\n" . $counter . "\n";
?>

Anschliessend führt man das Script aus, pipet die Ausgabe in eine Textdatei und lässt dann wget seine Arbeit verrichten:

$ php generate-urls.php > urls.txt
$ wget -i urls.txt
--2013-12-19 16:06:37--  http://www.ichwuensche.ch/images/gallery/4/7/7/9/6/1269774_l.jpg
Verbindungsaufbau zu www.ichwuensche.ch (www.ichwuensche.ch)|85.158.232.45|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 150027 (147K) [image/jpeg]
In »»1269774_l.jpg«« speichern.
...

ACHTUNG: Leider haben die Entwickler der Web-Site nicht viel überlegt: Unter den Total 530 Fotos findet sich auch die Hochzeit eines unbekannten Paares aus dem Thurgau, eine Amerika-Reise eines anderen, ebenfalls unbekannten Paares sowie die wohl fast schon obligatorischen Katzenfotos.

Umgekehrt bedeutet dies, dass ein Script-Kiddie in einer Nacht alle Fotos der Web-Site abräumen könnte. Na dann.

Tags: , , , , , ,
Labels: Web

7 Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Schwer zu eruierende LaTeX-Kompilationsfehler debuggen

Link zu diesem Artikel

Kürzlich konnte ich ein Dokument eines aktuellen LaTeX-Projektes nicht mehr kompilieren. pdflatex brach immer mit der folgenden Fehlermeldung ab:

...
! Missing \endcsname inserted.
 
\protect 
l.75 \printbibliography[heading=none]
...

Welcher der über 300 Einträge in der Bibliographie verursachte das Problem? Erst das manuelle Eingrenzen durch radikales Löschen (natürlich mit Sicherheitskopie der .bib-Datei) von Bibliographie-Einträgen brachte schlussendlich den verantwortlichen Eintrag zu Tage: Auf Grund der Overfull \hbox-Meldungen in der Log-Datei wusste ich, zwischen welchen zwei Einträgen das Problem bestand, nicht aber, welcher der circa 30 Einträge effektiv das Problem war. Nach der Löschaktion war der Eintrag isoliert. Meine Analyse ergab, dass ich in JabRef in das Feld Language den Wert Französisch eingetragen hatte, welches beim Abspeichern der Bibliographie zu Franz{\“o}sisch wird. Offenbar mag das Paket biblatex solche Sonderzeichen in diesem Feld gar nicht und bricht stumm ab …

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

MacPorts bricht die Installation von python27 ab

Link zu diesem Artikel

Das Problem stellte sich bei mir bereits auf mehreren Computern. Bei der Analyse der von MacPorts erstellten Log-Datei wird offensichtlich, wo das Problem liegt:

:info:destroot You have not agreed to the Xcode license agreements, please run 'xcodebuild -license' (for user-level acceptance) or 'sudo xcodebuild -license' (for system-wide acceptance) from within a Terminal window to review and agree to the Xcode license agreements.

Wer kürzlich Apple Xcode aktualisiert hat, muss wie von Apple angeraten folgenden Befehl ausführen:

# xcodebuild -license

Danach laufen die MacPorts-Installationen wieder sauber durch.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Google crawlt einmal entdeckte URLs auf immer und ewig

Link zu diesem Artikel

Seit Monaten plagten mich die Log-Dateien eines von mir betreuten Web-Projektes: Bestimmte URLs wurden von Googlebot periodisch wiederkehrend aufgerufen, obwohl die Informationen dieser Web-Seiten vor langer Zeit deaktiviert worden waren (kurz: Die Objekte wie Personen und Referate waren nicht mehr in der Datenbank vorhanden und generierten beim Aufruf eine PHP-Exception, welche zwar abgefangen wurde, aber meine Log-Dateien vollmüllte) und das Script seit einigen Wochen einen HTTP 404-Fehler zurückgab.

Wie zum Teufel kam der Googlebot immer wieder auf diese verflixten URLs zurück?

Ich hatte eine verdächtige Subdomain des Projektes im Visier, welche eine archivierte Version der Web-Site bereitstellte. Deshalb passte ich die URLs auf dieser Web-Seite dort an und fügte ihnen eine GET-Variable hinzu, welche unmissverständlich aufzeigen sollte, ob der Googlebot die URLs von dieser Web-Site bezog. Leider stellte sich heraus, dass die Ursache des Übels nicht von dieser Web-Site herrührte.

Daraufhin wählte ich URLs aus, welche eine ganz bestimmte, möglichst einmalige Zeichenkette enthielten und gab diese in der Google-Suche ein. Tatsächlich lieferte Google die Seite der Web-Site als Resultat aus — obwohl die Seite seit Wochen HTTP 404 retournierte. Ein Blick auf den Zeitpunkt des Caches bestätigte, dass Google eine mehrere Wochen alte Version aufbewahrte, welche kurz vor dem Einbau der 404-Routine gecrawlt wurde.

Nun gut, sagte ich mir: Irgendwann einmal muss ja der Googlebot akzeptieren, dass eine URL permanent einen 404er zurückliefert und diese URL dann nicht mehr regelmässig anpingen. Falsch gedacht:

Once Googlebot finds and crawls a URL, they will periodically come back and crawl it again forever. Even after you remove the page and have been returning 404 status for years, Googlebot will still crawl the URL from time to time.

Quelle: Google Crawls my disabled products on my Magento website [closed]

So ist das. Gibt es also wirklich nichts, was ein besorgter Webmaster tun kann? Doch, durchaus:

I followed up on the 404 vs 410 thing with the team here. As mentioned by some others here & elsewhere, we have generally been treating them the same in the past.

However, after looking at how webmasters use them in practice we are now treating the 410 HTTP result code as a bit „more permanent“ than a 404. So if you’re absolutely sure that a page no longer exists and will never exist again, using a 410 would likely be a good thing. I don’t think it’s worth rewriting a server to change from 404 to 410, but if you’re looking at that part of your code anyway, you might as well choose the „permanent“ result code if you can be absolutely sure that the URL will not be used again. If you can’t be sure of that (for whatever reason), then I would recommend sticking to the 404 HTTP result code.

In the worst case, the 410 will be treated the same as a 404; in the best case it’ll be a bit quicker & stickier :-).

Quelle: Does it make sense to return a 410 instead of 404 when some page has been permanently removed?, Via: Does it make sense to return a 410 instead of 404 when some page has been permanently removed?

Ich passte also meinen try-catch-Block im Script an, welcher neu heisst:

...
header("HTTP/1.0 410 Gone");
...

Tags: , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Mit cURL unter Windows das Verhalten eines Tomcat-Servers debuggen

Link zu diesem Artikel

Obwohl ich primär als IT-Auditor unterwegs bin, haben wir uns vor einigen Tagen mit einer Tomcat-basierenden Audit-Applikation herumgeschlagen. Kurz ging es darum, die Kommunikation im Intranet zwingend mit HTTPS zu verschlüsseln. Da der Server mit verschiedenen Domainnamen (teilweise nicht FQDNs) angesprochen werden kann, mussten wir Tomcat zuerst einmal so konfigurieren, dass er alle HTTP-Anfragen auf eine bestimmte Domain umleitete, falls die Anfrage nicht bereits an den korrekten Host gerichtet war (wir haben uns den UrlRewriteFilter) zu Nutze gemacht — und trauerte dabei leise dem (noch) eleganteren mod_rewrite in .htaccess Dateien unter Apache nach …

Item. Da unsere Web-Browser nicht wirklich hilfreich waren, um die Redirects zu analysieren und auch noch ein Enterprise Proxy-Server dazwischenstand, behalf ich mich mit der Win32-Version von cURL, curl.exe mit den Optionen --verbose, um den gesamten Ablauf der Verbindungsaufnahme auf der Kommandozeile auszugeben, sowie mit --noproxy *, um sicherzugehen, dass wir direkt mit dem Server sprachen und den Enterprise Proxy so umgingen. Das Resultat sah folgendermassen aus:

C:\Temp\cURL\> curl.exe --verbose --noproxy * http://software.domain.tld:8080/r2d2/asdf
* Adding handle: conn: 0x1c3def0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1c3def0) send_pipe: 1, recv_pipe: 0
* About to connect() to software.domain.tld port 8080 (#0)
* Trying 10.0.0.111...
* Connected to software.domain.tld (10.0.0.111) port 8080 (#0)
> GET /r2d2/asdf HTTP/1.1
> User-Agent: curl/7.32.0
> Host: software.domain.tld:8080
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Location: https://protected.domain.tld:8443/r2d2/asdf
< Content-Length: 0
< Date: Wed, 11 Dec 2013 10:35:41 GMT
<
* Connection #0 to host software.domain.tld left intact

Alles Bestens: Anfragen auf http://software.domain.tld:8080/r2d2/asdf werden auf https://protected.domain.tld:8443/r2d2/asdf umgeleitet. Und das Auditorenherz schlägt höher.

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Den Netatmo PHP API-Client mit weniger strikten SSL-Anforderungen patchen

Link zu diesem Artikel

Vor einigen Tagen hörte mein Raspberry Pi-Dashboard auf, die Werte meiner Netatmo NWS01 Wetterstation für Apple iPhone und Android anzuzeigen.

Auf meinem lokalen Mac funktionierte das Dashboard hingegen problemlos; d.h. ich konnte mittels dem Netatmo PHP API-Client die JSON-Datei mit den aktuellen Messwerten wie Temperatur, Luftdruck und -feuchtigkeit abrufen.

Die genaue Ursache hinter dem Problem kenne ich bis heute nicht, doch ich vermute mit dem jetzigen Wissensstand, dass die Cyon-Ingenieure an der Konfiguration ihrer Server herumgewerkelt haben und dabei unter anderem das Root-Zertifikat entfernt haben, welches der Netatmo API-Client zur HTTPS-verschlüsselten Kommunikation mit den Netatmo-Servern verwendet.

Nachdem ich nämlich die Exception mittels vardump() genauer betrachtete, welche NACurlErrorType zurücklieferte, war der Fall schnell sonnenklar:

...
[message:protected] => SSL peer certificate or SSH remote key was not OK
...

Nun … gut! Was macht man da? Ich habe die Datei NAApiClient.php gepatcht, indem ich cURL mit der auf false gesetzten Option CURLOPT_SSL_VERIFYHOST sage, unverifizierte SSL-Zertifikate kommentarlos zu akzeptieren:

...
        else 
        {
            $opts[CURLOPT_HTTPHEADER] = array('Expect:');
        }
        
        $opts[CURLOPT_SSL_VERIFYHOST] = false;
        
        curl_setopt_array($ch, $opts);
...

Bei einer API wie Netatmo ist diese manuell herbeigeführte Schwachstelle zu verantworten. Ginge es um Mailverkehr oder Online-Banking, würde ich eine solche Option definitiv nicht aktivieren.

Tags: , , , , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »