[UPDATE 1] WB7.eu – Freehostertest

Nach der gestrigen kurzen Chat-Konversation mit Sven (Nachname wird nicht genannt, es sei denn, Sven wünscht dies ;)), in welcher ich bloß eine kurze Bewertung brauchte, ging es erst richtig los: Der Hostertest. Paid-Hoster zu testen, war mir zu großer (finanzieller) Aufwand, da es in diesem Sektor auch einfach zu viele gibt. Aber bei Freehostern geht das etwas schneller. Der Reihe nach:

Irgendwann vor langer Zeit: Ich habe in irgendeiner Forum zu wenig zu tun, und ein sinnvolles Projekt muss her. Prompt in diesem Moment ruft mich ein Freund an, der neben diversen anderen Fragen auch wissen wollte, welchen Freehoster ich empfehlen kann. Ich empfehle ihm kurzerhand den ersten Freehoster, den ich bei Google fand, ich sagte ihm auch “Muss nicht der Beste sein, war eben der erste Treffer”. Ging auch 3 Monate gut, nur irgendwann fehlte dies und das.

Drei Monate später: Weitere Kreative Phase, nur 3 Monate nach dem Anruf. “Eine Idee muss her”. Suchen nach einem vernünftigen Freehoster-Test mit Gegenüberstellung? Fehlanzeige. Auf Anhieb nichts auffindbar. Viele Hoster haben auf ihren Seiten Uptime-Statistiken, aber ich teste das lieber selbst. Wie, kann ich erst verraten, wenn der Langzeit-Check vorbei ist, da ich ein paar Tricks einsetzen musste.

Montag, 18.02.2013: Ein schnelles Dokument mit einem Textverarbeitungsprogramm einer Firma aus Redmond. 15 Hoster. Erstes aussortieren: Dort muss zur Anmeldung Geld fließen. Raus. Der ist Englisch, deutscher Support sollte schon drin sein. Raus.

Dienstag, 19.02.2013: Zweite Phase: Von nun noch 10 übrig gebliebenen waren bei einem die weiteren Spezifikationen erst später sichtbar, welcher auf raus musste.

Weiterlesen

gitolite-Repos auf dem Uberspace per http veröffentlichen

Achtung: Ob man die Variable $USER an den Stellen, wo sie verwendet wird, auch wirklich nutzen sollte, habe ich nicht überprüft. Manuell den Nutzer eintragen ist sicherer.

Langer Titel, langer Weg dahin:

Alles fing damit an, dass “mal eben” zwei an einem Git-Repo arbeiten wollen, und da ich eben uberspace.de mag und dort Git zu Verfügung hatte, nutzten wir eben gitolite. Wir fingen an, doch bald stellte sich das erste Problem: Wie sollen andere das Repo “test.git” clonen? Wir können (dank dem SSH-Key) ja mal eben

git clone user@cetus.uberspace.de:test

machen, und haben halt einen Klon auf dem Rechner. Will man das ganze verlinken, kam Jonas als erstes die Idee, das Repo in einen für den Apachen erreichbaren Ordner zu verschieben und einen (wer hätte es gedacht) Link zu erstellen:

mkdir /var/www/virtual/$USER/git.$USER.cetus.uberspace.de
cd /var/www/virtual/$USER/git.$USER.cetus.uberspace.de
mv /home/$USER/repositories/test.git test.git
ln -s /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git /home/$USER/repositories/test.git

Wenn man jetzt aber versucht, das Repo zu clonen, wird das an einem 403 scheitern:

$ git clone http://git.user.cetus.uberspace.de/test.git
Cloning into 'test'...
error: The requested URL returned error: 403 while accessing http://git.user.cetus.uberspace.de/test.git/info/refs?service=git-upload-pack
fatal: HTTP request failed

Das liegt an der Berechtigung. Der Ordner /var/www/virtual/$USER/git.$USER.cetus.uberspace.de  hat von sich aus einen chmod von 700, und diverse Unterverzeichnisse bekommen den bei jedem push. Also jedes mal einen chmod setzen, ist sinnfrei. Damit alles funktioniert, braucht das Verzeichnis /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git  einen chmod von 705, und alle Unterordner und Dateien auch. Direkt nach dem erstellen des Repos sollte man es schon verschieben und diverse Handlungen vornehmen, auch vor dem ersten push. Als erstes wären da die update-server-infos , und der chmod:

cd /var/www/virtual/$USER/git.$USER.cetus.uberspace.de/test.git
Weiterlesen