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

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 Programmatically –iteratively (serial) –parallel (unix fork) –preallocation Inetd Sustaining Servers

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) ServerClient request Server Server (clone) Client (idle) Server (idle) Main server only fields requests, doesn’t really “serve”

Programmatically Preallocate Server (idle) Server (clone) (idle) Server (clone) (idle) Server Server (clone) (idle) Server (clone) (idle) Client Main Server chooses which clone will actually serve Request made by a client to Server

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

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 Provide an alias name to the machine like “stock” –p. 41

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