Demonstration of Inetd Server Emulation
This demonstration script emulates the standard inetd super-daemon found
on all Unix systems. It showcases the Stem modules Stem::Proc (which
handle processes) and Stem::SockMsg (a socket to message gateway). This
demonstration runa a single Hub which listens for socket connections on
two ports. When a connection comes in, a new process is spawned which
interacts with the remote client that made the connection. This is
effectively what inetd does but inetd_demo has several major
advantages. StemInetd can insert filters and/or taps in the data stream,
all its connections and status changes can be logged and filtered and it
can be distributed securely across a network. The demo script is
described in detail below with sections on running, using, configuring
and experimenting with it.
Running inetd_demo
The single Hub inetd demonstration is called inetd_demo and it uses the
inetd.stem configuration file (found in conf/). It is run with the simple
command:
inetd_demo
To exit, just enter 'q' in the inetd_demo script window itself. It will
kill all the other windows and then exit. This will also happen if you
interrupt the demo script with ^C.
If the -s option is used, then all the windows will use ssfe (split
screen front end) which provides a command line edit and history window
section and an output section. A single Hub window named Stem will be
created and then 4 smaller telnet windows which will be connected to
listen sockets in the Stem Hub. These telnet windows are the inetd users
and they can type data and interact with a simple command line server
program named proc_serv. The telnet windows are named A, B, C and D and
if you use ssfe, each will display the telnet command it ran.
Using inetd_demo
Now enter the help command into window A and hit return. These are the
commands you give the proc_serv application. Each of the user windows is
connected to a different running proc_serv process. You can verify this
by running the pid command in each window. Then have fun with the yow
and insult commands. Later in the experimenting section, you can change
the program to run and its options. The major difference among the user
windows is that two of them A and C are connected to the 6666 port in
the Hub and run the proc_serv in normal mode. The B and D windows are
connected to the 6667 port in the Hub and run the proc_serv with -n so
numbers the successful output lines.
You can print out the list of all the registered Cells by sending a
status command message to the Stem:Route Class Cell which is aliased to
'reg'. In the Hub window (named Stem) type this command:
reg status
You will see this printout:
Route Status for Hub ''
Object Cells with Target names of their Cloned Cells
A => Stem::SockMsg=HASH(0x2dd5a0)
:aaaaaa => Stem::SockMsg=HASH(0x2fda20)
:aaaaab => Stem::SockMsg=HASH(0x350ab0)
B => Stem::SockMsg=HASH(0x2ed474)
:aaaaaa => Stem::SockMsg=HASH(0x2c10ac)
:aaaaab => Stem::SockMsg=HASH(0x355040)
proc_serv => Stem::Proc=HASH(0x2fdbc4)
:aaaaac => Stem::Proc=HASH(0x3515c4)
:aaaaad => Stem::Proc=HASH(0x35554c)
:aaaaaa => Stem::Proc=HASH(0x2f881c)
:aaaaab => Stem::Proc=HASH(0x352660)
Class Cells with their Aliases
Stem::Conf => conf
Stem::Demo::Cmd => cmd
Stem::Hub => hub
Stem::Log =>
Stem::Log::Entry => entry
Stem::Portal => port
Stem::Route => foo reg
Stem::TtyMsg => tty
Stem::Vars => var
This shows the Parent Object Cells A, B and proc_serv each with their
own set of Cloned Cells. Below that are the loaded Class Cells.
The two Stem::SockMsg Cells have 2 telnet users connected to them and
the proc_serv Cell has cloned four Objects, each of which manages a
single process. Note that parent Cells don't do the work, they manage
the Cloned Cells which do it.
How inetd_demo is Configured
Look at the file conf/inetd.stem. That is the configuration file used by
inetd_demo. It is very simple and easy to understand. It is a Perl list
of lists structure with pairs of keys and values. Read the config_notes
for more on this.
The first Cell configured is Stem::TtyMsg which supports typing in and
sending command messages. This is done in all the demo configurations.
[
class => 'Stem::TtyMsg',
args => [],
],
Then come two Stem::SockMsg Cells named A and B. Each has a server
socket listening on its own port. Also they each will create a piped
connection to the cell named 'proc_serv'. The Cell B has one extra
attribute set, it adds the -n option when a process is spawned for it.
[
class => 'Stem::SockMsg',
name => 'A',
args => [
port => 6666,
server => 1,
piped_to => 'proc_serv',
],
],
[
class => 'Stem::SockMsg',
name => 'B',
args => [
port => 6667,
server => 1,
piped_to => 'proc_serv',
piped_args => [ '-n' ],
],
],
Finally we have the Stem::Proc Cell named 'proc_serv' which can clone
itself and spawn off processes.
[
class => 'Stem::Proc',
name => 'proc_serv',
args => [
path => 'proc_serv',
use_stderr => 1,
piped_to => 1,
no_init_spawn => 1,
],
],
The 'path' attribute is the absolute path or program name to
be run. Note that this configuration assumes it will find 'proc_serv in
$PATH. The three boolean attributed tell the Cell that it should handle
output from stderr of the process, it is expecting a pipe connection
request and it should only spawn processes when it has been cloned.
Experimenting with inetd_demo
These experiments are similar to the Hub and Portal ones in
DEMO_CHAT. They show you how to change the processes StemInetd runs, and
to distribute it over multiple systems over secure connections. Choose a
second system and make sure Stem is properly installed on it (NFS
mounting the tarball dir will help).
To support a remote Hub connecting the Hub which owns the Stem::Proc
Cell, you have to add a Stem::Portal Cell to each of them.
Make two copies of the configuration file conf/inetd.stem and call them
inetd_server.stem and inetd_client.stem
Edit inetd_server.stem and rename the Stem::Hub configuration to
inetd_server. Also insert this Stem::Portal Cell configuration into it
replacing 'foo_host' with the server hostname:
[
class => 'Stem::Portal',
args => [
'server' => 1,
'host' => 'foo_host'
],
],
Edit inetd_client.stem and rename the Stem::Hub configuration to
inetd_client. Delete the Stem::Proc Cell configuration. Also insert
this Stem::Portal Cell configuration into it replacing 'foo_host' with
the server hostname:
[
class => 'Stem::Portal',
args => [
'host' => 'foo_host'
],
],
You can create and modify as many of the Stem::SockMsg Cells as you want
on each Hub. Then in a window on the server box, do:
run_stem inetd_server
and on a window in the other box (called bar_host) where Stem is setup do:
run_stem inetd_client
You can create telnet sessions from the 'server' system that connect
to the ports of the Stem::SockMsg Cells.
telnet localhost 6666
telnet localhost 6667
And on the 'inetd_client' system, connect telnets to the ports of its
Stem::SockMsg Cells.
telnet localhost 6666
telnet localhost 6667
You can now interact with this Stem application just as you did when it
was running on one system as it did with inetd_demo.
Instead of editing the configuration files, you could also set the
Stem::Portal host attribute by setting a command line argument or
environment variable. This command will make the 'server' Hub accept
connections from the 'foo' host interface:
run_stem host=foo chat_server
You can do the same for the 'client' Hub and have it connect to host
'foo'. By setting the STEM_HOST environment variable to the host name
you can get the same effect.