Die Installation ist denkbar einfach. Sei es “yum install synergy” oder “pacman -S synergy“, Synergy ist für viele, verschiedene Plattformen verfügbar.
Was die Konfiguration angeht, so muss man diese verstehen. - Dann ist es völlig klar!

Es gibt eine Server- und eine Client-Komponente. Der Server wird einfach wie folgt gestartet:
synergys –address
Der Client im Anschluss so:
synergyc

Was die Konfiguration angeht, so muss diese nur und ausschließlich auf dem Server erfolgen.
Exemplarisch sei hier eine Konfiguration präsentiert, die bei mir läuft. - Mein “Server” (slnotebook) steht rechts, der Rechner, bzw dessen Monitor, (slroot) von ihm links.
vi /etc/synergy.conf

section: screens
slroot:
slnotebook:
end

section: aliases
slroot:
root.domain.de
slnotebook:
slnotebook.domain.siv
end

Wie zu sehen ist, verwende ich Aliases. - Das bringt zuweilen etwas Übersichtlichkeit, da die Verwendung voll ausgeschriebener Domainnamen kryptisch wirkt. - selbstredende Bezeichner sind durchaus sinnvoll.

Anhängen:
ALTER TABLESPACE “VMDAIN” ADD DATAFILE ‘/u02/oradata/neu_01.dbf’ SIZE 2G;

Erweitern:
ALTER DATABASE DATAFILE ‘d:\oradata\alt_01.dbf’ RESIZE 4G;

Ich habe mal die Pfade für Unix/Linux und Windows verwendet. - Auch hier ist wichtig:
Erst nachdenken und dann klicken!

So wird, pünktlich zu den kalten Tagen, der Weihnachtszauber auf den Desktop gebracht.

Ohne viele Worte machen zu wollen “no_root_squash” ist die Option, die auf Serverseite die Lösung bringt. Ein Eintrag könnte wie folgt aussehen:
vi /etc/exports
/media/disk32/system/opt *.cloudfarm(rw,sync,map_identity,no_root_squash)
service nfs restart

alias.url = ( "/dir1/" => "/var/www/dir1" )

Was aber auf Probleme stoßen lässt ist, nach dem gleichen Schema, weitere Alias-Einträge zu machen. Kein Problem! - So sieht’s aus!

alias.url += ( "/dir2/" => "/var/www/dir2" )

“417 - Expectation Failed”

Ohne viele Worte zu machen…
server.reject-expect-100-with-417 = “disable”
Diese Zeile muss nur in die lighttpd.conf eingefügt werden, Restart und fertig!

Nun geht es los mit Subversion (SVN)!
cd /etc/httpd/conf.d/
vi subversion.conf

Wenn die Installation richtig durchlief, dann befindet sich hier bereits eine Art Template, dass nur noch angepasst werden muss.
Faktisch muss folgendes enthalten sein:
LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

<Location /data/svn>
DAV svn
SVNParentPath /data/blabla/subversion

# Limit write permission to list of valid users.
#<LimitExcept PROPFIND OPTIONS REPORT>
# Require SSL connection for password protection.
# SSLRequireSSL

AuthType Basic
AuthName “SubVersion”
AuthUserFile /etc/httpd/svn.pwd
Require valid-user
Order allow,deny
Allow from all

#AuthzSVNAccessFile /etc/httpd/svn.acl
#</LimitExcept>
</Location>

“LimitExcept” habe ich einfach auskommentiert, weil sonst einfach mal nicht die Authentifizierung “vernünftig” funktioniert. - Es muss ja nicht jeder auch den Inhalt sehen können.

Nun kann der Kennwort-geschützte Zugang eingerichtet werden.
htpasswd -mc /etc/httpd/svn.pwd BENUTZER
Das “m” sorgt dafür, dass das Passwort mit MD5 “gehasht” wird…Auch ein wenig sicherer.

Nun ist es an der Zeit die eigentlichen SVN-Repositoris einzurichten.
svnadmin create /data/backup/svn/repo1
chown -R apache:apache /data/backup/svn/repo1

service httpd start

Darf die Nutzer-Verwaltung etwas feiner sein? Kein Problem, denn hier kommt die “Access Control Lists” von Subversion zum tragen.
Innerhalb des “Location”-Blocks, in der alt-bekannten Subversion-Konfiguration, wird dafür einfach die folgende Zeile hinzugefügt:
AuthzSVNAccessFile /etc/httpd/svn.acl

Nun muss eben diese ACL-Datei (/etc/httpd/svn.acl) entsprechende Einträge erhalten. Der Standard ist “no access”; es ist also, trotz erfolgreicher Anmeldung, kein Zugriff möglich. Es gibt “r” für den Lesezugriff und “w” für en Schreibzugriff. Wofür “rw” steht, kann man sich wohl herleiten.
Exemplarisch ein Ausschnitt:
[repo1:/]
user1=rw
user2=r

[repo2:/]
user1=rw
…

Die Änderungen der ACLs greifen auch ohne Neustart des Webservers.

Mit yum install lighttpd ist der WebServer schnell installiert. Die Konfiguration findet sich unter “/etc/lighttpd”.
Als erstes müssen der Konfiguration 2 Module hinzugefügt werden. - “mod_webdav” für WebDAV und “mod_auth”, damit der Zugriff nur ausgesuchten Benutzern vorbehalten bleibt.
vi /etc/lighttpd/lighttpd.conf
…
server.modules = (
“mod_webdav”,
“mod_auth”,
…
)
…
Nun folgt die eigentliche WebDAV-Konfiguration in der gleichen Datei.
…
$HTTP["host"] == “disk.enlightware.com” {
server.document-root = “/var/www/webdav/user1″
alias.url = ( “/user1″ => “/var/www/webdav/user1″ )
$HTTP["url"] =~ “^/user1($|/)” {
dir-listing.activate = “enable”
webdav.activate = “enable”
webdav.is-readonly = “disable”
auth.backend = “plain”
auth.backend.plain.userfile = “/var/www/webdav/user1/.passwd”
auth.require = ( “” => ( “method” => “basic”,
“realm” => “Disk of user1″,
“require” => “user=user1″ ) )
}
}
…

Nun kann und sollte das Kennwort angelegt werden.
vi /var/www/webdav/user1/.passwd
user1:furchtbar_geheim

Es ist die Zeit gekommen, dar der Server gestartet wird.
service lighttpd start

Unter “http://disk.enlightware.com/user1″ ist nun das Online-Laufwerk zu finden und zu nutzen.
Ohne es jemals ausprobiert zu haben - es sollte auf Grund der Konfiguration dem “Disk-Besitzer” nun auch möglich sein, sein eigenes Klartext-Kennwort zu ändern. Das eröffnet ein paar schöne und ein paar weniger schöne Möglichkeiten.
Wer es gern etwas sicherer hätte, der kann seine Konfiguration wie folgt abändern:
…
auth.backend = “htpasswd”
auth.backend.htpasswd.userfile = “/etc/lighttpd/disk.user1.pwd”
auth.require = ( “” => ( “method” => “basic”,
“realm” => “Disk of user1″,
“require” => “valid-user” ) )
…

Wie dir vielleicht auffällt, ist nun aus der auth-Methode “plain” “htpasswd” geworden. Das hat den entscheidenden Nachteil, dass man nun ein Tool benötigt, welches die Kennwörter anlegt.
Beispiel:
htpasswd -c /etc/lighttpd/disk.user1.pwd user1

Hier an der Stelle musst du für dich entscheiden, was die lieber ist. Ich hab’ die zwei Wege aufgezeigt…

Das höhere Ziel besteht darin, den Online-Speicher als ‘normaler’ Benutzer einhängen und nutzen zu können.
Jetzt wird’s interessant:
mkdir /data/gmx
mkdir /home/BENUTZER/.davfs2/
vi /home/BENUTZER/.davfs2/secrets
https://mediacenter.gmx.net BENUTZER@gmx.net KENNWORT
chmod 600 /home/BENUTZER/.davfs2/secrets

BENUTZER und KENNWORT sind natürlich sinnvoll zu ersetzen. Darüber hinaus solltest du gucken, ob du bei “gmx.de” oder bei “gmx.net” angemeldet bist.

Damit man einfach mit “mount /data/gmx” den neuen Cloud-Speicher einbinden kann, muss natürlich noch die “/etc/fstab” erweitert werden.
vi /etc/fstab
https://mediacenter.gmx.net /data/gmx davfs noauto,user 0 0

Der ‘normale’ Benutzer benötigt etwas andere Rechte, um den mount-Befehl nutzen zu können. Es kann also nicht schaden dem Befehl auch entsprechende Rechte zu geben.
chmod +s /sbin/mount.davfs

Versucht man sich nun am Einhängen, wird das wohl kaum funktionieren. - Nun begann nämlich meine Forschungsarbeit!
Ein Problem, welches es vermutlich so nur unter Arch Linux gibt ist:
Will man als ‘normaler’ Benutzer ein davfs2-Laufwerk einhängen, so kommt es zu folgender Ausschrift:

/sbin/mount.davfs: / is the home directory of user nobody.
You can't mount into another users home directory

Gut! - Also es gibt offenbar Betriebssystembenutzer, deren Home-Verzeichnis im Root liegt. Warum das ein Problem ist, vermag ich nicht zu sagen; es ist aber nötig, diesen Zustand abzuändern, damit davfs2 “vernünftig” funktioniert.
usermod –home /dev/null nobody
usermod –home /dev/null nobody
/etc/rc.d/dbus stop
usermod –home /dev/null dbus
/etc/rc.d/dbus start
usermod –home /dev/null avahi

So - nun müssen noch ein paar Rechte für davfs gesetzt werden. Diese können in die globale Konfiguration von davfs2 vorgenommen werden.
vi /etc/davfs2/davfs2.conf
dav_group GRUPPE
Möchte man den Zugriff auf einen bestimmten Benutzer beschränken, so kann auch folgende Konfiguration genutzt werden.
dav_user BENUTZER

Das Problem, welches am augenfälligsten und (vermutlich) auf allen Linux-Distributionen auftritt ist der oben angedeutete Umstand, dass sich nicht auf die Freigabe schreiben lässt. Es handelt sich dabei tatsächlich um einen Bug. Aber es ist die gute Form eines Bugs, denn er lässt sich einfach auskommentieren.
Abermals muss die globale davfs2-Konfiguration angepasst werden.
vi /etc/davfs2/davfs2.conf
if_match_bug 1

Diese kleine und unscheinbare Zeile entscheidet schlussendlich über den Sinn einer solchen Speichererweiterung. Denn kann man nicht auf den Online-Speicher schreiben…was brächte dieser dann.

So! - Nun ist es soweit!
Als ‘normaler’ Benutzer…
mount /data/gmx

Genial, oder?!

oder

for i in `find /PATH -size -1`; do rm -f $i; done
…wenn man alle leeren Dateien löschen will…

Nun muss die Datei ja nicht immer gleich gelöscht werden, es gibt da sicher auch noch andere Anwendungsmöglichkeiten…