Archiv ‘Linux’

Sonntag, 25. Mai 2014

curlftpfs unter Mac OS X

Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die “Erleuchtung”!)

Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der “Karren” etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:

MacPorts

curlftpfs installiert man sich folgendermassen:

# port install curlftpfs

Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.

Geduldiges mounten

In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:

...
MAXIMUMITERATIONS=5000
...
TIME=$(date +%H:%M:%S)
echo -n "Checking whether mountpoint is populated ($TIME): "

COUNTER=0
while [ ! -d "$SOURCE" ]
do
	let COUNTER=COUNTER+1
	echo -n "."
	
	if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ]
	then
		echo "Mountpoint still not available after $COUNTER iterations. Aborting."
		exit 1
	fi
done
...

In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.

Zugriff verweigert

Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?

Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):

$ curlftpfs -o defer_permissions ...

Zeichensalat

In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:

$ curlftpfs -o modules=iconv,from_code=latin1

Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71

Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.

Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:

$ iconv -l

In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).

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

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 10. April 2014

imapfilter funktioniert nach dem Heartbleed-Disaster nicht mehr automatisch

Da offenbar auch der Hoster meines Vertrauens vom Heartbleed-Disaster betroffen war und vorbildlicherweise schnurstracks seine SSL-Zertifikate ausgetauscht hat, kam es zu Problemen mit meiner imapfilter-Installation, welche ich hier in anderen Blog-Artikeln bereits beschrieben habe.

Obwohl das Shell-Script auf meinem Linux-Server zu Hause alle fünf Minuten aufgerufen wird, wurden meine Mails in verschiedenen Mail-Accounts seit Mittwoch 15:15 Uhr nicht mehr gemäss den imapfilter-Regeln verschoben.

Heute Mittag erst wurde ich stutzig, wieso sich soviel Müll in meinen INBOXes stapelte und ging der Sache auf den Grund. Dank meinen Log-Daten fand ich die Ursache dann sofort heraus:

imapfilter: certificate mismatch in non-interactive mode

Um dieses Problem zu beheben, musste ich mich per SSH auf meinen Linux-Server einloggen, in denjenigen User wechseln, unter welchem der imapfilter-Cron Job ausgeführt wird, und danach erst einmal die Datei mit den abgelegten Zertifikaten löschen:

$ rm ~/.imapfilter/certificates

Anschliessend musste ich imapfilter einmalig von Hand von der Kommandozeile ausführen (wer mit imapfilter auf verschiedenen Mail-Servern filtert, muss das Prozedere für jeden Server einzeln durchführen, damit die Zertifikatsdatei wieder mit allen aktuellen Zertifikaten gefüllt wird):

$ imapfilter -c /dir/to/recipes/mail-at-domain-tld
Server key fingerprint: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
    (R)eject, accept (t)emporarily or accept (p)ermanently? p

Voilà! Seither klappt das Filtering meiner IMAP-Konten wieder reibungslos.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

rsync braucht unter Mac OS X ewig für “building file list…”

rsync ist das Tool meiner Wahl, um meine Backups auf mein Synology NAS im LAN sowie per WAN auf einen Linux-Server im Elternhaus zu spiegeln. Doch aufgepasst: Wer sich seit jeher daran stört, dass die Backup-Scripts bei hunderttausenden Dateien eine Ewigkeit bei “building file list…” stehen bleiben, sei folgender Rat gegeben:

Man sollte unbedingt eine aktuelle Version von rsync – mindestens aber Version 3 – verwenden. Bis und mit Mac OS X 10.8 liefert Apple Version 2.6 mit, welche in dieser Hinsicht noch nicht optimiert wurde: Version 2 liest zuerst alle Dateien des Quellverzeichnis ein, während Version 3 nach den ersten 1000 Dateien (oder so) mit dem Backup beginnt und die verbleibenden Dateien anschliessend päckchenweise (nach Bedarf, basierend auf der Backup-Geschwindigkeit), einliest. Diese Massnahme verringert nebenbei auch gerade den RAM-Bedarf des Tools.

Version 3 ist auf meinem System über MacPorts installiert:

# port install rsync

Damit man auch wirklich sicher ist, dass in den eigenen Backup-Scripts Version 3 und nicht Version 2 verwendet wird, sollte man den rsync-Pfad in Scripts hardkodieren:

#RSYNC=$(which rsync)
RSYNC="/opt/local/bin/rsync/"

Um während der Ausführung eines Scripts zu prüfen, ob Version 3 des Tools verwendet wird, empfiehlt es sich, rsync das Argument --info=progress2 mitzugeben. In diesem Fall wird jede Datei, die kopiert wird, auf einer neuen Zeile ausgegeben. Neben dessen Grösse, dem Netzwerk-Durchsatz und der Transfergeschwindigkeit auf das Zielmedium steht ganz am Ende der Zeile einerseits xfr für die fortlaufende Nummer aller übertragender Dateien und Ordner sowie to-chk, die Zahl der bereits überprüften Dateien vom (provisorischen) Total aller Dateien. to-chk wird sich während der Laufzeit des Scripts sequentiell erhöhen.

$ rsync -av --info=progress2 . /mnt/backup/2014-03-06/
... 1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

SSH zwingen, sich ausschliesslich mit einem spezifischen Private Key anzumelden

Wer bereits einmal SSH-Verbindungsaufnahmen debuggen musste und dazu den Kommandozeilenparameter -v, -vv oder -vvv verwendet hat, weiss, das der SSH-Agent standardmässig all im .ssh-Ordner vorhandenen private Keys durchprobiert, bis einer passt (oder eben nicht).

Ob dies eine Sicherheitslücke darstellt weiss ich nicht, aber ich finde es ineffizient. Diese Unschönheit lässt sich mit zwei zusätzlichen Parametern IdentityFile sowie IdentitiesOnly in den Host-Definitionen in .ssh/config beheben:

Host shortcut
	Hostname domain.tld
	IdentityFile /Users/mario/.ssh/id_rsa_special
	IdentitiesOnly

Quelle: GitHub / SSH with multiple identities; the slightly-more-definitive guide

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

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 5. März 2014

UUID einer Festplatte unter Linux auslesen

Es empfiehlt sich heutzutage, in /etc/fstab die Festplatten basierend auf ihrer UUID am richtigen Mount-Point einzuhängen. Die UUID einer bestimmten Platte findet man auf folgenden zwei Wegen heraus:

$ ls -l /dev/disk/by-uuid

Oder wenn die Device-Bezeichnung der Festplatte bekannt/klar ist:

$ blkid /dev/sda

Quelle: Short Tip: Get UUID of Hard Disks [Update]

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 5. März 2014

Alle Spuren von GPT-Partitionen von einer portablen Festplatte entfernen

Ich habe eine kürzlich erworbene Festplatte mit dem Disk Utility von Mac OS X komplett neu formatiert und partitioniert. Als ich die Festplatte kürzlich unter Linux neu partitionieren wollte, realisierte ich, dass die Festplatte mit den neuen GPT-Partitionen eingerichtet war (im Gegensatz zu den aus der DOS-Zeit stammenden MBR-Partitionen).

Wie entfernt man jegliche Überreste von GTP-Partitionierungsschemen von der Festplatte? Ganz einfach: Man installiere sich das Debian-Paket gdisk und führe dann folgendes aus:

# apt-get install gdisk
# gdisk /dev/sde
GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 1

Command (? for help): x

Expert command (? for help): z
About to wipe out GPT on /dev/sde. Proceed? (Y/N): y
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): n
MBR is unchanged. You may need to delete an EFI GPT (0xEE) partition
with fdisk or another tool.

Quelle: Wiping Out Old GPT Data

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Shell-Script-Befehl auf STDOUT ausgeben und danach ausführen

Viele meiner Scripts sind mit hoher Verbosität programmiert, damit ich während der Entwicklung weiss, wo allfällig die Ausführung abbricht. Hierzu gehört auch, dass ich komplexe Befehle vor der Ausführung ausgebe. Damit kann ich den Befehl kopieren und beim Debugging manuell auf der Kommandozeile ausführen, um vielleicht weitere Hinweise auf das Problem zu erhalten.

Doch wie macht man das, wenn man bspw. bei rsync Pfadangaben mit Leerschlägen drin hat, die vom Tool dann auch effektiv erkannt und verarbeitet werden sollen? Hier die Lösung:

...
$SOURCE="/Users/mario/Pictures/iPhoto Library/"
$DEST="/Volume/Sicherungs Ordner mit vielen Leerzeichen/"
...
COMMAND="rsync $OPTS \"$SOURCE\" \"$DEST\""
...
echo "Executing '$COMMAND' ..."
...
eval $COMMAND
...

Die ganze Chose steht und fällt mit eval. Wird nur $COMMAND ausgeführt, stolpert rsync über die ordentlich mit Anführungszeichen versehenen Pfade mit Leerzeichen.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Shell-Scripte mit vielen Optionen

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

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

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

Keine Kommentare | neuen Kommentar verfassen