Transcript inetd...Server of Servers

inetd...Server of Servers
• Looks at a number of ports
• Determines when a service is needed on any
of those ports
• Calls the appropriate server
• Restarts new server
– for each client ( nowait )
– when the previous server dies (wait )
• Interacts with
– syslog to record activity
– inetd.conf to configure itself
– /etc/services to determine which ports are associated
with which server
inetd configuration
inetd.conf: (example entry.. one for each server)
telnet stream tcp nowait root /etc/telnetd telnetd
command line and options/parameters
path name to the executable
user id to run the server
when to start a new server (wait or nowait)
type of connection (steam tcp or dgram udp)
name of the service
/etc/services:(example entry)
telnet
23 / tcp
protocol
port number
service
INETD
superserver
configuration
Daemons
• Consider the overhead of starting a server for
inetd
• Frequent requests for service may result in
overhead which is less efficient than leaving
the server running
• These servers which run continuously are
daemons
• Daemons don’t
– recover easily or automatically if they die
– they don’t reconfigure themselves for each request for
service where a server spawned by inetd can reconfigure
itself on each spawning of a new server
How many connections?
• Different servers handle this question
differently
• Gopher
– Destroys a TCP connection for each file transmitted
• WWW servers
– new TCP connection for each file
– each page is potentially composed of a number of files
• FTP
– one connection for control
– one connection for data
Launching Servers
• Manually (at the command line)
• At boot
(part of a boot script)
• Inetd
(automatically)
– serially
– parallel
Sustaining Servers
• Programmatically
– iteratively (serial)
– parallel (unix fork)
– preallocation
• Inetd
Programmatically iterative
While (true)
Accept connection
While client wants service
get request
process
send response
Close Connection
Only ONE client serviced at a time!
How would you like a web server to make you wait
until another client was done?
Programmatically Parallel
Server
(idle)
Client
(idle)
Client
(idle)
request
Server
Server
Server
(clone)
Server
Main server only fields requests, doesn’t really “serve”
Programmatically Preallocate
(idle)
Server
(idle)
Server(clone)
(idle)
Server(clone)
Request made by a client to Server
(idle)
Server
Client
Server(clone)
(idle)
Server(clone)
Main Server chooses which clone will actually serve
Simple means of providing
information services
• Chapter 3 discusses some simple approaches
to defining services
– fingerd
– telnetd
– inetd
• These represent a means of starting the
process of information serving
finger and fingerd
• Build a services user and put a .plan file in
the services home directory
User Home Directory:
.plan
Look in my public directory for info
output
server:
fingerd reads .plan
and appends
user dgame Real Name:David Game
......
Look in my public directory for info
client:
finger dgame
GNU finger
• allows you to extend the idea of a .plan file
• instead of a text displayed, it executes a
script in a .fingerrc file in the home
directory
• considerations
– standard input of .fingerrc script is finger output
– three arguments
» domain name or ip address of remote host
» local/remote keyword indicating same host or not
» name of user fingering (or null)
– don’t use setuid or setgid in the script
– run by the user nobody
• get from ftp.gnu.ai.mit.edu as a tar file
updating your finger info
• Making the finger data current
• Perhaps putting todays schedule in it
• program in the archive to allow for uptodate
reporting
• replaces the .plan with a FIFO (more later)
• must recompile the program and install it
• must start the program running on the
machine, from a startup file if possible
• example p. 40
simple uses of inetd/telnet
• You supply a program which reads/writes standard
input/standard output
• inetd supplies the network connection
• Example:
in inetd.conf
stock stream tcp nowait nobody /bin/cat cat
/.../stockquote
in /etc/services
stock 2000/tcp
• Use telnet as the client, a stdin/stdout match on
client side.
telnet yourmachine.where.it.is. 2000
• Provide an alias name to the machine like “stock”
telnet/(d) ... it’s default
• daemon sends client a login prompt
• client logs in
• daemon looks in /etc/password and gets the
login shell to use
• login shell can be any program that read/writes
standard in/standard out
• replace the shell for this service (user) with your
own program instead of a shell
• program which serves should not allow escape
to a full-featured shell
• consider replacing login shells with text-based
– gopher or web browsers
Captured shell
• Provides access to a limited number of
commands
• perl script example on p. 44
X clients
• We don’t really cover x-windows in this track
• The idea is to start the x-client (running as an
x-windows application) but to display the
results on the x-server (the service client)
• x-client on service server
• x-server on service client
Downside of not providing a
central (telnet) login
• If you provide the service on your own port
number, how do you let others know where it
is.
• The more services you offer, the more you
have to publicize
• Providing a services login at a standard port
can then allow you to provide other services
from that point