This is a little perl script to make sure a remote nagios account only runs the checks it is configured to, and in case it somehow gets owned does (hopefully) not do any damage.

Script: forcecommand, Example config: forcecommand.cfg. I recommend the following line for .ssh/authorized_keys: command="/usr/local/lib/nagios/forcecommand",no-agent-forwarding,no-port-forwarding,no-pty,no-X11-forwarding $key

In my icinga, I configured it the following way: In /etc/nagios-plugins/config/ssh.cfg, I added:

define command {
    command_name check_by_ssh_fc
    command_line /usr/lib/nagios/plugins/check_by_ssh -H '$HOSTADDRESS$' -t 50 '$ARG1$'
}

And then use "check_command check_by_ssh_fc!check_apt_updates" etc.

For feh versions <= 1.7 down to at least 1.3.4, feh -G/--wget-timestamp contains an arbitrary code execution hole when called with malicious URLs containing shell characters.

The problem is that --wget-timestamp does a system() call to /bin/cp, handing it the unescaped URL. If the URL were to contain a sequence like ';something', "something" would be interpreted and executed as new shell command.

Constraints: The user must use --wget-timestamp, the URL's command part may (apparently) not contain "obfuscation" like %20 for space etc., and the remote file must exist on the server.

Example: Try feh --wget-timestamp 'https://derf.homelinux.org/stuff/foo;touch lol_hax'. Result.

All in all this is rather improbable, but I'd advise you anyways to update to feh 1.8 ;-)

Ugly hack to automatically connect external monitors using xrandr and udev:

Write SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/libexec/some-x-script.sh" into a udev rules file. This script will (at least on my system ;-) ) now get called every time you either plug in an external VGA connector or remove it.

In this script, you can now use xrandr to set up the monitor. To find out whether it is called after connecting or disconnecting, check /sys/class/drm/card0-VGA-1/enabled (or similar). Example. Happy hacking.

By the way, note that disconnecting the monitor before deconfiguring it with xrandr may break stuff. At least my system doesn not like it and does not accept other monitors until a reboot afterwards - manually calling xrandr --off first will work, of course. YMMV.

It first seems that all functions which are more advanced than "copy music files into .../MUSIC" are not possible without the proprietary Windows Software. But luckily, playlists, images and videos can also easily be converted into a format which the player understands. This post is meant to explain how to use all of the player's features (or at least those I found/used so far ;) ) with linux or any other UNIXish OS.

Music: Like you'd expect: connect player, mount the device, put your songs into .../MUSIC, umount and listen to them. Only possible catch: You may need to sed the device's USB Mode to "MSC". I didn't try MTP, but I believe that one might lead to problems.

Playlists: A little bit more sophisticated. The player supports the m3u format, but only DOS-style. The best way seems to be putting .m3u playlists with relative paths into MUSIC (assuming your songs are also stored in there), then changing all slashes to backslashes (sed 's:/:\:g') and converting the files' linebreaks to DOS format (unix2dos). UNIX line endings will not make the file unreadable, but the last line (the last song) will be missed.

Images: Standard JPEG, but possibly with size limitations (I didn't really test those). What definitely works: convert -resize 220x176.

Movies: This was the hardest part - The player expects a very specific type of MPEG not even mencoder can produce. However (these are the occasions where I really love the Open Source community) there is, of course, a program for it: fuzemux. With this, converting a video becomes a process of three "simple" program calls:

mencoder -msglevel all=0:statusline=5 -ffourcc DX50 -ofps 20 -vf \
pp=li,expand=:::::224/176,scale=224:176,harddup -ovc lavc -lavcopts \
vcodec=mpeg4:vbitrate=683:vmax_b_frames=0:keyint=15:turbo:vpass=1 \
-srate 44100 -af resample=44100:0:1,format=s16le -oac mp3lame \
-lameopts cbr:br=128 ${INPUT} -o ${TMPOUT}

mencoder -msglevel all=0:statusline=5 -ffourcc DX50 -ofps 20 -vf \
pp=li,expand=:::::224/176,scale=224:176,harddup -ovc lavc -lavcopts \
vcodec=mpeg4:vbitrate=683:vmax_b_frames=0:keyint=15:vpass=2 -srate 44100 \
-af resample=44100:0:1,format=s16le -oac mp3lame -lameopts cbr:br=128 \
${INPUT} -o ${TMPOUT}

fuzemux ${TMPOUT} ${OUTPUT}

If this is too much commandline usage for you, there is also video4fuze (Yeah, I already linked to that a few lines above) which does all of this in a quite nice GUI. That site also was a great help for me, I got the mencoder parameters from the source code ;-)

Always quote them with "$var" unless you are either absolutely sure they contain no spaces or you actually want to expand spaces. In the former case, you may want to use "$var" nevertheless for consistency.

Also: ${var} is more readable than $var, especially in cases like "$destdir$prefix/$file". "${destdir}${prefix}/${file}" is a little bit easier to digest. I'm not really sure if I want to use the ${var} form for all variables, though. With "${var}", it might get a little redundant. OTOH, in cases where you don't need quotation (like zsh scripts), ${var} looks better.

Unrelated, but maybe also interesting: I'm currently editing without syntax highlighting. As I can no longer rely on it to help me find stuff, it forces me to write a little more readable code. So I guess I'll keep it disabled.

Situation: SSH von meinem Netbook auf meinen Server lagt, sobald größere Dateien übertragen werden, enorm. Mit netcat schafft man 10 MB/s, via SSH bestenfalls 10 KB/s.

Das besonders tolle daran: Das Problem tritt nur in eine Richtung auf (server→netbook schafft die volle Bandbreite) und nur über LAN. Per WLAN gehen zwar grundsätzlich nur maximal 2MB/s durch die Leitung^wLuft, aber dafür stabil auch per SSH.

Ich glaube, ich will gar nicht wissen, woran das liegt. Aber vielleicht finde ich es ja irgendwann mal raus :>