seeseekey.net - Invictus Deus Ex Machina

Manch­mal benö­tigt man unter Linux einen Nut­zer, möchte aber das die­ser keine Shell zuge­wie­sen bekommt und sich somit nicht anmel­den kann. Dies kann unter ande­rem mit dem Befehl „addu­ser“ bewerk­stel­ligt werden:

adduser seeseekey --no-create-home --shell /bin/false

Damit legt man einen Nut­zer an, wel­cher sich nicht anmel­den kann, aber durch­aus für die Authen­ti­fi­zie­rung über das Nut­zer­sys­tem z.B. bei bestimm­ten Netz­werk­diens­ten taugt. Dane­ben wird auch gleich ver­hin­dert, dass der Nut­zer einen „home“-Ordner bekommt.

Möchte man den pri­va­ten SSH Schlüs­sel wel­cher mit­tels des „PuTTY Key Gene­ra­tor“ erzeugt wurde auch in der „Git Bash“ nut­zen, so muss man den Schlüs­sel in das OpenSSH For­mat bringen.

Der PuTTY Key Generator

Der PuTTY Key Generator

Dazu öff­net man den PuTTY Schlüs­sel mit­tels „File“ -> „Load pri­vate key“. Anschlie­ßend wird der Schlüs­sel über „Con­ver­si­ons“ -> „Export OpenSSH key“ in eine Datei mit dem Namen „id_rsa“ expor­tiert. Diese Datei wird dann in den Benut­zer­ord­ner (z.B. „c:\Users\seeseekey\.ssh\“ unter Win­dows 7) gelegt. Anschlie­ßend kann der Schlüs­sel auch unter der Git Bash benutzt werden.

Wie man Git auf einem Ubun­tu­ser­ver auf­setzt hatte ich vor eini­ger Zeit in einem Arti­kel beschrie­ben. Nach­teil der vor­ge­stell­ten Methode ist, das sie sich nur für einen Nut­zer eig­net. Natür­lich kann man mit die­ser Methode auch meh­rere Nut­zer zu dem Repo­si­to­ries ver­bin­den, hat damit aber keine Mög­lich­keit mehr Zugriffs­be­rech­ti­gun­gen für die Repo­si­to­ries zu setzen.

Als Lösung für das Pro­blem wird Gito­lite für die Nut­zer und Rech­te­ver­wal­tung genutzt. Im ers­ten Schritt wer­den auf dem Ser­ver die not­wen­di­gen Pakete installiert:

sudo apt-get install git openssh-server perl

Als nächs­ter Schritt wird der Nut­zer ange­legt, in wel­chem Gito­lite läuft und in die­sen gewechselt:

sudo useradd -m git
sudo su git

Danach geht es auch schon an die Instal­la­tion von Gitolite:

cd ~
git clone git://github.com/sitaramc/gitolite
mkdir bin
cd gitolite
./install -ln

Anschlie­ßend muss der öffent­li­che SSH Schlüs­sel von dem Rech­ner mit wel­chem auf das Sys­tem zugrif­fen wer­den soll in den Home Ord­ner des „git“ Nut­zers kopiert wer­den. Anschlie­ßend kann das Setup abge­schlos­sen werden:

cd ~/bin
./gitolite setup -pk $HOME/seeseekey.pub

Damit ist das Setup abge­schlos­sen und es kann an die Kon­fi­gu­ra­tion gehen. Dazu wird vom Rech­ner des­sen Public Key beim Setup benutzt wurde das ent­spre­chende admi­nis­tra­tive Repo­sitory geklont:

git clone git@192.168.1.128:gitolite-admin

Die Datei­struk­tur des Repo­si­to­ries sieht dabei wie folgt aus:

conf
  gitolite.conf
keydir
  seeseekey.pub

In dem Ver­zeich­nis „key­dir“ sind die SSH Schlüs­sel ent­hal­ten. Um einen Nut­zer hin­zu­zu­fü­gen reicht es ein­fach einen neuen öffent­li­chen Schlüs­sel in das Ver­zeich­nis zu legen und das ganze ins Git Repo­sitory ein­zu­brin­gen. Die eigent­li­che Kon­fi­gu­ra­tion der Repo­si­to­ries erfolgt in der „gitolite.conf“ Datei. Diese sieht nach der Erzeu­gung so aus:

repo gitolite-admin
    RW+     =   seeseekey

repo testing
    RW+     =        @all

Das bedeu­tet das es zwei Repo­si­to­res gibt, eines trägt den Namen „gitolite-admin“ und dient der Ver­wal­tung. Das zweite Repo­sitory ist „tes­ting“ auf das alle Nut­zer zugrei­fen dür­fen. Benö­tigt man nun ein neues Repo­sitory, so fügt man einen neuen „repo“ Abschnitt mit dem Namen und den ent­spre­chen­den Rech­ten hinzu. Sobald das ganze com­mi­tet und gepusht wurde, legt Gito­lite das neue Repo­sitory an. Wenn man bei den Schlüs­seln meh­rere SSH Schlüs­sel pro Nut­zer wünscht, so legt man dafür am bes­ten eine Ver­zeich­nis­struk­tur an:

keydir
  seeseekey
    rechner1
      seeseekey.pub
    rechner2
      seeseekey.pub

Möchte man ein Repo­sitory löschen so ent­fernt man es aus der „gitolite.conf“ und löscht es anschlie­ßend auch vom Ser­ver. Damit hat man eine Lösung für Git Ser­ver mit meh­ren Nut­zern und und ent­spre­chen­der Verwaltung.

Mit­tels des Kom­man­dos „ssh-copy-id“ ist es ohne wei­tere Pro­bleme mög­lich den öffent­li­chen SSH Schlüs­sel auf einen ent­fern­ten Rech­ner zu kopie­ren. Lei­der gibt es die­ses Kom­mando nicht unter Mac OS X. Dank des Scrip­tes von dev­t­hought kann man dies aber unter Mac OS X nach­rüs­ten. Dazu gibt man fol­gende Befehle im Ter­mi­nal ein:

curl -O http://seeseekey.net/wp-content/uploads/2013/03/ssh-copy-id.sh
sudo cp ssh-copy-id.sh /usr/bin/ssh-copy-id
sudo chmod a+x /usr/bin/ssh-copy-id

Danach kann das Kom­mando benutzt werden:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@example.org

Anschlie­ßend sollte man sich ohne Pass­wort an dem ent­spre­chen­den Rech­ner anmel­den können.

Vir­tua­li­sie­rung an sich ist eine feine Sache, man nehme einen Rech­ner und simu­liere auf die­sem meh­rere Rech­ner. Dank KVM ist die ganze Sache auch ziem­lich ein­fach. Dazu instal­liert man auf einem Rech­ner ein Ubuntu Ser­ver 12.10 (mit dem OpenSSH Paket, und einem Nut­zer (in die­sem Fall „see­see­key“)). Dabei sollte man dar­auf ach­ten, das der Nut­zer kein ver­schlüs­sel­tes „home“-Verzeichnis hat, sonst könnte es spä­ter Pro­bleme mit der Ver­wen­dung von SSH Schlüs­seln geben. Anschlie­ßend über­prüft man auf der Kon­sole mittels:

cat /proc/cpuinfo

ob die CPU über die ent­spre­chende Vir­tua­li­sie­rungs­funk­tio­nen ver­fügt. Die erkennt man in der Sek­tion „flags“ der Aus­gabe. Dort muss für Intel CPUs das Flag „vmx“ und für AMD CPUs das Flag „svn“ vor­han­den sein. Ist dies der Fall so kann KVM mittels:

sudo apt-get install qemu-kvm libvirt-bin virtinst

instal­liert wer­den. Ein anschließendes:

kvm-ok

über­prüft dann noch­mal ob die CPU wirk­lich für KVM geeig­net ist. Dabei ist zu beach­ten das es „kvm-ok“ nur unter Ubuntu gibt, andere Dis­tri­bu­tion ent­hal­ten es aller Wahr­schein­lich­keit nach nicht. Nun muss der Nut­zer noch der Gruppe „libvirtd“ hin­zu­ge­fügt wer­den. Auf der Kon­sole ist dazu ein:

sudo adduser seeseekey libvirtd

nötig. Danach sollte der KVM Host neu­ge­star­tet wer­den, bzw. sich an- und abge­mel­det wer­den. Zur Ver­wal­tung der Maschi­nen wird der „Vir­tual Machine Mana­ger“ benutzt. Die­ser wird auf der ent­spre­chen­den Ziel­ma­schine (wel­che nicht iden­tisch mit dem KVM Host sein muss) mittels:

sudo apt-get install virt-manager

instal­liert. Auf der ent­spre­chen­den Maschine, wel­che die Ver­wal­tung über­nimmt sollte ein SSH Schlüs­sel erzeugt wer­den. Dies geschieht auf der Konsole:

ssh-keygen -t rsa -C "user@example.org"

Nun über­tra­gen wir den Schlüs­sel auf den KVM Host, damit wir uns mit die­sem ver­bin­den kön­nen, was dann so aus­se­hen könnte:

ssh-copy-id -i ~/.ssh/id_rsa.pub seeseekey@kvmhost

Danach sollte der „Vir­tual Machine Mana­ger“ gestar­tet wer­den. Über „Datei“ -> „Ver­bin­dung hin­zu­fü­gen“ wird im dar­auf fol­gen­den Dia­log der KVM Host hinzugefügt.

Eine Ver­bin­dung wird hinzugefügt

Nun wird noch eine Netz­werk­brü­cke ein­ge­rich­tet. Diese dient dazu, das man die vir­tu­el­len Maschi­nen auch von außen anspre­chen kann. Ohne diese Brü­cke befin­den sich die Maschi­nen hin­ter einem NAT und kön­nen nur mit dem KVM Host kommunizieren.

Um die Bridge zu erstel­len wird die Datei „/etc/network/interfaces“ geän­dert. Auf einem nor­ma­len Sys­tem sollte diese wie folgt aussehen:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

Nun wird „auto eth0“ in „auto br0“ und „iface eth0 inet dhcp“ in „iface br0 inet dhcp“ geän­dert. Anschlie­ßend fehlt nur noch die Zeile:

bridge_ports eth1

wel­che am Ende hin­zu­ge­fügt wird. Damit sieht die neue „/etc/network/interfaces“ dann wie folgt aus:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto br0
iface br0 inet dhcp
bridge_ports eth0

Danach geben wir im Terminal:

/etc/init.d/networking restart

mit root-Rechten ein und schon ist die ent­spre­chende Kon­fi­gu­ra­tion wirksam.

Die Sto­rage Pools des KVM Host

Nach­dem dies gesche­hen ist kann man eine neue vir­tu­elle Maschine anle­gen. Wenn man ein Win­dows­sys­tem instal­liert, sollte man dar­auf ach­ten, das man die ent­spre­chen­den Trei­ber anschlie­ßend instal­liert. Diese fin­det man unter http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/.

Bei den Sto­rage Pools, in wel­chem die Daten für die vir­tu­el­len Maschi­nen lie­gen, emp­fiehlt es sich den „default“ Pool außen vor zu las­sen. Statt­des­sen legt man sich einen Pool „images“ und einen Pool „machi­nes“ an. Im „images“ Pool lagert man dann alle Betriebsys­tem­i­mages für die Instal­la­tion neuer Maschi­nen. Im „machi­nes“ Pool hin­ge­gen, soll­ten sich die instal­lier­ten Maschi­nen befinden.

Das Quell­ge­rät muss auf die Netz­werk­brü­cke ein­ge­stellt werden

In jeder vir­tu­el­len Maschine muss dabei das Quell­ge­rät in der Netz­werk­kon­fi­gu­ra­tion auf die Netz­werk­brü­cke (br0) ein­ge­stellt wer­den. Damit ist die Maschine ein Teil des Netz­wer­kes in wel­chem sich auch der KVM Host befin­det. Bei den vir­tu­el­len Maschi­nen, emp­fiehlt es sich bei gra­fi­schen Sys­te­men in der ent­spre­chen­den Kon­fi­gu­ra­tion unter „Video“ das Modell „vmvga“ auszuwählen.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/SSH
http://wiki.ubuntuusers.de/KVM
http://wiki.ubuntuusers.de/virt-manager
http://wiki.ubuntuusers.de/Virtualisierung
http://de.wikipedia.org/wiki/Kernel-based_Virtual_Machine

Manch­mal möchte man einen Linux Ser­ver unter Win­dows in das Datei­sys­tem ein­hän­gen. Unter Win­dows ist dies mit­tels „Dokan SSHFS“ mög­lich. Dazu muss im ers­ten Schritt der Dokan Instal­ler (http://dokan-dev.net/wp-content/uploads/DokanInstall_0.6.0.exe) her­un­ter­ge­la­den und instal­liert werden.

Danach wird „Dokan SSHFS“ (http://dokan-dev.net/wp-content/uploads/dokan-sshfs-0.6.0.zip) her­un­ter­ge­la­den und ent­packt. Dort star­tet man dann die Datei „DokanSSHFS.exe“ wor­auf­hin ein neues Icon im Tray erscheint.

Danach kann der Mount Dia­log gestar­tet wer­den und nach Ein­gabe der pas­sen­den Daten sollte er dann als Lauf­werk der Wahl auftauchen.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://dokan-dev.net/en/
http://de.wikipedia.org/wiki/SSHFS

Vor ein paar Tagen gab es einen Arti­kel dar­über wie man den SSH Schlüs­sel für Git­Hub unter Ubuntu hin­zu­fügt. Heute gibt es das ganze für Win­dows. Nach der Instal­la­tion von Tor­ti­se­Git star­ten wir die Git Bash wel­che im Start­menü zu fin­den ist. Dort erzeu­gen wir dann den SSH Schlüs­sel mittels:

ssh-keygen -t rsa -C "seeseekey@example.com"

Diese Schlüs­sel fügen wir nun unter Git­Hub (https://github.com/account/ssh) hinzu. Dazu öff­nen wir die Datei id_rsa.pub wel­che sich im Ord­ner .ssh befin­det. Der .ssh Ord­ner ist dabei in den Eige­nen Dateien zu finden.

Das Pro­blem an die­ser Vari­ante ist das damit das ausch­e­cken nur in der Git Bash aber nicht direkt in Tor­ti­se­Git funk­tio­niert, da die­ses einen ande­res Schlüs­sel­for­mat nutzt. Um einen Schlüs­sel im PuTTY For­mat zu erzeu­gen muss zuerst die Soft­ware PuTTYgen.exe (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) her­un­ter­ge­la­den wer­den. Nach dem Start der Anwen­dung sieht das ganze so aus:

Dort drü­cken wir auf den But­ton Gene­rate und bewe­gen die Maus in dem lee­ren Bereich um Zufalls­da­ten für die Schlüs­sel­ge­ne­rie­rung zu lie­fern. Nach­dem der Schlüs­sel erzeugt würde, drü­cken wir die But­tons Save public key und Save pri­vate key um die bei­den Schlüs­sel zu sichern. Der Public Key kann dabei direkt aus der Anwen­dung in das Git­Hub Pro­fil kopiert werden.

Beim git clone muss nun nur noch die PuTTY Pri­vate Key Datei ange­ben wer­den und schon sollte auch hier das ausch­e­cken auch hier ohne Pro­bleme funktionieren.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://help.github.com/win-set-up-git/

Bei Ger­rit han­delt es sich um ein Reviewsys­tem auf Git Basis. Die Soft­ware wird unter ande­rem vom Android Pro­jekt benutzt. Ger­rit selbst ist dabei in Java geschrie­ben. Des­halb sollte die­ses natür­lich instal­liert werden:

apt-get install openjdk-6-jre-headless

Nach der Instal­la­tion von Java legen wir für Ger­rit einen extra Benut­zer an und wech­seln in sei­nen Kontext:

adduser gerrit
su gerrit
cd ~gerrit

Im Home­ver­zeich­nis des Nut­zers ange­kom­men laden wir das Kom­pi­lat von Ger­rit her­un­ter und star­ten den Initialisierungsvorgang:

wget http://gerrit.googlecode.com/files/gerrit-2.2.1.war
chmod 744 gerrit-2.2.1.war
java -jar gerrit-2.2.1.war init -d review

Das „review“ bezeich­net hier­bei das Ver­zeich­nis in wel­chem Ger­rit die ent­spre­chen­den Dateien anlegt, wel­che für den Betrieb der Soft­ware benö­tigt werden.

Im ers­ten Schritt fragt Ger­rit ob der Ord­ner ange­legt und initia­li­siert wer­den soll, was wir mit Yes beant­wor­ten. Alle ande­ren Mel­dun­gen bestä­ti­gen wir mit der Enter­taste bis wir zum Punkt „Email Deli­very“ kom­men. Hier geben wir die Daten für einen SMTP Ser­ver ein über wel­chen Ger­rit die Mails ver­schickt. Bei der Frage nach der „Cano­ni­cal URL“ sollte die URL ein­ge­ge­ben wer­den unter der das Sys­tem spä­ter erreich­bar sein soll z.B. „http://review.invertika.org“.

Nach der Kon­fi­gu­ra­tion star­tet Ger­rit und ist dann per Brow­ser erreich­bar. Nach­dem man sich einen Account regis­triert hat ist man auto­ma­tisch in der Gruppe „Admi­nis­tra­tors“. Nun sollte man unter Set­tings -> SSH Public Keys den ent­spre­chen­den Schlüs­sel hin­ter­le­gen. Mittels

ssh -p 29418 nutzername@host

z.B.

ssh -p 29418 seeseekey@review.invertika.org

kann man nun über­prü­fen ob der Ser­ver den Schlüs­sel akzep­tiert. Das ganze sollte dann so aussehen:

  ****    Wel­come to Ger­rit Code Review    ****

Hi see­see­key, you have suc­cess­fully con­nec­ted over SSH.

Unfor­t­u­na­tely, inter­ac­tive shells are disa­bled.
To clone a hos­ted Git repo­sitory, use:

git clone ssh://seeseekey@review.invertika.org:29418/REPOSITORY_NAME.git

Nach­dem die grund­le­gende Kon­fi­gu­ra­tion ange­legt ist, kann damit begon­nen wer­den, ein Pro­jekt anzu­le­gen. Dies geschieht aller­dings nicht über die Webober­flä­che, son­dern per SSH:

ssh -p 29418 nutzername@host gerrit create-project -n projektname

z.B.

ssh -p 29418 seeseekey@review.invertika.org gerrit create-project -n sandbox

Damit ist das Pro­jekt dann ange­legt. Nun muss noch das beste­hende Repo­sitory in das Ger­rit Sys­tem über­führt wer­den. Dazu wird zuerst das bereits beste­hende Repo­sitory geclont:

git clone git@github.com:Invertika/sandbox.git

Dann pus­hen wir das Repo­sitory in das neue Ger­rit Projekt:

cd sandbox
git remote rm origin
git remote add origin ssh://seeseekey@review.invertika.org:29418/sandbox.git
git push ssh://seeseekey@review.invertika.org:29418/sandbox.git HEAD:refs/heads/master

Kommt es beim Push zu der Meldung:

Permission denied (publickey).

muss der ent­spre­chende SSH Schlüs­sel zu dem Nut­zer in Ger­rit ange­tra­gen wer­den. Ist die Mail­adresse eines Com­miters nicht bekannt kann es zu fol­gen­dem Feh­ler kommen:

remote: ERROR:  In commit 9228f67aa9113fa73c80f36e81cb5a62bf930c6c
remote: ERROR:  committer email address manaserv@herse.(none)
remote: ERROR:  does not match your user account.
remote: ERROR:
remote: ERROR:  The following addresses are currently registered:
remote: ERROR:    seeseekey@example.com
remote: ERROR:
remote: ERROR:  To register an email address, please visit:
remote: ERROR:  http://review.invertika.org/#settings,contact

Hier hilft es dem Pro­jekt die ent­spre­chen­den Rechte zu geben damit die Iden­ti­tät „gefälscht“ wer­den darf. Ansons­ten kann noch der Fehler:

! [remote rejected] HEAD -> master (prohibited by Gerrit)

auf­tre­ten. Auch hier hilft die tem­po­räre Anhe­bung der Rechte für das jewei­lige Pro­jekt, da man nor­ma­ler­weise nicht in den Mas­ter Branch schrei­ben darf (was aber beim ers­ten Anle­gen des Pro­jek­tes gewollt ist).

Nach­dem das Pro­jekt ange­legt ist kann man es sich mittels:

git clone ssh://seeseekey@review.invertika.org:29418/sandbox.git

auf die Fest­platte holen. Möchte man Ger­rit neu­star­ten, stop­pen oder star­ten so sieht das wie folgt aus:

review/bin/gerrit.sh restart
review/bin/gerrit.sh stop
review/bin/gerrit.sh start

Wei­tere Infor­ma­tio­nen gibt es unter:
http://code.google.com/p/gerrit/
http://www.rockbox.org/wiki/GerritDemoGuide
http://de.wikipedia.org/wiki/Gerrit_%28Software%29
http://gerrit.googlecode.com/svn/documentation/2.1.5/config-replication.html
http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html
http://gerrit.googlecode.com/svn-history/r6114/documentation/2.1.7/error-you-are-not-committer.html

Wenn man ein Git Repo­sitory bei Git­Hub hat, so ist es doch recht ner­vig mit die­sem per HTTPS zu arbei­ten, da man dort für jede Anwen­dung sein Git­Hub Pass­wort ein­ge­ben muss. Ein­fa­cher ist es wenn man sei­nen Public SSH Key bei Git­Hub hin­ter­legt. Dabei wird hier davon aus­ge­gan­gen das man noch kei­nen SSH Schlüs­sel besitzt. Um sich einen sol­chen anzu­le­gen wech­selt man auf die Kon­sole und gibt dort:

ssh-keygen -t rsa -C "user@example.org"

ein, wobei die Mail­adresse natür­lich zu erset­zen ist. In sei­nem Home­ver­zeich­nis hat man nun im Ord­ner .ssh eine Datei namens id_rsa.pub wel­che man in einem Text­edi­tor öff­nen sollte. Nun geht man auf die Seite https://github.com/account/ssh und fügt dort einen neuen Schlüs­sel (Add ano­ther public key) hinzu. Dabei kopiert man die Zei­chen­kette aus der id_rsa.pub Datei in das Feld Key. Anschlie­ßend kann man sich ein Git Repo­sitory über SSH mittels:

git clone git@github.com:Invertika/data.git

holen und (die ent­spre­chen­den Rechte vor­aus­ge­setzt) pro­blem­los mittels

git push

die getä­tig­ten Ände­run­gen wie­der in das Git­Hub Repo­sitory brin­gen, ohne ein Pass­wort ein­ge­ben zu müs­sen. Unter Mac OS X funk­tio­niert das ganze im übri­gen genauso.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://help.github.com/win-set-up-git/

Manch­mal hat man das Pro­blem das man einen SSH Cli­ent benö­tigt, aber nur einen Brow­ser (in die­sem Fall ein Fire­fox) zur Ver­fü­gung hat. Genau für die­ses Fall gibt es nun FireSSH. Dabei han­delt es sich um einen SSH Cli­ent wel­cher voll­stän­dig in Javaskript geschrie­ben wurde. Zu fin­den ist FireSSH dabei unter http://firessh.mozdev.org/. Der Cli­ent instal­liert sich als AddOn im Fire­fox und kann dann nach einem Neu­start benutzt werden.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://www.golem.de/1103/82332.html