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.

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.

Kaum nimmt man einen Ser­ver aus dem Ser­ver­schrank, zeigt der ent­spre­chende Ser­ver einem wel­che inter­es­san­ten Feh­ler er über die LEDs an der Front aus­ge­ben kann. In die­sem Fall leuch­tete bei einem Fujitsu Ser­ver die CSS LED. CSS steht dabei laut Fujitsu für „Cust­o­mer Self Service“.

Die leuch­tende CSS LED

Der erste Schritt führt bei einem sol­chen Feh­ler (wenn ein Win­dows auf dem Sys­tem läuft) in die „Com­pu­ter­ver­wal­tung“ und dort in die „Ereig­nis­an­zeige“ in den Unter­punkt „Anwen­dung“. Dort sollte die Quelle „Ser­ver­View Agents“ einen Feh­ler gewor­fen haben:

A cri­ti­cal error hap­pend while BIOS self­test in cabi­net 0 of ser­ver EXAMPLE. See ser­ver manage­ment mes­sage log (reco­very log) for detailed information.

Der Feh­ler an sich ist nicht sehr aus­sa­ge­kräf­tig, so das man hier den Feh­ler­spei­cher des Ser­vers aus­le­sen muss. Dies geschieht über die „Feh­ler­spei­cher­an­zeige“ wel­che Teil der „Fujitsu Ser­ver­View Suite“ ist. Dort sieht man dann auch das der Feh­ler in die­sem Fall nicht wirk­lich dra­ma­tisch ist:

Ursa­chen:
• Key­board error detec­ted during Power-On Self-Test (POST)
Pro­blem­lö­sun­gen:
• Check in the case of head­less mode (wit­hout local key­board) that AVR license is enab­led or key­board check is disa­bled
• Check key­board cable
• If pro­blem per­sists replace key­board / cable.

Die ent­spre­chende Ein­stel­lung wird im BIOS geän­dert und schon läuft der Ser­ver wie­der wie am Schnürchen.

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

Wer mal schnell einen HTTP Ser­ver unter Linux auf­set­zen möchte, der sollte ein­fach in das ent­spre­chende Ver­zeich­nis gehen und dort:

python -m SimpleHTTPServer

aus­füh­ren. Anschlie­ßend ist die­ses Ver­zeich­nis per HTTP (stan­dard­mä­ßig unter Port 8000) erreich­bar. Möchte man einen ande­ren Port benut­zen so gibt man ein­fach die ent­spre­chende Port­num­mer als letz­tes Argu­ment mit an.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://docs.python.org/library/simplehttpserver.html

Nach eini­gen Mona­ten ist es Zeit den Zwi­schen­stand für den neuen Inver­tika Ser­ver und den Cli­ent vor­zu­stel­len. Inver­tika soll somit auf einer neuen tech­ni­schen Basis ste­hen. Diese neue tech­ni­sche Basis sieht so aus, das der Ser­ver in C# geschrie­ben wird und somit unter Mono und .NET läuft. Für den Cli­ent ist eine Imple­men­ta­tion als Webap­pli­ka­tion ange­dacht. Das ganze hatte dabei meh­rere Gründe:

  • die Pro­duk­ti­vi­tät ist in C# höher als in C/C++
  • es kön­nen keine Spei­cher­lö­cher entstehen
  • durch die auto­ma­ti­sche Spei­cher­ver­wal­tung wird der Ent­wick­ler entlastet
  • moder­nes und kon­sis­ten­tes Framework
  • Anpas­sung auf eigene Bedürfnisse
  • schnel­lere Entwicklung
  • IPv6 Unter­stüt­zung ist pro­blem­los möglich
  • bes­sere Unter­stüt­zung von mobi­len Geräten

Neben die­sen Grün­den sind es auch einige Dinge wie „typedefs“ wel­che nicht unbe­dingt zum Ver­ständ­nis bei­tru­gen oder meh­rere Klas­sen und Struk­tu­ren in einer Datei, wel­che das ganze ziem­lich unüber­sicht­lich machen. Auch die Abhän­gig­keit von zu vie­len Biblio­the­ken wurde verringert.

Der Inver­tika Code in der Entwicklung

Nach einer kur­zen Pla­nung­phase ging es dann am 3. Januar los mit der Ent­wick­lung. Zuerst wurde damit begon­nen den Account­ser­ver zu por­tier­ten. Dabei wur­den im Gegen­satz zum Ori­gi­nal einige Dinge verändern:

  • das Netz­werk setzt nun statt auf der Biblio­thek „enet“ direkt auf TCP auf
  • PhysFS wurde wegrationalisiert

Am 13. Januar (einem Frei­tag ;) ) waren die größ­ten Por­tie­rung­pro­bleme beim Account­ser­ver gelöst und es wurde begon­nen den Game­ser­ver zu por­tie­ren. Am Game­ser­ver ist die ein­zige grö­ßere Ände­rung die Anpas­sung der Skript­schnitt­stelle, damit diese mit den CLR Spra­chen kom­pa­ti­bel ist. Die Road­map für die Por­tie­rung sah dabei so aus:

  • Januar 2012: Imple­men­ta­tion des Inver­tika Server
  • Februar 2012 Imple­men­ta­tion des Inver­tika Clients
  • März 2012: Test der Software

Wie sich das für eine ordent­li­che Road­map gehört wurde sie nicht ein­ge­hal­ten. So ist eini­ges noch nicht fer­tig und auch am Cli­ent muss noch viel getan wer­den. Der Cli­ent sollte ursprüng­lich auch in C# geschrie­ben wer­den und es wurde damit auch begon­nen. Theo­re­tisch ließe sich diese Cli­ent­va­ri­ante auf die Platt­for­men Win­dows, Linux, Mac OS X, iOS und Android brin­gen, prak­tisch ist es mit klei­ne­ren und grö­ße­ren Pro­ble­men verbunden.

Ein gene­rel­les Pro­blem an einem sol­chen Cli­ent ist, das er auf der jewei­li­gen Ziel­platt­form erst instal­liert (oder auch kom­pi­liert) wer­den und außer­dem vom Nut­zer aktu­ell gehal­ten wer­den muss. Schö­ner wäre es, wenn man diese Hürde aus dem Weg geschafft wird. Mitt­ler­weile ist es dank Tech­ni­ken wie Webso­ckets, Web­wor­kern und Can­vas mög­lich, den Cli­ent kom­plett als Webap­pli­ka­tion zu schreiben.

Die Anfänge des neuen Cli­ents basie­ren dabei auf der Tech­demo „mana.js“ wel­che unter https://github.com/bjorn/mana.js zu fin­den ist. Der Vor­teil der web­ba­sier­ten Lösung ist dabei die große Kom­pa­ti­bi­li­tät mit unter­schied­lichs­ten Gerä­ten solange sie über einen aktu­el­len Brow­ser verfügen.

Die Tech­demo des Cli­ents auf einem iPad

Wäh­rend der Ent­wick­lung beka­men die ein­zel­nen Teile auch Namen die wie folgt lauten:

  • inver­tika (Client)
  • invertika-account (Account­ser­ver)
  • invertika-game (Game­ser­ver)

Der Quell­text sollte in den nächs­ten Tagen im Repo­sitory (http://source.invertika.org) erschei­nen und zur Mit­ar­beit ein­la­den ;)

Wei­tere Infor­ma­tio­nen gibt es unter:
http://invertika.org

Ein Ubuntu Ser­ver upzu­gra­den ist so eine Sache, vor allem wenn man auf den Ser­ver nur per SSH zu grei­fen kann. Kon­kret geht es in die­sem Arti­kel um ein Update von 10.04 (Lucid) auf 10.10 (Maverick). Dazu instal­lie­ren wir erst ein­mal das Paket „update-manager-core“ mittels

apt-get install update-manager-core

und schauen dann mittels

nano /etc/update-manager/release-upgrades

in die Kon­fi­gu­ra­ti­ons­da­tei des sel­ben. Dort sollte eine Zeile

Prompt=lts

ste­hen, wel­che wir in

Prompt=normal

ändern. Nun sor­gen wir noch dafür das der Ser­ver auf dem aktu­ells­ten Stand ist, bevor es an das Update geht:

apt-get update
apt-get dist-upgrade

Da das Update über SSH gesteu­ert wird und es pas­sie­ren kann das die SSH Ver­bin­dung wäh­rend des Updates weg­bricht, star­ten wir den Updatevor­gang über „screen“ an:

screen do-release-upgrade

Das Upgrade star­tet dann und bringt einige Mel­dun­gen und Fra­gen wel­che bestä­tigt wer­den müs­sen. Gleich­zei­tig sagt es dem Nut­zer Bescheid das ein wei­te­rer SSH Ser­ver für den Not­fall auf dem Port 1022 gestar­tet wurde. Nach dem Upgrade schauen wir ob die neue Ver­sion auch ange­kom­men ist und star­ten den Rech­ner neu:

cat /etc/lsb-release
reboot -f

Nach dem Neu­start sollte dann erst mal wie­der ein

apt-get update
apt-get dist-upgrade

aus­ge­führt wer­den um sicher­zu­stel­len das das Sys­tem aktu­ell ist. Bei mir tra­ten hier zwei Pro­bleme auf. Das erste Pro­blem äußerte sich in der Fehlermeldung:

Failed to connect to socket /com/ubuntu/upstart

Hier half es im Terminal

dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

ein­zu­ge­ben und das ganze Upgrade wie­der zu star­ten. Der zweite Feh­ler war

/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

Hier half es das Paket „grub-pc“ zu dein­stal­lie­ren und durch das Paket „grub“ zu erset­zen. Danach lief das Upgrade nor­mal durch und Maverick war auf dem Ser­ver installiert.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/GRUB
http://wiki.ubuntuusers.de/upgrade
http://wiki.ubuntuusers.de/Upgrade_auf_Maverick
http://mrzard.posterous.com/failed-to-connect-to-socket-comubuntuupstart

Bei MiniDLNA han­delt es sich um ein UPnP/DLNA Ser­ver, mit wel­chem man z.B. auf einen Fern­se­her strea­men kann. Im Gegen­satz zu Media­tomb und uShare arbei­tet MiniDLNA pro­blem­los mit Samsung Fern­se­hern zusam­men und bie­tet so MKV, AVI und noch einige andere For­mate. Nur das spu­len scheint lei­der nicht zu funk­tio­nie­ren :(

Möchte man MiniDLNA auf einem Ubuntu Ser­ver auf­set­zen so sollte man es mittels:

sudo apt-get install minidlna

instal­lie­ren. Nach der Instal­la­tion geht es an die Kon­fi­gu­ra­tion. Dazu öff­net man die conf Datei mittels

sudo nano /etc/minidlna.conf

Nach der Kon­fi­gu­ra­tion könnte die Datei dann so aussehen:

# port for HTTP (descriptions, SOAP, media transfer) traffic
port=8200

# network interfaces to serve, comma delimited
network_interface=eth0

# set this to the directory you want scanned.
# * if have multiple directories, you can have multiple media_dir= lines
# * if you want to restrict a media_dir to a specific content type, you
#   can prepend the type, followed by a comma, to the directory:
#   + "A" for audio  (eg. media_dir=A,/home/jmaggard/Music)
#   + "V" for video  (eg. media_dir=V,/home/jmaggard/Videos)
#   + "P" for images (eg. media_dir=P,/home/jmaggard/Pictures)
media_dir=A,/home/seeseekey/share/Media Archiv/Group Musik
media_dir=V,/home/seeseekey/share/Media Archiv/Group Video

# set this if you want to customize the name that shows up on your clients
friendly_name=LEXA

# set this if you would like to specify the directory where you want MiniDLNA to store its database and album art cache
#db_dir=/var/cache/minidlna

# set this if you would like to specify the directory where you want MiniDLNA to store its log file
#log_dir=/var/log

# this should be a list of file names to check for when searching for album art
# note: names should be delimited with a forward slash ("/")
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg

# set this to no to disable inotify monitoring to automatically discover new files
# note: the default is yes
inotify=yes

# set this to yes to enable support for streaming .jpg and .mp3 files to a TiVo supporting HMO
enable_tivo=no

# set this to strictly adhere to DLNA standards.
# * This will allow server-side downscaling of very large JPEG images,
#   which may hurt JPEG serving performance on (at least) Sony DLNA products.
strict_dlna=no

# default presentation url is http address on port 80
#presentation_url=http://www.mylan/index.php

# notify interval in seconds. default is 895 seconds.
notify_interval=900

# serial and model number the daemon will report to clients
# in its XML description
serial=12345678
model_number=1

# use different container as root of the tree
# possible values:
#   + "." - use standard container (this is the default)
#   + "B" - "Browse Directory"
#   + "M" - "Music"
#   + "V" - "Video"
#   + "P" - "Pictures"
# if you specify "B" and client device is audio-only then "Music/Folders" will be used as root
#root_container=.

Wenn man mit der Kon­fi­gu­ra­tion fer­tig ist sollte man die Daten­bank ein­mal neu erstel­len. Dies funk­tio­niert mittels:

sudo minidlna -f /etc/minidlna.conf -R -d

Möchte man MiniDLNA neu­star­ten so funk­tio­niert das mittels:

sudo /etc/init.d/minidlna restart

Anschlie­ßend kann man sich seine Medi­en­samm­lung auf den Fern­se­her strea­men lassen.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/MiniDLNA
http://www.icancode.de/2011/07/samsung_dlna/
http://pario.no/2011/08/29/configure-minidlna-to-work-with-a-sony-bravidia-kdl-40ex711-tv/

Ges­tern habe ich mein NAS (mit Ubuntu Ser­ver) von 11.04 auf 11.10 geup­datet. Soweit lief auch alles gut. Nur ein Pro­blem gab es: der Rech­ner wollte nicht her­un­ter­fah­ren. Nor­ma­ler­weise fuhr ich ihn immer mittels

sudo halt

her­un­ter. Dabei fährt er das Sys­tem auch her­un­ter, bleibt dann am Ende aller­dings ste­hen und schal­tet das Netz­teil nicht ab. Abhilfe schafft es hier

sudo shutdown -h now

oder

sudo poweroff

wel­che den Rech­ner beide erfolg­reich herunterfahren.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/herunterfahren
http://linux.about.com/library/cmd/blcmdl8_halt.htm
http://www.cyberciti.biz/faq/shutdown-ubuntu-linux-computer/