Autostarting screen on a server with programs running

There are some things I want my little home server to do permanently in the background. The corresponding programs may or should run in the context of the regular, non-privileged user. They may be interactive / full-screen console applications that I want to access from different computers around my network.

A way to accomplish this is to set up screen with an autostart configuration. The screen command is part of all modern Linux distributions, although it may not be installed by default.

To start the jobs at boot time without manual intervention, screen must be hooked up with the boot process. For gentoo this happens through an executable file /etc/local.d/*.start. Fedora uses /etc/rc.d/rc.local, which must be created in contemporary releases of the distribution. In both cases, the files must be set executable.

The call to screen from this system boot hook needs to be prefixed with an appropriate sudo to run in the context of the non-privileged user:

sudo -u <user> /usr/bin/screen -wipe

sudo -u <user> -i /usr/bin/screen -dm

From the screen manpage:

-d -m   Start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts.

When the system was not shut down properly, screen session files may have been left behind which can prevent screen from autostarting on the next boot. Since this is in bootup and no other screen sessions are yet running, we can just use the -wipe option preventively to make sure no such leftovers remain.

There is an additional catch with Fedora as it sets Defaults requiretty in /etc/sudoers which prevents sudo from working here:

sudo: sorry, you must have a tty to run sudo

The solution is to add another line using visudo as follows:

/etc/sudoers

Defaults:root   !requiretty

Now create a directory .screen and a file .screenrc in the user's home directory. The directory holds a number of scripts containing the commands to be run in various screen windows, while the .screenrc file assigns these scripts to windows.

.screenrc

defflow off
screen -t shell0 0 $HOME/.screen/s0
screen -t pinger 1 $HOME/.screen/s1
screen -t nload 2 $HOME/.screen/s2

The defflow off directive turns off screen's flow control handling, which allows fullscreen console applications to receive and process the keystrokes Ctrl-S / Ctrl-Q. This can also be set per window (-f / -fn).
The -t option to the screen directive sets the window title; it is followed by the window number and the command to run.

.screen/s0

#!/bin/sh
fetchmail -d 3600
bash

This starts fetchmail in the background to retrieve mail each hour, and also gives me a shell in screen window 0.

 

.screen/s1

#!/bin/sh
pinger

Window 1 runs a tool that regularly pings a number of other computers and presents statistics about their availability.

 

.screen/s2

#!/bin/sh
nload -i 100000 -o 100000 -t 4000 -u K -U K eth0

This tool visualizes the utilization of the eth0 interface as an ascii-art graph.

See here for how to connect to such a screen session, and here for a general introduction to screen.

google-musicmanager -p

Thankfully I did not have to face this situation again with google music manger's reluctance remembering the password when using 2-step authentication as a (supposedly) nice guy wrote about the -p command line option here. Simply have it followed by an application password and you're good to go.
Let's hope it'll be just a short while till Google fixes music manager to support 2-step properly...

Backup into the (T-)Cloud

For a while now the Deutsche Telekom has been offering 25GB of online storage free of charge. The service is branded Mediencenter or T-Cloud. While the web interface seems mostly targeted towards photo, video and music use, it also works as a plain network drive accessible through secure WebDAV.

One use I found for this space is to do off-site backups using duplicity.
Not very sophisticated yet but it principally works like this:

#!/bin/sh export PASSPHRASE="this_is_not_my_data_encryption_key" export FTP_PASSWORD="the_tonline_email_password" duplicity -vn --include /home/guesswho/important_stuff --include /home/guesswho/more_important_stuff --exclude / / webdavs://<myaccount>@t-online.de@webdav.mediencenter.t-online.de/backup/

In case you get errors like this from duplicity

GPGError: GPG Failed, see log below: ===== Begin GnuPG log ===== gpg: problem with the agent: Bad CA certificate ===== End GnuPG log =====

try killall gnome-keyring-daemon. Some resource clash along the lines of gpg going on there.

Update:
After encountering some problems with the built-in webdav support of duplicity when doing incremental backups, I changed it towards davfs2 for mounting the cloud space to a local directory and running duplicity against that by replacing the webdavs:// url with file:///home/guesswho/mnt/tcloud/backup/.

This also renders the need to kill gnome-keyring-daemon moot.

There is one caveat though, which is you need to add the statement use_locks 0 to the config file (eg. /home/guesswho/.davfs2/davfs2.conf).

Recording and archiving streaming radio

First store the stream to disk, which in case of an http stream can be done like this

$ mplayer -dumpaudio http://whatever/streaming.url

That should result in a file stream.dump, which in this case luckily comes directly in mp3 format

$ file /tmp/stream.dump
/tmp/stream.dump: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo

Since we're talking live recording here, we'll (hopefully) have provided for some buffer minutes at the beginning and at the end of the file which we need to get rid of now. So fire up the audacity sound editor (in case you're doing this on Fedora Linux make sure to install audacity-freeworld from rpmfusion over the regular audacity package which lacks mp3 support) and find the cue points. Of course you can also trim the stream and save it to a new file right there, but that would mean re-encoding. Not much of an issue but still it would be nicer to preserve the original stream.

So just note the cue points in audacity and head back to the commandline, this time we'll be using a tool by the name mpgtx from a package of the same name.

$ mpgtx -s /tmp/stream.dump [5:47-57:38] -o myrecording.mp3

Easy to tell, the actual program started 5 minutes 47 seconds into the stream, and went on until 57 minutes and 38 minutes. Whole-second precision is usually sufficient, but decimal seconds are also supported.

Finally, we'll want to tag our new file. I like to use eyeD3 (package name python-eyed3) for that:

$ eyeD3 -a "The artist" -t "The title" -G <genre> -Y <year> --add-image=/tmp/artist_pic.jpg:ARTIST: myrecording.mp3

To learn about the possible <genre>s, run "eyeD3 -l"; to see supported image types invoke as "eyeD3 --list-image-types". The term image type may be a bit confusing in this context, we're not talking JPEG vs. PNG but what is depicted (in the example it would be a picture of the performer).