37

all of this is on ubuntu 6.06 lts dapper drake. it most likely equally applies to all linuxes (possibly other unixes) that have gnu screen installed and use inittab. the runlevels may be different.

i spent a several hours yesterday looking into how to use screen to launch an app from inittab and still maintain a console to it. the initial goal was related to how to start a common lisp server application at boot, but the testing was done using a java app. unfortunately, there’s no console control on the java application, but it does print out some messages at startup and if something goes horribly wrong, the exception is dumped to stderr. it might be worth while to write one.

at any rate, the initial lead came from a post to comp.lang.lisp from like 2004 that i didn’t have the forsight to bookmark. there wasn’t any specifics and searching on google for anything related to screen is practically useless, as one might, due to “screen” being a fairly generic word. hopefully, including “gnu screen” will make it better. probably not.

so, here’s what i found/figured out. i figure the best way is to create a specific screen config file to pass on the command line with “-c”. this makes the command in inittab shorter and possibly makes it easier to keep things separate if you’re starting multiple applications. the main thing to watch out for is that when starting gnu screen with a config file and using the “chdir” command in the file you need to specify the absolute path to the config file. if you don’t, when you try to re-attach, you’ll get an “Unable to open ” message and the detached screen process will exit. not very useful.

here’s the (sort of) contents of my screen config file:

sessionname app

chdir

screen -t ces -L 0 java -jar [full path]/app.jar [args]

the sessionname is whatever you want to use for when you re-attach with “screen -r app”. you may or may not need to use chdir, but it’s probably helpful for most apps if that’s somewhere that the user the application is running as can write to or maybe not. your call. the “screen” command is what starts the application. “-L” does logging to the default file (which is in wherever the current working dir for screen is. in this case, the dir after “chdir”). “-t” is probably unnecessary as it’s just the screen window title. we’re only using one in this case so i doubt it’s important. the rest is the command to launch the application. fairly simple.

the next step is the command to start screen. this is (sort of) what i have in /etc/inittab:

app:23:respawn:/bin/su - [user] -c “screen -D -m -c [fullpath]/app.screenrc”

the “-D -m” will cause the screen process to start detached without forking to a new process. this is important because when the screen process exits, init will respawn it. the app at the beginning of the line can be whatever you want as long as it’s unique to the file and 4 characters or less. currently, we are starting some java applications by just directly calling it from inittab and redirecting the stderr and stdout to files. to get it active, just do a “kill -HUP 1″ as root.

now, to re-attach to the screen session you just use “screen -r app” or whatever you used for sessionname in the config file. you should see any output from your application now and have full terminal access just like if you had started it from a shell. gnu screen has support for password protecting the session, but i haven’t tried it yet. it’s probably less important in this specific case since you can’t input/control anything and you have to be either the user or root to re-attach to the session.

there may be a question of screen stability, but i find it unlikely to be a problem as gnu screen has been around for a while and is only getting bug fixes. what a plus to have an application that is feature complete.

an alternative might be to not use screen at all and directly start the application on an empty console instead of a getty program. the downside is that you would have to have physical access to the console in order to access the program. wasn’t really an option for me.

there’s also a program called detachtty written by a lisper that he thinks works better than screen. supposedly, you can access it over the network using ssh, but it’s not immediately apparent how this is done from my extremely limited scanning of the webpage. it appears to be targeted at use in a real init.d script and doesn’t seem like it would work from within inittab.
hopefully, this post will help me save some time in the future when i finally get around to using this method.

this is using racoon for ike and ipsec tools. i didn’t use the racoon-tool or whatever the debian added config thing is for racoon because it wouldn’t startup properly for me. problems loading modules.

i believe the only extra packages installed passed the server defaults was shorewall firewall, racoon and ipsec-tools.

here’s the notes i took for adding a connection to a new remote host.

• add pre shared key to /etc/racoon/psk.txt
• update /etc/racoon/racoon.conf by adding a remote and sainfo sections similar to an existing entry. sainfo requires encryption_algorithm, authentication_algorithm and compression_algorithm entries.
• add spdadd entry pairs for both local to remote network and remote to local in /etc/ipsec-tools.conf.
• stop racoon: /etc/init.d/racoon stop
• restart ipsec: /etc/init.d/setkey restart
• start racoon: /etc/init.d/racoon start
• if racoon doesn’t start, check /var/log/daemon.log for config errors.
• add an entry to /etc/shorewall/tunnels to define the remote gateway
• add an entry to /etc/shorewall/zones to create a zone to use for rules. the zone name can’t be more than 5 characters long.
• add entries in the /etc/shorewall/hosts to define what hosts are in the zone
• add entires to /etc/shorewall/policy for whatever firewalling rules need to be created for the vpn. at a minimum an entry to allow full access from loc to vpn and vpn to loc would be necessary. everything gets dropped by default.
• restart shorewall: /etc/init.d/shorewall restart