Posts Tagged ‘Mac OS X’

Donnerstag, 6. März 2014

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

Link zu diesem Artikel

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

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

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

Sonntag, 17. November 2013

Finder-Eigenschaften von Dateien auf der Kommandozeile auslesen

Link zu diesem Artikel

Mit nachfolgendem bash-Script durchsuche ich einen Ordner mit über 700 Photos und gebe all diejenigen JPG-Dateien aus, welche im Finder die Farbe „Rot“ zugewiesen haben:

#!/bin/sh

MDLS=`which mdls`
ATTRIBUTE="kMDItemFSFinderFlags" # Color
VALUE=12 # Red

for FILE in *.JPG
do
	RETVAL=$($MDLS -name "$ATTRIBUTE" "$FILE" | cut -d "=" -f 2)
	
	if [ $RETVAL -eq $VALUE ]
	then
		echo $FILE
	fi
done

exit 0

Alle zutreffenden Dateien kopiere ich mit folgendem Script in den Unterordner Highlighted (das obige Script habe ich unter filter-highlighted.sh abgelegt):

#!/bin/sh

FILES=`./filter-highlighted.sh`

for FILE in $FILES
do
	cp "$FILE" "Highlighted/"
done

exit 0

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Remove Apple-specific files

Link zu diesem Artikel

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

.DS_Store contains information on how to display folders; e.g. list view. Such files are of no use for Linux- and Windows-users. The following command finds all .DS_Store-files in the current directory and every subdirectory and deletes it immediately. I put it in a cron-job, which is performed every five minutes.

find . -type f -name .DS_Store -exec rm -f '{}' ';'

The next thing is about these fucking Resource Forks. If I could, I would travel back through time and eliminate the person who created it. Anyway, they’re among us now, and we can’t get rid of’em. Well, at least they serve no needs on a Linux-server, so it’s (usually) safe to delete them. As example, if you drag photos from iPhoto to a Samba-Share, not only the JPGs are stored, but also ._-files with thumbnails in it. Well then, good bye little bastards:

find . -type f -name ._* -exec rm -f '{}' ';'

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

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 8. Oktober 2013

Unter Linux eine aktive screen-Session übernehmen

Link zu diesem Artikel

Ab und zu kommt es vor, dass sich mein alter Mac mini in den Ruhemodus versetzt, während ich noch per SSH mit einer screen-Session verbunden bin. Mit folgendem Befehl kann ich die Session nach einem neuen Login mit SSH übernehmen:

$ screen -d -r

-d bedeutet „detach“, -r bedeutet „resume“.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 25. September 2013

Das Mac OS X Terminal mit dem aktuellen Finder-Pfad öffnen

Link zu diesem Artikel

Wer sich fliessend zwischen den zwei Welten — dem OS X GUI und dem Unix-Terminal — bewegt, wird die Minimalapplikation Go2Shell äusserst nützlich finden. Nachdem man sie als Button in die Finder Button-Leiste gezogen hat, kann man auf Knopfdruck das Mac OS X Terminal (Unix-Shell) öffnen und findet sich im selben Ordner wieder, welchen man gerade im Finder sieht.

Die umgekehrte Variante sei hier selbstverständlich auch noch am Rande erwähnt:

$ open .

öffnet ein Finder-Fenster mit dem Verzeichnis, in welchem sich der Shell-Benutzer gerade befindet.

Tags: , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. Juni 2013

RAM-Speicherauslastung unter Mac OS X über SNMP auslesen

Link zu diesem Artikel

Ich habe heute Sonntag ein wenig Zeit in dieses Projekt investiert und stelle die Scripts, Konfigurationsanpassungen und Installationsanleitung über GitHub zur Verfügung:

macosx-memory-snmp

Tags: , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. Juni 2013

SNMP unter Mac OS X 10.8 Mountain Lion aktivieren

Link zu diesem Artikel

Mac OS X 10.8 (Mountain Lion) bringt Out-of-the-box alles mit, um einen SNMP-Server bereitzustellen. In Verbindung mit cacti zeichne ich so in Echtzeit Systeminformationen meines Mac minis, MacBook Airs und Stephanies Mac mini auf.

Wer Rechner ausschliesslich in seinem heimischen LAN betreibt, kann nachfolgende Minimal-Konfiguration einrichten, damit cacti auf einem Drittserver per SNMP v1 und ohne Passwort darauf zurückgreifen kann:

/etc/snmp/snmpd.conf (Desktop-Rechner)

sysContact  Vorname Nachname 
sysLocation Strasse Strassennummer, PLZ Ort

rocommunity public

includeAllDisks 10%
load    30 10 5

Auf einem portablen Gerät würde ich SNMP abriegeln und den Zugriff nur mittels Benutzernamen und Passwort zugänglich machen. Verwendet man obige Lösung, kann im Flughafen-WiFi oder im Uni-WiFi jedes Script-Kiddie mit nmap-Portscans auf den SNMP-Server aufmerksam werden und mehr oder weniger sensitive Informationen abrufen.

Hierzu eignet sich folgende Konfiguration:

/etc/snmp/snmpd.conf (portabler Rechner)

createUser <username>     MD5 "<password>" DES "<secret>"
authuser   read -s usm  <username> priv  .1

sysContact  Vorname Nachname 
sysLocation Strasse Strassennummer, PLZ Ort

includeAllDisks 10%
load    30 10 5

Sowohl password als auch secret können frei gewählt werden (alphanumerische Zeichenfolge).

Quelle: Setup SNMP V3 USM with encryption.

Daemon (neu) starten

Nach der Konfigurationsanpassung heisst es, den SNMP-Server (neu) zu starten. Dies habe ich mit folgendem Script automatisiert:

#!/bin/sh

echo "Stopping SNMP daemon ..."
sudo launchctl unload /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist

echo "Starting SNMP daemon ..."
sudo launchctl load -w /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist

exit 0

Daemon bei jedem Neustart von Mac OS X laden

Hierzu habe ich die von Apple mitgelieferte plist-Datei /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist angepasst:

	<key>Disabled</key>
	<false/>

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

Keine Kommentare | neuen Kommentar verfassen

Freitag, 7. Juni 2013

Mac OS X Mountain Lion und die immer wiederkehrenden Log-Einträge

Link zu diesem Artikel

Console.app zeigt mir in regelmässig wiederkehrenden Zeitabschnitten folgende Fehlermeldungen an:

07.06.13 22:43:03.898 mdworker[27399]: Unable to talk to lsboxd
07.06.13 22:43:03.904 mdworker[27401]: Unable to talk to lsboxd
07.06.13 22:43:03.910 mdworker[27400]: Unable to talk to lsboxd
07.06.13 22:43:04.003 sandboxd[27404]: ([27399]) mdworker(27399) deny mach-lookup com.apple.ls.boxd
07.06.13 22:43:04.012 sandboxd[27404]: ([27401]) mdworker(27401) deny mach-lookup com.apple.ls.boxd
07.06.13 22:43:04.022 sandboxd[27404]: ([27400]) mdworker(27400) deny mach-lookup com.apple.ls.boxd
07.06.13 22:43:04.000 kernel[0]: Sandbox: sandboxd(27404) deny mach-lookup com.apple.coresymbolicationd

Das Problem ist an einschlägigen Orten im Internet sehr gut dokumentiert — nur leider ist mir die ultimative Lösung des Problems bisher nicht angeboten worden. Werte Apple-Ingenieure, könnt ihr euch nicht einmal um einen Bugfix bemühen? Danke.

Nachtrag: Mac OS X 10.8.4 scheint das Problem endlich zu beheben:

I’ve had 10.8.4 running for about eight hours now (installed via combo update), and it appears to have have partially fixed my issues. I no longer am getting sandboxd[296] ([299]): mdworker(299) deny mach-lookup com.apple.ls.boxd and kernel[0]: Sandbox: sandboxd(314) deny mach-lookup com.apple.coresymbolicationd messages.

I’ve only gotten one mdworker[299]: Unable to talk to lsboxd message during that time.

Quelle: 10.8.2 – mdworker: Unable to talk to lsboxd

Tags: , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »