Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ttysnoop(8) [debian man page]

TTYSNOOP(8)						    BSD System Manager's Manual 					       TTYSNOOP(8)

NAME

     ttysnoop -- snoop on a user's tty

SYNOPSIS

     ttysnoop [pty]
     ttysnoops

DESCRIPTION

     The ttysnoop / ttysnoops client-server combo can be used to snoop (watch) on a user's login tty.  The server (ttysnoops) is usually started
     by getty(8) or telnetd(8) and reads the file /etc/snooptab to find out which tty's should be cloned and which programs to run on them (usu-
     ally /bin/login). A tty may be snooped through a pre-determined (ie.  fixed) device, or through a dynamically allocated pseudo-tty (pty).
     This is also specified in the /etc/snooptab file. To connect to the pty, the client ttysnoop should be used. The available pseudo terminals
     pty are present as sockets in the directory /var/spool/ttysnoop/.

   Format of /etc/snooptab
     The /etc/snooptab file may contain comment lines (starting with a '#'), empty lines, or entries for tty's that should be snooped upon. The
     format of such an entry is as follows:

	   tty	 snoop-device	type   program

     where tty is the leaf-name of the tty that should be snooped upon (eg. ttyS2, not /dev/ttyS2) OR the wildcard '*', which matches ANY tty.
     snoop-device is the device through which tty should be snooped (eg. /dev/tty8) OR the literal constant "socket". The latter is used to tell
     ttysnoops that the snoop-device will be a dynamically allocated pty.  type specifies the type of program that should be run, currently recog-
     nized types are "init", "user" and "login" although the former two aren't really needed. Finally, program is the full pathname to the program
     to run when ttysnoops has cloned tty onto snoop-device.

EXAMPLE

     The following example /etc/snooptab file should illustrate the typical use of ttysnoop / ttysnoops:

	    #
	    # example /etc/snooptab
	    #
	    ttyS0    /dev/tty7	  login    /bin/login
	    ttyS1    /dev/tty8	  login    /bin/login
	    #
	    # the wildcard tty should always be the last one in the file
	    #
	    *	     socket	  login    /bin/login
	    #
	    # example end
	    #

     With the above example, whenever a user logs in on /dev/ttyS0 or /dev/ttyS1, either tty will be snooped through /dev/tty7 or /dev/tty8
     respectively. Any other tty's will be snooped through a pty that will be allocated at the time of login. The system-administrator can then
     run ttysnoop pty to snoop through the pty. Note that it is up to the system-administrator to setup getty and/or telnetd so that they execute
     ttysnoops instead of /bin/login.

SEE ALSO

     getty(8), telnetd(8)

FILES

     /etc/snooptab

BUGS

     The program is unable to do any terminal control-code translations for the original tty and the snoop-device. I doubt it will ever do this.

AUTHOR

     Carl Declerck, carl@miskatonic.inbe.net

BSD
								   August 8 1994							       BSD

Check Out this Related Man Page

BLOGD(8)						       The SuSE boot concept							  BLOGD(8)

NAME

       blogd - boot logging on /dev/console

SYNOPSIS

       /sbin/blogd [/dev/realtty]

DESCRIPTION

       Without	argument blogd determines the real underlying character device of /dev/console.  blogd spawns a pty/tty pair to reconnect the cur-
       rent /dev/console with the slave of the pty/tty pair. During writing information from this slave to the real character device a ring buffer
       is used to hold the information for writing it to an existing logging file.

       To  fetch  the  real  tty  of /dev/console the program showconsole(8) can be used. This has the advantage that blogd will not hold the real
       character device of /dev/console as its controlling tty (would hangup any running getty on that character device).

SIGNALS

       blogd knows a few signal to contol its behavior.

       SIGQUIT, SIGINT, and SIGTERM
	      will cause blogd tries to write out the ring buffer and to exit.

       SIGIO  says blogd that now it is able to write on /var/log/boot.msg which means that the file system is mounted read/write and  the  kernel
	      messages are written to that file.

       SIGSYS says blogd that it should stop writing to disk but continue to repeat messages to the old devices of the system console.

BUGS

       blogd  needs  a	mounted  /proc	and  /dev/pts  file  system  and tries to set the controlling tty to stdin if the real character device of
       /dev/console is not given.  After reading /proc blogd tries to restore the status of the controlling tty to avoid problems with getty  pro-
       cesses.	This can fail because blogd forks to run in the background as a daemon.

FILES

       /proc/<pid of blogd>/stat
	      the stat file of the blogd process.

       /dev/console
	      the system console.

       /var/log/boot.msg
	      logging file which is created by klogd(8) or dmesg(8).

SEE ALSO

       showconsole(8), syslogd(8), klogd(8), dmesg(8), proc(5).

COPYRIGHT

       2000 Werner Fink, 2000 SuSE GmbH Nuernberg, Germany.

AUTHOR

       Werner Fink <werner@suse.de>

3rd Berkeley Distribution					   Nov 10, 2000 							  BLOGD(8)
Man Page