Munin auf SL, CentOS, RedHat Linux installieren

muninMunin ist ein Hardwaremonitoring Werkzeug für Linux/Unix Systeme, welches sehr einfach zu installieren ist und es ermöglicht, mehrere PCs und Server zu überwachen. Dabei fragt ein Master-Node in regelmäßigen Abständen die Clients und bereitet die Daten grafisch auf.

Installation

Die Installation ist sehr einfach gehalten. Installieren Sie zuerst als root mittels

yum install munin munin-node

die nötigen Pakete.

Klammern Sie nun in der Datei /etc/munin/munin.conf folgendes aus, um die Daten anzeigen zu lassen. Auf Clients müssen Sie dies nicht tuen, wenn nur Daten abgefragt werden sollen.


dbdir /var/lib/munin
htmldir /var/www/html/munin
logdir /var/log/munin
rundir /var/run/munin

Passwortabfrage

Später können Sie unter http://localhost/munin auf die Grafiken zugreifen. Wenn Sie dies durch ein Passwort geschützt haben wollen müssen Sie zuerst eines mittels

htpasswd -c /etc/munin/munin-htpasswd username

erstellen.

Außerdem müssen Sie noch eine Datei unter /etc/httpd/conf.d/munin.conf erstellen bzw. bearbeiten und mit folgenden füllen:


AuthUserFile /etc/munin/munin-htpasswd
AuthName "Munin"
AuthType Basic
require valid-user
ExpiresActive On
ExpiresDefault M310

ScriptAlias /munin-cgi/munin-cgi-graph /var/www/cgi-bin/munin-cgi-graph

Nach einem

service httpd restart

erscheint nun eine Passwortabfrage.

Plugins konfigurieren

Munin verfügt ab Werk über eine große Anazahl an Plugins. Diese liegen unter /usr/share/munin/plugins
Wenn Sie eines der Plugins verwenden möchten so müssen Sie es nur linken

ln -s /usr/share/munin/plugins/df /etc/munin/plugins

Ob zu kontrollieren, ob ein Plugin konfiguriert werden muss, können Sie es einfach ausführen:

./df autoconf

Erscheint ein Yes müssen Sie nichts mehr vornehmen.

Einige Plugins sind Wildcard Plugins und enden auf einen Unterstrich wie zum Beispiel sensors_. Führen Sie diese mit der Option suggest aus um die möglichen Optionen zu erhalten:

./sensors_ suggest

Nun können Sie ja nach gewünschter Option die Datei umbennen

mv sensors_ sensors_fan

Manche Plugins können in der Datei /etc/munin/plugin-conf.d noch weiter angepasst werden. Dies würde den Artikel aber sprengen, deswegen hier nur ein Beispiel:


[sensors_*]

env.ignore_fan3 true
env.ignore_fan4 true
env.ignore_volt3 true
env.ignore_volt7 true

[smart_*]
user root
group root

[hddtemp_smartctl]
user root
group root
env.ignore "sda"

Andere Systeme verbinden

Munin selber benutzt den Port 4949, den Sie in der Firewall, wenn laufend, frei geben müssen. Andere Munin Installation können dann von der oben eingerichteten Master-Server abgefragt werden. Wenn nur ein Client (Node) installiert wird, können Sie die Einstellungen von munin.conf und dem Apache ignorieren. Auschlaggebeden ist nur die munin-node.conf an der Sie allerdings nichts mehr einstellen müssen. Sie können dort festlegen welche IPs auf die gesammelten Daten zugreifen kann um diese Abzufragen.

Beim Master-Server tragen Sie die zusätzlichen PCs / Server in der munin.conf ein. Hier eine Beispiel:

[Lokal]
address 127.0.0.1
use_node_name yes
[Server_1]
address 10.0.0.5
use_node_name yes
[Server_2]
address 10.0.0.6
use_node_name yes

Interessante Links zum Thema

Cisco IP Phone 7960 mit Fritz!Box 6360 Cable

Cisco IP Phone 7960

Cisco IP Phone 7960

Das das Cisco IP Phone ein schönes Gerät ist, scheint in vielen Kreisen bekannt zu sein. Das gute ist, dass es sich als IP Telefon sogar an der Fritzbox nutzen lässt. Auch wenn es ein wenig Spielerei und Gefummel ist.

Die Geräte gibt es bei eBay für 30 bis 50 Euro gebraucht bzw. neu für etwa 120 bis 200 Euro.

Bitte zuerst die Anleitung komplett lesen. Auch den unten aufgeführten Link lege ich sehr ans Herz. Durch das flashen mit der falschen Firmware kann das Gerät u.U. nicht mehr funktionieren. Die Konfigurationsdateien können immer wieder neu eingespielt werden. Falsche Konfigurationsdateien sollten das Gerät nicht unbrauchbar machen.

Fritzbox vorbereiten

Einfach unter Telefonie > Telefoniegeräte > Neues Gerät einrichten klicken und dann Telefon auswählen. Im nächsten Dialog wählen Sie LAN/WLAN (IP-Telefon) aus und geben Sie dem Gerät einen Namen. Drücken Sie dann weiter. Im nächsten Dialog notieren Sie sich die Angaben und wählen ein Passwort aus. Dann noch die Rufnummer einrichten und das war es an der Fritz!Box auch schon.

TFTP Server einrichten

Windows

Für Windows empfehle ich TFTPD32.

Linux

Diese Anleitung bezieht sich auf CentOS / Scientific Linux.

yum install tftp-server
chkconfig --level 345 xinetd on
chkconfig --level 345 tftpd on

Die benötigten Dateien können dann später nach

/var/lib/tftpboot

abgelegt werden.

(Falls noch eine Firewall läuft muss der Port noch freigegeben werden. Dies kann mit system-config-firewall-tui geschehen.)

Konfigurationsdateien

Je nachdem welche Firmware Sie auf dem Gerät installiert haben müssen Sie dieses erst flashen. Die nötigen Dateien finden Sie, wen Sie einen Supportvertrag mit Cisco haben in deren Downloadbereich oder z.B. unter
http://radiotwenterand.nl/~graver/cisco/SIP-7960/

Ich habe mich für die Release P0S3-8-12-00.zip entschieden. Dies funktionierte auch bei mir ohne Probleme. Entpacken Sie das Archiv einfach in den tftpboot Ordner.

Nun kommt die schwierigere Aufgabe. Die Konfigurationsdateien für das Telefon. Hier habe ich bei http://www.europott.org/2009/05/31/cisco-7960g-und-fritzbox-fonwlan abgeschaut. Die Anleitung ist sehr gut gemacht und die zum Download bereitstehenden Konfigurationsdateien haben bei mir funktioniert. Dort beachten Sie einfach die Kommentare in den ersten Zeilen der Dateien. Die bennenung der der SIP[MAC].cnf wird auf der oben genannten Webseite erklärt.

Allerdings müssen Sie an der SIPDefault.cnf eine änderung vornehmen. Klammern Sie

# image_version: "P0S3-08-8-00" Auskommentiert da SIP Firmware schon geladen ist

aus und ändern Sie die Zeile so ab wie die Firmware heisst. In unserem Falle

image_version: "P0S3-8-12-00"

Wenn Sich das Telefon dann die Konfiguration abholen möchte wird es sich direkt flashen. Die beiden Konfigurationsdateien kommen dann nach dem Ändern der entsprechende Zeilen auch in den tftpboot Ordner. Ändern Sie die Rechte noch mit

chmod 777 /var/lib/tftboot

ab.

Telefon einrichten

Wenn Sie jetzt das Gerät richtig angeschlossen haben (Netzwerkkabel gehört in den mit Switch beschrifteten Anschluss) wird erstmal nicht viel passieren, außer das sich das Gerät mit hoher Wahrscheinlichkeit beschwert das die Konfiguration nicht abgerufen werden kann.
Gehen Sie deshalb auf den Menübutton (der Knopf mit den zwei Quadraten und dem Haken davor) und drücken Sie 9. Das Passwort sollte im optimalen Fall das Standardpasswort cisco sein.
Drücken Sie dann 3 gefolgt von 32 und ändern Sie den Wert auf YES ab. Drücken Sie dann wieder 3 gefolgt von 7 > EDIT und geben Sie die IP Ihres TFTP-Servers ein und drücken Sie SAVE. Nun sollte sich das Gerät neu starten die Firmware laden und die Konfiguration einlesen. Sollten Sie nun nichts falsch gemacht haben, steht ein funktionierendes IP Phone vor Ihnen. Sollte das Gerät nicht neu starten einfach mal kurz den Stecker ziehen.

syslog auf Nadeldrucker ausgeben

Da wir ja ein neues Spielzeug im fNordeingang haben, hab ich mal was gebastelt.

Ziel war es, den syslog (/var/log/messages) zu Archivierungszwecken auf einem entfernt stehenden Nadeldrucker in realtime zu sichern.  Ich habe ein paar Anleitungen gefunden wie man syslog per UDP durchs lokale Netz schickt. Habe dann aber doch was eigenes gefrickelt. Der Server läuft auf Scientific Linux der Druckerserver auf Debian.

Druckerserver (DEBIAN) einrichten

Legen Sie am besten einen extra Benutzer an und fügen Sie Ihm der Gruppe lp hinzu. Als Beispiel nenne wir mal den Benutzer drucker

# adduser drucker --ingroup lp

SSH KEY erzeugen (Scientific)

Zuerst legen wir auf dem Server / Rechner dessen syslog ausgedruckt werden soll einen SSH-Schlüssel an. Mit dem Befehl

# ssh-keygen -t rsa

legen wir einen Schlüssel an. Kein Passwort eingeben. Ansonsten kann das spätere Script nicht laufen. Den öffentlichen Schlüssel kopieren Sie mit

# ssh-copy-id drucker@druckerserver-ip

auf den Druckerserver.

Server einrichten (Scientific)

Erst einmal müssen wir ein Scipt erstellen.

# vi /usr/local/sbin/drucker.sh

Das folgende Script können Sie übernehmen.

#!/bin/bash
while [ 1=1 ]
do
tail -F /var/log/messages | ssh -i /root/.ssh/id_rsa benutzername@serveradresse "cat > /dev/lp0"  
done

(Die Schleife ist dafür da, falls einmal die Verbindung abbricht)
Speichern Sie das Script ab und machen Sie es mit

chmod +x drucker.sh

ausführbar.

Nun noch das Script an die rc.local hängen

vi /etc/rc.local

und am Ende eintragen

/usr/local/sbin/drucker.sh

Nach einem Neustart sollte der Drucker nun munter in Realtime den Log ausdrucken. Ausprobieren kann man dies auch indem man das Script von Hand zum testen startet.

Anmerkung

Das Script lässt sich natürlich auch auf andere Logs anweden. Ob es /var/log/secure ist oder ein IRC Log.

ownCloud auf CentOS, RHEL oder SL installieren

Nachdem ich bereits einen Artikel für openSUSE geschrieben habe, hier noch eine ausführliche Anleitung für die Installation unter CentOS, RHEL sowie Scientific Linux. Die Installation unter openSUSE ist im übrigen wesentlich einfacher. Für diejenigen die noch nicht wissen was ownCloud ist verweise ich auf den Artikel der Wikipedia zu finden unter http://de.wikipedia.org/wiki/OwnCloud. Die Anleitung unten müssen Sie einfach durcharbeiten.

Alle Befehle werden als root ausgeführt.

Zuerst müssen wir einige Pakete nachinstallieren (falls noch nicht installiert).

yum install httpd mod_perl php-mbstring perl-string-Multibyte php php-mysql

Abhängigkeiten werden automatisch aufgelöst. Nach der Installation wechseln wir mit

cd /var/www/html

in das Webverzeichnis vom apache. Laden Sie mit

wget http://owncloud.org/releases/owncloud-2.0.1.tar.bz2

die aktuelle Release herunter. Der Link oben war zum Zeitpunkt des Artikels aktuell. Nach dem Herunterladen entpacken Sie das Verzeichnis mit

tar xvjf owncloud-2.0.1.tar.bz2

Dann ändern Sie mit

chown -R apache:apache /var/www/html

den Verzeichnisbesitzer sowie mit

chmod 0770 /var/www/html/owncloud/data

die Schreibrechte des späteren Datenverzeichnisses von ownCloud.

Nun müssen wir den apache noch so Konfigurieren, dass die gespeicherten Dateien nicht direkt herunterladbar sind. Öffnen Sie die Konfigurationsdatei mit

vi /etc/httpd/conf/httpd.conf

und ändern Sie die unten stehende Optionen wie folgt ab (Sie müssen die Taste i drücken um in den Einfügemodus zu gelangen; speichern mit ESC :wq):


Options None
AllowOverride None
Order allow,deny
Allow from all

und fügen Sie am Ende der Datei noch folgendes ein:


AllowOverride All
Order allow,deny
allow from all


Damit Dateien über 2 MB hochgeladen werden können müssen wir die php.ini noch bearbeiten. Mit dem Befehl:

vi /etc/php.ini

Öffnen Sie die Datei und ändern unten stehende Werte wie folgt ab:

upload_max_filesize=8MB
upload_max_size=8MB

Nun müssen Sie noch mit

system-config-firewall-tui

die Firewall einrichten und Port 80 freigeben. Klicken Sie auf Anpassen und wählen Sie den Punkt WWW (HTTP) aus (weiter unten in der Liste). Dann auf Schließen > OK > Ja.

Nun können Sie ownCloud mit

service httpd start

starten. Erreichbar ist es unter

IP.des.Servers/owncloud.

Tipp: Im Ordner /var/www/htmlliegt noch die owncloud tar.gz Datei. Diese können Sie nun löschen.

Interessante Links zum Thema

Scientific Linux – oder die Suche nach der Serverdistribution

Nachdem es ja wie bekanntlich Richtung Jahresende geht, habe ich mir zu Weihnachten eine Hardware-RAID-Karte von 3ware gegönnt, um genauer zu sein eine 3ware 9650SE-2LP. Auf dieser läuft nun die Systemplatte(n) im RAID1 Verbund. Die Platten mit den Daten lasse ich weiter einzeln laufen. Diese werden jede Woche einem mit rsync abgeglichen. Zeitkritische Daten liegen auf der Systempartition.

Da ich nun eh schon am Server dran war habe ich mir Gedanken gemacht inwieweit es sinnvoll ist openSUSE weiterhin auf dem Server zu betreiben. Nicht aus Gründen des Systems sondern aus der Sicht des Supportzeitraums. Spätestens Ende 2012 müsste ich mir Gedanken über in Upgrade auf die nächst höhere Version machen. Das dies meistens nicht klappt ist wohl bekannt (siehe Versionsprung auf 11.4 mit dem AppArmor Bug und SMB). Da ich allerdings auch kein Debian(derivat) verwenden wollte blieb im Endeffekt nur noch CentOS und Scientific Linux übrig. Ich habe mich dann letztendlich für Scientific entschieden, da dort die Updates schneller gepackt werden.

CentOS oder Scientific

Scientific Linux

CentOS und Scientific sind beides Nachbauten von RHEL. Da Red Hat die Quellpakete offen legen (muss), kann daraus eine Distribution gepackt werden die binärkompatibel mit RHEL ist. Und da RedHat seine Distribution 5 bzw. 7 Jahre mit Updates versorgt, können CentOS und Scientific die Updates einfach verpacken und ausliefern. Zwar habe ich kein Support durch RedHat, diesen werde ich aber bei mir Zuhause wohl kaum benötigen.

Scientific Linux

Wie schon erwähnt ich Scientific Linux ein Klon von RHEL. Gebaut wird die Distribution zum großen Teilen von CERN, Fermilab, ETH Zürich, und dem DESY. Diese haben sich zusammenschlossen um auf einer Basis eine eigene Distribution zu schaffen, damit nicht jede Institution ihre eigene Distribution pflegen muss. Mehr dazu findet sich auf der Wikiseite von Scientific Linux.

Servereinsatz

Auf dem Server macht sich Scientific gut, auch wenn ich manch praktische Dinge von openSUSE vermisse. Das Einrichten von rsync ist etwas aufwendiger. Das voreingestellte SELinux ist bisweilen (für mich) unbrauchbar. Weder rsync noch SMB ließen sich mit den voreingestellten SELinux Regeln benutzen. Auch nachdem ich die Regeln so geändert  habe das es laufen sollte, lies sich rsync immernoch nicht verwenden. Ich habe SELinux dann einfach vom System genommen. An der Stelle finde ich AppArmor bei weitem einfacher zu konfigurieren und warten.

Desktopeinsatz

Scientific Linux Screenshot

Auf dem Desktop kann ich Scientifc Linux zum Teil empfehlen. Es kommt darauf an was machen möchte. Das KDE liegt in Version 4.3 vor. Neuere Versionen müsste man sich selber kompilieren und aktualisieren. Das Gnome liegt in Version 2.28 vor und macht einen stabilen Eindruck. Für Arbeitsplatzrechner oder für einfache Arbeiten ist der Desktop völlig in Ordnung. Wer allerdings „bleeding edge“-Software haben möchte sollte dann doch lieber zu einer schneller veröffentlichenden Distribution wie openSUSE oder Fedora wechseln. Ansonsten bekommt man ein stabiles System, das für die normalen Office und Internetanwendungen völlig ausreichend ist. Sollte man Scientific für den Desktop verwenden und hat nicht mehr als 4 GB RAM empfehle ich die 32bit Version, da es dort mehr Pakete für gibt die man sich sonst extra raussuchen muss. CentOS und RHEL Paketquellen können eigentlich ganz normal benutzt werden da alle Distributionen zueinander kompatibel sind.

Interessante Links zum Thema:

Server nur ohne angemeldeten Benutzer herunterfahren

Wie bestimmt in jedem Hackerspace oder manchen Büros stehen dort Server die eigentlich nur über den Tag hinweg genutzt werden und abends oder bei „Ladenschluss“ heruntergefahren werden können. Zwar ist es kein Problem die Einstellungen in den ACPI Config-Dateien so vorzunehmen das der Server beim drücken des Power-Knopfes herunterfährt, allerdings würden dann alle Nutzer, die noch (von extern über einen SSH Tunnel) auf dem Server sind, rausgeschmissen. Damit man trotzdem den Server per Tastatendruck ohne sich extra per ssh anzumelden herunterfahren kann gibt es eine kleine Shellscriptabfrage die man einbauen kann. Gefunden habe ich diese auf linux-club.de. Sie bewirkt, dass der Server per Tastendruck nur heruntergefahren wird wenn kein Nutzer mehr einen Tunnel zum Server offen hat. Ist dies der Fall und der Power-Knopf wird gedrückt, läuft der Server trotzdem weiter und der root bekommt eine E-Mail das der Power-Knopf betätigt wurde. Dei nötigen Schritte sind recht simpel:

Kontrollieren Sie vorher ob das Paket acpid installiert ist.

Öffnen Sie als root die Config-Datei für den Powerbutton mit dem Befehl

vi /etc/acpi/events/power_button

und ändern sie den Eintrag

action=

so ab das dort

action=sh /root/bin/poweroff.sh

steht (mit i kommen Sie in den Eingabemodus, zum speichern Esc und dann :wq). Das Script poweroff.sh erstellen wir noch später. Sie können es auch woanders speichern. In diesem Falle müssen Sie nur den Pfad ändern.

Mit dem Befehl vi /root/bin/poweroff.sh erstellen Sie das Script und öffnen gleichzeitig den Editor. Drücken Sie i um in den Eingabemodus zu gelangen und tragen Sie folgendes ein:

#!/bin/bash
r=`who -u`
if [[ $r != "" ]];
then echo "Der Powerknopf wurde gedrückt" | mail -s "Powerknopf" root@localhost
else poweroff
fi

Nun speichern Sie das Script ab (zum speichern Esc und dann :wq). Jetzt müssen Sie das Script noch ausführbar machen.

chmod +x poweroff.sh

Nun kann der Server nur noch heruntergefahren werden wenn keiner mehr auf dem System angemeldet ist. Sollte trotzdem der Powerbutton betätigt werden während noch jemand angemeldet ist wird dem root eine Mail zugeschickt, dass der Knopf betätigt wurde. Der Befehl kann aber auch einfach durch ein

exit 0

ersetzt werden, falls keine Mail erwünscht ist.

Plötzlicher Ausfall der Serverfestplatte

Nur mal so nebenbei etwas von mir. Wie bereits bekannt läuft mein Homeserver mit mehreren Festplatten. System und Daten sind dabei getrennt voneinander auf zwei unterschiedlichen Platten gespeichert. Das dies von Vorteil ist hat sich heute wieder herausgestellt.

Eigentlich wollte ich nur ein paar Dateien auf den Server verschieben, als dies mit einem I/O Error abgebrochen ist. Ein Blick auf die Festplattenzugriffslampe zeigte ein regelmäßiges kurzes aufleuchten. Das schlimmste schon vermutend habe ich mich per SSH auf dem Server eingeloggt um folgendes wiederholend in den messages zu finden:

ata4.00: exception Emask 0x50 SAct 0x1 SErr 0x280900 action 0x6 frozen
ata4.00: irq_stat 0x08000000, interface fatal error
ata4: SError: { UnrecovData HostInt 10B8B BadCRC }

Zum Glück habe ich eine gleiche Festplatte mitlaufen die in regelmäßigen Abständen die Datenplatte synct. Von daher kein Datenverlust.

Was mich mehr sorgte, war die Frage was genau jetzt los ist. Also Gehäuse aufgeschraubt und hineingeschaut. Alles sah in Ordnung aus. Ein wenig am SATA Kabel gewackelt und interessanterweise ging es dann kurzerweise ein paar Sekunden bis das gleiche Spiel wieder von vorne anfing. Zum Glück wusste Google rat. Angeblich liegt der Fehler in den meisten Fällen an einem schlecht isolierten oder defekten SATA Kabel bzw. die Platte bekommt zu wenig Strom. In guter Hoffnung habe ich also das alte Kabel entfernt und ein neues eingesteckt. Gut das ich immer einen Vorrat an SATA Kabeln habe. Erfahrungsgemäß braucht man die immer wieder. 😉 Und siehe da… Die Kiste läuft nun seit 3 Neustarts und zwei Stunden wieder problemlos.

Das SATA Kabel werde ich am Mittwoch im Hackerspace mal durchmessen ob es letzendlich daran lag oder doch nur irgendwo ein Wackler drinne war. Ich kann mir aber gut vorstellen das irgendwo ein Kabelbruch ist. Zwischen dem SATA Anschluss und dem dahinter befindlichen Lüfter ist nicht viel Platz so das das Kabel etwas eingequetscht wird. Ich werde wohl bei der nächsten Bestellung ein paar gewinkelte SATA Kabel bestellen um dem entgegenzuwirken.

Interessante Links zum Thema

Music Player Daemon unter openSUSE einrichten

Sie kennen das sicher: Sie geben eine Party und lassen natürlich auch Musik laufen, möchten aber nicht jedesmal zum Rechner / Laptop gehen um ein anderes Lied abzuspielen oder die Lautstärke zu ändern In einem anderen Beispiel haben Sie einen Homeserver über den Sie Musik abspielen möchten ohne extra einen PC oder Laptop anschalten zu müssen. Dies alles ist mit dem Music Player Daemon auch MPD genannt möglich. Im Endeffekt handelt es sich dabei um einen Musikplayer der als Hintergrunddienst läuft. Ansteuern lässt er sich nur über das Netzwerk. Dazu gibt es mehrere Clients ob für das Terminal, KDE, Gnome oder Android. Über diese Clients lässt sich der Daemon steuern.

Abspielen kann der MPD fast jedes Dateiformat soweit die entsprechenden Pakete installiert sind. Alle nötigen Pakete erhalten sie aus dem Packman-Repository, zu finden unter http://packman.links2linux.de/ oder unter YaST > Software-Repositories > Hinzufügen > Community/Gemeinschafts-Repositorys.

MPD installieren

Starten Sie zuerst ein Terminal und machen Sie sich mittels

su -

zum root. Dann installieren Sie den MPD mit dem Befehl

zypper in mpd ffmpeg

MPD konfigurieren

Nach der Installation müssen wir die Konfigurationsdatei noch anpassen. Öffnen Sie die Konfigurationsdatei mit dem Befehl

vi /etc/mpd.conf

Den Eintrag music_directory ändern Sie folgendermaßen ab (mit der Taste i kommen Sie in den Eingabemodus)

music_directory "/var/lib/mpd/"

Den Eintrag password ändern Sie folgendermaßen ab (am Anfang der Zeile das # entfernen)

password "hiereinpasswort@read,add,control,admin"

Das

hiereinpasswort

ändern Sie nach belieben ab, was Sie als Passwort haben möchten. So können später nur Sie mit dem Passwort auf dem mpd zugreifen. Speichern Sie die Änderungen nun mit Esc und dann

:wq

ab.

Datei und Gruppenrechte zuweisen

Nun ist der MPD im wesentlichen Einsatzbereit. Zu beachten ist allerdings das der MPD aus Sicherheitsgründen als Systembenutzer mpd in der Gruppe audio ausgeführt wird. Das heisst, dass er keinen Zugriff auf Ihre Musiksammlung hat die in der Regel der Gruppe users gehört. Kopieren Sie die Musikdateien in den Ordner

/var/lib/mpd/

da wir diesen Ordner als Musikquelle angegeben haben. Um die ganze Sache konfortabler zu machen können Sie Ihren Benutzer auch der Gruppe audio zuweisen. Dies machen Sie unter YaST > Benutzer und Gruppenverwaltung > Benutzer auswählen > Bearbeiten > Details > Zusätzliche Gruppe „audio“ auswählen und bestätigen.

So können Sie die Musikdateien nun einfach in den MPD-Ordner hineinkopieren. Denken Sie daran das die Dateien mit dem Befehl

chgrp audio Dateien

der Gruppe audio zugewiesen werden müssen, ansonsten kann der MPD (der ja als Benutzer mpd läuft) nicht auf die Dateien zugreifen. Alternativ können Sie auch Ihr Musikverzeichnis per Softlink in das Verzeichnis einhängen. Beachten Sie das dabei das alle Dateien und Ordner auch die Gruppe wechseln müssen oder die Rechte angepasst werden müssen. Wenn Sie die Daten auf einen Server kopieren möchten, können Sie auch einen FTP Server einrichten und So die Daten hochladen.

Firewall einstellen

Nun müssen Sie noch in der SuSE Firewall den Port 6600 freigeben. Über diesen wird der MPD angesteuert. Den Port geben Sie in dem Firewall Modul von YaST frei. Unter Erlaubte Dienste > Erweitert geben Sie bei den TCP Ports den Wert

6600

ein und bestätigen alles mit OK.

MPD starten

Nun können Sie den MPD mit dem Befehl

rcmpd start

starten. Mit dem Befehl

tail -F /var/log/messages

können Sie verfolgen was der MPD an Meldungen ausgibt.

Starten Sie nun einen MPD Client wie Quimup oder Gimmix und verbinden Sie sich mit dem Daemon. Sie müssen nun die Bibliothek einmal aktualisieren (und jedesmam wenn neue Dateien dazugekommen sind). Der Button dazu heisst in den meisten Fällen Sammlung aktualisieren oder Update.

AnmerkungEN

Wenn der Music Player Daemon auch beim hochfahren mitgestartet werden soll können Sie Ihn unter YaST > Systemdienste (Runlevel) im Modus Expertenmods auswählen und den Runleveln 3 und 5 zuweisen. Mit OK bestätigen Sie die Änderungen.

Um auf den MPD zu streamen muss zusätzlich der Port 8000 geöffnet werden.

Läuft der MPD in dieser Konfiguration belegt der das Sounddevice so das andere Programme keinen Sound ausgeben können. Abhilfe schafft hier Pulseaudio welches in openSUSE 11.4 allerdings noch Probleme macht. Mehr dazu finden Sie unter http://mpd.wikia.com/wiki/PulseAudio.

Überwachungskamera mit motion

Ist das openSUSE Bräu noch da?

Mittels dem Programm motion und einer Webcam lässt sich schnell und einfach eine Überwachungskamera bauen. Die Konfiguration ist nicht schwer und geht schnell von der Hand. In dieser Anleitung beschreibe ich eine einfache Konfiguration, dass die Webcam nur Fotos aufnimmt wenn sich etwas bewegt. So wird weniger Speicherplatz gebraucht. Für die Funktionalität von motion benötigen Sie eine Webcam die von openSUSE unterstützt wird. Ich hatte bei einer günstigen 10€-Webcam von Hama Glück gehabt. Intern identifiziert sich die Webcam als Microdia Sonix USB 2.0 Camera.

Installation

Leider gibt es zurzeit für 11.4 keine motion Pakete im openSUSE Buildservice. Sie können aber das verfügbare motion Paket für 11.3 ohne Probleme auf 11.4 installieren. Zu finden unter:

https://build.opensuse.org/project/show?project=home%3Agarloff%3AWebcam

Nachdem Sie die entsprechende RPM heruntergeladen haben können Sie dieser mit dem Befehl su und danach rpm -i <Dateiname> installieren. <Dateiname> ersetzen Sie durch den Namen des Paketes.

Konfiguration

Wechseln Sie als root mit

cd /etc/motion

in den Konfigurationordner von motion. Hier können Sie mittels

vi motion.conf

die Konfigurationsdatei aufrufen.

Hier nehmen Sie folgende Einstellungen vor. Ändern Sie die grün hinterlegten Optionen entsprechend ab. Bitte kein Copy & Paste. Vorhanden Optionswerte in der Konfigurationsdatei sind auch wichtig. Die in Klammer stehenden Sätze lassen Sie außen vor (Zum editieren in vi die Taste i drücken):

# Image width (pixels). Valid range: Camera dependent, default: 352
width 640  (hier die Auflösung Ihrer Webcam)

# Image height (pixels). Valid range: Camera dependent, default: 288
height 480  (hier die Auflösung Ihrer Webcam)

# Minimum time in seconds between capturing picture frames from the camera.
# Default: 0 = disabled - the capture rate is given by the camera framerate.
# This option is used when you want to capture images at a rate lower than 2 per second.
minimum_frame_time 2

# The quality (in percent) to be used by the jpeg compression (default: 75)
quality 80

# Target base directory for pictures and films
# Recommended to use absolute path. (Default: current working directory)
target_dir  /verzeichnis/wo/die/bilder/gespeichert/werden

# File path for motion triggered ffmpeg films (mpeg) relative to target_dir
# Default: %v-%Y%m%d%H%M%S
# Default value is equivalent to legacy oldlayout option
# For Motion 3.0 compatible mode choose: %Y/%m/%d/%H%M%S
# File extension .mpg or .avi is automatically added so do not include this
# This option was previously called ffmpeg_filename
;movie_filename %v-%Y%m%d%H%M%S

# File path for timelapse mpegs relative to target_dir# Default: %Y%m%d-timelapse
# Default value is near equivalent to legacy oldlayout option
# For Motion 3.0 compatible mode choose: %Y/%m/%d-timelapse
# File extension .mpg is automatically added so do not include this
;timelapse_filename %Y%m%d-timelapse

# The mini-http server listens to this port for requests (default: 0 = disabled)
#webcam_port 8081 (Wenn Sie die Raute entfernt lassen startet ein HTTP-Server wo sie die Liveausgabe der Webcam verfolgen können. Denken Sie daran das Sie dafür die Port in der Firewall freigeben müssen)

# TCP/IP port for the http server to listen on (default: 0 = disabled)
;control_port 8080

Bei allen Optionswerte die mit ffmpeg beginnen setzen Sie ein Semikolon vor. Beispiel:

# Use ffmpeg to encode mpeg movies in realtime (default: off)
;ffmpeg_cap_new on

Speichern Sie die Einstellungen mit dem Befehl :wq ab und testen Sie motion. Dazu starten Sie den Deamon mit dem Befehl rcmotion start. Wenn nun Bewegung im Bild der Kamera ist sollten alle 2 Sekunden ein Bild geschossen werden. Sollte alles klappen können Sie den Deamon falls gewünscht auch im Runlevel Editor bei YaST so einstellen, dass er automatisch beim Hochfahren mitstartet.

Zusätzliche Infos

  • Unter http://www.lavrsen.dk/foswiki/bin/view/Motion/FrequentlyAskedQuestions finden Sie eine gute FAQ zu motion.
  • Die hier installierte Verson von motion kann wegen Lizenzproblemen keine MPEG Video codieren.
  • Sollten zuviele „Leerbilder“ geschossen werden, können Sie die Empfindlichkeit des Auslöser mit in der Konfigurationsdatei mit dem Wert threshold einstellen. Der Standardwert ist hier 1500. Dies sind die Anzahl der Pixel die sich ändern müssen damit die Kamera auslöst. Je kleiner die Zahl desto ehr wird ein Foto geschossen.
  • Bitte bedenken Sie das die Bilder (sollte das Programm ernsthaft zur Überwachung von Eigentum genutzt werden) nicht lokal auf der Festplatte liegen sollten, denn wird der PC geklaut sind auch die Bilder weg.
  • Bitte auch beachten: http://de.wikipedia.org/wiki/Video%C3%BCberwachung#Private_Video.C3.BCberwachung

webYaST Server überschreibt Apache Webseite

Seit Anfang Dezember 2010 benutzt webYaST statt dem Webserver lighttpd den Webserver nginx. Der neue Webserver wurde automatisch installiert ohne das der Benutzen etwas dazu umstellen musste. Leider hat man dies, sollte man eine Apache Server auf der gleichen Maschine nutzen, sehr schnell gemerkt, da im RPM Paket des nginx Webservers auch zwei Dateien vorhanden sind die in

/srv/www/htdocs

kopiert werden.

Hier die beiden Dateien

Nämlich einmal eine

index.html

und eine

50x.html

Sollte man nun eine Webseite schon im selbigen Verzeichnis haben werden die Dateien falls schon vorhanden überschrieben. Dies passiert bei jeder Aktualisierung des Webservers durch zypper.

Meine Bisherige Lösung ist es, das Arbeitsverzeichnis von Apache in YaST umzulegen. Zum Beispiel in den Ordner 

/srv/www/apache_htdocs

. So bleiben die Dateien auch erhalten. Die Einstellungen können Sie in YaST unter Netzwerkdienste > HTTP Server in dem Reiter Haupthost vornehmen. Einfach die Pfade von Document Root und Directory in das neue Verzeichnis umändern. Das wars. Nun nimmt Apache das neue Verzeichnis als Hauptverzeichnis. Somit haben neue Installationen von ngnix keine Auswirkungen mehr auf Apache.