Niels Horn's Blog

Starting a text-based program on a headless box at boot time

February 16th, 2010 by Niels Horn in Sem categoria

Imagine yourself in the following situation:
You have a "headless" (this means: without a monitor attached) server that boots nicely, starts all the services you configured, like dns, ntp, nfs, samba, httpd, mysql, etc. But - since it has processing power left and stays on 24×7, you decide that it could do something extra that you run on your desktop now and so you have to keep that running 24×7 as well.

Some examples:

1. a torrent program to download all those Linux ISOs (you're not downloading anything illegal, are you? )
2. an irc program so that you can log all conversations while you're away
3. a mainframe emulator (well, this was my main reason)

For (1) there is rTorrent and for (2) there is irssi, included in Slackware. For (3) I use Hercules that runs in a terminal screen.
Now services you can start in /etc/rc.d/rc.local, as they do not need a terminal to show output and run as daemons. But these three programs need to show their output on a terminal screen to be useful, and a user that is logged in.
The standard solution for these cases is using "screen", that lets programs run on "virtual terminal" you can "attach" to.

Since an easy-to-use and still relatively safe setup is a bit tricky, here are a few simple instructions. As an example (not very useful in the real world), I will start "top" at boot time in a screen session.

1. Defining the user that will run the program
First of all, I personally think it is a very bad idea to run programs as root, especially if they need access to drives, the internet, etc. So for my example, I create a user "_top" with the "adduser" command.
I suggest starting the name with the "underline" character, but that's just a habit I have for special users.
I also create these special users with uid's in a special range, like 5001-5999.

2. Editing the ~/.screenrc file
After creating your _top user, you will have a file called "/home/_top/.screenrc"
If your version of Linux does not copy it automatically for new users, there should be a "skeleton" version somewhere you can copy.
Edit the copy of .screenrc in the user's home directory, and add the following lines at the end:

multiuser on
acladd user1,user2,user3

What do these lines mean:

• multiuser on will make the screen session available for other users. Without this line, it would be a "private session", with only "_top" having access to it.
• acladd user1,user2,user3 gives access to user1, user2 and user3. Replace these with the users you want to be able to attach to the screen session _top will start at boot time.

We'll come back to this .screenrc file later…

3. Starting screen + the desired program at startup
We will start the program as usual in /etc/rc.d/rc.local by adding the following line:

sudo -H -u _top screen -dmS top /usr/bin/top

Let's dissect this command:

• sudo rc.local is run by root but not as a logged-in user, so with sudo we tell root that we want the program to start as another user
• -H This tells sudo to use the home directory of the user we choose. Without the -H option, sudo will not find the /home/_top/.screenrc file.
• -u _top Here we define the user - _top in our case.
• screen -dmS top /usr/bin/top This is the command sudo will execute, with these options:
  • -dm Start screen in "detached" mode, not at the current terminal (as we do not have a current terminal, after all we're not even logged in)
  • S top Use the session name "top" - this is so that we can identify the screen session if we have several of them
  • /usr/bin/top The command screen will run in the "virtual terminal"

4. Trying our first setup
To try this setup, you do not need to boot your server yet. Simply run the sudo -H -u _top screen -dmS top /usr/bin/top as root. It should simply return to the prompt, but we can check if it worked with ps -ef f | grep ^_top that should return with:

_top 1418 1 0 13:40 ? Ss 0:00 SCREEN -dmS top /usr/bin/top
_top 1419 1418 5 13:40 pts/0 Ss+ 0:00 \_ /usr/bin/top

Of course the PIDs and times will be different.

Now log in as one of the users you defined in the acladd line in .screenrc and type screen -ls _top/ where:

• -ls is the option to list all running sessions
• _top/ tells screen to list the sessions of user _top

It should return with:

There is a suitable screen on:
 1418.top (Multi, detached)
1 Socket in /home/_top/.screen.

• 1418 is the pid - this will change of course
• top is the session name we defined
• Multi means that it is a multiuser session (as defined in .screenrc)
• detached means that no user is attached to the session

So let's attach to the session and see how "top" is doing, by typing screen -r _top/top
If everything worked fine, you should see "top" as running on your server

Screen has several commands, but for now the most interesting are:

• ctrl-A d - detach from the current session but let it running
• ctrl-A ? - show the ctrl-A commands
• ctrl-A : - gives the prompt in screen to enter commands

5. Adding some security
So now we have a working setup, but all the users we defined in the .screenrc file can access our session (even several at once) and input commands there.
I suggest at least asking for a password before letting a user attach to a session. This is a bit tricky to set up if you have never done this, but these are the basic steps:

1. Attach to a session normally
2. Type ctrl-A c to create a second screen (the first one will still be there)
3. Go to the screen prompt by typing ctrl-A :
4. Enter password + enter and type your password twice
5. The encrypted password will be in screens "paste buffer"
6. Type ctrl-A ] to reveal the encrypted password

Now edit the .screenrc file and change the lines at the end as follows:

multiuser on
acladd user1,user2,user3 xxxxxxxxxxxxx
aclchg * +rwx "#?"

Substitute xxxxxxxxxxxxx with your encrypted password.
The last line gives full access to all users that know the password. According to the manual this should be automatic, but that is not how it worked for me. Without this line I could not even detach from a session! I simply received an error like "detached: permission denied (user: niels)"
You can change the +rwx options for some users, so that they can only "read" the session and not "write" (type) anything. This adds extra security that can be important in some cases.

After finishing editing the .screenrc file, you can close the second session by typing exit at the prompt.

6. Advanced options
There are many more things you can do with screen, like having several users accessing the same session, some only reading, others typing as well. There are also many security adjustments you can configure…

Read the man-page for screen to study all the interesting things you can do!