Will man seine eigenen Vorgänge in Form von Skripts o.ä. regelmäßig ausführen lassen, dann hat man folgende Möglichkeiten.

1. Einfügen eines eigenen Skripts in den existierenden periodic Mechanismus

Abhängig davon, ob der Vorgang täglich, wöchentlich oder monatlich ablaufen soll, gibt es eine dafür vorgefertigte Ablage:
* /etc/periodic/daily – Verzeichnis, welches die täglich auszuführenden Skripts enthält
* /etc/periodic/weekly – Verzeichnis, welches die wöchentlich auszuführenden Skripts enthält
* /etc/periodic/monthly – Verzeichnis, welches die monatlich auszuführenden Skripts enthält

Die Reihenfolge wie die Skripts ausgeführt werden ist über die vorangestellte Zahl definiert. Und die Uhrzeit wann die Skripts gestartet werden, ist über die Konfiguration des periodic Mechanismus definiert. Wie man die Ausführungszeit dieses Dienstes beeinflussen kann, erfährt man hier.

2. Hinzufügen eines eigenen Skripts bzw. Skriptaufrufs in einen vorgefertigten Platzhalter.

Jeweils am Ende eines periodic Ablaufs wird ein vordefiniertes Skript ausgeführt, sofern es existiert.
* /etc/daily.local
* /etc/weekly.local
* /etc/monthly.local

Werden verschiedene Interpreter zur Ausführung der Befehle benötigt, dann kann man aus dieser Datei weitere Skripts aufrufen. Dann sind für den Fall eines Abbruchs jedoch spezielle Vorkehrungen zu treffen.

Anstatt eines Skripts lassen sich auch mehrere oder der Inhalt eines ganzen Verzeichnis ausführen. In diesem Fall kann man in einer der unter 3. erwähnten Dateien die Variablen:
* $daily_local
* $weekly_local
* $monthly_local
überschreiben (z.B. monthly_local=”/usr/local/scripts.monthly/*”).

3. Vorgesehene Ablage aktivieren …

Entsprechend den Anforderungen eigene Konfigurationsvariablen hinterlegen oder vorhandene überschreiben. Dafür sind zwei Dateien vorgesehen:
* /etc/periodic.conf
* /etc/periodic.conf.local
Auch ein Verzeichnis zur Ablage der eigenen Maßnahmen ist schon definiert: /usr/local/etc/periodic in der Variable $local_periodic.
Es wird allerdings vom bestehenden Mechanismus (noch) nicht verwendet.
Bei Bedarf kann man es in einer der beiden o.g. lokalen Konfigurationsdateien anpassen.

Analog zu den 999.local Skripts in den unter 1. aufgeführten Verzeichnissen bspw. 888.local Skripts anlegen, welche die benötigten selbstdefinierten Variable auswerten.

Der launchd Mechanismus ist ein ziemlich schlaues Verfahren zur Verwaltung von Systemdiensten und Hintergrundprozessen. Einer meiner folgenden Artikel wird sich speziell mit diesem Thema befassen.

Die vom launchd regelmäßig ausgeführten Wartungsmaßnahmen sind:
* periodic daily – /System/Library/LaunchDaemons/com.apple.periodic-daily.plist
* periodic weekly – /System/Library/LaunchDaemons/com.apple.periodic-weekly.plist
* periodic monthly – /System/Library/LaunchDaemons/com.apple.periodic-monthly.plist

Es gibt schon zahlreiche Artikel (u.a. diesen hier) die sich mit dem Thema befassen, was da genau im Hintergrund getan wird. Doch wenige zeigen einem, wie man die Uhrzeit des Ablaufs anpaßt.
Zum Beispiel funktioniert der Mechanismus auf unserem Mac Server ohne Probleme (der Server ist ja auch rund um die Uhr angeschaltet).

zebra:~ super$ cd /var/log
zebra:log super$ ls -ltr *.out
-rw-r--r--  1 root  wheel    1653 Oct  1 05:30 monthly.out
-rw-r--r--  1 root  wheel    6269 Oct 15 03:15 weekly.out
-rw-r--r--  1 root  wheel  455430 Oct 21 03:15 daily.out

Hingegen werden diese Systempflegemaßnahmen auf meinem MacBook eigentlich nie ausgeführt, denn zwischen 3 und 6 Uhr mogens ist der entweder im Stromsparmodus schlafen gelegt oder ganz ausgeschaltet.

Man kann die Skripte natürlich manuell aus dem Terminal Programm starten, doch zwischen 12 und 13 Uhr mittags ist bei mir eine gute Zeit wann diese auf meinem mobilen Computer automatisch ihren Dienst tun können. Also ändern wir das, und das geht bspw. so …

[super@sequoia:LaunchDaemons]? cd /System/Library/LaunchDaemons
[super@sequoia:LaunchDaemons]? sudo vi com.apple.periodic*
....

Wer den vi noch nicht bedienen kann, findet hier eine Anleitung.

Will man die Änderungen hingegen im Xcode 4 mit dem eingebauten Property List Editor durchführen, dann sind dazu mehr Anpassungen nötig.

[super@sequoia:LaunchDaemons]? cd /System/Library/LaunchDaemons
[super@sequoia:LaunchDaemons]? sudo chmod o+w . com.apple.periodic*
[super@sequoia:LaunchDaemons]? open -a /Developer/Applications/Xcode.app com.apple.periodic*
....
[super@sequoia:LaunchDaemons]? sudo chmod g-w,o-w . com.apple.periodic*
[super@sequoia:LaunchDaemons]? sudo chown root:wheel com.apple.periodic*
[super@sequoia:LaunchDaemons]? sudo xattr -d com.apple.xcode.PlistType com.apple.periodic*

Warum bloß soviel Zusatzaufwand für das bißchen mehr an Komfort?
Nun es ist so, daß Xcode zum einen die geänderten Dateien dem Benutzer und seiner primären Gruppe übereignet, und zusätzlich noch Metadaten den Dateien hinzufügt.
Wenn Metadaten zu einer Datei existieren, wird das durch ein @ kenntlich gemacht …

[super@sequoia:LaunchDaemons]? ls -le@ com.apple.periodic*
-rw-rw-r--@ 1 super staff  - 612 23 Okt 10:46 com.apple.periodic-daily.plist
	com.apple.xcode.PlistType	  0 
-rw-rw-r--@ 1 super staff  - 665 21 Okt 14:01 com.apple.periodic-monthly.plist
	com.apple.xcode.PlistType	  0 
-rw-rw-r--@ 1 super staff  - 667 21 Okt 14:01 com.apple.periodic-weekly.plist
	com.apple.xcode.PlistType	  0

Die hier ausgegeben Zeilen zeigen die Dateirechte, welche nach dem Speichern der Änderungen vorherrschten, bevor die Kommandos zum Herstellen des ursprünglichen Zustandes ausgeführt wurden.
Einer meiner folgenden Artikel wird sich noch genauer mit diesem Thema auseinandersetzen.

Die eigentlich durchzuführenden Änderungen liegen auf der Hand …

periodic-daily.plist

                <key>Hour</key>
		<integer>12</integer>
		<key>Minute</key>
		<integer>13</integer>

Jeden Tag um 12:13 Uhr geht es mit der täglichen Pflege los.

periodic-weekly.plist

		<key>Hour</key>
		<integer>12</integer>
		<key>Minute</key>
		<integer>23</integer>
		<key>Weekday</key>
		<integer>1</integer>

Jeden Montag (Sonntag = 0) kommen um 12:23 Uhr die wöchentlichen Pflegemaßnahmen hinzu. Als Standard ist hier der Samstag (6) eingetragen. Aber ich arbeite nicht jedes Wochenende, so kommt mir persönlich der Montag gelegener.

periodic-monthly.plist

		<key>Hour</key>
		<integer>12</integer>
		<key>Minute</key>
		<integer>37</integer>
		<key>Day</key>
		<integer>1</integer>

Und an jedem ersten im Monat werden um 12:37 Uhr die monatlichen Pflegevorgänge gestartet.
Natürlich werden diese Einstellung erst nach dem erneuten Laden der Konfigurationsdateien aktiviert. Ganz sicher ist das nach einem Neustart des Systems der Fall.

Dem Thema wie man mit Time Machine auf verschiedenen Medien Sicherungen durchführen kann widmet sich ein Artikel auf Macworld.

Und das Thema wie die lokalen Sicherungen verwaltet werden, wird auf der Seite von Alexander Wilde sehr ausführlich erklärt.

Technisch funktioniert dieses Verfahren so …

[root@sequoia:~]# mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
localhost:/gT1vdKfZjhVeYqEnaYXbbb on /Volumes/MobileBackups (mtmfs, nosuid, read-only, nobrowse)

Die Sicherungen sind im Verzeichnis /Volumes/MobileBackups bereitgestellt und befinden sich in der etwas kryptischen Freigabe localhost:/gT1vdKfZjhVeYqEnaYXbbb.

[root@sequoia:~]? ls -l /Volumes/
drwxrwxrwx  0 root  wheel  0 Oct 21 08:23 MobileBackups
lrwxr-xr-x  1 root  admin  1 Oct 21 08:22 sequoia_hd0 -> /
[root@sequoia:~]? ls -l /Volumes/MobileBackups/Backups.backupdb/sequoia/
drwxr-xr-x@ 3 root  wheel  102 Oct 21 08:23 2011-10-15-163456
drwxr-xr-x@ 3 root  wheel  102 Oct 21 08:23 2011-10-16-174223
drwxr-xr-x@ 3 root  wheel  102 Oct 21 08:23 2011-10-17-180254
drwxr-xr-x@ 3 root  wheel  102 Oct 21 08:23 2011-10-18-180544
lrwxrwxrwx  0 root  wheel    0 Oct 21 08:22 Latest -> 2011-10-18-180544

Auf der Festplatte liegen die lokalen Sicherungen im versteckten Ordner /.MobileBackups.

[root@sequoia:Volumes]? ls -la /
drwxr-xr-x  23 root  wheel      1156 Oct 16 15:44 .
drwxr-xr-x  23 root  wheel      1156 Oct 16 15:44 ..
-rw-rw-r--   1 root  admin     15364 Oct 13 16:09 .DS_Store
d--x--x--x   7 root  wheel       238 Oct 16 15:44 .DocumentRevisions-V100
drwxr-xr-x+  3 root  wheel       102 Oct 14 07:26 .MobileBackups
drwx------   4 root  wheel       170 Oct 13 13:34 .Spotlight-V100
d-wx-wx-wt   2 root  staff        68 Oct 13 13:09 .Trashes
.....

Nach dem Ausschalten der lokalen Sicherungen, sind diese Verzeichnisse verschwunden und der verbrauchte Platz wieder freigegeben.

Zunächst einmal handelt es sich dabei um nichts Neues. Auf Mac OS wurden diese Dateiattribute mit Mac OS 10.4 (Tiger) eingeführt, welche offiziell am 29. April 2005 erschien.
Die meisten anderen Betriebssysteme hatten ACLs schon bedeutend länger mit an Bord.
Der Funktionsumfang dieser erweiterten Dateizugriffsrechte liegt im wesentlichen im zugrunde gelegten Dateisystem verankert. Und bezüglich Mac OS X haben sich vor einigen Jahren auch schon andere damit befaßt.

Die Befehle, welche man zum Anschauen und zur Bearbeitung von ACLs benutzt lauten:
* ls -le
* chmod +a

Und was soll das jetzt?

Zum einen wird man manchmal unfreiwillig damit konfrontiert, davon handelt mein vorangehender Artikel.
Zum anderen gibt es denkbar viele Anwendungsfälle, welche sich mit ACLs sehr geschickt und einfach lösen lassen. Greifen wir uns also einen heraus …

1. Individuelle Drop Box

Ein jeder Mac OS X Benutzer stellt für andere Anwender eine Ablage für Dateien bereit, deren Inhalt sie aber nicht sehen können bzw. dürfen.
Nun wäre es manchmal hilfreich, einer einzelnen Person das Recht einräumen zu können in ein solches Verzeichnis hineinzuschauen, was denn schon drin liegt. Also eine individuelle Drop Box anlegen.

Man schaut sich die aktuellen Rechte an …

$ ls -le
drwx-wx-wx+ 2 martin  staff   102  8 Okt 09:30 Drop Box
 0: user:martin allow list,add_file,search,delete,add_subdirectory,delete_child,
    readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,
    chown,file_inherit,directory_inherit
 1: user:_spotlight inherited allow list,search,file_inherit,directory_inherit
 
-rw-r--r--+ 1 martin  staff  1711  8 Okt 09:11 mac_rastetter-gpg.asc
 0: user:_spotlight inherited allow read,execute

Das der Kennzeichnung der Zugriffsrechte nachgestellte + Zeichen, gibt einem den Hinweis es sind ACLs für diese Datei gesetzt. Diese werden je Benutzer bzw. Gruppe von dem Befehl ls -le aufgelistet.
ACL 0 : Der Besitzer (martin) des Verzeichnisses bekommt explizit alle Rechte
ACL 1 : Der Spotlight Dienst (_spotlight) darf alles darinnen befindliche lesen und durchsuchen
Bei einer darinnen befindlichen Datei (mein öffentlicher PGP Schlüssel) hat jeder Leserechte und unabhängig davon, wie ich die gewöhnlichen Dateirechte einschränkte, blieb dem Spotlight Dienst die Möglichkeit den Inhalt zu lesen bzw. diese auszuführen (wozu auch immer).

Nun legen wir ein Verzeichnis mit individueller Berechtigung an …

$ cp -Rp Drop\ Box Ina\'s\ Box
$ chmod o-wx Ina\'s\ Box
$ chmod g-wx Ina\'s\ Box
$ chmod +a "ina allow list" Ina\'s\ Box
$ chmod +a "ina allow add_file" Ina\'s\ Box
$ chmod +a "ina allow search" Ina\'s\ Box
$ chmod +a "ina deny delete_child" Ina\'s\ Box

Wir kopieren also das Verzeichnis Drop Box mit Inhalt (in diesem Fall hoffentlich leer) und allen Berechtigungen und nennen es Ina’s Box.
Dann nehmen wir allen anderen Benutzern und jenen der eigenen Gruppe (staff s.o.) alle Rechte.
Wir erlauben nur der Benutzerin ina sich den Inhalt des Verzeichnisses anzusehen, Dateien hinzuzufügen,
darin zu suchen und verbieten das Löschen.

Das ganze sieht dann wie folgt aus …

$ ls -le
drwx-wx-wx+ 2 martin  staff   204 10 Okt 08:46 Drop Box
 0: user:martin allow list,add_file,search,delete,add_subdirectory,delete_child,
    readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,
    chown,file_inherit,directory_inherit
 1: user:_spotlight inherited allow list,search,file_inherit,directory_inherit
drwx------+ 2 martin  staff   306 10 Okt 08:47 Ina's Box
 0: user:ina deny delete_child
 1: user:ina allow list,add_file,search
 2: user:martin allow list,add_file,search,delete,add_subdirectory,delete_child,
    readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,
    chown,file_inherit,directory_inherit
 3: user:_spotlight inherited allow list,search,file_inherit,directory_inherit
-rw-r--r--+ 1 martin  staff  1711  8 Okt 09:11 mac_rastetter-gpg.asc
 0: user:_spotlight inherited allow read,execute

So, jetzt wollen wir schauen ob und wie es funktioniert.
Alle Benutzer sehen mein öffentliches Verzeichnis im Finder wie folgt:

Wohingegen die Benutzerin ina mein öffentliches Verzeichnis im Finder wie folgt dargestellt bekommt:

Und siehe da, diese Benutzerin kann mir dort nicht nur Dateien hinterlegen, sondern diese und deren Inhalt kontrollieren.

Die tatsächlichen Rechte sehen dann wie folgt aus.

$ ls -le Ina\'s\ Box/
-rw-r--r--+ 1 ina  staff  1188252 15 Sep  2009 ObjC.pdf
 0: user:martin inherited allow read,write,execute,delete,append,
    readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,
    chown
 1: user:_spotlight inherited allow read,execute
-rw-r--r--+ 1 ina  staff      124 10 Okt 08:40 maxosx_extensions.txt
 0: user:martin inherited allow read,write,execute,delete,append,
    readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,
    chown
 1: user:_spotlight inherited allow read,execute

Man kann erkennen, daß bei den Dateien die Rechte vom Verzeichnis vererbt (inherited) wurden, sowie keine Verzeichnisattribute gesetzt sind.
Die allgemeinen Zugriffsrechte bleiben erhalten.
Will die Besitzerin die Dateien löschen, wird das abgelehnt, bzw. mit der Frage nach dem Kennwort des Administrators quittiert (der darf sowieso alles).
Nachträgliche Änderungen an den Dateien sind mit Mac Texteditoren (TextEditor, XCode) nicht mehr möglich, wohingegen auf der Unix Kommandoebene keine Einschränkungen bestehen.

$cd ~martin/Public
$ echo "Hallo Welt ... wie geht's?" >> Ina\'s\ Box/maxosx_extensions.txt 
$ tail -1 Ina\'s\ Box/maxosx_extensions.txt 
Hallo Welt ...wie geht's?

Man erwartet eigentlich auch genau dieses Verhalten, dennoch behaupten o.g. Editoren die Datei sei gesperrt?!
Vielleicht will ja ein interessierter Leser dieser Sache näher auf den Grund gehen …

Nutzer der Apple Mac OS X Betriebssystemfamilie greifen dabei gerne auf das Softwarepaket GPGTools zurück. Eine deutsche Installationsanleitung erlaubt selbst technischen Laien eine problemlose Installation der Software.
Unabhängig davon, ob man einige der Funktionen nun direkt aus irgendwelchen Anwendungen nutzen will, kann ein gewöhnlicher Anwender unter Mac OS 10.7 (Lion) weder ent- noch verschlüsseln. Und das sollte generell schon möglich sein!

Schaut man in der Konsole Anwendung, fallen einem Meldungen der Art

08.10.11 09:43:30,335 org.gpgtools.macgpg2.gpg-agent: gpg-agent[5844]: 
    error binding socket to `/Users/myuser/.gnupg/S.gpg-agent': Invalid argument

ins Auge. Und man stellt fest, daß der persönliche GPG Agent nicht läuft.

$ ps uxw | grep gpg

bzw.

$ launchctl list | grep gpg
	-	(2) org.gpgtools.macgpg2.gpg-agent

Die Zahl in Klammern ist die Fehlernummer, welcher beim Startversuch des Agenten auftritt.

Nun gut, sucht man im Internet … dann findet man zu diesem Thema einige Konversationen direkt mit den Entwicklern der Software.
1. Diskussion vom Januar 2011
2. Diskussion vom Juni 2011
Und siehe da, man erkennt sofort es werden bei Mac OS 10.7 (Lion) viel häufiger als in den vorhergehenden Versionen dieser Betriebssystemfamilie sogenannte ACLs (= Access Control Lists, zu deutsch sind damit erweiterte Zugriffsberechtigungen auf Dateiebene gemeint) verwendet werden.

Beheben wir zunächst das Problem, und schauen uns dieses Phänomen danach noch etwas genauer an (in einem meiner nachfolgenden Beiträge).

So nimmt man alle ACLs vom benutzereigenen GnuPG Verzeichnis weg …

$ cd ~
$ chmod -R -a# 0 .gnupg

… dann startet man den Agenten erneut und schaut, ob er diesmal läuft …

$ launchctl start org.gpgtools.macgpg2.gpg-agent
$ launchctl list | grep gpg
213	-	org.gpgtools.macgpg2.gpg-agent

Die Zahl vorne ist die Prozeßkennung des Agenten.

Bei Interesse kann man sich Details zum Agenten anzeigen lassen …

$ launchctl list org.gpgtools.macgpg2.gpg-agent

… und das sollte etwa so aussehen.

{
	"Label" = "org.gpgtools.macgpg2.gpg-agent";
	"LimitLoadToSessionType" = "Background";
	"OnDemand" = true;
	"LastExitStatus" = 0;
	"PID" = 213;
	"TimeOut" = 30;
	"ProgramArguments" = (
		"/usr/local/MacGPG2/bin/gpg-agent";
		"--launchd";
		"--write-env-file";
	);
};

Und jetzt klappt auch die Ent- und Verschlüsselung wieder, bspw. …

$ gpg -d -o decoded.file encoded.file 
Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Martin Rastetter <martin@baden.de>"
1024-Bit ELG Schlüssel, ID EE827F34, erzeugt 2005-01-09 (Hauptschlüssel-ID D94AFAD0)
gpg: verschlüsselt mit 1024-Bit ELG Schlüssel, ID F3D63379, erzeugt 2008-11-03
      "Fritz Fuchs <fritzle@schwaben.de>"
gpg: verschlüsselt mit 1024-Bit ELG Schlüssel, ID EE827F34, erzeugt 2005-01-09
      "Martin Rastetter <martin@baden.de>"
gpg: Signatur vom Mi 27 Mai 12:01:06 2009 CEST mittels DSA-Schlüssel ID 63525EE3
gpg: Korrekte Signatur von "Fritz Fuchs <fritzle@schwaben.de>"
Haupt-Fingerabdruck  = CA62 6DD9 CE88 4D3D 0621  1343 6806 7B58 6352 5EE3

Bestens, ab jetzt können wir wieder mit GnuPG arbeiten wie wir es bisher gewohnt waren.

Danach nach dem Textbereich suchen der so aussieht:

< key>StartInterval< /key>
< integer>3600< /integer>


Der angegebene Wert muss in Sekunden angegeben werden.

Mit Rechtsklick aufs Timemachineicon im Dock kann man übrigens auch “Backup jetzt erstellen” wählen.

Das wars, und schon erscheint das Dock im “alten glanz”.

Ebenso nach 24 Stunden ist auch schon UPS mit dem Päckchen gekommen. Ich habe bisher mit keiner IT Firma so gute Supporterfahrungen gemacht wie mit Apple.

Hier ein Bild wie es normal aussehen sollte:

Und hier ein Bild wie es auf der anderen Seite des Akkus aussieht:

Nach ein paar sehr sehr netten Telefonaten mit Apple bekomme ich jetzt ein neuen Akku zugeschickt. So ein guten Support hätte ich gar nicht von Apple erwartet.