Starting a text-based program on a headless box at boot time
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.
- a torrent program to download all those Linux ISOs (you’re not downloading anything illegal, are you? )
- an irc program so that you can log all conversations while you’re away
- 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 onwill 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,user3gives 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:
sudorc.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
-HThis 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 _topHere we define the user – _top in our case.
screen -dmS top /usr/bin/topThis is the command sudo will execute, with these options:
-dmStart 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 topUse the session name “top” – this is so that we can identify the screen session if we have several of them
/usr/bin/topThe 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:
-lsis 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.
1418is the pid – this will change of course
topis the session name we defined
Multimeans that it is a multiuser session (as defined in .screenrc)
detachedmeans 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:
- Attach to a session normally
ctrl-A cto create a second screen (the first one will still be there)
- Go to the screen prompt by typing
password+ enter and type your password twice
- The encrypted password will be in screens “paste buffer”
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!