Den virtuellen Desktop kann man gewöhnlich schön per Tastenkombination wechslen, was leider nicht funktioniert, wenn eine VirtualBox-VM den Fokus hat. Dabei wäre es so schön, wenn man auf einem virtuellen Desktop eine VM im Vollbildmodus hätte und man bequem zwischen Host und Gast wechseln könnte.
Da ich leider keine VBox-Einstellung oder irgendeinen einfachen Trick gefunden habe, um dieses Verhalten zu ändern, habe ich eine vielleicht etwas primitive aber einfache Lösung gefunden.
Ein kleines Tool, welches auf dem Host läuft und per Socket einfache Befehle wie "down" oder "up" entgegen nimmt und daraufhin den virtuellen Desktop wechselt. Im Gast-System muss man noch die dortigen Tastenkombinationen für das wechseln des virtuellen Desktops so ändern, dass stattdessen an den Host diese Befehle gesendet werden.
Hier gibt es das Programm, welches auf dem Host laufen muss. Dieses lauscht auf Port 9302 und nimmt die Befehle "up", "down", "left" und "right" an, wobei "left" und "right" aktuell das gleiche machen wie "up" und "down". Außerdem gibt es noch keine Konfigurationsmöglichkeiten oder Sicherheitsmechanismen.
Im Gastsystem erstellt man dann passende Scripte wie dieses hier:
#!/bin/sh
echo "up" | nc host 9302
Diese Scripte müssen dann nur noch per Tastenkombination ausgeführt werden.
Das ganze ist noch etwas primitiv, aber Verbesserungen sind geplant. Fortsetzung folgt (irgendwann).
Beispielcode ohne großartige Erklärung.
aes_commoncrypto.c
Ein kurzes Beispiel dafür, wie man mit der macOS-API CommonCrypto mit AES etwas verschlüsselt und wieder entschlüsselt.
WebDAV kennt zwei Arten von Locks: Exclusive und Shared Locks. Ein Exclusive Lock wird vom Server pro Resource immer nur einem User gestattet. Dies verhindert effektiv, dass andere User eine Ressource überschreiben. Shared Locks hingegen können von mehreren Usern gleichzeitig erhalten werden. Damit sind Shared Locks kein Schutz davor, dass andere eine Ressource überschreiben, sondern sind eher da, um andere Clients zu informieren, dass die Datei gerade in Bearbeitung ist.
Ein Lock bezieht sich entweder auf eine einzelne Ressource, oder auf ganze Collection. Bei letzterem hat man auch die Wahl, ob nur alle direkten Kind-Ressourcen gelockt werden sollen, oder alles was sich unterhalb der gelockten Collection befindet.
Kann ein Client einen Exclusive Lock erfolgreich erstellen, erhält er vom Server ein Locktoken. Dieses Locktoken muss bei allen Schreiboperationen auf die gelockte Resource angegeben werden.
In dav werden bisher nur Exclusive Locks unterstützt. Hierfür gibt es für das Tool dav die Befehle lock und unlock, um Resourcen zu sperren oder zu entsperren. Das Tool dav-sync kann bei Bedarf auch die ganze Collection locken, in dem man die passende Option angibt oder in der Konfigurationsdatei Locking aktiviert.
Um mit dav eine Ressource zu sperren benutzt man den Befehl lock und übergibt die URL der Ressource. Optional kann auch ein Lock-Timeout angegeben werden. Wenn die Ressource erfolgreich gelockt werden konnte, wird auf stdout das Locktoken ausgegeben.
$ dav lock myserv/file.txt
opaquelocktoken:cde48dcb-c860-0512-a770-x38b4f980dbc
Das Locktoken muss man unbedingt irgendwo speichern oder es muss im Terminal zumindestens in Sichtweite bleiben. Denn verliert man das Locktoken ist vor Ablauf des Timeouts kein Schreibzugriff auf die Ressource mehr möglich, was ungünstig bei einem unendlichen Timeout ist. In diesem Fall müsste der Serveradministrator im Webserver den Lock entfernen.
Hat man nun das Locktoken, kann dies bei allen dav-Befehlen, die Schreibvorgänge ausführen, angeben. Also z.B. um eine gelockte Ressource zu überschreiben, gibt man mit der -L Option das Locktoken an:
$ dav put -L opaquelocktoken:cde48dcb-c860-0512-a770-x38b4f980dbc myserv/file.txt localfile.txt
Eine Ressource unlocken kann man mit dem unlock Befehl. Dabei muss auch das Locktoken angegeben werden. Falls nicht mit der -L Option angegeben wird, liest dav von stdin das Locktoken.
$ dav unlock -L opaquelocktoken:cde48dcb-c860-0512-a770-x38b4f980dbc myserv/file.txt
Es ist empfehlenswert, das Locktoken direkt in einer Datei zu speichern.
$ dav lock myserv/file.txt > locktoken
$ dav put -L `cat locktoken` myserv/file.txt uploadthisfile.txt
$ dav unlock myserv/file.txt < locktoken
Um in dav-sync WebDAV-Locks zu nutzen, kann man entweder bei den Synchronisationskommandos (pull, push, archive) die Option -l angeben, oder man aktiviert standardmäßig Locking für das Sync-Verzeichniss, in dem man in der Datei $HOME/.dav/sync.xml innerhalb eines <directory>-Elements folgendes einfügt:
<directory>
...
<!-- enable lock for pull command -->
<lock-pull>true</lock-pull>
<!-- enable lock for push/archive command -->
<lock-push>true</lock-push>
</directory>
Natürlich ist es auch möglich, nur pull oder nur push mit Lock zu nutzen.
Wenn dav-sync die Collection lockt, wird im Verzeichnis $HOME/.dav temporär eine Datei (locktoken-$syncdir.txt) angelegt, die das Locktoken enthält. Sollte dav-sync unerwartet beendet werden, kann man somit noch manuell die Collection unlocken. Wenn dav-sync sauber terminiert, wird automatisch die Collection entsperrt und die temporäre Datei entfernt.
Wer sich mit File-Locking beschäftigt, der wird vermutlich auf zwei Möglichkeiten stoßen: die Funktion flock und Locking mit fcntl. Es gibt zwei wichtige Unterschiede zwischen diesen beiden Funktionen.
Locks, die mit flock erstellt wurden, werden bei einem fork an den Kind-Prozess weitergegeben. Es wird jedoch nicht der Lock kopiert, wenn durch fork oder dup der Filedescriptor dupliziert wird, denn jeder Filedescriptor auf die gelockte Datei enthält nur eine Referenz auf den selben Lock. Der Lock bleibt bestehen bis entweder alle Filedeskriptoren geschlossen sind, oder explizit eine Unlock-Operation auf einen Filedescriptor mit diesem Lock, egal in welchem Prozess, ausgeführt wird.
Mit fcntl erstellte Locks werden bei einem fork hingegen gar nicht weitergegeben. Der Lock gilt immer nur für den Prozess, der ihn erstellt hat. Außerdem wird ein Lock entfernt, wenn auch nur ein Filedescriptor der gelockten Datei geschlossen wird.
Der andere große Unterschied ist, dass nur Locking mit fcntl Posix-spezifiziert ist. Die Funktion flock hingegen ist eine BSD-Erfindung, die jedoch auch von Linux übernommen wurde. Andere Unixe, wie z.B. Solaris, unterstützen flock gar nicht.
Außerdem unterscheidet sich auch das Interface der beiden Funktionen deutlich. Mit fcntl hat man ein bisschen mehr Schreibarbeit, dafür ist es auch möglich nur einen Bereich einer Datei zu locken, wärend flock etwas primitiver ist.
Locking mit fcntl:
int fd = open(path, O_RDWR);
struct flock lock;
memset(&lock, 0, sizeof(struct flock));
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 0;
fcntl(fd, F_SETLK, &lock);
Locking mit flock:
int fd = open(path, O_RDWR);
flock(fd, LOCK_EX);
Die Verlockung ist vielleicht groß, flock zu nutzen, wenn man nur schnell und einfach eine ganze Datei locken möchte. Ich würde aber empfehlen, immer fcntl zu nutzen, außer man möchte wirklich Locks mit mehreren Prozessen teilen.
Mit dem BSD-Tool mtree kann eine Datei-Hierarchie mit einer Spezifikation verglichen werden, wobei diese Spezifikation ebenfalls mit mtree erstellt werden kann. So kann man mit mtree geänderte Dateien finden, es ist jedoch auch möglich, Dateien, die nicht der Spezifikation entsprechen, zu löschen oder geänderte Dateirechte wiederherzustellen.
Nehmen wir mal an, man hat ein paar Dateien:
$ find .
.
./file2
./dir
./dir/abc
./dir/ccc
./file1
Bevor man mit mtree etwas vergleichen kann, benötigt man eine Spezifikation der Dateien. Diese erstellen wir mit mtree -c.
$ mtree -c > ../spec
$ cat ../spec
# user: olaf
# machine: m2.fritz.box
# tree: /Users/olaf/Desktop/test
# date: Mon Dec 18 18:50:28 2017
# .
/set type=file uid=501 gid=20 mode=0644 nlink=1 flags=none
. type=dir mode=0755 nlink=5 size=160 \
time=1513618591.304192231
file1 size=6 time=1513619185.055667000
file2 size=13 time=1513619203.579709605
# ./dir
dir type=dir mode=0755 nlink=4 size=128 \
time=1513618608.749249207
abc size=6 time=1513618604.803276546
ccc size=5 time=1513618611.066866426
# ./dir
..
..
Nun hat man eine Spezifikation, mit der man später die Dateien vergleichen kann.
$ touch dir/abc
$ echo "Hello World" > file1
$ mtree < ../spec
dir/abc changed
modification time expected Mon Dec 18 18:36:44 2017.803276546 found Mon Dec 18 18:56:22 2017.582045000
file1 changed
size expected 6 found 12
modification time expected Mon Dec 18 18:46:25 2017.055667000 found Mon Dec 18 18:57:03 2017.596168115
Wie man sieht, werden standardmäßig nur wenige Eigenschaften im der Spezifikation gespeichert, man hat jedoch eine große Auswahl an sogenannten keywords, die pro Datei gespeichert werden sollen. Diese können mit der -K-Option angegeben werden.
$ mtree -c -K sha256digest
Das Tool ist zwar ein BSD-Tool und unter Linux standardmäßig nicht anzutreffen, ich habe aber zumindestens einen Port gefunden. Und unter Ubuntu gibt es das Paket freebsd-buildutils, welches das Tool fmtree enthält.