Tag Archives: xbmc

Fixing HDMI-CEC on the Wandboard

I (Hanny) have recently bought a Wandboard Quad and have been playing with it since I got it. My primary objective was to get XBMC running on that device using ArchLinuxARM which was possible after some fiddling with the proprietary stuff (this deserves its own post some time in the future). Many thanks to Stéphan Rafin, without his work, I would not have been able to do that.

After finding out (also, thanks Stéphan) that the Freescale i.MX6 SoC on the Wandboard supports HDMI-CEC, I was eager to get it running on the wandboard. Sadly though the CEC signal is not properly routed on the wandboard.

But according to a post in the wandboard forums with instructions, you can actually fix this if you have some soldering skills (which I have absolutely not!). So I handed my board to a fellow PI member (Neutrino) who will describe the things he did:

The pins for CEC are available but there is no connection from the SoC to the HDMI-connector. But if you have some SMD-soldering skills (or a friend who can do that), you can fix it yourself. Be careful though as this WILL VOID YOUR WARRANTY.

It isn’t hard to solder the 3 things but you should be careful not to damage a pad. You need a soldering tip with 1,5-3mm width, thin solder, an electronic tweezer and a good loupe (or microscope). Soldering flux is also helpful for good joints.

1. You have to remove the 0Ω resistor R383 on the bottom side of the processor board. Maybe you could unsolder it carefully, to recycle it in step 2. Because it is in tiny 0402 package I unsoldered it at one time with a 2mm width soldering tip on the side over both soldering joints and add a bit solder until I could smoothly push the resistor from the pads.
2. We need to connect the 2 empty pads of R405 on the bottom of the baseboard. We could use the R383 resistor or a piece of wire which we cut after soldering on both pads or maybe we simple solder a soldering blob over the two pads (I took a new 0Ω resistor in 0402 package because I had it in my reach).
3. The “most difficult” part is to solder a wire from the connector-side pad of R383 to the testpoint TP78 on the bottom side of the processor board. Cut a 2cm piece of insulated thin wire bend it right and remove insulation or enamel the ends before soldering it.
 

Bottom side of processor board.

Bottom side of processor board. The white line shows to the testpoint-labels. The purple line illustrate the wire.

Enamelled copper wire from below pad of R383 to testpoint TP78.

Enamelled copper wire from below pad of R383 to testpoint TP78.



This two empty pads of R405 have to be short connected together.

This two empty pads of R405 have to be short connected together.



Thanks again Neutrino!

To me(Hanny), the needed software-modifications are far more simpler :)

Now that you have routed the cec signal to the right pins, you just need a slightly modified kernel and a modified libCEC (thanks again, mighty Stéphan :)).

You’ll have to compile the modified kernel (be sure to set CONFIG_MXC_HDMI_CEC in the kernel config) and the modified libCEC and install both (you can find PKGBUILDs for ArchlinuxARM here).
If you now connect hdmi to a CEC-enabled tv (every manufacturer calls it differently!), cec-client should spit out some data!

Compiling xbmc with

should enable libCEC in xbmc. Afterwards, xbmc should recognize your TV as CEC input device and the whole thing should work!

XBMC on the Raspberry PI running ArchLinux

Finally after a very long time I’ve found the motivation to write a new post, yay :)

I’ve gotten myself a RPI a long long time ago with the primary target to use it as a htpc (Desktops are powerful, but also loud and power-hungry. ARM-SoC are the exact opposite.)
I’ve since used various setups to get the maximum performance out of this very nifty but also really slow device.
If you are a beginner and not that experienced with linux in general, I’d recommend Sam Nazarkos Raspbmc. Sam frequently adds new tweaks to the distribution and keeps the xbmc-builds updated.

But being an ArchLinux fanatic I just couldn’t stand the fact that there is an ArchLinuxARM version available for the Raspberry and not having it installed on mine. Also installing Arch-ARM is even easier than installing the ‘normal’ Arch (you just dd the image to the sd-card).
But after you have installed ‘xbmc-rbp’ from the repos you end up with a system that is too slow to play DTS tracks, doesn’t start xbmc at boot, has a slower GUI than raspbmc and boots slower than raspbmc. (You can fix the DTS-problem easily by using an AV-Receiver which does the DTS-Decoding, but as I don’t have such a device at the moment I had to find another solution…)
This is why im going to point out the modifications I’ve done to my system to make it as awesome as a £27.84 arm-development board could possibly be :)

Warning: I’ve noticed, that this post is still relevant and gets read a lot. I do not use my raspberry for xbmc anymore as I have bought a wandboard quad now (see some of the other posts here). Nearly all of the advice given in this blog is still totally valid, but the parts where I mention very specific build dates or versions should be taken with a grain of salt. Just keep in mind that most likely a lot has changed during those few months and the specific problems with specific versions I mention are most likely gone.

Changelog
20130707 – initial post.
20130816 – some updates, including kernel 3.10 and xbmc-rpb-git.
20130912 – updates to the f2fs section.
20130913 – updated python script.
20131020 – update f2fs section, added custom xbmc build
20131023 – added information about sqlite (see xbmc-rbp-git section)
20140125 – added notes about the wandboard

Overclocking
The most powerful and easiest solution to boost the performance is to run the device at a higher speed. In this post it even souns like if the Raspberry Foundation kinda ‘recommends’ overclocking. As far as I know (im not responsible for your raspberry overheating and creating another human-like species which threatens the life on our planet) there are no down-sides to the stability (provided you have a strong powersupply) or the lifetime of the device. (Using the this settings doesn’t even void your warranty).

All you have to do is include this snippet in your /boot/config.txt

Using a modified version of memory-functions like memcpy
This is a library that implements standard system-functions like memcpy/memset/strcpy (and even more) in hand-written assembler. This improves general performance and made a noteable difference in playback-performance (at least for me).
On Arch-ARM all you have to do is install ‘arm-mem-git’ and reboot.

Using kernel 3.9 3.10 3.11 and f2fs
While f2fs does not affect playback performance (at least not over the network) it does greatly improve the booting-speed and speeds up the general performance.
F2FS (Flash-friendly FileSystem) is a file-system designed by Samsung specifically for flash-drives and is said to improve filesystem performance and is available since kernel 3.8.
To use it on the raspberry you have to install ‘linux-raspberrypi-latest’ and ‘linux-headers-raspberrypi-latest’ on the pi and then recreate your filesystems.
I did that on my archlinux-desktop (you have to use a recent kernel and have to have mkfs.f2fs, packaged in ‘f2fs-tools’). Just cp -a the contents of the /-partition to a temporary directory (don’t use a ntfs-volume, you’ll have to preserve the file-attributes), mkfs.f2fs on the partition and then cp -a it on the new filesystem. The only thing thats left to do now is to change the parameter “ext4” in /boot/cmdline.txt to “f2fs” and its going to boot off your new shiny f2fs.
Do not downgrade your kernel afterwards as 3.6 does not include f2fs.

Update: This does also work fine with kernel 3.10. Sadly, the current (3.10.6-1, 20130816) kernel does not boot on the raspi so you have to stick to 3.10.4-2 posted here. 3.10 does bring some changes to f2fs, the newest version of 3.10 (3.10.6) should also improve overall performance. Sadly its not available yet but it sure will be soon :)

Update: I’ve had some recent issues with f2fs like total corruption to the filesystem after a hardreset (On 3.10). I’ve therefore switched back to ext4 (you do notice the slower performance) :/ I have yet to try f2fs with 3.11.

Update: Back to f2fs, it just feels much faster, especially while navigating with the shell. I’ve not found anything to counter corruption, it seems to happen more or less randomly. I just keep a backup of my root-filesystem and write it over as soon as it corrupts :/

Use kernel-space nfs implementation with big buffers
While xbmc does have the feature to use nfs shares, I’d recommend using mount.nfs4 for maximum performance. I’ve played around with the values a bit and this is what my /etc/fstab looks like:

Using udp and rsize=32768 gave me the best results in raw transfer performance.
Also, nfs uses less CPU than smb which frees capacity for those DTS-tracks

Update: I switched back to tcp because udp seems to be a bit unreliable, even over very reliable networks (around 2m cable distance, 1 gigabit switch). TCP is still fast enough to play the samples I am using.

Use xbmc-rbp-git
The newest versions of xbmc (Gotham alpha 7 or later builds or builds off the master-branch) include a sick patch for the dts decoder. According to the pull request, some guys hand-optimized the dts-decoder for the SoC of the raspberry in assembly which in turn runs 36% faster now! On archlinux, all you have to do is ‘pacman -S xbmc-rbp-git’.

According to the database table versions 12.2 and 13 alpha7 do not share the same database version, this means you should backup your .xbmc-folder in case you want to switch back later.

Update: xbmc-rbp-git has not been updated for a very long time (nearly 2 months now). I’ve chosen to compile my own build and got it working by modifyin the PKGBUILD slighty (issue is filed, info supplied to upstream) and im going to provide the binaries here!
You’ll have to download the tar file, extract it and install all the packages I’ve provided. The new firmware is necessary because xbmc relies on a never version of the userspace-libraries than the one which is provided in the repos (surely they will update it some time in the future…).
As always: back up your .xbmc folder :)

Update: I’ve submitted my changes to archlinux PKBUILDs master. The firmware was updated and xbmc should also be built but I’ve not been able to verify it yet).

Download:
20131019 – (xbmc at 37a0959099ce6589221c10097f2161558d1710ce, firmware at 4c1456944b5f6cc9e5141077ed4e158398811fc1)

Altough this build technically works, I’ve experienced some issues such as tv shows not being listed etc. I’ll provide a new build as soon as this changes :)
Update: According to the archlinux bug-tracker and the xbmc bug-tracke the problem with the library seems to be related the the 3.8.1 version of sqlite. As a workaround, you can downgrade to the previous version of sqlite until this is fixed.

Autostart xbmc and change governors on the fly
Most likely, you’ll want to have xbmc autostarted at boot, so you have to create a service for starting it.
I’ve added a small wrapper script and some python code to change the cpu-governor to RoundRobin and change the io scheduler of the xbmc performance as soon as you hit play.
The Round-Robin governor does improve the performance on playback, but decreases it if you want to browse through the library, thats why I decided to switch it on demand.
The python-script does only wirk with python 2.7, not with python 3 or higher.

The bash start-script does also stop policy-kit which uses a few megabytes of ram if its running. You can stop it and reboot/shutdown in xbmc still works, I’ve yet to discover any downsides.

I don’t know if changing the governor to performance is equivalent to force_turbo=1 which (if you used my overclocking settings) does void your warranty!. If you don’t want the script to change the governor, remove the appropriate lines in the python-file.

Im running xbmc as user ‘xbmc’ in ‘/home/xbmc’

While you should definitely not start to learn python off this code, it does work as expected and I have no intents to refactor it :)

Update: I’ve been having some weird issues with xbmc-git lately where it does only listen on ipv6, not on ipv4 which means 127.0.0.1 doesn’t work there. You can see if xbmc sends its event via the socket by telnetting to 127.0.0.1:9090. If you get permission denied or similar, try ::1:9090. If it works change the address in the script aswell as the socket to AF_INET6.

Update: I’ve updated the script and fixed an issue where the script did not change governors if you playback a ‘episode’ rather than a ‘movie’. Earlier xbmc versions did not make a difference here.
Thinking about rewriting the whole thing in go, not sure what the benefits would be…

These modifications greatly increase booting speed, render the xbmc-ui useable and improve the playback-performance in xbmc. I’ve some mkv Files which are about 20g in size and have 3 different DTS-tracks at around 1500kbit/s and they play smoothly (played over nfs of course :))

I can’t remember any more modifications I applied, but if I find something else I’ll keep this post updated!
If you know of any other things I can do to improve performance, I’d be more than happy to read about them in the comments :)

ArchLinux Touchscreen-CarPC mit XBMC-Frontend

Hardware setup

Die Idee hinter der Hardware des CarPCs war, das Ganze möglichst kostengünstig mit bereits vorhandenen Teilen zu realisieren. Deshalb sind einige der Komponenten nicht wirklich optimal. Außerdem hatte ich mir zum Motto gemacht im Zweifelsfall die Dinge lieber selbst zusammenzubasteln als etwas fertiges zu kaufen.

Der Rechner selbst ist ein ASUS EeePC 1000H der wegen eines gesprungenen Display ausgemustert wurde. Um im Auto selbst Platz zu sparen wurde lediglich die Hauptplatine mit der Festplatte eingebaut. Die 160GB Festplatte ist mit SATA direkt auf der Platine angeschlossen und mit Heißkleb fixiert. Zur Kühlung des Netbooks wurde entfernt und durch eine Metallplatte, die auf dem Prozessor (Intel Atom) und dem Chipsatz der Motherboards aufliegt, ersetzt.

Das Auto in dem der CarPC verbaut wird ist ein Nissan Primera. Hier gibt es ein kleines, flaches Fach unter dem Lenkrad, in das die Platine hinein passt. Lediglich für die Stecker die rund um die Platine eingesteckt werden benötigen mehr Platz. In dem Plastik oberhalb des Fachs wurde zusätzlich ein kleiner Lüfter angebracht der die Luft über der Kühlungsmetallplatte in Bewegung hält. Die Kühlung ist auch ohne Kühlrippen ausreichend, das die Wärmeentwicklung so gering ist.

Die Stromversorgung gestaltete sich relativ kompliziert, da der EeePC zwar 12 V Eingangsspannung braucht aber die Spannung des Bordnetzes im Auto zu stark schwankt und der Rechner früher oder später ausgeht. Außerdem stellt sich das Problem wie starke Spannungsabfälle, wie etwa beim Anlassen des Motors, abgefangen werden, damit der Rechner weiterläuft. Ein handelsübliches ATX-Netzteil für den Autobetrieb kann an den EeePC nicht angeschlossen werden und der Originalakku ist auch nicht mehr vorhanden. Für einen eventuellen Neu- oder Nachbau des CarPCs ist hier wahrscheinlich das größte Verbesserungspotential vorhanden.
Letztendlich wird der Rechner von einem KFZ-Netzteil für Laptops mit konstanter 12V Spannung versorgt
Zur Überbrückung von Spannungeinbrüchen wurde zusätzlich ein kleiner 12V Bleiakku mit 3.4 Ah verbaut und mit einer Diode der Stromrückfluss ins Bordnetz verhindert.

Der Plan ist mit einem Microcontroller noch ein automatisches Zuschalten des zusätzlichen Akkus sowie das An-/Abschalten der Rechners mit Drehen des Zündschlüsseln zu verwirklichen.

Angeschlossen an der Rechner sind:

  • 1x Line-Out (Klinke) zum Radio
  • 1x USB Hub im vorderen Bereich des Autos
  • 1x USB Hub im Kofferraum
  • 1x USB für Touchscreen
  • 1x VGA für Touchscreen

Der Bildschirm ist ein resistiver 8″ Touchscreen (lsusb -> Bus 003 Device 006: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen) mit einer nativen Auflösung von 1024×768 Pixeln. Eingelassen ist er in die Mittelconsole etwa auf Lenkrad Höhe. Für den Einbau des Touchscreens wurde das Radio nach unten in die Nähe des Schaltknüppels verschoben und die Lüftungsgitter wurden entfernt.

An den USB-Hub im Kofferaum ist ein GPS-Empfänger angeschlossen, der direkt unter der Heckscheibe befestigt und somit nicht durch die Karosserie behindert wird.

Software setup

Die Softwarebasis des CarPCs stellt eine unveränderte x86-ArchLinux Distribution dar, die nur “Core”-Software bereitstellt, also keine graphische Oberfläche oder unerwünschte, im Hintergrund laufende Daemons die garnicht benötigt werden. Das “Minimal”-Betriebssystem ist besonders praktisch, um eine sehr anpassungsfähige, von der Konfiguration nachvollziehbare und performance-orientierte Architektur unterhalb des eigentlichen XBMC-Frontends zu garantieren. Dieses Tutorial setzt eine mit Standarteinstellungen installierte ArchLinux-Version (linux>3.5,xbmc=11,xorg-server>1.12,systemd) voraus, auf dessen Installation hier aber nicht wieter eingegangen wird.

Wurde das Betriebssystem erfolgreich installiert, über LAN mit dem Internet verbunden und ist nach dem Root-Login einsatzbereit, kann die Konfiguration des Betriebssystems vorgenommen werden.

Netzwerk einrichten, Packetquellen einstellen

Mit einen der folgenden Befehle werden die Netzwerkeinstellungen gesetzt (entweder automatisch oder manuell) und danach extra Paketquellen in der Konfigurationsdatei des Paketmanagers hinzugefügt, indem vor der “[Extra]”- und der darunterstehenden “Include”-Zeile die “#”-Kommentarzeichen entfernt werden:

Darauf hin können alle Software-Pakete heruntergeladen und installiert werden, darunter unter anderem:

  • Video-Treiber und X-Server (Touchtreiber: xf86-input-evdev)
  • GPS-Daemon und eine grafische Statussoftware für denX-Server (gpsd, xgps)
  • Netzwerkmanager und Bluetooth-Daemon (wicd, bluez)
  • Audiotools und Audiocodecs (alsa-utils, libvorbis)
  • Xbmc-Mediacenter
  • Automount-Programm (udevils, beinhaltet devmon)

Der Pacman-Wrapper Yaourt wird benötigt um zusätzliche Programme aus dem “Arch User Repository” (AUR) herunterzuladen, unter anderem:

  • Das freie Navigationssystem Navit und für Windows Navigationsprogramme die Laufzeitumgebung Wine
  • ein Touchscreen-Kalibrierungsprogramm (xinput_calibrator)
  • ein Benachrichtigungsprogramm für ein mit Android betriebenes Smartphone (android-notifier-desktop)
  • und ein Freisprechgateway/eine Bluetooth Handsfree-Software namens hfpforlinux

Benutzer erstellen, Zugriffsrechte erstellen

Jetzt wird ein normaler Benutzer ohne administrative Rechte erstellt (der auch Xbmc ausführen soll) und zusätzlich in die sudoers-Datei eingetragen, um bei bedarf wieder “Superuser”-Rechte zu bekommen. Eine Anleitung für ein Autologin findet man hier. Anmerkung: Anstatt vi kann auch z.B. nano als Editor benutzt werden. Vim muss jedoch erst mit dem Paketmanager Pacman installiert werden.

Mit dem Programm visudo folgende Zeile in die sudoers-Datei hinzufügen (in diesem Beispiel heißt der Benutzer carpc!!):

XBMC und X-Server konfigurieren

Mit folgenden Befehlen werden wichtige Addons für XBMC installiert (aber noch nicht aktiviert! see here), wie z.B. ein Wicd-Frontend mit dem man sich innerhalb von XBMC mit WLAN-Netzwerken verbinden kann, sowie das eigentliche Touchscreen-Theme “carpc”:

Die Datei .xinitrc dient dazu, Befehle nach bzw. mit dem X-Server start auf dessen aktivem Display auszuführen. Die hier aufgelisteten Befehle starten zum einen das Navigationssystem im Hintergrund via xvfb und zum anderen ein Automountscript (devmon/udevil) und XBMC.

Folgende Service-Datei startet den X-Server automatisch (für den Benutzer carpc):

Für unseren Touchscreen wurde folgende Konfiguration benötigt. Die Kalibrierungswerte wurden mit dem Programm xinput_calibrator ermittelt, welches leider nach unserer Erfahrung einen Window-Manager benötigt wie Metacity um zuverlässig zu funktionieren (TTY1: export DISPLAY=:0 && xinput_calibrator && metacity –replace).

Navigations-Software

Testweise verwenden wir hierfür die von Nav&Go entwickelte Navigations-Software “iGO 8.3.1.59883 R3-Version PC”, von der es leider keine Updates mehr gibt (letzte Version vermutl. von 2008). Trotzdem ist diese unter Linux via Wine lauffähig, bietet eine hervorragende grafische Touch-Oberfläche, unterstüzt neuste Kartenformate (z.B. Maps Europa TomTom R3 (TeleAtlas)) und lässt sich auch gut in XBMC einbinden. Wine wurde schon vorher installiert, desweiteren müssen noch folgende Programme installiert werden (zum Zeitpunkt der Veröffentlichung des Beitrags, hatte winetricks noch einen Bug bezüglich allfonts):

Der Befehl lsusb zeigt das GPS-Device an, hier nur in Form eines USB-Serial-Wandlers. Desweiteren sollte auch ein ttyUSB0-Interface auftauchen, für das mittels gpasswd der User leserechte erhält (alternativ kann dies auch mit udev-rules bewerkstelligt werden). Für die Windows-Anwendung iGO wird dieses Interface als virtuelle Schnittstelle in den dosdrives Ordner gesymlinkt. Welche Port-Nummer hierbei das Gerät hat ist irrelevant, solange iGO dieses noch automatisch finden kann (also ca. com1-com6). Mit cat lässt sich nun der GPS-NMEA Stream anschauen, der im roh-format die aktuelle Position beinhaltet.
Die Baudrate des angeschlossenen GPS-Devices lässt sich mit stty ermitteln, falls man diese manuell später in iGO festlegen möchte:

In ~/.wine/user.reg müssen noch folgende zwei Zeilen hinzugefügt werden, um das Wine-Systray zu deaktivieren:

In dem Script, das gestartet wird, wenn man in XBMC den Menüpunkt Navigation auswählt, muss in den ersten Zeilen auch der Pfad zu der iGO.exe angegeben werden. Dieses Tutorial geht, wie vielleicht bei Befehlen zuvor schon gemerkt von einer Installation in /opt/iGO8.3_PC aus: ~/.xbmc/addons/skin.carpc/script/script
Es muss zudem sichergestellt sein, dass der WM XBMC nicht in den “floating” o.ä. Mode setzt, sondern wie ein normales Fenster behandelt. Ansonsten starten iGO aus dem Skript nicht ordnungsgemäß heraus. Mittels der “\”-Taste (Backslash) kann in XBMC der Modus zwischen Vollbild und Fenstermodus gewechselt werden. Falls die rc.conf noch nicht editiert wurde (wie später beschrieben) und auch noch kein Neustart durchgeführt wurde, kann der virtuelle X-Server, in dem iGO dann ausgeführt wird, auch manuell schon gestartet werden via: sudo /etc/rc.d/xvfbd start

Anmerkung: Laut einem Beitrag bei mp3car.com ist es für andere Anwendungen wie Garmin PC Mobile oder Sygic Drive notwendig eine Devicemap der Serial-Ports in der Wine-Registry anzulegen.

Kleinere Systemeinstellungen

Für ein deutsches Keyboard-Layout innerhalb des X-Servers muss folgende Datei angelegt werden:

Zuletzt sollte noch mit einem Befehl die aktuell, mit z.B. alsamixer gesetzte Lautstärke persistent gespeichert werden. Mit dem Befehl systemctl enable werden die Dienste bluez und wicd automatisch gestartet:

Work in progress …

Die nächsten Schritte des Projektes sind:

  • Eine Freisprechanlage, realisiert mit hfpforlinux (Projektseite), die sich via. Bluetooth mit dem Android-Handy des Fahrers verbindet.
  • Sprachausgabe für Navit.
  • Alternatives Navigations-System Navigator 11 von Mapfactor (ist kostenlos!)
  • Alternative Setups mit Android 4.0 x84 (es gibt auch schon VBox-Images für 4.1), Win7 (CPOS CarPC-Software / iCT(inCar Terminal) /Centrafuse) und Windows 8 mit MetroUI
  • Automount funktioniert leider noch nicht ganz.
  • XBMC-Theme fertigstellen
  • Gpsd.conf fehlt noch
  • Android-Telefon automatisch mti Obexfs mounten und Multimediadateien in XBMC einbinden und z.B. einen Bluetooth-Audiogateway für Handys bereitstellen.
  • Bluetooth-Audiogateway mit PulseAudio, um die Audioausgabe eines Mobiltelefons direkt an den CarPC weiterzuleiten.
  • (Infrarot)Webcam, um z.B. schwer einsehbare Straßenabschnitte auf dem CarPC sichtbar zu machen oder auch um in bestimmten Zeitintervallen einzelne Bilder aufzunehmen (für Zeitraffervideos)

Credits:

Anmerkungen:

Ich bitte darum, Kritiken, Verbesserungsvorschläge oder Alternativkonzepte in den Kommentarbereich zu schreiben. Es ist nicht einfach, einen Überblick über vorhandene CarPC-Projekte und dazugehörige Software im Internet zu finden, deswegen würden wir uns über jede Anregung freuen, danke.

Weiterführende Links:

  • Car-PC.info – Webseite mit Forum, Wiki (Anleitungen) und einer Übersicht (zum Teil veraltet) zu verschiedener CarPC-Software.
  • Android-Notifier Google-Code Projektseite
  • Mp3Car.com – Forum mit vielen hilfreichen Beiträgen zum Thema CarPC
  • Liste mit alternativen CarPC-Systemen sowie weitere Software
  • nghost2 – Eine leider seit 2008 nicht mehr weiterentwickelte, native CarPC-Software. Benutzt SDL++-Library für die grafische Darstellung (SourceForge Projektseite)
  • nghost3 – Ein relativ aktueller Prototyp und kompletter rewrite von nghost2 auf Basis von QT4 und Clutter (GitHub Projektseite)
  • centrafuseauto 4.0 beta gibt es auch für Linux, zwar noch in der Beta, aber schön zu sehen, dass sich die Entwickler die Mühe machen, so ein großes Projekt auch für andere Systeme lauffähig zu machen. Da es sich um eine frühe Beta-Version handelt, ist es in diesem Fall abzuraten, die Software als Alternative schon einzusetzen. Wohingegen die Windows-Version schon richtig gut funktioniert, aber leider noch nicht so viele Modifizierungsmöglichkeiten anbietet. (Projektwebseite)

Changelog:

  • 09.12.2013 – Kleinere Korrekturen
  • 10.10.2012 – Aktualisierte Version, mit: Xbmc 11, Kernel 3.5, Xorg 1.13, Systemd, iGO 8.3 (Navigations-System), skin.carpc 1.0
  • 23.12.2011 – Originaler Beitrag

Homeserver Setup mit Ubuntu: Samba Fileserver

Da immer mehr Leute sich gerne zuhause einen eigenen Homeserver aufsetzen um ihre Filme, Bilder oder andere Dateien gemeinsam zu speichern und zu nutzen, wollte ich dieses Thema auch hier im Blog mal aufgreifen.Ich habe selbst einen eigenen, kleinen Homeserver mit 1,5 TB Speicher und einem µATX Board mit Intel Atom Prozessor. Ich nutze den Server hauptsächlich zum lagern von Filmen, die an allen Rechnern im Haus abgespielt werden können. Dafür nutzte ich XBMC an den Clients.

Auf dem Server selbst läuft ein Ubuntu Server Edition 11.04 mit einem Samba Fileserver. Da die Konfiguration von Samba nicht immer auf Anhieb funktioniert werden ich meine Vorstellungen und (gelöste) Probleme hier mal beschreiben in der Hoffung damit jemanden zu helfen.

Die INSTALLATION gestaltet sich unter Ubuntu Gott sei Dank sehr einfach:

Ist Samba installiert hat man verschidenen Möglichkeiten die Konfiguration vorzunehmen. Zum einen kann sie über das Webinterface SWAT, welches eines der bekanntesten Konfigurationstools ist, vorgenommen werden. Andere GUI Tools gibt es auch hier.

Wer ein wenig tiefer gehen möchte, oder wer auf der Suche nach Bugs ist, wird schnell feststellen, dass man um manuelles konfigurieren nicht herumkommt. Unter Ubuntu findet sich die Configfile von Samba under /etc/samba/smb.conf
Diese Datei ist in verschiedene Sektionen aufgeteilt. Es wird hier hauptsächlich zwischen allgemeinen und Freigabespezifischen Einstellungen unterschieden (siehe unten). Ich will hier nicht alle Konfigurationenmöglichkeiten durchkauen, das würde auch den Rahmen dieser Seite sprengen. Mein Ziel war zu Anfang Freigaben wie Musik und Filme für alle (inkl. Nutzer ohne Account) zugänglich zu machen und bestimmte Freigaben wie private Dateien und Backups nur für ausgewählte Nutzer  freizugeben. Nutzer die Schreibrechte in privaten Ordnern haben, sollen auch Schreibrechte in den öffentlichen Ordnern haben.

Hierzu muss man erst einmal die Benutzer im System anlegen. Jeder Nutzer in Samba muss auch ein echter Linuxuser sein. Das heißt wir legen alle Nutzer zu erst einmal im System an:

Mit diesem Befehl wird der User nutzerXYZ angelegt, es wird jedoch kein Home-Ordner erstellt (-M) und auch keine extra Gruppe für den Benutzer angelegt (-N). Mit

wird der Nutzer als Sambauser angelegt und kann fortan benutzt werdern um sich auf Freigaben einzuloggen. Die Benutzer können mit

wieder gelöscht werden. Nun schauen wir uns mal die smb.conf selbst an. Die Datei beginnt mit der [global] Sektion in der sämtliche allgemeine Einstellungen stehen.

  • workgroup – Ist natürlich die Arbeitsgruppe in der der SMB-Server erscheinen soll.
  • server string – Ist der Hostname der, etwa in der Netzwerkumgebung von Windows, angezeigt wird
  • log file – gibt die Datei an in der alle Ereignisse des SMB-Servers festgehalten werden
  • security – ist diese Option auf “user” gesetzt muss sich ein User am Samba Server zuerst anmelden und sieht dann die verschiedenen Freigaben. Ist die Option auf “share” gestellt, werden dem User erst die Freigaben angezeigt und er loggt sich dann bei einer einzelnen ein
  • map to guest – “bad user” bedeutet wenn sich jemand mit einem User versucht einzuloggen der in Samba nicht existiert. In diesem Fall wird der Benutzer als Gast eingeloggt und hat auch nur entsprechende Rechte.
  • guest account – ist der Account der als Gast verwendet wird. Normalerweise ist diese Option auf nobody gesetzt. Es wäre allerdings auch möglich hier einen anderes Benutzer einzutragen.
Öffentliche Freigabe:

  • path –  ist der Pfad zu freizugebenden Ordner
  • comment  – Kommentar
  • public – Die Freigabe kann grundsätzlich von jedem  angesehen werden. Schreibrechte werden in der nächsten Option geklärt.
  • write list – hier werden die Nutzer angegeben die in der Freigabe Schreibrechte haben. Alle anderen haben automatisch nur read-only zugriff.
  • force create mode/ force directory mode – Hier werden die Datei- und Ordnerrechte für neue Objekte gesetzt. Mit 0777 hat auf eine neu erstellte Datei bzw. einen neu erstellten Ordner jeder Zugriff.
Private Freigabe:

  • Hier ist nur die Option public = no gesetzt. Das hat zu Folge, dass niemand die Freigabe öffnen kann, es sein denn sein Nutzername steht in der write list
Das sind nur die einfachsten Optionen um solch einen Fileserver aufzusetzen. Es gibt viele weitere Optionen für Schreib- und Leserechte oder Druckerfreigaben. Im Zweifelsfall sucht man sich seine Optionen für die smb.conf am besten in der SMB Manpage.