Entries filed under Linux

Bildschirmsignal über HDMI kappen

Posted on 19. Oktober 2012 Comments

Auf meiner Suche nach einer Möglichkeit Bildschirme Remote in den Standby Modus zu bringen habe ich die folgende Zwischenlösung gefunden. Diese Befehle beenden das HDMI Signal und die meisten Bildschirme bekommen dann eine Meldung à la „Kein Signal, Überprüfuen Sie die Stromversorgung des angeschlossenen Geräts sowie die Kabelverbindung und gewählte Signalquelle“(Samsung). Nach einer bestimmten Zeit fahren dann die meisten Monitore automatisch in den Standby Modus. Benutzen kann man hierfür das Programm tvservice.

Ausschalten war relativ einfach herauszufinden:

$ tvservice -o

Anschalten mit dem -p Parameter jedoch funktioniert zwar; also der Monitor erkennt, dass es ein HDMI Signal gibt, jedoch findet er den X-Server nicht. Normalerweise müsste man diesen entweder neustarten oder einfach direkt mit einem reboot das ganze Gerät. Stattdessen habe allerdings einen kleinen Workaround gefunden:

$tvservice -p

$sudo chvt 6

$sudo chvt 7

Mit chvt wechselt man die virtuellen Konsolen durch, standardmässig läuft auf 7 der X-Server. Man muss allerdings einmal vorher zu einem anderen, z.B. 6, wechseln.

Credits gehen an XavM und vor allem svelev vom raspberry-pi.org forum, sowie sysstem.at.

Bildschirm an- und ausschalten mit xset dpms

Posted on 16. Oktober 2012 Comments

Bei meinem Raspberry Pi wollte ich über Nacht den Bildschirm ausschalten bzw. eigentlich in den Standby Modus bringen, um Strom zu sparen. Das mit dem Standby hat nicht geklappt aber jetzt ist der Bildschirm zumindest schonmal schwarz. Das hat bei meinem 40“-Bildschirm etwa einen Unterschied von 30Watt gemacht. Die beiden Befehle sind:

xset dpms force off

und

xset s reset

Erklärung:

  • xset setzt das Display Power Management Signaling auf off. Ein entsprechender Befehl mit on statt off hat bei mir nicht funktioniert.
  • das s hinter xset steht für screensaver (s. auch xset –help). Wenn dieser resetet wird, sieht man wieder ein Bild.

Credits und Dank gehen wieder einmal an Christoph von linuxundich.de

Autostart und NTP beim Raspberry Pi

Posted on 16. Oktober 2012 Comments

Autostart: Es scheint zwar noch einen Weg über ~/.config/autostart zu geben, aber ich habe einfach meine Autostart Programme in /etc/xdg/lxsession/LXDE/autostart eingetragen, jeweils mit einem @-Zeichen davor.

NTP: Er wollte bei mir mit ntpdate nicht aktualisieren. Dann bin ich mit Hilfe von Left_Guard auf folgende Idee gekommen:

sudo ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Danach habe ich folgende Befehle ausgeführt:

$ sudo /etc/init.d/ntp stop

$ sudo ntpdate <ntp-server-deiner-wahl>

$ sudo /etc/init.d/ntp start

$ sudo reboot

Nach diesem Reboot war meine Zeit richtig gesetzt.

Midori Fullscreen und Reload im Sekundenintervall

Posted on 16. Oktober 2012 Comments

Ich wollte den Raspberry Pi benutzen, um auf einem großen Bildschirm eine Website mit Informationen darzustellen. Da doch hin und wieder mal die Internetverbindung verschwindet, war es mir wichtig einen Reload jede Stunde oder so zu haben. Bei Firefox könnte man jetzt ein Reload Plugin nehmen, der minimalistische Standard-Browser unter dem Debian Derivat RaspianMidori – unterstützt aber natürlich keine Plugins. Also habe ich ein kleines Skript geschrieben, welches in einer Endlosschleife ein sleep 3600 (3600 Sekunden = 1 Stunde) ausführt und dann mit dem Kommandozeilen-Parameter -e Reload einen Reload in dem schon geöffneten Midori macht. Außerdem möchte ich das Skript per SSH starten, also muss noch der Display :0 angegeben werden, s. Programme über SSH auf Display :0 starten. Für einen Fullscreen benutze ich schon beim ersten Start in Zeile 3 -e Fullscreen. Eine erste Idee, einfach einen Refresh über eine statische HTML Seite mit iframes zu machen, habe ich verworfen, weil es blöd aussah. Die Parameter -i <Sekunden> -a <Website> haben dazu geführt, dass oben die Adressleiste wieder sichtbar wurd.e. Weitere interessante Funktionen findet man mit midori –help-execute.

#!/bin/bash
export DISPLAY=:0
midori -e Fullscreen --display=:0 &
while [ TRUE ]; do
  sleep 3600
  midori -e Reload
done

Credits go to W. H. Heydt at raspberrypi.org Forum

Drehbarer Stylus Touchscreen unter Ubuntu

Posted on 2. Oktober 2012 Comments

Ich habe hier einen Laptop mit drehbarem Bildschirm auf dem man mit einem Stfit/Stylus bedienen kann. Leider erkennt Ubuntu weder die Drehung noch die Hotkeys, die sich unter dem Monitor befinden. Zum drehen habe ich also 2 einfache Skripte geschrieben. Eigentlich gab es dafür ein eine gnome-shell-extension(xrandr-indicator), aber die funktioniert mit der neusten Version anscheinend nicht mehr. Hier sind also die einzelnen Befehle in den 2 Dateien rotate und rotate-back, denke die sind selbstsprechend.

Es reicht nicht(!), einfach nur mit xrandr den Bildschirm zu drehen, weil dann der Stift entgegengesetzt reagiert. Am besten legt man sich die beiden Dateien in /usr/local/bin ab und erstellt ein Shortcut auf dem Desktop. Wenn ich irgendwann mal Zeit finde, werd ich nochmal eine gnome-shell-extension dafür schreiben.

Eine Auflistung der verfügbaren Hardware mir ergab das folgende Ausgabe:

user@laptop:~$ xsetwacom --list dev
Wacom Serial Penabled 1FG Touchscreen stylus    id: 16    type: STYLUS
Wacom Serial Penabled 1FG Touchscreen eraser    id: 17    type: ERASER
Wacom Serial Penabled 1FG Touchscreen touch    id: 18    type: TOUCH

Die beiden Dateien:

user@laptop:~$ cat rotate
xsetwacom --set "Wacom Serial Penabled 1FG Touchscreen touch" rotate half
xsetwacom --set "Wacom Serial Penabled 1FG Touchscreen stylus" rotate half
xsetwacom --set "Wacom Serial Penabled 1FG Touchscreen eraser" rotate none
xrandr -o inverted
user@laptop:~$ cat rotate-back
xsetwacom --set "Wacom Serial Penabled 1FG Touchscreen touch" rotate none
xsetwacom --set "Wacom Serial Penabled 1FG Touchscreen stylus" rotate none
xsetwacom --set "Wacom Serial Penabled 1FG Touchscreen eraser" rotate none
xrandr -o normal

Programme über SSH auf Display :0 starten

Posted on 25. September 2012 Comments

Um Programme über SSH auf einem Bildschirm zu starten, der über Kabel angeschlossen ist muss man bei bestimmten Konfigurationen erstmal herausbekommen, welches Display zu welchem physikalischen Bildschirm gehört. Wenn es nur einen gibt ist es meistens 0.

Der aktuelle Bildschirm ist gelockt, d.h. wenn man versuchen würde über SSH jetzt ein Programm zu starten kommt folgende Meldung:

pi@raspberrypi ~ $ leafpad
leafpad: Anzeige kann nicht geöffnet werden:

Oder über xinit:

pi@raspberrypi ~ $ xinit leafpad :0
Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.

Um das zu lösen muss kann man folgende Befehle benutzen:

pi@raspberrypi ~ $export DISPLAY=:0
pi@raspberrypi ~ $ firefox

Das ist vor allem praktisch, falls VNC nicht auf den ersten Display vom X-Server zugreifen kann(-> x0vnc). Um einfach nur eine grafische Oberfläche zu bekommen reicht ja normalerweise das XForwarding vom SSH-Server oder normales VNC
Credits go to Oli.

Sound beim Raspberry Pi über Klinke

Posted on 27. August 2012 Comments

Damit bei eingesteckten HDMI-Kabel der Sound trotzdem über Klinke (der normale Kopfhöreranschluß) und nicht über das HDMI-Kabel über den TV kommt, muss man die Priorität des Audioausgabegeräts mit folgendem Befehl umstellen:

sudo amixer cset numid=3 1

Credits go to Johannes

Install ssl-cert-check plugin under SLES11 with Nagios 3.0.6

Posted on 26. Juli 2012 Comments

The guys at prefetch.net already wrote a script for checking if a SSL certificate is still valid: http://prefetch.net/code/ssl-cert-check

The only challenge now is to implement the script into the monitoring tool Nagios, in this case we used a SuSE Linux Enterprise Server 11 and Nagios version 3.0.6.

Nagios 1

To get the little boxes in Nagios green, yellow and red(=Nagios‘ return values) and to receive e-mails in case of an expiration you have to change these 2 parameters in the ssl-cert-check file:

NAGIOS=TRUE
ALARM=TRUE

To match the given form of Nagios plugins we renamed the file to check_ssl-cert and then moved it to /usr/lib/nagios/plugins, where the rest of the plugins are.

For Nagios to recognize the plugin it has to be defined in /etc/nagios/objects/commands.cfg (NOT /etc/nagios/commands.cfg):

define command {
command_name check_ssl-cert
command_line /usr/lib/nagios/plugins/check_ssl-cert -s $HOSTADDRESS$ -p 443 -e $ARG1$
}

The port is usually the same for the same service. If it’s not port 443 for every server, you can also define the port as the second parameter in the next step. Of course, instead of -p 443 it has to be -p $ARG2$.

You now have to add the configuration of the plugin in /etc/nagios/conf.d/services.cfg. In this case, the hostgroup „all“ is selected, but if you have different hostgroups, the admin who has to get the e-mail might be different. The parameters go after the exclamation mark, comments begin with the semicolon.

define service {
hostgroup_name all
service_description ssl-certs
check_command check_ssl-cert!mail@example.org
use generic-service
notification_interval 0 ; set > 0 if you want to be renotified
}

 

If an ssl-cert is expired, it looks like this:
Nagios 2
Credits go to the Alex and the other guys at the CentOS mailing list:

prosody 0.8.2. still waiting

Posted on 10. Juli 2012 Comments

I tried to start prosody with user-privileges (with user/group prosody) but I kept getting this message from prosodyctl start:

Still waiting...
Proody is still not running. Please give it some time or check your log files for errors.

But there were no errors in the log-file. If I deleted the log-file nothing was created again. I tried giving all the prosody folders 777 rights and chown‚d them to the prosody-user, still…same error. I then went to the Prosody MUC. Once again, Zash helped me to isolate the error: the pid-file could not be written by the user. So I just changed the line

pidfile="/var/run/prosody.pid"

to:

pidfile="/home/prosody/prosody.pid"

changers.com software mobile-battery auf Ubuntu 11.10 64-Bit

Posted on 9. Juli 2012 Comments

Ich habe mir neulich schonmal die Software von changers.com angeguckt, einem kleinem berliner Start-Up, das Solarpanel und dazu passende Akkuspacks verkauft. Der Clou: ein bisschen Hardware in dem Akku misst, wieviel Energie erzeugt wurde und so kann man die Daten per USB übertragen und bei facebook/twitter hochladen.

Anyway, das .deb-Paket ließ sich erst nicht installieren, weil ein paar Abhängigkeiten fehlten. Ist ja auch kein Problem, das löst unter Ubuntu normalerweise ein

sudo apt-get install -f

Die Abhängigkeiten wurden installiert nur gab das auch diese Fehlermeldung:

E: Das Paket mobile-battery muss neu installiert werden, es kann jedoch kein Archiv dafür gefunden werden.

Dasselbe passierte wenn ich mit folgendem Befehl versucht habe, das Paket zu entfernen:

sudo apt-get remove mobile-battery

Wäre jetzt alles nicht so schlimm gewesen aber ich konnte weder über upgrade meine Programme auf dem aktuellen Stand halten noch über install neue installieren!

Eine Neuinstallation brachte mich dann auf den richtigen Weg:

repat@laptop:~/Downloads$ sudo dpkg -i changers_software_v274-1_amd64.deb
    (Lese Datenbank ... 473163 Dateien und Verzeichnisse sind derzeit installiert.)
    Vorbereitung zum Ersetzen von mobile-battery 1.0-274-1 (durch changers_software_v274-1_amd64.deb) ...
    Ersatz für mobile-battery wird entpackt ...
    /var/lib/dpkg/info/mobile-battery.postrm: Zeile 11: return: can only `return' from a function or sourced script
    dpkg: Warnung: Unterprozess altes post-removal-Skript gab den Fehlerwert 1 zurück
    dpkg - stattdessen wird Skript aus dem neuen Paket probiert ...
    /var/lib/dpkg/tmp.ci/postrm: Zeile 11: return: can only `return' from a function or sourced script
    dpkg: Fehler beim Bearbeiten von changers_software_v274-1_amd64.deb (--install):
     Unterprozess neues post-removal-Skript gab den Fehlerwert 1 zurück
    /var/lib/dpkg/tmp.ci/postrm: Zeile 11: return: can only `return' from a function or sourced script
    dpkg: Fehler beim Aufräumen:
    Unterprozess neues post-removal-Skript gab den Fehlerwert 1 zurück
    Trigger für bamfdaemon werden verarbeitet ...
    Rebuilding /usr/share/applications/bamf.index...
    Trigger für desktop-file-utils werden verarbeitet ...
    Trigger für gnome-menus werden verarbeitet ...
    Fehler traten auf beim Bearbeiten von:
    changers_software_v274-1_amd64.deb

Vor allem diese Zeile machte mich stutzig:

 /var/lib/dpkg/tmp.ci/postrm: Zeile 11: return: can only `return' from a function or sourced script

.deb-Pakete sind ja eigentlich auch eine Art Archive wie .zip oder .tar.gz. In diesen findet man 2 Ordner: DEBIAN und usr.Die beiden post-removal Skripts in .deb-Paketen heissen postrm und postinst. Man findet sie im DEBIAN-Ordner, wenn man das .deb-Paket man mit einem Archiv-Programm aufruft(z.B. File-Roller). postinst enthält in Zeile 18 und postrm in Zeile 11 (s.o.) tatsächlich ein return, was da anscheinend nicht ‚reingehört. Nun war das Problem, dass bei jeder neuen Installation, er die Skripte aus dem temporären Verzeichniss tmp.ci startet. Nach ein bisschen googeln stieß ich auf diesen Beitrag von bed von zockertown.de. Also habe ich in /var/lib/dpkg/info in den beiden Dateien die return-Zeile gelöst und dann ein

sudo apt-get install -f

ausgeführt. Das hat die Software dann runtergeschmießen. Ich habe den Support mal angeschrieben(ich hatte sie vorher auch schon über Twitter um Hilfe gebeten aber keine Antwort erhalten…), vielleicht fixen sie das ja mal. Bis dahin muss ich meine Daten wohl per Windows hochladen. Mein Solarpanel ist heute angekommen, unboxing folgt;-)

Sie haben allerdings beim Schreiben dieses Blog-Eintrags auf meine E-Mails geantwortet, mal sehen was das wird:-)