Mein Rettungsboot ankert in Friedersdorf

Eigentlich will ich den Link einer Bastelanleitung in meinem Blog suchen. Aber nach dem Aufrufen der Seite erhalte ich nur eine Fehlermeldung. Irgendwas mit “Database Error” in Times New Roman, schwarz auf weiß. Immer wieder. Schlicht und hässlich.

Ich hab’s ja nicht so mit dem Programmieren in diesem Internet. Aber Database dürfte was mit einer Datenbank zu tun haben. Habe ich da nicht vor ein paar Tagen was gemacht? Ich hatte in den Datenbanken etwas gesehen, das auf eine uralte Domain hinwies, die ich schon lange nicht mehr habe. Ich stöberte ein bisschen in dieser Datenbank. Mir fiel aber nichts auf, das auf aktuelle Verwendung hindeutet. “Wollen Sie die Datenbank wirklich löschen?” - “Ja!” Weg isse.

Es fällt mir wie Schuppen von den Augen, dass es da evtl. doch noch eine Verbindung mit der alten Datenbank gegeben haben könnte, nämlich mit meinem Blog, als ich die Fehlermeldung sehe. Was soll’s. Spiele ich halt ein Backup ein. 

Ich stelle fest, dass das letzte Backup vom 3. Januar dieses Jahres ist. Da hat wohl was nicht funktioniert. Früher bekam ich Datenbank-Backups auch mal per Mail. Bekomme ich auch immer noch, aber nur zu anderen Webseiten, die ich so betreibe.  

Ich jammere etwas in der ständigen Redaktionskonferenz, und Kathrin fischt auch schon die alten Beiträge aus dem web archive für mich heraus. Damit könnte ich im Grunde alles in mühsamer Handarbeit wieder herstellen. Ich wage noch einen verzweifelten Rettungsversuch und schreibe um 8:54 Uhr an meinen Provider all inkl in Friedersdorf:

Hallo, anscheinend hab ich vorgestern oder Montag eine Datenbank in meinem Webspace gelöscht. Ich kenne vermutlich die Antwort, will aber sichergehen: Bei Ihnen gibt es nicht zufällig eine Datensicherung davon? Mein letztes Backup ist nicht ganz aktuell. Viele Grüße M. Winnninghoff

Nach nur 10 Minuten erreicht mich die Antwort:

Sehr geehrter Herr Winninghoff, vielen Dank für Ihre Anfrage. Es wurde in den letzten Tagen nur eine Datenbank gelöscht, diese haben wir wiederhergestellt. Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen Supportteam

In gerade mal 10 Minuten hat all-inkl mein Blog gerettet und mir geantwortet! Nicht nur ich, sondern die gesamte Redaktionskonferenz ist zu Tränen gerührt. Ich installiere dann schnell ein neues Backup-Tool. 

.@ReinisNitissRX moves to @allinklracing with New Seat Ibıza

Latvia’s Reinis Nitiss will drive for German squad ALL-INKL.COM Muennich Motorsport in the 2016 FIA World Rallycross Championship presented by Monster Energy. Announced on Latvian television earlier today , Nitiss will contest all 12 rounds of the Championship in a brand new Seat Ibiza RX Supercar. Having spent the past two World RX seasons driving for Ford Olsbergs MSE, Nitiss has amassed seven…

1. Vorbereitung

Wichtig ist, dass die ersten beiden Schritte meines SSH und all-Inkl-Tutorials bereits ausgeführt wurden. Ebenso setze ich voraus, dass bereits das Repository auf BitBucket angelegt wurde und ebenfalls lokal existiert.

2. Vorbereitung

Wir loggen uns per SSH auf dem all-inkl-Server ein und erstellen uns SSH-Keys. Diese sind wichtig, um auf das auf BitBucket hinterlegte Git-Verzeichnis zugreifen zu können. Ich persönlich empfehle einen Key ohne Passphrase, da all-inkl sonst immer Fehler meldet (falls jemand dieses Problem lösen sollte, bitte immer her mit den Infos!). Da diese Anleitung höchstwahrscheinlich genauso für GitHub funktioniert, verweise ich noch einmal auf deren Anleitung.

# Wir wechseln in das SSH-Verzeichnis cd ~/.ssh # Der Key wird generiert ssh-keygen -t rsa -C "[email protected]" # Wir lassen uns den Key anzeigen und kopieren ihn anschließend manuell in unsere Zwischenablage cat id_rsa.pub

Nachdem dieser auf dem Server generiert wurde, muss er noch auf BitBucket im Verzeichnis hinterlegt werden. Dazu wechselt man in die Administration seines Projekts, klickt auf „Deployment Keys” und fügt einen neuen Eintrag hinzu. Der Name ist egal, wichtig ist nur, dass wir den Key einfügen. Damit wir jedoch tatsächlich später auf das Repo zugreifen können, müssen wir zuerst BitBucket unserer ~/.ssh/known_hosts hinzufügen. Ich klone dabei einmal alle vorhandenen Daten und habe so einen Live-Test, ob tatsächlich alles funktioniert:

# Wechsle in den Root cd ~ # Klone das Repo von BitBucket git clone [email protected]:USERNAME/Repo.git # Lösche diese Daten nach Erfolg rm -rf Repo.git

3. Capistrano-Deployment

Erneut muss zuerst Capistrano initialisiert werden:

capify .

Die eben angelegte Datei config/deploy.rb kann nun auf unsere Bedürfnisse angepasst werden:

# Unsere Repo-URL auf BitBucket set :repository, '[email protected]:USERNAME/Repo.git' # Der Branch, aus dem wir deployen möchten set :branch , 'master' # Unsere Domain set :domain , 'server.tld' # SSH-Nutzer set :user , 'ssh-w00000x' # Server-Pfad set :deploy_to, '/www/htdocs/w00000x/' # Nutze kein Sudo, da all-inkl dieses verbietet set :use_sudo , false # Standard-Rechte role :website, domain, :primary => true

Inspiriert dadurch, dass Dennis für sein Ausbildungsprojekt seine Webseiten bei all-inkl per Capistrano „deployt”, wollte ich mir dieses System auch für meine eigenen Webseiten einrichten.

Bei empuxa nutzen wir Gitolite zur einfachen Administration der Repositories und schieben diese dann per Capistrano auf die entsprechenden Server. Das ist unglaublich bequem, spart viel Zeit und Energie und ist nicht so fehleranfällig wie das händische Hochladen per FTP. Passt man dann noch die Konfigurationsdateien entsprechend an, dann kann man auch direkt Dateien komprimieren etc.

1. Vorbereitung

Der SSH-Zugang ist bei all-inkl leider erst ab dem Premiumpaket möglich. Hat man dieses gebucht, so muss im KAS für jeden Account einzeln die SSH-Verbindung aktiviert werden. Die Bereitstellung dauert in der Regel nur ein paar Minuten und dann kann losgelegt werden.

2. Konfiguration SSH

Wie auf all-inkl beschrieben, loggen wir uns zuerst mit unserem eben erstellten Nutzer und unserem Passwort ein. Die (erste und hoffentlich letzte) Passwortabfrage erfolgt nach Eingabe des folgenden Kommandos:

ssh [email protected]

Jeder, der bereits einen SSH Public Key besitzt, sollte diesen nun der Einfachheit halber auf dem Server ablegen. Wir erstellen also erst einmal eine entsprechende Datei:

cd ~ cd .ssh touch authorized_keys

Anschließend fügt man seinen eigenen Key mit dem Texteditor seiner Wahl ein. Ich benutze Nano für solche Aktionen.

nano authorized_keys

Ist der Code eingefügt kann man sich in Zukunft einfach ohne die Passwortabfrage einloggen.

3. Einrichtung von Git

Bevor auf dem Server Git initialisiert wird, sollte man zuerst eine gute Struktur schaffen. Ich habe mich dazu entschieden, die Repositories in mein Rootverzeichnis zu legen. All-inkl warnt mich zwar, dass alle meine Daten flöten gehen könnten, da ich jedoch keinen Serverumzug plane und auch hoffe, dass sie das nicht so einfach tun werden, probiere ich es einfach mal aus. Für Erfahrungen und Anregungen wäre ich sehr dankbar.

Im ersten Schritt muss das Git-Verzeichnis angelegt werden:

cd ~ git init --bare VERZEICHNISNAME.git

Nachdem wir das Verzeichnis nun auf dem Server erstellt haben, müssen wir dieses noch lokal initialisieren. Dazu wechseln wir in unseren gewünschten Ordner und geben folgendes ein:

git init git add * git commit -m 'First commit' git remote add origin [email protected]:VERZEICHNISNAME.git git push -u origin master

Git ist nun voll funktionsfähig.

4. Einrichtung Capistrano

Capistrano ist Ruby geschrieben und kann als RubyGem verwendet werden. Alle Informationen zur Installation findet man auf GitHub. Um Capistrano für unser Projekt einzurichten gehen wir in unser lokales Repository und führen folgenden Befehl aus:

capify .

Durch diesen Befehl wurden nun die Datei CAPFILE und ein Ordner names config erstellt. In dem Ordner befindet sich zudem eine weitere Datei mit Namen deploy.rb. Am besten löscht man alle vorhandenen Einträge und gibt folgendes ein:

# Pfad zum Git auf dem Server set :repository, 'file:///VERZEICHNISNAME.git'  # Eure Domain set :domain , 'domain.tld # SSH-Nutzer set :user , 'ssh-w00000x'  # Verwendung von Git set :scm , 'git' # All-inkl braucht den Hinweis, dass der Code lokal ist. set :local_repository, 'file://.'  # Der Branch, aus dem wir deployen möchten set :branch , 'master' #  # Wir benötigen keinen Sudo-Nutzer set :use_sudo , false  # Verzeichnis, in das wir deployen möchten set :deploy_to, '/www/htdocs/w00000x/' # Login via SSH-Keys (s.o.) ssh_options[:forward_agent] = true # Nur auf diese Seite deployen role :website, domain, :primary => true

Unsere deploy.rb ist nun soweit vorbereitet. Im nächsten Schritt müssen wir den Server auf das Deployment vorbereiten. Der folgende Befehl übernimmt die Einrichtung auf dem Server:

cap deploy:setup

Auf dem Server erscheinen nun drei Ordner im Zielordner: current, shared und releases. Um nun den Code auf unseren Server zu laden müssen wir nur noch folgenden Befehl ausführen:

cap deploy

Unsere Webseite ist nun unter domain.tld/current in der neusten Version erreichbar. Da ich persönlich URLs in diesem Format nicht mag, habe ich mich erneut ins KAS eingeloggt und verweise die Domains direkt auf das Verzeichnis current. So habe ich nun immer den neusten Stand meiner Software erreichbar und der eigentliche Benutzer sieht keinen Unterschied.

Gestern habe ich den Server Umzug vorbereitet. Nachdem mir mein alter Provider viel zu langsam geworden ist, hatte ich mich entschlossen, zu einem deutschen, schnelleren Provider zu wechseln. Die Datenbank mit all den ganzen Artikeln, Fotos und Verweisen habe ich also gesichert und an neuer Stelle importiert. Aktuell noch unter einer anderen Domain, die ich hier aber nicht bekannt geben werde, da…