seeseekey.net - Invictus Deus Ex Machina

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.

Da möchte man nichts­ah­nend Mine­craft star­ten und bekommt nur fol­gende Feh­ler­mel­dung an den Kopf geworfen:

Exception in thread "main" java.awt.HeadlessException
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:173)
        at java.awt.Window.(Window.java:546)
        at java.awt.Frame.(Frame.java:419)
        at net.minecraft.LauncherFrame.(LauncherFrame.java:20)
        at net.minecraft.LauncherFrame.main(LauncherFrame.java:167)
        at net.minecraft.MinecraftLauncher.main(MinecraftLauncher.java:13)

In die­sem Fall hilft ein beherztes:

apt-get install openjdk-6-jdk

auf der Kon­sole. Nach der Instal­la­tion sollte Mine­craft ohne wei­tere Pro­bleme starten.

Möchte man auf einem Ubun­tu­sys­tem einen Git Ser­ver auf­set­zen, so ist dies rela­tiv schnell erle­digt. Zuerst muss dafür „git“ mittels:

apt-get install git

instal­liert wer­den. Danach wird der pas­sende Nut­zer für die Git Repo­si­to­ries angelegt:

adduser git

Nun kann man ein beste­hen­des Repo­sitory zu die­sem Ser­ver hoch­la­den. Auf dem Ser­ver wird in den Kon­text des Nut­zers „git“ gewech­selt und dort ein pas­sen­der Ord­ner sowie ein „rohes“ Git Repo­sitory angelegt:

su git
mkdir testproject.git
cd testproject.git
git init --bare

Dem loka­len Git Repo­sitory wird mittels:

git remote add origin git@example.org:testproject.git

ein neuer Remote zuge­wie­sen. Sollte bereits ein „remote“ für „ori­gin“ exis­tie­ren, so wird die­ser mit:

git remote rm origin

ent­fernt. Anschlie­ßend kann das lokale Repo­sitory an den Ser­ver über­tra­gen wer­den und auf Updates über­prüft werden:

git push origin master
git pull origin master

Wenn gewünscht kann man nun noch ver­hin­dern das man sich mit­tels des „git“ Accounts auf dem Ser­ver anmel­den kann. Dazu muss die Datei „/etc/passwd“ edi­tiert wer­den. Für den Nut­zer „git“ wird die Shell dabei von „/bin/bash“ in „/usr/bin/git-shell“ geän­dert. Anschlie­ßend kann man sich mit dem Account nicht mehr an der Shell anmelden.

In eini­gen Ver­sio­nen hat Inkscape Pro­bleme mit der Fontaus­wahl. Nach­voll­zie­hen kann man das zum Bei­spiel mit den Ubuntu Fonts. Diese gibt es in den Vari­an­ten „Ubuntu“, „Ubuntu Con­den­sed“ und „Ubuntu Light“. Möchte man nun z.B. den Font „Ubuntu Light“ anwäh­len, so funk­tio­niert es nicht. Inkscape springt unver­mit­telt auf den Font „Ubuntu“.

Die Fontauswahl unter Inkscape

Die Fontaus­wahl unter Inkscape

Bei die­sem Pro­blem han­delt es sich um ein Feh­ler in Inkscape, wel­che sich glück­li­cher­weise umschif­fen lässt. Dazu gibt man den Font­na­men, in der Font­leiste ein und hängt ein Komma an den Namen. Aus „Ubuntu Light“ wird dann „Ubuntu Light,“. Damit akzep­tiert Inkscape den Font und man kann wie­der damit arbeiten.

Wei­tere Infor­ma­tio­nen gibt es unter:
https://bugs.launchpad.net/inkscape/+bug/595432

Echt­zeitstra­te­gie­spiele gibt es eine ganze Menge. Mit SpringRTS (http://springrts.com/) gibt es ein sol­ches schon eine ganze Weile als Open Source Vari­ante. Dabei ist SpringRTS streng genom­men kein Spiel für sich, son­dern eine Engine für Echt­zeitstra­te­gie. So gibt es für diese Engine einige Mods wie „Ker­nel Panic“, „Balan­ced Anni­hil­a­tion“ und einige wei­tere. Zu die­sen Mods ist nun ein wei­te­res hinzugekommen.

Der neue Mod, bzw das Spiel hört dabei auf den Namen „Zero-K“ und wird seid mitt­ler­weile knapp zwei Jah­ren ent­wi­ckelt. Die offi­zi­elle Seite des Mods ist unter http://zero-k.info/ zu fin­den. Lauf­fä­hig ist das ganze unter Win­dows, Mac OS X und Linux.

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

Falls man mal in die Ver­le­gen­heit kommt ein Andro­id­ge­rät löschen zu müs­sen, aber das Gerät kei­nen funk­tio­nie­ren­den Bild­schirm mehr besitzt, so hilft „adb“ aus dem Android SDK wel­ches unter http://developer.android.com/sdk/index.html bezo­gen wer­den kann.

Nach dem Down­load wird man fest­stel­len das „adb“ nicht mehr im „tools“ Ord­ner des SDKs liegt. Statt­des­sen erwar­tet uns dort eine Datei mit dem Namen „adb_has_moved.txt“. Dort wird man dar­über infor­miert das „adb“ nun in dem Ord­ner „platt­form tools“ zu fin­den ist. Um die­sen Ord­ner zu bekom­men führt man unter Linux die Appli­ka­tion „android“ aus dem „tools“ Ord­ner aus und instal­liert das ent­spre­chende Paket.

Sollte anschlie­ßend beim Start von „adb“ die Meldung:

./adb Datei oder Verzeichnis nicht gefunden

erschei­nen so hilft hier ein:

sudo apt-get install ia32-libs

Nun schließt man das aktive Gerät an und gibt im Ter­mi­nal fol­gen­des ein:

./adb remount
./adb shell

In der Shell geben wir dann die ent­schei­den­den Befehle ein:

wipe all
exit

Damit ist das Tele­fon von pri­va­ten Nutz­da­ten befreit.

Manch­mal möchte man ein Git Repo­sitory von Ser­ver A auf Ser­ver B umzie­hen (in die­sem Fall von Google Code zu Git­hub). Das ganze ist dabei rela­tiv unpro­ble­ma­tisch. Zuerst wird das beste­hende Repo­sitory geklont:

git clone https://code.google.com/p/cscl/

In der Git­Hub Ober­flä­che erstel­len wir nun ein neues Repo­sitory (in die­sem Fall mit dem Namen „CSCL“). Danach ent­fer­nen wir den alten Remote und wei­sen einen neuen hinzu:

git remote rm origin
git remote add origin git@github.com:seeseekey/CSCL.git

Mit­tels „git remote -v“ kann man sich die beste­hen­den „Remo­tes“ anschauen. Nach­dem der neue Remote gesetzt wur­den laden wir das Repo­sitory (mit­tels „push“) bei Git­Hub hoch:

git push -u origin master

Damit ist der Umzug abgeschlossen.

Wei­tere Infor­ma­tio­nen gibt es unter:
https://help.github.com/articles/removing-a-remote

Die Funk­tion „Time Machine“ wel­che unter Mac OS X zu fin­den ist funk­tio­niert mit­tels einer USB Fest­platte oder einer Time Cap­sule. Wer aber nun schon einen Linux Ser­ver (in die­sem Fall ein Ubuntu 12.04) rum­zu­ste­hen hat, der möchte die­sen even­tu­ell für die Siche­rung mit­tels Time Machine benut­zen. Dazu gibt man im der Kon­sole fol­gen­des ein:

sudo apt-get install netatalk avahi-daemon libnss-mdns

Nach­dem die ent­spre­chen­den Pakete instal­liert wor­den sind, kon­fi­gu­rie­ren wir den Avahi Ser­vice mit­tels „sudo nano /etc/avahi/services/afpd.services“. In die sich öff­nende Datei tra­gen wir fol­gen­des ein:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=TimeCapsule</txt-record>
</service>
</service-group>

Danach legen wir die ent­spre­chende Frei­gabe an, in dem wir die Datei „/etc/netatalk/AppleVolumes.default“ mittels:

sudo nano /etc/netatalk/AppleVolumes.default

bear­bei­ten. Der Inhalt die­ser Datei sieht dabei so aus:

/home/seeseekey/Backup TimeMachine allow:seeseekey cnidscheme:dbd options:usedots,upriv,tm

Nun muss noch ein­mal der Ser­ver neu­ge­star­tet wer­den und schon kann die Frei­gabe mit­tels Time Machine benutzt wer­den. Sollte beim Start des ers­ten Back­ups fol­gende Fehlermeldung:

Feh­ler 30 beim ers­ten Backup mit­tels Time Machine

erhal­ten so muss man das Ter­mi­nal öff­nen und dort fol­gen­des eingeben:

hdiutil create -size $500g -fs HFS+J -type SPARSEBUNDLE -volname “BACKUP” Amy_133713371337.sparsebundle

Damit erzeu­gen wir eine Sparsebundle-Datei. Der Para­me­ter Size gibt dabei die maxi­male Größe an. Der Datei­name ent­spricht dem Schema „COMPUTERNAME_MACADRESSE.sparsebundle“. Die erzeugte Datei kopie­ren wir nun in das Wur­zel­ver­zeich­nis der ent­spre­chen­den Frei­gabe. Danach sollte das Backup dann ohne Pro­bleme funktionieren.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://meetinx.de/tutorial-time-machine-auf-nas-netzwerk-laufwerk/
http://www.kvibes.net/2011/08/mac-os-x-lion-timemachine-und-linux/
http://meetinx.de/tutorial-time-machine-backup-sparsebundle-in-groesse-begrenzen/
http://blog.rotzoll.net/2010/07/linux-als-apple-afp-share-mit-timemachine-support-backups-uber-das-netzwerk/

Für Mine­craft gibt es ja zwei Ser­ver, den offi­zi­el­len und den Craft­Buk­kit Ser­ver wel­cher unter http://bukkit.org/ her­un­ter­ge­la­den wer­den kann. Der Craft­Buk­kit Ser­ver hat dabei den Vor­teil das er mit Plugins aus­ge­stat­tet wer­den kann, wel­che die Funk­tio­na­li­tät des Spie­les erhöhen.

Um den Ser­ver auf einem Ubun­tu­sys­tem auf­zu­set­zen muss im ers­ten Schritt Java instal­liert werden:

apt-get install openjdk-6-jre-headless

Danach legt man sich den pas­sen­den Nut­zer für Mine­craft an und wech­selt in des­sen Kontext:

adduser minecraft
su minecraft
cd /home/minecraft/

Dort lädt man nun mit­tels „wget“ die neuste Craft­Buk­kit Ver­sion herunter:

wget "http://dl.bukkit.org/downloads/craftbukkit/get/01119_1.2.5-R3.0/craftbukkit.jar" -O "craftbukkit.jar"

Das Bashskript „start-server.sh“ soll den Ser­ver dann starten:

#!/bin/sh
screen java -Xmx2048M -Xms2048M -jar craftbukkit.jar

Nach­dem der Ser­ver mit­tels „screen“ gestar­tet wurde, drückt man „Strg + A“ und anschlie­ßend „Strg + D“ um ihn in den Hin­ter­grund zu legen. Beim ers­ten Start sollte der Ser­ver einen Ord­ner „plugins“ anle­gen. In die­sen kann man dann eigene Plugins legen. Für den Anfang sollte man es mit fol­gen­den Plugins versuchen:

Diese kön­nen auch ohne Rech­te­plu­gin genutzt wer­den, da die Befehle nur den Ser­ver­ope­ra­to­ren zu Ver­fü­gung stehen.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://seeseekey.net/blog/4276