siyman.de | blogging und GNU/*buntu – Backup

… spread the (s)word ;)

All posts in blog

Serverumzug

Posted on Author siymanPosted in *buntu, blogLeave a Reply

Nachdem mein Hoster netcup.de mich vor einem halben Jahr über die geplante Umstellung auf KVM anstelle von Linux vServer informiert hat, wurde ich nun rechtlich zwar sauber aber ethisch nicht ganz nett dazu genötigt, meinen Server zu migrieren. Damit das alles so wenig zeitaufwendig und komplikationslos wie möglich abläuft, ich aber kein Backup der Installation durchführen konnte, musste ich also alle Daten kopieren respektive adaptieren. Aber wo fängt man an, wo hört man auf, und wie hat man die geringste Last auf der eigenen Leitung – gerade beim Upload?

Zunächst habe ich meine Distribution gewechselt. Anstelle von Debian 6.0 Squeeze läuft nun ein Ubuntu Server 12.04.2 LTS. Warum? LTS! Damit habe ich theoretisch bis 2017 Ruhe vor einer neuen Migrationsrunde, und sollte das mit der Zwangsmigration bei netcup.de weiter so laufen, dann werde ich bis dahin auch immer wieder neue Hardware haben und kann dennoch bei der gleichen Installation bleiben.

Sodann habe ich überprüft, was der Server eigentlich macht, und entsprechend die Komponenten bei der neuen Installation via apt-get eingespielt. Für mich war das nicht mehr besonders viel, da der Server vor allem als Webserver dient: apache2, php5, mysql und einige Module derselben (SSL, curl, rewrite)

Hiernach ging es um die Frage der Daten. Wie bekomme ich nun alles vom einen auf den anderen Server, ohne mir dabei die Finger wund zu kopieren? Total einfach via SCP, insofern man Zugriff auf zwei SSH Server hat (was hier der Fall war). Dafür habe ich mich folgenden Tipps bedient:

MySQL-Transfer: “mysqldump –extended-insert –force –log-error=log.txt -uBENUTZER -pPASSWORT –all-databases | ssh -C BENUTZER@NEUERSERVER “mysql -uBENUTZER -pPASSWORT”

Datentransfer: “scp -rp DATEN NUTZER@SERVER:/VERZEICHNIS”

Einfach, nicht? Schon lag das gesamte /var/www sowie meine Home-Verzeichnisse samt MySQL-DB auf dem neuen Server. Was gab’s dann noch zu tun? SSL einrichten, zlib Compression in der php.ini steuern, .htaccess Datei anpassen, ownCloud testen, finito. Alles in allem hat das Übertragen der Daten via mysqldump und scp mir also vielfältige Arbeitsstunden erleichtert.

Jetzt geht es um’s Testen. Aber wie erreiche ich eigentlich den Server, wenn meine Domain die gleiche bleiben soll? Dafür ändere ich noch schnell die MX-Records auf die neue IP und flushe meinen Betriebssystem-Cache meines Produktivsystems, damit auch der neue Server erreichbar wird. Dafür gibt’s übrigens ein kleines Tool unter Ubuntu.

Übrigens: Das alles geschieht schon auf dem neuen Server, der alte ist bereits abgeschaltet. Vielleicht fällt mir ja nochmal etwas ein, was ich vergessen habe, wenn es den alten Server nicht mehr online gibt. Bis dahin sieht es sehr gut aus.

Gimps.de

Posted on Author siymanPosted in blogLeave a Reply

Ich mache ja ungern Werbung für irgendwelche Dinge noch will ich sie auf meiner Seite haben – ich mag einfach Werbefreiheit. Allerdings gibt es eine Seite, über die ich eben bei der Foto-Nachbearbeitung gestolpert bin: gimps.de

Hier gibt es kleine, nette und vor allen Dingen leicht nachvollziehbare Tutorials für die Nachbearbeitung mit Gimp. Alles nicht gerade aktuell (der letzte Beitrag datiert auf Mitte 2011), jedoch schön formuliert, gut bebildert und mit einfachsten Schritten erreicht man große Wirkung. Für Menschen wie mich ideal, die keine Ahnung von der digitalen Fotografie haben und doch öfter über unschöne, unscharfe und unechte Bilder stolpern.

Echte Empfehlung!

Von Thunderbird zu Kubuntu – Endlich natives PIM mit ownCloud und KDE

Posted on Author siymanPosted in *buntu, blog2 Replies

Vor einer ganzen Weile schon bin ich von Funambol auf ownCloud umgestiegen. Gründe dafür gibt es viele, der Hauptverdächtige war aber das Update- und Communityverhalten von Funambol – es existiert nicht. Außerdem war auch die Plugin-Situation für meine Exchange-Alternative Outlook minderwertig sowie eine Synchronisation mit Android abenteuerlich. Aus diesem Grund ging es zu ownCloud.

ownCloud selbst arbeitet dabei nicht als JAVA-, sondern bietet als Interface Webzugriff und fungiert als WebDAV-, CalDAV- und CardDAV-Server. Er ist ziemlich sicher, übersichtlich, komfortabel, funktional und vor allem SCHNELL. Zudem basiert er auf meinem vServer auf bereits eingerichteten Umgebungen und lässt sich leicht und sicher backupen sowie updaten.

Aber warum schreibe ich das hier? Weil ich bislang auch ownCloud über Thunderbird zugänglich gemacht habe. Nur ist das furchtbar – Synchronisation mit Kalendern und Kontakten funktioniert nur über Plugins, die selbst weder richtig gewartet werden noch korrekt funktionieren. Und das schlimmste: Der sowieso schon langsame Thunderbird geht bei einer einfachen Kalendersynchro in die Knie auf meinem i5; der Atom meines Netbooks wird unausstehlich.

Deshalb muss nun bei meinem KDE 4.9 endlich wieder KMail ran. Ich bin damals wegmigriert, weil mir Thunderbird auf allen Plattformen zur Verfügung steht, was bei KMail nur prinzipiell der Fall ist. Jedoch bin ich nun zufriedener denn je. Der Import funktioniert einfach: Über Extras -> Import-Assistent einfach alles auf Thunderbird migrieren und schon ist quasi alles wie gehabt. Die Kalender und das Adressbuch richtet man sich in Akonadi über diese Anleitung ein. Noch Fragen? Ich habe keine.

Übrigens dauert der Import bei großen Nachrichtenarchiven sehr lange – keine Sorge, der Import-Assistent arbeitet auch ohne direkte Rückmeldung. Nicht verzagen also, bei mir hat es eine gute Stunde gebraucht, weil ich aber auch Mails seit 2010 archiviere. Wichtig ist nur, dass ihr den Import auch entsprechend einschaltet – warum? Weil ich dazu erstmal einen Import-Ordner bestimmen müsst (das blaue Ordnersymbol bietet euch da die Auswahl) und danach auf Starten/Weiter klickt. Erst dann geht’s richtig los 😉

Philosophische Gedanken

Posted on Author siymanPosted in blogLeave a Reply

The need for public learning carries with it the need for a second kind of learning. If government is to learn to solve new public problems, it must also learn to create the systems for doing so and discard the structure and mechanisms grown up around old problems. (Schon 1973: 109)

Donald Schön sagt hiermit, was viele Politiker/Bürger in Deutschland aber auch in der EU und weltweit nicht sehen: Strukturen, welche geschaffen worden sind, um frühere Probleme zu lösen, müssen bei Zeiten auch wieder ersetzt/gestrichen werden. In meinen Augen ist aber das Ausbleiben solcher Reinigungen Grund für unsere bürokratischen Problemfelder aber auch für eine Vielzahl an Steuerverschwendungen. jm2c

Frohes Neues und ein glückliches Updaten mit Rechteproblemen

Posted on Author siymanPosted in blogLeave a Reply

Manchmal steht man vor einem Fiasko: Webserverumzug ohne Migrationsscript oder Hilfe. Man nimmt dann erstmal, was man kriegt. Ändert hier was, ändert da was, verschiebt Rechte großflächig und freut sich zunächst, dass einmal alles funktioniert. Aber halt! Was macht denn der FTP-User?

Dumm gelaufen. Jetzt aktualisiert WordPress nichts mehr, weder Plugins noch Themes noch das Hauptsystem selbst. Zwar sagen alle Aktualisierungen nach folgendem Muster

Runterladen der Aktualisierung von http://downloads.wordpress.org/plugin…
Entpacken der aktualisierten Version…
Die aktuelle Version wird installiert…
Die alte Version des Plugins wird entfernt…
Plugin erfolgreich aktualisiert.

doch kommt man zurück auf die Aktualisierungsseite und es ist dort, als wäre nichts gewesen. Diesen Prozess kann man unendliche Male durchführen und kommt dennoch nicht zu einem Ergebnis. Das Problem lag bei mir daran, dass sowohl der apache2-Serer (www-data) Schreib- und Ausführungsrechte in den WordPress-Ordnern brauchte als auch der FTP-User (ftpuser), welcher die Dateien zunächst in die Upgrade-Verzeichnisse schiebt.

Sodann bin ich hier auf eine sehr nette Lösung gestoßen, welche für meinen Debian-Server ohne Probleme funktioniert.

Dazu einfach nur den FTP-Nutzer in die www-data Gruppe des Webservers einfügen und die betreffenden Ordner in ihren Rechten neu zuweisen:

sudo gpasswd -a ftpuser www-data

sudo chown -R www-data:ftpgroup -R %Wordpressverzeichnisse

Das rekursive Setzen der Dateirechte (-R) ist nicht unbedingt erforderlich und kann sogar etwas hinderlich sein, war in meinem Fall allerdings nötig. Dass ftpuser und ftpgroup ebenfalls nur Platzhalter für die eigentlichen Nutzer und Gruppen sind, sollte sich ebenfalls von selbst verstehen.