Ich wollte nur [...] und dann ist das Universum explodiert.

Projects
Books
Archive
About









    Permalink
  1. Git and the Unix philosophy

    Mein Feedreader hat heute einen Post von Julius ausgespuckt, den ich so gut fand, dass ich ihn hier rezitieren möchte.

    Git follows Linux’s philosophy of refusing to protect you from yourself. Much like Linux, Git will sit back and watch you fuck your shit right up, and then laugh at you as you try to get your world back to a state where up is up and down is down. As far as source control goes, not a lot of people are used to this kind of free love.

    Ich rezitierte also Julius Zitat. Blogpost-Inception?


  2. Permalink
  3. Abschlussprüfung | Zentrales Versionskontrollsystem mit git und etckeeper

    Nachdem ich letzten Donnerstag erfolgreich meine Ausbildung zum Fachinformatiker abgeschlossen habe, kann ich die dazugehörige Dokumentation / Präsentation hier veröffentlichen.

    Dokumentation

    Präsentation

    Zu danken habe ich dabei hauptsächlich all den wunderbaren OpenSource Tools, die mir zur Erstellung und Umsetzung gedient haben. Um einige zu nennen:

    • LaTeX bzw. TeX-Live (Dokumentation)
    • HTML & Slidy (Präsentation)
    • git (Projektinhalt)
    • etckeeper von Joey Hess (Projektinhalt)
    • gitolite (Projektinhalt)
    • und natürlich allen Debian Developern, die die genannte Software paketiert haben :)

  4. Permalink
  5. Minecraft + Git + Bash = <3

    Seit mittlerweile erstaunlich langer Zeit spiele ich Minecraft. Minecraft hält seine Daten in ~/.minecraft vor. Also Levels, Statistiken, Items. Das Minecraft Home Directory unter Versionskontolle zu stellen hat unter Umständen mehrere Vorteile, die ich hier kurz erläutern möchte :)

    Initiales Setup

    Als erstes muss das Verzeichnis initial eingerichtet werden. Initialisierung, hinzufügen aller Dateien und ersten Commit erstellen.

    $ cd $HOME/.minecraft
    $ git init
    $ git add .
    $ git commit -a -m "Initialer Commit"

    Spielstände manuell Laden und Verwalten (Commits)

    Einer der gravierendsten Vorteile. Wer wie ich oft an Klippen hinunter stürzt oder an einem (oder auch mehreren :P ) Creeper(n) scheitert wird das bestätigen können. Einmal gefallen/gestorben gibt es kein zurück mehr. Bis jetzt.

    Die hypothetische “Herausforderung” scheint sich gerade aufzutun. Ob jetzt Creeper, Berg oder sonst was ist erstmal egal. Könnte auf jeden Fall kritisch für meinen Minecraft Character enden.

    $ git commit -a -m "Ob man den Sprung ueberlebt?"

    Nach einem kurzen Tab in die Konsole, sollte das Spiel erstmal gesichert sein und ich kann den Sprung wagen.

    Anscheinend überlebt man nicht, aber genau das war auch der kritische Punkt. Genau jetzt bin ich in der Lage meinen alten Spielstand wiederherzustellen. Mit nachfolgendem Kommando verwerfe ich alle seit dem letzten Commit entstandenen Änderungen an meinem Spielstand. Vorher dringend aufs Minecraft Titelmenü zurückkehren!

    $ git stash
    # Update
    # oder alternativ:
    $ git checkout -f

    Dieses Szenario lässt sich nicht nur auf gerade geschehene Ereignisse abbilden sondern auch zwischen Commits die längere Zeit her sind. Wenn nach einer halben Stunde/einem Monat klar wird, das der Minecraft Char gerade nur Müll verzapft hat, kann auch zwischen mehrere Commits hin und her gesprungen werden. Mit welchen git Kommandos das bewerkstelligt wird, bleibt jedem selbst überlassen.

    git-revert macht den letzten Commit rückgängig, erstellt dabei einen neuen in dem die Änderungen enthalten sind. Das ist in soweit gefährlich, dass zwischenliegende Commits unberührt bleiben und eventuell in einen großen Haufen Datenmüll zerfallen(!). Eher Anwendung für den “Warp” an einen früheren Zeitpunkt X findet daher git-reset.

    $ git reset 66a2594
    # oder
    $ git reset HEAD^

    Das Working Directory wird damit auf einen Stand gebracht, wie es zum Zeitpunkt des angegebenen Commits aussah. Dieser kann somit auch weiter in der Vergangenheit liegen.

    Automatische Speicherung (Bash-Einzeiler)

    Allerdings muss ich zugeben, dass diese Praxis relativ schnell aufwendig wird. Immer zwischen Fenstern hin und her zappen ist ja auf Dauer auch eher zermürbend. Daher habe ich mir diese “Arbeit” von einer kleinen Bash Zeile abnehmen lassen.

    $ SEKUNDEN=10 ; while true ; do git add . ; git commit -a -m "AutoSave $(date)" ; sleep $SEKUNDEN ; done

    Ich denke es ist Geschmacksache wie oft bzw. in welcher Frequenz die Commits abgesetzt werden können. Bis jetzt bin ich mit ca 300 Sekunden (5 Minuten) am besten Gefahren. Die Commits rieseln vor sich hin und beeinträchtigen so in keinster Weise den Spielfluss.

    [master bf9dd85] AutoSave Mo 4. Jul 19:56:17 CEST 2011
    4 files changed, 15 insertions(+), 12 deletions(-)
    rewrite saves/0pen_Running/level.dat (100%)
    rewrite saves/0pen_Running/level.dat_old (100%)
    [master 5ddedc8] AutoSave Mo 4. Jul 19:56:27 CEST 2011
    4 files changed, 17 insertions(+), 19 deletions(-)
    rewrite saves/0pen_Running/level.dat (100%)
    rewrite saves/0pen_Running/level.dat_old (100%)
    [master 2d33023] AutoSave Mo 4. Jul 19:56:37 CEST 2011
    4 files changed, 10 insertions(+), 11 deletions(-)
    rewrite saves/0pen_Running/level.dat (100%)
    rewrite saves/0pen_Running/level.dat_old (100%)

    Parallele Welten (Branches)

    Um einfach mal ein Anwendungsbeispiel zu nennen: Wer in seinem virtuellen Minecraft-Keller mal raue Mengen an TNT gebunkert hat, möchte es nach Möglichkeit auch mal benutzen, right? Aber danach das ganze Dorf wieder aufbauen? Nee… Branching!

    Das ist der Punkt an dem die Geschichte der lokalen Minecraft Map sich in zwei Teile spaltet. In einer wird das eigene Bauwerk Sodom und Gomorra mäßig untergehen und in der anderen weiterhin existierenden Welt tollen sich Pigs und Sheeps in Minecarts herum. Die Abzweigung lässt sich wie folgt bewerkstelligen.

    $ git branch blowup
    $ git checkout blowup

    Jetzt kann man in aller Seelen Ruhe TNT verteilen und auch mal Destroyer statt Builder spielen. Tipp: Commit vor der Sprengung setzen :P Explosion immer und immer wieder von vorne genießen ;) Bemerkenswert sind außerdem die unterschiedlichen Abläufe von ein und der selben Explosion, aber dazu vielleicht wann anders ein Blogpost. Irgendwann wird aber auch das dann zur Routine und man wechselt via

    $ git checkout master

    wieder zu den Schäfchen. Der Branch “blowup” bleibt aber bestehen und lässt sich auch nach weiteren Spielständen immer wieder herbeirufen. Ich habe mittlerweile eine Art Branchset meiner “Lieblingssituationen” im Game, die ich immer wieder durchspielen kann, wie es mir gerade gefällt. Und nein es sind nicht immer nur Explosionen :)

    Networking, Baby! (Remotes)

    Mein Minecraft Setup mit allen Einstellungen und Spielständen zentral an einem Ort zu haben war ehrlich gesagt meine erste Motivation git einzusetzen. Ich spiele Minecraft auf 3 verschiedenen Maschinen (Ubuntu, Debian und sogar Mac OSX) und wollte keine 3 unterschiedlichen Maps pflegen müssen. Deshalb fing ich an auf meinem Server zwischen zu lagern. Ein eigens laufender git-Server ist hier aber Vorraussetzung! Freies Hosting bei beispielsweise Github fällt wegen der großen Datenmengen (ca. 300MB bei mir derzeit) und der fehlenden Privatsphäre flach. Remote-Server hinterlegen und aktuellen Stand pushen:

    $ git remote add origin git@gitserver.com:minecraft
    $ git push origin master

    Remote-Server auf anderen hosts klonen:

    # Ubuntu/Debian
    $ git clone git@gitserver.com:minecraft $HOME/.minecraft
    # Mac OSX
    $ git clone git@gitserver.com:minecraft $HOME/Library/Application\ Support/minecraft

    At least

    Ich möchte nicht sagen, dass dies hier der ultimative Weg zum heiligen Gral in Minecraft ist. Manchmal weckt eben diese erzeugte “Sicherheit” durch den Reset eine gewisse “Wayne…” Einstellung in einem, die dem Spielspaß ein Kleinwenig den kitzel raubt. Gerade am Anfang hat es mir aber extrem geholfen, nicht bei jedem Wipe alle Items zu verlieren oder sich nach einem Ausflug in den Wald wieder “zurück warpen” zu können.

    Auf weitere Ideen im Umgang mit Minecraft und Git freue ich mich natürlich wie immer :)


  6. Permalink
  7. statistical | Statistiken visualisieren im Terminal

    Mir erschien es einen kurzen Moment lang für sinnvoll ein kleines Shell Tool zu haben, welches mir aus einer Liste von Key:Value Paaren eine Balkenstatistik baut und visualisiert. Wie in etwa $ statistical john:12 alice:5 linus:7 bob:1. Mir gefiel die Idee einfach alles mögliche in meinem Terminal ansehen zu können.

    Relativ schnell stieß ich aber an eine Grenze. Diese hieß “Windowsize”. Ich konnte nicht ohne bedenken eine Schleife die die Value Werte zählt bauen, die dementsprechend viele Zeichen anhängt. Denn bei Zahlen >10000 wird das ziemlich unlesbar :)

     while [ $COUNTER -lt $VALUE ]; do
            ((COUNTER++))
            echo -n "$OUTPUTCHAR"
            if [ $COUNTER -ge $VALUE ]; then
                echo
            fi
        done

    Ich brauchte ein Schema, welches alle Werte einließt und eine skalierbare Basis für alle Werte schafft. Ich entschied mich für eine simple Lösung.

    while [ ${FACTORCOUNT} -lt $(( ${#MAXVALUE} - 2 )) ]; do
    FACTOR="${FACTOR}0"
        ((FACTORCOUNT++))
    done
    

    Letztenendes kam dann folgendes Verhalten bei meinem Key:Value Statistik Script raus. Ich mags.

    # Beispiel
    $ statistical john:433 alice:49 linus:12 bob:231
    john    |###########################################
    alice   |####
    linus   |#
    bob     |#######################

    Damit lassen sich sogar teilweise sinnvolle Sachen produzieren. Zum Beispiel die Anzahl der Commits innerhalb eines Git-Repositories. Ich habe hier als Beispiel mal bash-it aufgeführt:

    for a in $(git shortlog -sn --all | cut -f2 | cut -f1 -d' '); do echo -n "$a:" ; git log $LOGOPTS --all --numstat --format="%n" --author=$a | cut -f3 | sort -iu | wc -l; done  | statistical
    Mark          |##################
    Robert        |#########################################################################
    Florian       |##############
    Jesus         |######
    John          |##############
    Rich          |########
    Piotr         |###
    Travis        |####
    Fedyashev     |##
    zerobearing2  |####
    Andy          |###
    Daniel        |####
    Jeff          |##
    Karl          |##
    Robert        |#########################################################################
    Sirupsen      |##
    

    Sollte jemand Interesse daran hegen, das Skript auch mal auszuprobieren es befindet sich wie immer auf Github: http://github.com/noqqe/statistical


  8. Permalink
  9. Persönlicher Eindruck | Chemnitzer Linux Tage 2011

    Nachdem mich die Vorträge letztes Jahr so beeindruckt haben, hab ich mich auch dieses Jahr wieder entschieden die Linux Tage in Chemnitz zu besuchen. Durch einen Ausfall im Debian Team, hatte mir mein Kollege angeboten anstelle des ausgefallenen Mitglieds bei Debian mitzufahren. Was sich im Endeffekt als sehr nice herausstellte.

     

    Freitag

    Freitag war relativ entspannt. Ankunft und Aufbau des Debian Standes, mexikanisches Essen und danach Treffen mit Ben und Bier auf der Opening Party in der Mensa. Die Turnmatten in der Turnhalle waren auch kuschlig :)

    Samstag

    • Frühstück @ Catering-Tage – Sehr leckere Sachen.
    • 1. Vortrag: Storage – Aber richtig von Martin Gerhard Loschwitz. Fand ich persönlich interessant, gerade der iSCSI-DRBD-Ansatz um FibreChannel zu ersetzen gefiel mir sehr gut.
    • 2. Vortrag: Provokante Thesen zur IT-Administration von Peer Heinlein Ja, Herr Heinlein. Der Autor des Buchs, welches mich durch die LPIC-1 Prüfung geführt hat sinnierte auf eher komödiantische Art über die typischen Eigenschaften der IT-Dienstleistungsbranche. Hat allerdings Spaß gemacht zuzuhören.
    • Danach Pause. Erstmal durch die Stände gestöbert, die mittlerweile so gut wie vollzählig anwesend waren. Währenddessen ausgeknobelt, ob der nächste Vortrag Icinga oder Configs mit Git verwalten wird.
    • 3. Vortrag: Konfigurationsdateien mit Git verwalten von Julius Plenz. Mit bash-it benutze ich ja bereits eine Lösung die für mich zur Verwaltung Teile meines /home gut funktioniert. Aber es schadet ja nie, sich andere Taktiken anzusehen und daraus zu lernen. Genau das habe ich auch erreicht. Julius hatte ein sinnvolles zwei Branches Modell, mit denen er lokale und globale Änderungen seiner Konfigurationsdateien verwaltet. Disziplin und etwas Aufwand sind dafür allerdings nötig. (http://chemnitzer.linux-tage.de/2011/vortraege/folien/782-config-management.pdf)
    • Hungerbedingt verpasste ich den Vortrag über von C.  Klostermann über Professionelle IT Dokumentation – Anforderungen aus rechtlicher Sicht Mittagsbuffet schaffte aber Abhilfe.
    • 4. Vortrag: Von H. Uhlig Dem Hack keine Chance: LAMP sicher betreiben: erwieß sich grade als Administrator von Shared Hosting Systemen als hilfreich und informativ.
    • 5. Vortrag: A. Scherbaum: Datenbanken von MySQL zu PostgreSQL portieren: Hierzu muss ich sagen, dass ich mir den Ansatz etwas Administrativer vorgestellt habe. Die Feinheiten der Möglichkeiten fernab vom SQL Standart von MySQL und PostgreSQL wurden aber schön ausgeführt und beschrieben. Persönlich aber muss ich gestehen, nicht sagen zu können ob PostgreSQL (abgesehen von dieser Oracle Sache) besser ist als MySQL. Es scheint eben anders zu sein.
    • 6. Vortrag: P. Heinlein: SPF, DKIM und Greylisting – Was bringen Absender-Authentifizierung und der neue Spam-Schutz? : Nochmal Herr Heinlein, diesmal über SPF und DKIM als Spam-Schutz sinnierend. Aufklärend auf jedenfall, da ich die beiden Funktionen garnicht kannte und gegen Ende noch 2-12 Worte über Greylisting. Alles in Allem Runde Sache
    • 7. Vortrag: T. Winde: Mit dem Midnight Commander Freiheit leben: Hauptsächlich hat mich Jan’s Vorliebe für MC in diesen Vortrag getrieben. Es war schön zu sehen, nicht nur Vorträgen von Business-Guys auf den Linux Tagen zu sehen. Ein fast schon “goldiger” Vortrag eines älteren Taxi-Unternehmers, der mir trotz geringem Lernerfolg irgendwie gefiel.
    • Social Event: Wunderbares Buffet mit reichlich zu trinken und zu Essen. Hat im Endeffekt genau dem gedient, für was es gut war. Bier, Essen & Social’n.

     

    Sonntag

    • 8. Vortrag: Sonntag begann nach einer  weiteren Turnhallen-Nacht mit einem Vortrag von S. Kemter: Höher, Schneller, Weiter – openSUSE 11.4 : Der auch als Buergermeister von Karl-Tux-Stadt.de bekannte Redner, gab sich größte Mühe im Einsteigerforum das neue openSUSE, sowie die LTS, stable und unstable Linien vorzustellen.
    • 9. Vortrag: Von Andreas Tille Ein Jahr OpenStreetMap: Im Einsteigerforum ging es dann für mich auch gleich weiter mit einem (für mich komplett unbekannten) Thema. OpenStreetMap und seine Anwendung. Andreas, der selbst erst ca. 1 Jahr mit OpenStreetMap arbeitet, klärte die Zuhörer über all das auf, was er gerne von Anfang an über das Projekt gewusst hätte. War sehr schön gemacht und hat mir super gefallen. Dem ansonsten überfüllten Raum scheinbar auch.
    • 10. Vortrag: H. Voß Erstellung großer und größter Dokumente mit dem Satzsystem TeX: Ich muss sagen das meine Definition von “große Dokumente” ca. 1000 Seiten vor dem begonnen hatte die der Redner als große Dokumente definierte. Wenn so ein LaTeX Dokument mal länger läuft, als ein Kaffee hält, ist es eben viel :)
    • Mittags ließ ich mich dann von Julius (vom Git-Vortrag) nochmal einen Schritt in Zsh einführen, da sich am Social-Event rausgestellt hat, das er der Autor von Zsh beim OpenPress Verlag ist. Gab ehrlichgesagt vieles, bei dem ich nicht schlecht geschaut hab. … Wenn ich noch Zeit fände mir das alles einzuprägen… :)
    • 11. Vortrag: J. Kubieziel: Tor Bridges — Eine Brücke für freie Information: Danach ließ ich mich dann über die Risiken und Nebenwirkungen von Tor-Bridges aufklären. War sehr aufschlussreich. Langfristiges Interesse == unvermeidbar ;)
    • Stand abbauen – Ab nach Hause ;)

    Im großen und ganzen war es wirklich sehr schön und interessant, viele Leute und Projekte näher kennenzulernen. Die Zahl der Projekte die mich interessieren ist wiedermal gewachsen, die Zahl für die ich die Energie/Zeit habe mich auseinanderzusetzen bleibt aber leider wie immer gleich.

    Und gerade als ich mich daran gewöhnt habe, dass am Rednerpult intelligente Leute stehen die Ahnung haben von dem was Sie tun, muss ich wieder in die Schule. Bäm Montag.


  10. Permalink
  11. bash-it | n0qorg theme und git_info

    Um die Entwicklung des Bash Community Frameworks bash-it noch zusätzlich etwas vorran zu treiben, hab ich ein neues Theme und git_info  bereitgestellt.

    n0qorg theme

    Schema: host directory (git-status dirty)>
    Bis jetzt noch nicht gemerged. Denke aber das kommt noch. Theme @ Github

    git_info Funktion

    Gibt Übersicht über das aktuelle Repo. Ab jetzt im Framework vorhanden.


  12. Permalink
  13. github | Sinn, Unsinn, Interfaces und schon wieder Zombies

    github ist da wo ich mich momentan sehr gerne rumtreibe.

    http://www.flickr.com/photos/jeremykendall/

    creative commons @ jeremy kendall on flickr

    Unsinn

    Dort gibt es viele Projekte die mich interessieren, ich ihnen aber trotzdem nicht folgen kann. Dazu gehören unter anderem:

    diaspora/diaspora
    gothfox/Tiny-Tiny-RSS
    github/gitignore

    Das ist so weil diese Repo’s _so viel_ Aktivität aufweisen, dass ich von keinem anderen meiner Projekte (auch nicht meiner eigenen) Meldungen mehr mitbekomme. Ich meine, wieso kann ich nicht regulieren? Wieso lassen sich Aktivitäten pro Projekt nicht zusammenfassen? Jeder Pull Request, Kommentar oder Issue wird mir direkt in meine TimeLine gepushed. Und das bei Diaspora, bei dem am Tag alleine >30 Commits passieren? Warum habe ich nicht die Möglichkeit mir nur die Aktivitäten meiner Repos anzeigen zu lassen? Denke die Jungs von Github müssen erst noch lernen solche hyperaktiven anständig mit der Plattform zu handlen. Sollte jemand die nötigen Links für mich haben, bitte immer her damit.

    Sinn

    Andererseits nehme ich auch an ein paar wirklich schönen Sachen teil. Unter anderem bash-it. Das Framework ist etwas, wo ich mir nichtmehr vorstellen kann vorher ohne ausgekommen zu sein.

    revans/bash-it
    jgoerzen/twidge

    Zombies

    Was ich außerdem verblüffend finde ist, dass wirklich jemand eines meiner eigenen Projekte interessant fand. Nämlich genau das, dass ich für den größten Quatsch halte. TaurusOlson hat auf Anhieb ein einwandfreies Modul und eine neue Lib für das zombie-revolution-environment geschrieben. O_o


  14. Permalink
  15. Bash | the zombie-revolution-environment

    Wer kennt eigentlich noch MUD‘s? Diese textbasierten Rollenspiele über Telnet. Uralt und genau genommen dürfte mir das auch nichts sagen, denn das war vor meiner Zeit.

    Wie dem auch sei. Vor kurzem saß ich nachts vor meiner Shell und suchte irgendeine Ablenkung. Dachte dann an ein Python Projekt, welches ich zusammen mit Chris vor ca. 2 Jahren mal aufgegriffen hatte. Ich fand die Idee damals schon gut, aber es mangelte einfach an Python Kenntnissen.

    Ich habe dann (auch wenn es schon spät war) versucht, das nochmal in Bash abzubilden. Nur ein bisschen interessanter. Eine kleine Welt kam dabei heraus, wie schon damals ausgedacht. In dieser Welt passieren Dinge, die durch Zufall ausgewählt und gewichtet werden, was sich auf die Bewohner dieser “Welt” auswirkt. In meiner jetzigen Version sollte allerdings bisschen was passieren. Irgendwer musste da kämpfen oder sowas. Ich ließ also Zombies und Humans auf dieser Welt gemeinsam leben. Es werden neue Lebewesen geboren, sie sterben wieder, greifen einander an und so weiter.

    Im Klartext habe ich nichts anderes in dieses Bash-Script gepackt als die Anzahl der Menschen/Zombies auf der Welt und eine Hand voll Funktionen definiert, die “Events” darstellen, die von einer Schleife und einem Case bei jeder Runde zufällig ausgewählt werden. Das war’s auch schon. Eigentlich hat mich mehr der Grad an Zufälligkeit interessiert, der den Verlauf der erstellten Welt beeinflusst, wie viele Zombies greifen wie viele Menschen auf einer imaginären Farm an, können sich die Menschen wehren oder werden Sie von der Übermacht der Zombies einfach überrannt? Wie viele Opfer gibt es? Wer rottet wen zuerst aus?

    Das war letzten Endes auch der Punkt der mich an ZRE (so hab ich das Script genannt) immernoch unterhält und amüsiert. Jedesmal wenn ich es starte, beginnt ein total neuer Verlauf dieser Welt, wer wann wo wen angreift und letzten Endes besiegt.

    Ich hab das zombie-revolution-environment auf github hochgeladen. Ich weiss nicht wirklich was es ist, aber es unterhält mich.

    http://github.com/noqqe/zombie-revolution-environment
    zombie-revolution-environment als RAW.

    Usage ist relativ einfach.

    $ wget http://github.com/noqqe/zombie-revolution-environment/raw/master/zre.bash
    $ ./zre.bash

    Ein beispielhafter Verlauf klemmt auch in dem github Repository.

    Für neue Ideen, Bugreports, Meinungen, Flamewars oder Shitstorms bin ich wie immer dankbar.


  16. Permalink
  17. Git | Verschiedene Repos zusammenführen

    In einem Anfall des Ordnungswahns entschloss ich mich im Mai (oder einem deren anderen 11 Monate des letzten Jahres) dazu, mein textbasiertes Wiki, meine Dotfiles und meine Scripte in separaten Git-Repos zu verwalten und zu verteilen. Mit der Zeit merkt man aber, dass das ziemlicher Unsinn war.

    Kurz: Ich brauchte eine Lösung, wie ich alle 3 Repositories (ohne History-Verlust) zusammen gemerged bekomme.

    /repos/
    |-- dotfiles.git
    |-- scripts.git
    `-- wiki.git

    Hierfür hat Zrajm C Akfohg schon eine wunderbare schnelle Lösung gefunden.
    Zuerst ein neues Repo erstellen:

    mkdir ~/repos/noqqe.git
    cd ~/repos/noqqe.git
    git init

    Im Grunde wird jedes Repository in einen separaten Branch gefetched:

    git fetch ~/repos/dotfiles master:dotfiles
    mkdir dotfiles #Subdir fuer dotfiles

    Um die Files im neuen Branch jetzt in einen Unterordner umzumappen hat Zrajm auch einen wunderbaren Weg gefunden:

    SUBDIR_NAME=dotfiles
    BRANCH_NAME=dotfiles
    git filter-branch --index-filter \
        'git ls-files -s | \
            sed "s-\t-&'"$SUBDIR_NAME"'/-" | \
            GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && \
            mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE
        ' "$BRANCH_NAME"

    Wenn alles erfolgreich war, kann man den neuen Branch mit dem Master zusammenführen:

    git merge dotfiles

    und das Spiel wie beschrieben von vorne beginnen.


  18. Permalink
  19. Gitosis | Zweischneidigkeit des Auth-Verfahrens

    Ein Nachtrag und zugleich ein ganz besonders unschöner Zustand kam mir gestern unter die Finger. Gitosis benutzt bekanntermaßen SSH-Public-Keys zum authentifizieren der User, die in Git-Repositories arbeiten dürfen. Dieser Austausch zwischen Reporitory und Arbeitskopie passiert ebenfalls über SSH-Port 22. Die Benutzer, die sich dort anmelden, dürfen allerdings keinen direkten SSH-Zugriff bekommen. Soweit die Theorie.

    Wenn man seinen Public-Key also Gitosis zur automatischen Authentifizierung vorwirft, wird man in das System der Git-Benutzer eingespeißt.

    cp id_rsa.pub ~/gitosis/keydir/user@host.pub
    git add keydir/*
    git commit -a -m "user hinzugefügt"
    git push

    Bei erneuter Anmeldung an das System passiert folgendes:

    $ ssh user@gitserver.domain.com
    PTY allocation request failed on channel 0
    ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
    Connection to git closed.

    Ich darf mich also nicht mehr einloggen. Bin ich normaler Benutzer, der wirklich nur mit git arbeiten darf, ist das auch gut so. Denn so wird die Sicherheit des Systems gewahrt. Bin ich allerdings Administrator des git-Remote-Servers sieht das anders aus. Ich habe ab diesem Zeitpunkt keine Möglichkeit mehr mein System (auf gewohntem Wege) zu pflegen.

    Die Verbose-Ausgabe von ssh lässt darauf schließen was passiert:

    $ ssh -v user@gitserver.domain.com
    debug1: Authentications that can continue: publickey,password
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/user/.ssh/identity
    debug1: Offering public key: /home/user/.ssh/id_rsa
    debug1: Remote: Forced command: gitosis-serve user@host
    debug1: Remote: Port forwarding disabled.
    debug1: Remote: X11 forwarding disabled.
    debug1: Remote: Agent forwarding disabled.
    debug1: Remote: Pty allocation disabled.
    debug1: Server accepts key: pkalg ssh-rsa blen 277
    debug1: read PEM private key done: type RSA
    debug1: Remote: Forced command: gitosis-serve user@host
    debug1: Remote: Port forwarding disabled.
    debug1: Remote: X11 forwarding disabled.
    debug1: Remote: Agent forwarding disabled.
    debug1: Remote: Pty allocation disabled.
    debug1: Authentication succeeded (publickey).
    PTY allocation request failed on channel 0
    ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
    debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
    debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
    debug1: channel 0: free: client-session, nchannels 1
    Connection to git closed.

    Die Authentifizierung mit meinen Public-Key klappt zwar, aber ich werde in eine gitosis-serve ssh-session gezwungen und damit bleibt mir der ssh-zugang ins System verwehrt. Nicht mit dieser Situation rechnend, starrte ich völlig perplex auf mein Terminal und die Reverse-Engeneering-Abteilung in meinem Kopf ratterte vor sich hin. Was passiert da und warum passiert das? Und vor allem: Wie komme ich jetzt wieder auf den Server?

    Solve it!

    1. Public-Key Auth deaktivieren
    Ohne PubKey Auth, wird der ssh-daemon nicht erkennen, das er mir eine git-serve session geben müsste. Dem lokalen ssh-client beizubringen sich nicht mit dem Public-Key am entfernten System anzumelden, wäre also eine Lösung (aber keine Schöne). Folgende Konfiguration führt dazu.
    $ vi ~/.ssh/config
    Host git
    HostName gitserver.domain.com
    User root
    pubkeyauthentication no

    2. Different User
    Die Alternative zu dieser dauerhaften Veränderung ist (wenn vorhanden) einen anderen Benutzer zu verwenden um sich ins System einzuloggen und erst anschließend zu root zu werden.

    3. gitosis-serve zurechtstutzen
    Nachdem der Zugriff auf das System  wiederhergestellt ist, gehts zum Bugfix (gitosis-serve). gitosis muss diesen Umstand in irgendeiner ssh-config erzwingen. Ich verstehe nicht ganz warum, aber gitosis schrieb mir diese Änderungen in /root/.ssh/authorized_keys.

    command="gitosis-serve user@host",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AABBB3NzaC1yc2EAAAABIwAAAQEAyjwZCinCmB4oJJZ4RuiSqrQmiYE8+C+JKpTmiPkdfojUbiB9gm3BOhsYAdu99vP7yDOaIqg9e2dk/4HGm+P8obUR7lVrinMf5NvoRkOa8EfGdPJRz4ABOGRDte454bwestyWlvLhnKyWd+a9lU07siDJg5b1NbitIXkXa76V+lGMrqkixaDC6meZQEjZlxnVMpgzC5wyEQy2cVwUnX+Swiw68gsHsMYKBNsiVgNQ7nY8fa5lhV13E6L2aYAIorVpudS1bTiQfvfXCpVtJkJVSNPP6RzUtuSSErhsqOn1o2QtVjWhH5J/Y0D1b4eeEAgmdhq7554kQupJ9LgRww== user@host

    Dieser Eintrag ist für das Verhalten verantwortlich. Auskommentieren oder entfernen aller Parameter bis ssh-rsa fixt das Problem . Happy Committing.


Older »