[PLUG] Logging and multi-user in 'screen'

[JP Vossen <jp@jpsdomain.org>]

After the very well attended and excellent preso by Julian at PLUG N, we 
were talking about tmux (http://en.wikipedia.org/wiki/Tmux) and screen 
(http://en.wikipedia.org/wiki/GNU_Screen, see also 
http://en.wikipedia.org/wiki/Byobu_(software)).  In particular, we 
talked about screen logging and multi-user access, and I said I'd post 
some details.

This is how I do logging from within 'screen' in a shell script:

----- cut here -----
# Set a log file and turn on 'screen' logging
screen -X logfile $LogDirPrefix/filename.log && screen -X log on

{stuff to log happens here}

screen -X logfile 1  # Set logfile buffer to 1 sec. (default is 10)
sleep 3              # Wait 3 seconds, to avoid truncation
screen -X log off    # Turn off the log
----- cut here -----

If you don't do that stuff at the end, you can truncate your log.  There 
may be a better way to do it, but the above has worked for me in 
production for years.

This is also covered in chapter 17 of the _bash Cookbook_ (the eBook of 
which is on sale on V-Day, see http://oreil.ly/VKmd63 :)  Or read the 
recipe here: 
https://www.google.com/search?q=%22Logging+an+Entire+Session+or+Batch+Job%22



As for multi-user screen, it's a bit of a pain unless you know some tricks.

First, screen versions from 3.9.15-8 to 4.0.1-1 from Red Hat (i.e. 
RHEL3) are totally broken and should not be used if you actually want 
multiuser mode to work. 4.0.2-5 or later should work. 
http://vault.centos.org/4.9/os/i386/CentOS/RPMS/screen-4.0.2-5.i386.rpm 
works even on RHEL3, though once you start using the new screen, 
existing screen sockets in $HOME/.screen are not found and thus orphaned 
and unusable. Log out of all sessions, and use the new version to create 
new sockets in /tmp/screens/S-$USER', then remove the $HOME/.screen 
directory.  But hopefully no one is stuck with cruft that old.

Next, depending on your version, '/tmp/screens', '/tmp/uscreens' (both 
older) or '/var/run/screen/' must exist and be world readable and 
executable. (Fix, e.g.: sudo chmod 0755 /var/run/screen)

The screen binary must be SUID root so it can write to the appropriate 
user dev pseudo terminals (tty) for multiuser mode. If screen doesn't 
work, especially in multiuser mode, this is a likely reason why. (Fix: 
sudo chmod u+s /usr/bin/screen)  (Sigh.)

Ubuntu update, at least, break both of the above settings, so you 
periodically have to go:
	sudo chmod 0755 /var/run/screen
	sudo chmod u+s /usr/bin/screen


That's just the prep.  Once you get all that out of the way you have to 
actually configure it.  I just add the stuff to my .screenrc file, but 
for one-off use...  I also re-map CTRL-A to CTRL-N, since I use CTRL-A 
in bash.  But I've documented it as CTRL-A per the screen docs here.

1.  As the "host"
    screen -S {name of session, no spaces}, e.g. screen -S training
    Turn on multi-user mode: CTRL-a:multiuser on
    CTRL-a:addacl {usernames} of accounts (comma delimited, no spaces!) 
which may access the display. Note this allows full read/write access! 
E.g. CTRL-a:addacl alice,bob,carl
    Use the CTRL-a:chacl {usernames} {permbits} {list} command to 
refine permissions if needed.

2. As the "viewer"
    Use screen -x {user}/{name} to connect to a shared screen, e.g. 
screen -x jp/training
    CTRL-aK<code> to kill the window and end the session.

So, my ~/.screenrc has stuff like:
	multiuser on
	acladd alice,bob,carl

All of that sounds like a pain, and it can be.  But the clarity of 
sharing the session for troubleshooting and/or training can be worth it, 
especially when heavier-weight full-desktop sharing solutions are 
overkill or unavailable.

Enjoy
JP
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug