Möchte man den privaten SSH Schlüssel welcher mittels des „PuTTY Key Generator“ erzeugt wurde auch in der „Git Bash“ nutzen, so muss man den Schlüssel in das OpenSSH Format bringen.
Der PuTTY Key Generator
Dazu öffnet man den PuTTY Schlüssel mittels „File“ -> „Load private key“. Anschließend wird der Schlüssel über „Conversions“ -> „Export OpenSSH key“ in eine Datei mit dem Namen „id_rsa“ exportiert. Diese Datei wird dann in den Benutzerordner (z.B. „c:\Users\seeseekey\.ssh\“ unter Windows 7) gelegt. Anschließend kann der Schlüssel auch unter der Git Bash benutzt werden.
Wie man Git auf einem Ubuntuserver aufsetzt hatte ich vor einiger Zeit in einem Artikel beschrieben. Nachteil der vorgestellten Methode ist, das sie sich nur für einen Nutzer eignet. Natürlich kann man mit dieser Methode auch mehrere Nutzer zu dem Repositories verbinden, hat damit aber keine Möglichkeit mehr Zugriffsberechtigungen für die Repositories zu setzen.
Als Lösung für das Problem wird Gitolite für die Nutzer und Rechteverwaltung genutzt. Im ersten Schritt werden auf dem Server die notwendigen Pakete installiert:
sudo apt-get install git openssh-server perl
Als nächster Schritt wird der Nutzer angelegt, in welchem Gitolite läuft und in diesen gewechselt:
sudo useradd -m git
sudo su git
Danach geht es auch schon an die Installation von Gitolite:
cd ~
git clone git://github.com/sitaramc/gitolite
mkdir bin
cd gitolite
./install -ln
Anschließend muss der öffentliche SSH Schlüssel von dem Rechner mit welchem auf das System zugriffen werden soll in den Home Ordner des „git“ Nutzers kopiert werden. Anschließend kann das Setup abgeschlossen werden:
cd ~/bin
./gitolite setup -pk $HOME/seeseekey.pub
Damit ist das Setup abgeschlossen und es kann an die Konfiguration gehen. Dazu wird vom Rechner dessen Public Key beim Setup benutzt wurde das entsprechende administrative Repository geklont:
git clone git@192.168.1.128:gitolite-admin
Die Dateistruktur des Repositories sieht dabei wie folgt aus:
conf
gitolite.conf
keydir
seeseekey.pub
In dem Verzeichnis „keydir“ sind die SSH Schlüssel enthalten. Um einen Nutzer hinzuzufügen reicht es einfach einen neuen öffentlichen Schlüssel in das Verzeichnis zu legen und das ganze ins Git Repository einzubringen. Die eigentliche Konfiguration der Repositories erfolgt in der „gitolite.conf“ Datei. Diese sieht nach der Erzeugung so aus:
Das bedeutet das es zwei Repositores gibt, eines trägt den Namen „gitolite-admin“ und dient der Verwaltung. Das zweite Repository ist „testing“ auf das alle Nutzer zugreifen dürfen. Benötigt man nun ein neues Repository, so fügt man einen neuen „repo“ Abschnitt mit dem Namen und den entsprechenden Rechten hinzu. Sobald das ganze commitet und gepusht wurde, legt Gitolite das neue Repository an. Wenn man bei den Schlüsseln mehrere SSH Schlüssel pro Nutzer wünscht, so legt man dafür am besten eine Verzeichnisstruktur an:
Möchte man ein Repository löschen so entfernt man es aus der „gitolite.conf“ und löscht es anschließend auch vom Server. Damit hat man eine Lösung für Git Server mit mehren Nutzern und und entsprechender Verwaltung.
Mittels des Kommandos „ssh-copy-id“ ist es ohne weitere Probleme möglich den öffentlichen SSH Schlüssel auf einen entfernten Rechner zu kopieren. Leider gibt es dieses Kommando nicht unter Mac OS X. Dank des Scriptes von devthought kann man dies aber unter Mac OS X nachrüsten. Dazu gibt man folgende Befehle im Terminal ein:
Virtualisierung an sich ist eine feine Sache, man nehme einen Rechner und simuliere auf diesem mehrere Rechner. Dank KVM ist die ganze Sache auch ziemlich einfach. Dazu installiert man auf einem Rechner ein Ubuntu Server 12.10 (mit dem OpenSSH Paket, und einem Nutzer (in diesem Fall „seeseekey“)). Dabei sollte man darauf achten, das der Nutzer kein verschlüsseltes „home“-Verzeichnis hat, sonst könnte es später Probleme mit der Verwendung von SSH Schlüsseln geben. Anschließend überprüft man auf der Konsole mittels:
cat /proc/cpuinfo
ob die CPU über die entsprechende Virtualisierungsfunktionen verfügt. Die erkennt man in der Sektion „flags“ der Ausgabe. Dort muss für Intel CPUs das Flag „vmx“ und für AMD CPUs das Flag „svn“ vorhanden sein. Ist dies der Fall so kann KVM mittels:
überprüft dann nochmal ob die CPU wirklich für KVM geeignet ist. Dabei ist zu beachten das es „kvm-ok“ nur unter Ubuntu gibt, andere Distribution enthalten es aller Wahrscheinlichkeit nach nicht. Nun muss der Nutzer noch der Gruppe „libvirtd“ hinzugefügt werden. Auf der Konsole ist dazu ein:
sudo adduser seeseekey libvirtd
nötig. Danach sollte der KVM Host neugestartet werden, bzw. sich an- und abgemeldet werden. Zur Verwaltung der Maschinen wird der „Virtual Machine Manager“ benutzt. Dieser wird auf der entsprechenden Zielmaschine (welche nicht identisch mit dem KVM Host sein muss) mittels:
sudo apt-get install virt-manager
installiert. Auf der entsprechenden Maschine, welche die Verwaltung übernimmt sollte ein SSH Schlüssel erzeugt werden. Dies geschieht auf der Konsole:
ssh-keygen -t rsa -C ""
Nun übertragen wir den Schlüssel auf den KVM Host, damit wir uns mit diesem verbinden können, was dann so aussehen könnte:
Danach sollte der „Virtual Machine Manager“ gestartet werden. Über „Datei“ -> „Verbindung hinzufügen“ wird im darauf folgenden Dialog der KVM Host hinzugefügt.
Eine Verbindung wird hinzugefügt
Nun wird noch eine Netzwerkbrücke eingerichtet. Diese dient dazu, das man die virtuellen Maschinen auch von außen ansprechen kann. Ohne diese Brücke befinden sich die Maschinen hinter einem NAT und können nur mit dem KVM Host kommunizieren.
Um die Bridge zu erstellen wird die Datei „/etc/network/interfaces“ geändert. Auf einem normalen System 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ändert. Anschließend fehlt nur noch die Zeile:
bridge_ports eth0
welche am Ende hinzugefü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 entsprechende Konfiguration wirksam.
Die Storage Pools des KVM Host
Nachdem dies geschehen ist kann man eine neue virtuelle Maschine anlegen. Wenn man ein Windowssystem installiert, sollte man darauf achten, das man die entsprechenden Treiber anschließend installiert. Diese findet man unter http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/.
Bei den Storage Pools, in welchem die Daten für die virtuellen Maschinen liegen, empfiehlt es sich den „default“ Pool außen vor zu lassen. Stattdessen legt man sich einen Pool „images“ und einen Pool „machines“ an. Im „images“ Pool lagert man dann alle Betriebsystemimages für die Installation neuer Maschinen. Im „machines“ Pool hingegen, sollten sich die installierten Maschinen befinden.
Das Quellgerät muss auf die Netzwerkbrücke eingestellt werden
In jeder virtuellen Maschine muss dabei das Quellgerät in der Netzwerkkonfiguration auf die Netzwerkbrücke (br0) eingestellt werden. Damit ist die Maschine ein Teil des Netzwerkes in welchem sich auch der KVM Host befindet. Bei den virtuellen Maschinen, empfiehlt es sich bei grafischen Systemen in der entsprechenden Konfiguration unter „Video“ das Modell „vmvga“ auszuwählen.
Manchmal möchte man einen Linux Server unter Windows in das Dateisystem einhängen. Unter Windows ist dies mittels „Dokan SSHFS“ möglich. Dazu muss im ersten Schritt der Dokan Installer (http://dokan-dev.net/wp-content/uploads/DokanInstall_0.6.0.exe) heruntergeladen und installiert werden.
