Fehler beim Öffnen der PSD-Datei: Farbmodus wird nicht unterstützt: CMYK

Sucht man nach einer Lösung im Internet, wird man häufig auf Aussagen treffen wie: “Photoshop kann es”. Wer sich aber kein Photoshop installieren will, nur um eine PSD-Datei im RGB-Farbmodus oder in anderen Formaten abzuspeichern, der sollte imagemagick verwenden. imagemagick kann – wer es noch nicht installiert hat – ganz einfach über den Linux-Paketmanager installieren und anschließend führt dann im Terminal folgenden Befehl aus:

convert /pfad/zur/psd/Ursprungsgrafik.psd /pfad/zum/ziel/Zielgrafik.png

Statt png können auch andere Formate verwendet werden. PNG bietet sich jedoch an, um verlustfrei und mit Transparenz zu speichern. imagemagick extrahiert dabei die einzelnen Ebenen und eine Komplettansicht und speichert sie als Zielgrafik-0.png bis Zielgrafik-n.png … ab.

Das Skript von der Heinlein Professional Linux Support GmbH arbeitet dabei mit Hardlinks, d.h. jeden Tag wird das Backup des Vortages per Hardlink (mehr zum Hardlink bei Wikipedia) kopiert und verbraucht dabei keinen Speicher, da quasi nur ein Link auf die bestehenden Dateien auf der Festplatte gesetzt wird. Erst wenn anschließend das Backup per rsync durchgeführt wird und sich Dateien verändern, werden eben diese veränderten Dateien neu geschrieben. Das heißt, es belegt nur soviel Plattenplatz wie sich Dateien verändern. So kann man die Snaphots viele Tage in die Vergangenheit ragen lassen.

Viel mehr möchte ich an dieser Stelle jedoch nicht beschreiben, da die Beschreibung zum Skript schon sehr ausführlich ist. Auf jeden Fall habe ich die Backup-Lösung mittlerweile im Produktiv-Einsatz und bin sehr zufrieden. Und wie versprochen, hält sich die Festplatten-Belegung in Grenzen und dennoch ist ein vollständiger Zugriff auf die Snaphots der letzten Tage möglich.

Hier der Link zu den Backup-Scripts und dessen Beschreibung

Wer einen weiteren Fest-PC hat, der kann das Backup ganz automatisiert darüber ablaufen lassen. Bei mir läuft der HTPC immer und da er sowieso schon Server-Dienste übernimmt, ist er nun auch zum Backup-Server befördert worden.

Stündlich lasse ich nun mein gesamtes /home-Verzeichnis per rsync in ein Backup-Verzeichnis auf dem HTPC updaten. Und falls der Laptop einmal nicht da oder nicht an ist, verabschiedet sich rsync mit einer einfachen Fehlermeldung und belässt das Backup unberührt.

Einrichtung

Installation

Auch wenn der HTPC in diesem Fall als Backup-”Server” zuständig ist, übernimmt er eigentlich eine Client-Funktion. Deshalb spreche ich ab sofort von server (eigentlich der Laptop) und client (der HTPC).

Damit überhaupt ein Zugriff erfolgen kann, muss auf dem server ein ssh-Server (Daemon) laufen. Dieser wird unter Ubuntu durch das Paket openssh-server zur Verfügung gestellt:

user@client:~$ sudo apt-get install openssh-server

In Arch Linux heißt es einfach nur openssh.

user@client:~$ pacman -S openssh

Zusätzlich muss der Daemon unter Arch Linux noch in die /etc/rc.conf unter DAEMONS eingetragen werden, damit er bei jedem Start mitgestartet wird.

Nun kann man sich vom client auf den server einloggen:

user@client:~$ ssh user@server

Wobei für server der entsprechende Hostname bzw. IP eingesetzt wird und für user der User auf dem server, dessen Dateien gesichert werden sollen. Es wird eine Passwort-Abfrage kommen, wo das Passwort des entsprechenden users auf dem server eingegeben wird.

Falls das klappt, kann man die Sitzung mit “exit” verlassen, da wir zunächst ein paar Aufgaben auf dem client erledigen müssen.

Authentifizierung

Da unser Cronjob später nicht auf die Passwort-Abfrage reagieren kann, umgehen wir diese, indem wir ein Keyfile generieren:

user@client:~$ ssh-keygen -t dsa -f ~/.ssh/backup_key

Die passphrase wird leer gelassen, damit es später zu keiner Passwort-Abfrage kommt.

Das Programm sollte nun in ~/.ssh/ ein privates und ein öffentliches Keyfile (erkennbar an der .pub-Endung) angelegt haben.

Hinweis: Eine leere passphrase stellt ein Sicherheitsrisiko dar. Wer in die Hände des Keyfiles kommt, kann Zugriff zum server erlangen. Diese Methode sollte deshalb nur im lokalen Netzwerk verwendet werden.

Damit die Authentifizierung zwischen client und server funktioniert, muss das Keyfile auf den server übertragen werden:

user@client:~$ ssh-copy-id -i ~/.ssh/backup_key.pub user@server

Auch hier wird server und user wieder entsprechend angepasst.

Wir werden aufgefordert, den Zugang zu prüfen. Das machen wir folgendermaßen:

user@client:~$ ssh -i ~/.ssh/backup_key user@server

Falls nicht nach einem Passwort gefragt wurde, hat alles geklappt. Die Sitzung verlassen wir wieder mit “exit”.

Hier legen wir nun ein Verzeichnis an, in welches die Dateien gesichert werden sollen, z.B.:

user@client:~$ mkdir ~/backup

Synchronisation

Ab sofort sollte ein erstes Synchronisieren der Daten möglich sein:

user@client:~$ /usr/bin/rsync –delete -avze "ssh -i /home/user/.ssh/backup_key" user@server:/home/user ~/backup

Ein Paar Worte zum Befehl:

–delete sorgt dafür, dass Dateien , die am Quellort gelöscht wurden, auch am Zielort gelöscht werden
-a ist der Archiv-Modus, d.h. er behält alle Permissions, Symlinks, Zeiten, Besitzer und Gruppen bei
-v zeigt alle Dateien an, die übertragen werden.
-z überträgt die Dateien komprimiert
-e nutzen wir in diesem Fall, um die Übertragung über SSH laufen zu lassen.

user ist für die client- und server-Seite entsprechend anzupassen. Der Pfad hinter -i ist auf die client-Seite bezogen.

Der Pfad hinter user@server: ist der Remote Path, also der Pfad zu den zu sichernden Dateien auf dem server.

Die Ausführung kann eine ganze Zeit dauern, da beim ersten Aufruf noch alle Dateien übertragen werden müssen. Jeder folgende Aufruf vergleicht die Daten und überträgt nur die Veränderungen.

Hat das erfolgreich geklappt, kann ein Script geschrieben werden, wo wir den obigen Befehl eintragen:

#!/bin/bash
/usr/bin/rsync –delete -avze "ssh -i /home/user/.ssh/backup_key" user@server:/home/user ~/backup

Ich habe die Datei als /usr/bin/backup angelegt und mit

sudo chmod a+x /usr/bin/backup

ausführbar gemacht.

Ab sofort sollte der Aufruf von “backup” in der Konsole ausreichen.

Automatisierung

Fehlt nur noch ein Eintrag in der crontab, damit das Backup stündlich ausgeführt wird:

crontab -e

Folgende Zeile einfügen:

01 * * * * /usr/bin/backup

Die Zeit kann natürlich angepasst werden. In den meisten Fällen sollte auch ein tägliches Backup um 11:59 Uhr ausreichen:

59 11 * * * /usr/bin/backup

Schaut regelmäßig in /var/mail/user (user ist durch euren Benutzernamen zu ersetzen), ob Probleme aufgetreten sind.

sudo gedit /etc/X11/xorg.conf

Innerhalb von Section “InputDevice” folgende Zeilen hinzufügen:

Option      "ZAXisMapping" "4 5"
Option      "XAxisMapping" "6 7"
Option      "Emulate3Buttons" "true"
Option      "EmulateWheel" "on"
Option      "EmulateWheelButton" "2"

Speichern und X-Server neustarten (Strg+Alt+Backspace)

Über den Nutzen dieser Funktion lässt sich natürlich streiten und der Spott der Arbeitskollegen ist quasi einprogrammiert. Ich allerdings halte es für eine sinnvolle Funktion, denn immerhin hält sie einen von stundenlangen Computer-Sessions ab und bewegt einen dazu, das Chaos auf dem Schreibtisch zu beseitigen.

Sehr zur Freude der Ärzte, würden durch diese Funktion weniger Arbeitnehmer über Rückenprobleme klagen. Würde die Funktion nun auch noch abwechselnde Gymnastikübungen vorschlagen, wäre es doch eine runde Sache ;-)

Die Aktivierung dieser vorinstallierten Funktion ist so einfach wie die Funktion selbst:

Man klicke auf System -> Einstellungen -> Tastatur und wechselt zum Reiter “Tipppause”.

Tastatureinstellungen – Tipppause

Hier lassen sich auch die Intervalle der Pausen verändern. Für ganz Hartnäckige lässt sich sogar das Verschieben der Pause ausschalten.

Sobald es Zeit für ein Päuschen ist, wird sozusagen das Werkzeug fallen gelassen und der Bildschirm wird mit folgendem Countdown überlagert:

Mach ‘ne Pause: Noch 2 Minuten und 36 Sekunden