lond - ``LON Daemon'' Server (port ``LOND'' 5663)
Usage: lond
Should only be run as user=www. This is a command-line script which is invoked by loncron. There is no expectation that a typical user will manually start lond from the command-line. (In other words, DO NOT START lond YOURSELF.)
There are two characteristics associated with the running of lond, PROCESS MANAGEMENT (starting, stopping, handling child processes) and SERVER-SIDE ACTIVITIES (password authentication, user creation, subscriptions, etc). These are described in two large sections below.
PROCESS MANAGEMENT
Preforker - server who forks first. Runs as a daemon. HUPs. Uses IDEA encryption
lond forks off children processes that correspond to the other servers in the network. Management of these processes can be done at the parent process level or the child process level.
logs/lond.log is the location of log messages.
The process management is now explained in terms of linux shell commands, subroutines internal to this code, and signal assignments:
PID is stored in logs/lond.pid
This is the process id number of the parent lond process.
SIGTERM and SIGINT
Parent signal assignment: $SIG{INT} = $SIG{TERM} = \&HUNTSMAN;
Child signal assignment: $SIG{INT} = 'DEFAULT'; (and SIGTERM is DEFAULT also) (The child dies and a SIGALRM is sent to parent, awaking parent from slumber to restart a new child.)
Command-line invocations: kill -s SIGTERM PID kill -s SIGINT PID
Subroutine HUNTSMAN: This is only invoked for the lond parent PID. This kills all the children, and then the parent. The lonc.pid file is cleared.
SIGHUP
Current bug: This signal can only be processed the first time on the parent process. Subsequent SIGHUP signals have no effect.
Parent signal assignment: $SIG{HUP} = \&HUPSMAN;
Child signal assignment: none (nothing happens)
Command-line invocations: kill -s SIGHUP PID
Subroutine HUPSMAN: This is only invoked for the lond parent PID, This kills all the children, and then the parent. The lond.pid file is cleared.
SIGUSR1
Parent signal assignment: $SIG{USR1} = \&USRMAN;
Child signal assignment: $SIG{USR1}= \&logstatus;
Command-line invocations: kill -s SIGUSR1 PID
Subroutine USRMAN: When invoked for the lond parent PID, SIGUSR1 is sent to all the children, and the status of each connection is logged.
SIGUSR2
Parent Signal assignment: $SIG{USR2} = \&UpdateHosts
Child signal assignment: NONE
SIGCHLD
Parent signal assignment: $SIG{CHLD} = \&REAPER;
Child signal assignment: none
Command-line invocations: kill -s SIGCHLD PID
Subroutine REAPER: This is only invoked for the lond parent PID. Information pertaining to the child is removed. The socket port is cleaned up.
SERVER-SIDE ACTIVITIES
Server-side information can be accepted in an encrypted or non-encrypted method.
Query a client in the hosts.tab table; ``Are you there?''
Respond to a ping query.
Read in encrypted key, make cipher. Respond with a buildkey.
Respond with CPU load based on a computation upon /proc/loadavg.
Reply with current authentication information (only over an encrypted channel).
Only over an encrypted channel, reply as to whether a user's authentication information can be validated.
Allow for a password to be set.
Make a user.
Allow for authentication mechanism and password to be changed.
Respond to a question ``are you the home for a given user?''
Update contents of a subscribed resource.
The server is unsubscribing from a resource.
The server is subscribing to a resource.
Place in logs/lond.log
stores hash in namespace
put a role into a user's environment
returns hash with keys from array reference filled in from namespace
returns hash with keys from array reference filled in from namesp (encrypts the return communication)
get a role from a user's environment
deletes keys out of array from namespace
returns namespace keys
dumps the complete (or key matching regexp) namespace into a hash
stores hash permanently for this url; hashref needs to be given and should be a \%hashname; the remaining args aren't required and if they aren't passed or are '' they will be derived from the ENV
returns a hash for a given url
Tells client about the lonsql process that has been launched in response to a sent query.
Accept information from lonsql and make appropriate storage in temporary file space.
Defines usernames as corresponding to IDs. (These ``IDs'' are unique identifiers for each student, defined perhaps by the institutional Registrar.)
Returns usernames corresponding to IDs. (These ``IDs'' are unique identifiers for each student, defined perhaps by the institutional Registrar.)
Accept and store information in temporary space.
Send along temporarily stored information.
List part of a user's directory.
Pushes a file in /home/httpd/lonTab directory. Currently limited to: hosts.tab and domain.tab. The old file is copied to *.tab.backup but must be restored manually in case of a problem with the new table file. pushtable requires that the request be encrypted and validated via ValidateManager. The form of the command is: enc:pushtable tablename <tablecontents> \n where pushtable, tablename and <tablecontents> will be encrypted, but \n is a cleartext newline.
What to do when a client tells the server that they (the client) are leaving the network.
If lond is sent an unknown command (not in the list above), it replys to the client ``unknown_cmd''.
If the anti-spoofing algorithm cannot verify the client, the client is rejected (with a ``refused'' message sent to the client, and the connection is closed.
IO::Socket IO::File Apache::File POSIX Crypt::IDEA LWP::UserAgent() GDBM_File Authen::Krb4 Authen::Krb5
linux
Server/Process