*** UNIX MANUAL PAGE BROWSER ***

SVCMGR(8) System Manager's Manual SVCMGR(8) NAME svcmgr - service remote computing requests SYNOPSIS /usr/ipc/mgrs/svcmgr [ -d ] DESCRIPTION Svcmgr performes services such as login and command execution, often in response to requests from network listeners like dkmgr and tcpmgr(8). It should be run once from rc(8). Svcmgr is controlled by several files in directory services are defined in files serv and serv.local, authorization in auth and auth.local. The .local files are searched first. The idea is that serv and auth will be the same throughout an administrative cluster of machines, and anything peculiar to specific systems will be kept in serv.local and auth.local. Each service is announced as a name in directory using the routines in ipc(3). When a connection is requested to one of these services, svcmgr receives a file descriptor connected to the requester. A new process is created to perform the actions listed for that service in the serv files, usually resulting in a login(8) with standard input, output, and error files attached to the connection. Often there are flags to login specifying a local user name or a command to be exe- cuted. Environment variable CSOURCE is set to a string of the form source=remote-machine user=ruser line=lineinfo Remote-machine and ruser are supplied in the connection message; line- info network-dependent stuff of varying interest and meaning. If a particular command was specified (the cmd or exec action), login sets environment variable REXEC to The auth files are used to translate remote user names to local ones. They contain lines with four fields: service name calling system name calling user name local user name The service, calling system, and calling user names are regular expres- sions in the style of regexp(3). The calling system and calling user fields may be omitted; is assumed. The local user name is a literal name, to repeat the calling user name provided in the request, or to explicitly reject a call. If the local user name is omitted, is as- sumed. Several service actions `look up the connection in the auth files.' This means to find the first line in auth.local or auth for which the service, calling system, and calling user match the patterns, and re- turn the local user name in that line (the same as the calling user if If no matching line is found, or if the first match has local user name the lookup fails. The serv files contain lines with three fields: service name a list of actions, separated by the calling system name The calling system name is a regular expression as in the auth file. The line matching an incoming call is the first whose service matches the requested service and whose regular expression matches the calling machine. The possible actions are: Use local username x. Look up the connection in the auth files. If a match is found, use the resulting local user. Otherwise reject the call. Look up the connection in the auth files; if a match is found, send to the caller, and use the result. If there is no match, send and read a string of the form `login,passwd\n'. If the login and password describe a valid local user, send and use that user; otherwise send and try again (until the caller gives up). This is the authentication protocol used by ipclogin (see ipc(3)), hence by con(1), push(1), and pull. Read two null-terminated strings from the caller. If they aren't the same, reject the call. Otherwise look up the service, calling system, and the null-ter- minated string (as a user name) in the auth files, use the re- sulting local user if there's a match, reject the call other- wise. This is the authentication protocol used by ipcrogin, hence by rsh and rlogin; see ipc(3) and con(1). Push the terminal line discipline ttyld(4) onto the connection. Push the reverse message line discipline (see mesgld(4)) onto the connection. Read a null-terminated string from the caller, and set environment variable TERM to the result. Read a null-terminated string from the caller, and save the result as arguments to a possible command. Extract arguments from the destination address in a way compatible with the DKHOST network software used by System V Datakit implementations, and save for later use. Execute shell command x, with any saved arguments, and with the connection as standard input, output, and error. Provide a login session with the connection as standard input, output, and error. Provide a login session, but ignore any local user name; always demand a login and pass- word. Use any saved arguments as a shell command to be executed. Call network address gateway and send the connection info there, If all is well, pass the new connection's file descriptor to the original caller: the result is a connection through the gateway. Gateway should be a svcmgr service, perhaps on some other machine, with action gate- way. The intended target for gateout: read new connection info from the connection, and place a call to the new destination; if it succeeds, loop passing data between the new connection and the original one. If the file can be opened, svcmgr prints miscellaneous chatter there, including a record of each service request. The -d (debug) option in- creases the chatter. FILES SEE ALSO con(1), ipc(3), dkmgr(8), tcpmgr(8), ipc(3) SVCMGR(8)