so i’ve been using screen for a couple years now, and i really dig it. i use it to keep tabs on my ubuntu box at home, where i run irssi on top of znc, apache, and a few other services. the only thing that bugged me up until now was that any time i needed to reboot (patches or power outages), i’d have to spend extra time interactively logging in and setting up my screen session all over again. i fixed all that this morning.  i did two things:

• i did a little RTFM’ing of the screen man page so that i could write a custom .screenrc file (actually .screen.boot) that would start up exactly the way i wanted it to every time, and
• i taught myself a little bit of bash so that i could write a boot script that would test for screen sessions and if none existed, would start up my custom screen for me so that it would be ready before i even logged in.  yeah, i’m a tcsh guy by nature.  i don’t know what to tell you.

first, i made a .screenrc.boot (as opposed to a normal .screenrc) to differentiate from a normal invocation of screen, because i only want this custom setup at boot time, and not every time i invoke screen.  don’t feel that you have to, but it might be a good idea.

following are some example commands to add to the end of your ~/.screenrc.boot.  check the man page for more details, or google for ‘screenrc’, there’s a lot of info out there.  thusly:

screen -t irssi 0 /home/alice/scripts/zncirssi
screen -t shell1 1 /bin/tcsh
screen -t shell2 2 /bin/tcsh
screen -t rtorrent 3 /usr/bin/rtorrent
screen -t alpine 4 /usr/bin/alpine

to explain the syntax briefly here:
screen -t title windownum process
this lets me give each window a name, and windownum is the window number i want each process to have, with the process to start at the end.

then, once i had my .screenrc.boot set up the way i liked, i created the boot script as /etc/init.d/screen-startup.   you can give it any name, really.  i cribbed my version from /etc/screen-cleanup.  don’t forget to link the finished script to /etc/rc3.d or wherever is most appropriate for your flavor of *nix, so that it actually executes at boot time.  here’s the script minus some of the irrelevant header comments:

#!/bin/sh
# Script to start screen on boot for users.
#

set -e

SCREENDIR=/var/run/screen

if [ "$(ls -A $SCREENDIR/S-alice | grep boot)" ]; then
    echo boot screen session already running for alice
else
    # -dm runs the screen detached,
    # -S lets me define a name for the session,
    # -c lets me pick my config file.
    sudo -u tonye /usr/bin/screen -dmS alice.boot -c /home/alice/.screenrc.boot
fi

exit 0

if you have multiple users who needs screens at boot time, feel free to add additional if conditionals.  i could probably set up a foreach, but i was lazy.

additionally, zncirssi is a short script that runs znc and then irssi right afterwards. if run alone, znc will fork into the background and then close the originating screen window. this way you can make sure znc forks and then once running, lets irssi run.

contents of zncirssi:

/usr/bin/znc ; /usr/bin/irssi

that’s pretty much it. i hope you find it useful.

edit: i found that the bash script didn’t launch screen the way i thought it should.  not sure why.

so i’ve played with PGP in the past, and was completely overwhelmed and confused. for me, the tools were arcane, the documentation assumed much knowledge that i didn’t have, and wasn’t very helpful for the novice.

that was probably ten years ago. PGP (Pretty Good Privacy) has gone away, and in its place is GPG (GNU Privacy Guard). there are distros of GPG for pretty much every major platform, and there’s even a firefox extension to help integrate gpg into gmail, making things That Much Easier. i’ve used it a bit (though i only have three friends who use gpg at the moment), and the process isn’t as hard as i once thought, especially with the tools in the state they are today. if you’re curious, you might find it a little easier than you thought. it basically works like this:

1. install GPG for your OS.
2. with your newly installed software, use the key manager to create a key pair for a specific email address. this includes a private key that you never share with anyone, and a public key that you do share with everyone that you want to exchange mail with.
3. get your friends’ public keys. if you want to exchange mail with people, they need to be using gpg as well. that’s the drawback. import these keys with your key manager.
4. you’re now ready to encrypt things to other people! when you encode something, make sure you encode it using the public key of the person you want to send it to. that’s the mistake i made early on, and wound up encrypting a bunch of stuff with my public key that only i could unencrypt. nurrr.

fireGPG works will for firefox, and integrates some handy buttons into gmail so that you can sign, verify, encrypt, decrypt, and send — all without having to leave your browser. when i installed GPG4Win on my XPSP2 box, it dropped right in and worked like a charm. however, i also installed it on my suse 9.3 box at work. in that case, it complained of not being able to find the gpg binary, even though i pointed the extension right at it. on the fireGPG forums, this seems to be a known issue for some people (on both windows and linux) with no solid solution yet, so it may or may not bite you. the developer is working on it, so there’s still hope.

another thing i found myself wanting to do is have my private key on two different machines (home, work) so that i could send encrypted mail from both places. i found a really awesome command-line gpg cheatsheet that helps a lot when doing more of the fiddly bits, and i recommend reading it. tip for you windows users: after installing GPG4Win, running cmd.exe to get a terminal will let you do these command-line items.

so that’s been my past couple days, aside from a lot of super mario galaxy with sara. oh, and tiger woods pga tour 2008. which, while a nice game, has one of the worst interfaces in the known universe. cheers, and if i hear from you, i hope to hear from you via gpg!