9. Configuring MultiNet Services

 

 

This chapter describes how to configure MultiNet services. The chapter provides specific information about configuring the RLOGIN, RSHELL, NTY, TFTP, and SYSLOG services. The remaining chapters in this guide provide specifics about configuring other services.

MultiNet services require basic IP connectivity on your system for the services to function properly. Read Chapter 8 to learn how to establish IP connectivity.

For a list of the servers you can configure with SERVER-CONFIG, see Appendix A.

Introducing Service Configuration

When configured, MultiNet services start when a request for service is accepted by the master server (MULTINET_SERVER) process, which listens for incoming connections. When a connection request is received, either a separate, detached process is created to handle the connection, or the MULTINET_SERVER process handles the service internally.

Configuration information for the master server is in the configuration file MULTINET:SERVICES.MASTER_SERVER which is read by the MULTINET_SERVER process when it starts to determine its configuration.

When MultiNet is first installed, the normal set of services is enabled. Before starting MultiNet, you may want to verify that the server configuration meets your needs. This may require:

·         Disabling servers your site does not want accessed

·         Enabling servers your site wants accessed

·         Adding servers specific to your site

The server configuration supplied with MultiNet is adequate to get a system up and running. The server configuration can be easily changed as needed.

Generally, services are configured with the SERVER-CONFIG utility, invoked with the MULTINET CONFIGURE /SERVERS command. This chapter describes how to use this utility and provides information about other MultiNet servers.

 

Using SERVER-CONFIG to Configure Services

The MultiNet command line-based server configuration utility (SERVER-CONFIG) is an interactive utility that controls which network servers are available on the local node. In addition, you can use SERVER-CONFIG to set restrictions on a server to prevent access from unauthorized sites, to keep a log file of connections to a server, and to limit the system resources available to a server.

 

Invoking SERVER_CONFIG

To invoke SERVER-CONFIG, enter this command:

$ MULTINET CONFIGURE /SERVERS

Exit this utility with the EXIT or QUIT command.

To display the list of servers available under MultiNet, run SERVER-CONFIG, and issue the SHOW command. You can use the SHOW /FULL command to display the characteristics of a particular server. To change the default configuration, enable a server with the ENABLE command and modify server configuration parameters with the SELECT and SET commands.

In the following example, SERVER-CONFIG enables the TFTP server (which is disabled by default) displays the TFTP server's configuration, and restarts the MULTINET_SERVER process so the changes take effect immediately.

$ MULTINET CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.6(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE TFTP
SERVER-CONFIG>SHOW TFTP/full
Service "TFTP":
     UDP socket (AF_INET,SOCK_DGRAM), Port 69
     INIT() = Merge_Image
     Program = "MULTINET:LOADABLE_TFTP.EXE"
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first?[YES]Return
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]

 

SERVER-CONFIG Commands

The below table lists the SERVER-CONFIG commands.

Before using a SET command, use the SELECT command to select a service.

Command

Description

ADD

Adds a service to the configuration

ATTACH

Detaches a terminal from calling process and attaches it to another process

COPY

Copies a service to create a new service

DELETE

Deletes a service from the current configuration

DISABLE

Disables a service in the current configuration

ENABLE

Enables a service in the current configuration

EXIT

Exits from the SERVER-CONFIG session

GET

Reads in a server configuration file

NETCONTROL

Contacts the NETCONTROL server

PUSH

Accesses the DCL command line while pausing
SERVER-CONFIG

QUIT

Exits SERVER-CONFIG without saving changes

RESTART

Restarts the master server process

SAVE

Writes out the current server configuration file

SELECT

Selects a server for SET command

SET ACCEPT-HOSTS

Specifies hosts that can access the server

SET ACCEPT-NETS

Specifies networks that can access the server

SET BACKLOG

Specifies server connection queue limits

SET CONNECTED

Specifies a connection-request-received routine

SET DISABLED-NODES

Specifies VMScluster nodes on which the service is disabled

SET ENABLED-NODES

Specifies VMScluster nodes on which the service is enabled

SET FLAGS

Specifies a flag bit mask for service operation control

SET INIT

Specifies an initialize-service routine

SET KEEPALIVE-TIMERS

Specifies probes for cleaning up dormant connections

SET LISTEN

Specifies a listen-for-connections routine

SET LOG-ACCEPTS

Enables/disables successful connections logging

SET LOG-FILE

Specifies a log message destination

SET LOG-REJECTS

Enables/disables failed connections logging

SET MAX-SERVERS

Specifies the maximum number of processes

SET PARAMETERS

Specifies service-dependent parameters; affects the current configuration and becomes active the next time MULTINET_SERVER starts

SET PQL-ASTLM

Specifies the OpenVMS AST (asynchronous system trap) limit (the number of pending ASTs available to a process)

SET PQL-BIOLM

Specifies the OpenVMS buffered I/O limit (the number of outstanding buffered I/O requests  available to a process)

SET PQL-BYTLM

Specifies the OpenVMS buffered I/O byte count limit (the number of bytes allowed in any single buffered I/O request)

SET PQL-CPULM

Specifies the OpenVMS CPU time limit of the created process

SET PQL-DIOLM

Specifies the OpenVMS direct I/O limit (the number of outstanding direct I/O requests available to a process)

SET PQL-ENQLM

Specifies the OpenVMS enqueue limit of the created process

SET PQL-FILLM

Specifies the OpenVMS open file limit (the number of open files available to a process)

SET PQL-JTQUOTA

Specifies the OpenVMS job-wide logical name table byte quota (the quota allocated to the job-wide logical name table on its creation)

SET PQL-PGFLQUOTA

Specifies the OpenVMS paging file quota of the created process

SET PQL-PRCLM

Specifies the OpenVMS sub-process limit (the number of sub-processes available to a process)

SET PQL-TQELM

Specifies the OpenVMS timer queue entry limit (the number of timer queue entries available to a process)

SET PRIORITY

Specifies the OpenVMS priority for created processes

SET PROGRAM

Specifies an OpenVMS file name for run or merged images

SET RECEIVE-BUFFER-SIZE

Specifies the size of receive socket buffer

SET REJECT-BY-DEFAULT

Specifies what happens if no match is found on SET ACCEPT-HOSTS and SET REJECT-HOSTS, and on SET ACCEPT-NETS and SET REJECT-NETS

SET REJECT-HOSTS

Specifies hosts not allowed service access

SET REJECT-MESSAGE

Specifies a rejected connection message

SET REJECT-NETS

Specifies networks not allowed service access

SET SEND-BUFFER-SIZE

Specifies the size of the send socket buffer

SET SERVICE

Specifies a perform-service routine

SET SERVICE-NAME

Changes a service name. The underscore character can be used in the service name.

SET SOCKET-FAMILY

Specifies service family address

SET SOCKET-OPTIONS

Specifies setsockopt() options

SET SOCKET-PORT

Specifies the port for connection listening

SET SOCKET-TYPE

Specifies the socket type

SET USERNAME

Specifies the name of the user under which the service is started; applies only to UCX services. A UCX service has the UCX_SERVER flag set

SET WORKING-SET-EXTENT

Specifies the OpenVMS working set extent of the created process

SET WORKING-SET-QUOTA

Specifies the OpenVMS working set quota of the created process

SHOW

Shows the current server configuration

SHUTDOWN

Stops the master server process

SPAWN

Executes a DCL command, or mimics PUSH

STATUS

Shows the SERVER-CONFIG status

USE

Reads in a server configuration file

VERSION

Shows the SERVER-CONFIG version

WRITE

Writes out the current server configuration file

 

When you run SERVER-CONFIG commands, a number of prompts are displayed. These prompts are explained in Appendix A. There are a number of per-service prompts when you modify server parameters. Some of these parameters control the operation of the server, including process priority, working set limit, restrictions, and auditing. Other parameters define operations of the server, such as the protocol and port number.

Adding Your Own Services

The MULTINET_SERVER process can listen for user-written services (including IPX/SPX) and, when a connection request arrives, create an OpenVMS detached process running the user-written program. This process is created with full privileges. SYS$INPUT, SYS$OUTPUT, and SYS$ERROR are set to the network. See the MultiNet Programmer's Reference for descriptions of library routines for writing your own services that interface to MultiNet.

The following example shows how to add a user-written service called NNTP to the MultiNet configuration. The program NNTP_SERVER.EXE is invoked when an NNTP connection arrives.

SERVER-CONFIG>ADD NNTP
[Adding new configuration entry for service "NNTP"]
Protocol: [TCP] TCP
TCP Port number: 119
Program to run: USER$DISK:[NNTP]NNTP_SERVER.EXE
[Added service NNTP to configuration]
[Selected service is now NNTP]
SERVER-CONFIG>

 

Note: If your service uses the getservbyname( ) or getservbyport( ) socket library functions, you must also add your service to the HOSTS.LOCAL file and recompile your host tables.

 

 

 

Disabling, Enabling, and Deleting Services

You can tailor the MULTINET_SERVER to meet your specific needs by enabling or disabling services using the ENABLE, DISABLE, or DELETE commands.

For example, to enable BOOTP service with the SERVER-CONFIG ENABLE BOOTP command and restart the server to make the change immediately available, issue these commands:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.6(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE BOOTP
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]
$

The following example shows how to disable the SMTP service:

SERVER-CONFIG>DISABLE SMTP

 

Disabling or Enabling Services on a Per-Cluster-Node Basis

You can enable or disable services on a per-node basis in a VMScluster. Using the SET ENABLED-NODES or SET DISABLED-NODES commands, you can specify a list of VMScluster nodes on which the service does or does not run. You must also enable the service using the ENABLE command. For example, to enable the SMTP service to run only on the VMScluster node VMSA:

SERVER-CONFIG>SELECT SMTP
[The Selected SERVER entry is now SMTP]
SERVER-CONFIG>SET ENABLED-NODES
You can now add new VAXcluster nodes for SMTP.
An empty line terminates.
Add VAXcluster node: VMSA
Add VAXcluster node: RETURN
SERVER-CONFIG>

 

Restricting Access to Servers

MultiNet allows a system manager to restrict access to services on a per-service, per-network, or per-host basis.

 

Note: Restriction lists are supported only for services that listen for connections through MULTINET_SERVER. For example, the NFS Server, which reads datagrams directly, ignores any restrictions configured through SERVER-CONFIG.

 

 

Five service parameters (ACCEPT-HOSTS, ACCEPT-NETS, REJECT-HOSTS, REJECT-NETS, and REJECT-BY-DEFAULT) control whether the MULTINET_SERVER process allows or rejects a connection request based on the requesting host address, network, or subnetwork.

·         If the connection comes from a host listed in the ACCEPT-HOSTS or REJECT-HOSTS lists, the connection is accepted or rejected, respectively.

·         If the host is not found in one of these lists, the ACCEPT-NETS and REJECT-NETS lists are examined.

·         If a match is found, the connection is accepted or rejected.

·         If the host does not match any of these four lists, the action taken is governed by the REJECT-BY-DEFAULT parameter, which is normally set to FALSE, indicating that all connections are accepted.

You can also use the ACCEPT-NETS and REJECT-NETS parameters to specify a subnetwork number. You specify a subnetwork by supplying the subnetwork number followed by a space and the subnetwork mask for that subnetwork. For example:

REJECT-NETS 128.1.1.0 255.255.255.0

rejects only the hosts on the 128.1.1.n network. All other hosts on 128.1.n.n have access.

 

Note: If you answer YES after the Internet address at the prompt, only connections from a port number below 1024 are accepted.

 

 

The action taken to reject a connection depends on the protocol involved; for example, a UDP datagram is rejected by ignoring it, but a TCP connection is rejected by immediately closing the connection.

The REJECT-MESSAGE parameter specifies a text string sent to the client before the connection is closed. The following example shows how to restrict access to the TELNET server to hosts that are on a local network at address 128.1.0.0, with the one exception of the host at the address 192.0.0.2.

$ MULTINET CONFIGURE/SERVERS
MultiNet Server Configuration Utility 5.6(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET ACCEPT-NETS
You can now add new addresses for TELNET.  An empty line terminates.
Add Address: 128.1.0.0
Add Address: RETURN
SERVER-CONFIG>SET ACCEPT-HOSTS
You can now add new addresses for TELNET.  An empty line terminates.
Add Address: 192.0.0.2
Add Address: RETURN
SERVER-CONFIG>SET REJECT-BY-DEFAULT TRUE
SERVER-CONFIG>SET REJECT-MESSAGE Illegal source of TELNET connection
SERVER-CONFIG>SHOW/FULL
Service "TELNET":
               TCP socket (AF_INET,SOCK_STREAM), Port 23
               Socket Options = SO_KEEPALIVE
               INIT() = TCP_Init
               LISTEN() = TCP_Listen
               CONNECTED() = TCP_Connected
               SERVICE() = Internal_Telnet
               Accept Hosts = IP-192.0.0.2
               Accept Nets = IP-128.1.0.0
               Reject by default all other hosts and nets
                Reject Message = "Illegal source of TELNET connection"
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ?  [YES] YES
[Writing configuration to
MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600054
SERVER-CONFIG>

 

Auditing Access to Servers

MultiNet allows the security-conscious system manager to audit access to a service, file, or the OpenVMS process. Three service parameters govern the auditing that occurs when a connection is accepted or rejected:

LOG-ACCEPTS

Enables or disables logging for accepted connection requests.

LOG-FILE

Specifies the OpenVMS file name to which log messages are written. The auditing data collected by the MultiNet Server is collected in this file and flushed (written to disk) approximately every five to ten minutes. To maintain different versions of this file, you can copy an empty file over the old one on a daily basis (or at a frequency that meets your needs).

LOG-REJECTS

Enables or disables logging for rejected connection requests. A request can be rejected if the REJECT-HOSTS, REJECT-NETS, or REJECT-BY-DEFAULT security restrictions are enabled and succeed, or if the ACCEPT-HOSTS and ACCEPT-NETS restrictions are enabled and fail. For more information, refer to the Restricting Access to Servers section.

 

 

Note: The only services that support auditing are those that listen for connections through the   MULTINET_SERVER. For example, the optional NFS server, which reads datagrams directly, ignores the auditing parameters.

 

 

You should not turn on logging for a UDP service. Because there is no "formal" connection for UDP, every packet sent to the UDP service would be logged.

The following example shows how to enable a log file on the TELNET service.

$ MULTINET CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.6(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET LOG-ACCEPTS TRUE
SERVER-CONFIG>SET LOG-REJECTS TRUE
SERVER-CONFIG>SET LOG-FILE MULTINET:SERVER.LOG
SERVER-CONFIG>SHOW/FULL
Service "TELNET":
TCP socket (AF_INET,SOCK_STREAM), Port 23
Socket Options = SO_KEEPALIVE
INIT() = TCP_Init
LISTEN() = TCP_Listen
CONNECTED() = TCP_Connected
SERVICE() = Internal_Telnet
Log File for Accepts & Rejects = MULTINET:SERVER.LOG
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] YES
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600054
SERVER-CONFIG>

The next example shows the auditing records written to the log file.

15-JUN-2015 17:27:00 RPCPORTMAP (accepted) from [127.0.0.1,108] (localhost)
15-JUN-2015 17:50:25 FINGER (accepted) from [10.1.228.65,1071] (ABC.COM)
15-JUN-2015 21:10:40 RLOGIN (accepted) from [10.1.228.65,1022] (ABC.COM)
16-JUN-2015 11:49:46 FINGER (accepted) from [10.1.228.65,1214] (ABC.COM)
16-JUN-2015 11:51:05 RLOGIN (accepted) from [10.1.228.68,1022] (Bubba)
16-JUN-2015 20:09:48 FTP (accepted) from [10.1.228.68,1039] (Bubba)

 

Writing an Auditing Dispatcher

MultiNet allows a system manager to further customize the auditing facilities.

You can provide a user-written shareable image that is merged into the MULTINET_SERVER when the server is restarted. The user-written shareable image is called whenever a connection arrives with information about the connection and can perform the desired auditing.

If the MultiNet Programmer’s Kit is installed, the directory MULTINET_ROOT:[MULTINET.EXAMPLES] contains the file USER_AUDITOR.C. This is a C-language template of a routine called when a connection arrives.

Compile, link, and place it in the MULTINET: directory according to the instructions at the beginning of the file.

 

Detecting Intruders

MultiNet provides the IP address and an optional IP port number of a suspected intruder to OpenVMS accounting and intrusion detection. The IP address is recorded in hexadecimal format to make room for the optional IP port address. By default, the IP port address is included. To disable this feature, set the LGI_BRK_TERM system parameter to zero.

This example shows accounting and intrusion reports generated with LGI_BRK_TERM set to one (the default).

$ ACCOUNTING/NODE=TELNET
Remote node name:  TELNET            Privilege <31-00>: 00148000
Remote ID:         A12C800C:0F94     Privilege <63-32>: FFFFFFC0
                   ^^^^^^^^ ^^^^
IP address IP port
$ SHOW INTRUSION
Intrusion  Type           Count      Expiration      Source
NETWORK    SUSPECT         2         17:35:09.28    TELNET::A12C800C:0F94
                                                     ^^^^^^^^^^^^^^^^^^
                                                         IP address IP port

In these examples, A12C800C is the IP address 10.1.34.22 and 0F94 is IP port 3988, both expressed in hexadecimal. You can use the following DCL code to convert hexadecimal IP addresses and port numbers (of the form hex-address:hex-port-number) into dotted decimal format:

$ IP_ADDRESS   = F$ELEMENT(0,":",P1)
$ PORT_NUMBER  = F$ELEMENT(1,":",P1)
$ WRITE SYS$OUTPUT F$FAO("IP address/port:  !UL.!UL.!UL.!UL/!UL", -
F$INTEGER("%X''F$EXTRACT(0,2,IP_ADDRESS)'"), -
F$INTEGER("%X''F$EXTRACT(2,2,IP_ADDRESS)'"), -
F$INTEGER("%X''F$EXTRACT(4,2,IP_ADDRESS)'"), -
F$INTEGER("%X''F$EXTRACT(6,2,IP_ADDRESS)'"), -
F$INTEGER("%X''PORT_NUMBER'"))
$ EXIT

Intrusion detection uses the physical (Ethernet) address, SPX port number, and possibly the target user name. The target user name appears only when the break-in attempt targets a valid account and LGI_BRK_TERM is set to one (the default), as in the following example intrusion report.

$ SHOW INTRUSION
Intrusion   Type     Count  Expiration   Source
TERM_USER   SUSPECT    1    16:23:38.67  [A12C8000:AA.00.04.00.08.60#ECB]:
                                       ^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^  ^^^
                                     Network  Ethernet address  SPX User
                                        number                       port Name

In this example,

·         A12C8000 is the network number, expressed in hexadecimal.

·         AA.00.04.00.08.60 is the Ethernet address, expressed in dotted-hexadecimal format.

·         ECB is the SPX port.

·         No user name is specified; the user name normally follows the ending colon.

The OpenVMS SHOW INTRUSION Utility truncates the Source display field to 33 characters. The TERM_USER record is actually associated with a particular user name; you can delete it (with DELETE/INTRUSION) only by specifying the full source specification, including the invisible, truncated data.

 

Detecting Intruders on an FTP Server

The following example of an FTP_SERVER.COM file shows the use of the FTP server qualifiers. The first section ensures that global and local symbols appear as expected. Information is then taken from the logical names that store data about the person who has accessed this FTP server:

MULTINET_FTP_ADDRESS

Provides an ASCII representation of the user's IP address.

MULTINET_FTP_HOSTNAME

Provides an ASCII representation of the user's host name.

MULTINET_ANONYMOUS_PASSWORD

Contains an ASCII representation of the user's anonymous FTP password.

MULTINET_FTP_MAXIMUM_IDLE_TIME

Controls the duration (in seconds) the FTP server allows a connection to be idle before it is closed. The default is 300 seconds. This logical can be specified in any logical name table accessible to the user running the FTP server.

 

$ Set := "Set"
$ Set Symbol/Scope=(NoGlobal,NoLocal)
$ If F$TrnLNM("MULTINET_FTP_ADDRESS") .Eqs. "" Then -
MultiNet FTP/Server/Get_Remote_Info
$ FTP_Address = F$TrnLNM("MULTINET_FTP_ADDRESS")
$ FTP_Hostname = F$TrnLNM("MULTINET_FTP_HOSTNAME")
$ FTP_Password = F$TrnLNM("MULTINET_ANONYMOUS_PASSWORD")
$ Ident = FTP_Hostname
$ If FTP_Hostname .Eqs. "" Then Ident = FTP_Address

In the next section, if FTP_Hostname is null, the IP address could not be found in the host table or by DNS lookup. The Ident symbol is set to flag this event:

$ Message = ""
$ If FTP_Hostname .Eqs. "" Then -
       Message = Message + ",""Unknown hostname: ''Ident'; DNS Problem!"""
$ If F$Edit(FTP_Password,"UPCASE") .Eqs. "GUEST" Then -
       Message = Message + ",""''Ident'; say who really you are."""
$ Message = Message + ",""@WELCOME.TXT"""
$ If Message .Nes. "" Then -
       Message = "/Message=("+F$Extract(1,256,Message)+")"

In the following section, the banner message is altered to fit the circumstances under which the user logs in.

$ If F$Extract(0,6,FTP_Address) .Eqs. "192.0." Then Goto Intruder
$!
$ DirOptions = "/Directory=Users:[Anonymous]"
$ AccOptions = "/Access=NoWrite"
$ MultiNet FTP/Server 'AccOptions' 'DirOptions' 'Message'
$!
$ Logout/Brief

The following section tests the IP address for a known intruder. If the intruder is discovered, control is passed to the Intruder label. Next, the FTP server is called to handle the anonymous login, and when done, logs out.

1. An offensive stance is taken when an intruder is discovered by running a FINGER of the intruder's system.

2. INFLAME.TXT is invoked to display a personalized message.

3. The FINGER output is displayed on the intruder's terminal.

4. Mail is sent to the system manager to indicate that an intrusion event occurred.

5. The procedure exits.

$ Intruder:
$ Set NoOn
$ create finger.temp
$ define/user sys$output finger.temp
$ MultiNet Finger @'FTP_Address
$!
$ MultiNet FTP/Server/Reject/Message=("@Inflame.txt",-
"Thanks for listening ''FTP_Password'@''Ident';
       now smile:","","@finger.temp")
$ Mail/Subject="intruder FTP access from
       ''FTP_Password'@''Ident'" finger.temp system
$ del finger.temp;*
$ logout/Brief

 

Detecting Intruders with NETCONTROL Accounting

If OpenVMS Accounting is enabled on your system, the following process header fields are set for network server processes created by the MultiNet master server:

·         CTL$T_NODENAME is the name of the service being run; for example, FTP, TELNET, or SMTP.

·         CTL$T_REMOTEID is the IP address of the remote client system in dotted-decimal format.

This change can make attempted break-ins to your system easier to track. It also provides a simple mechanism for tracking remote access to your system.

For example, to determine which users are using TELNET to gain access to your system, you can issue the command:

$ ACCOUNTING /NODE=TELNET

 

Note: IP address and port information is displayed in hexadecimal in accounting reports.

 

 

The MULTINET NETCONTROL command features ACCOUNTING and DEBUG parameters for the NETCONTROL (master server) service.

The format of this command is:

$ MULTINET NETCONTROL NETCONTROL ACCOUNTING n

By default (as described above), additional information is provided in the accounting record by the MultiNet server. You can disable this feature by setting n to 0. When set to 1, the remote name and service name are added to the ACCOUNTING record.

OpenVMS adds accounting records to a central database each time a special system event occurs. These events include processes exiting, images (programs) ending, failed logins, and so on. OpenVMS stores a record of the event with information from the process.

One item that OpenVMS includes in the accounting record is the remote node ID, which it gets from the internals of the process. For most processes, the remote node ID is empty.

When you use SET HOST to create a log for another node, DECnet fills in the remote node ID field when it creates the process. This information then appears in any accounting record generated for that process.

If you suspect an intruder has attempted a security breach of your system, you can examine the accounting records to see who has logged in and identify where a login attempt originated.

The master server fills in both the remote node ID and the node name field. The remote node ID field is set to the ASCII representation of the dotted-decimal IP address of the node that requested the service. The NODE NAME field is set to the service name, such as FTP, TELNET, and so on.

The following example shows a LOGIN failure accounting record:

LOGIN FAILURE
-------------
Username:         JDOE         UIC:               [SYSTEM]
Account:          <net>        Finish time:       23-MAR-2020 21:27:34.47
Process ID:       21200124     Start time:        23-MAR-2020 21:27:33.81
Owner ID:                      Elapsed time:                0 00:00:00.66
Terminal name:                 Processor time:              0 00:00:00.26
Remote node addr:              Priority:          4
Remote node name: FTP          Privilege <31-00>: FFFFFFFF
Remote ID:        10.1.1.94    Privilege <63-32>: FFFFFFFF
Remote full name:
Queue entry:                   Final status code: 00D380FC
Queue name:
Job name:
Final status text:%LOGIN-F-INVPWD, invalid password
Page faults:              166      Direct IO:                  7
Page fault reads:           5      Buffered IO:               12
Peak working set:         246      Volumes mounted:            0
Peak page file:          3280      Images executed:            1

 

Using UCX-Compatible Services under MultiNet

Services written to be started by the auxiliary server (INETD) in HP TCP/IP Services can be configured for use with MultiNet by setting the service parameter SET FLAGS UCX_SERVER.

Driver enhancements support TeamLinks, POSIX sockets, DCE for OpenVMS, and TCP/IP Services V2.0 keepalive compatibility.

The logical names UCX$INET_HOSTADDR and TCPIP$INET_HOSTADDR contain the text value of the primary interface. MultiNet defines UCX$INET_HOSTADDR and TCPIP$INET_HOSTADDR automatically, much the same as other TCP/IP Services logical names. It is defined in START_MULTINET.COM.

Performing a close (dassgn) operation on any TCP/IP Services (BG) device used in a select list cancels the select operation.

The following logicals are defined for improved UCX compatibility:

TCPIP$BIND_DOMAIN
TCPIP$BIND_SERVER000
TCPIP$BIND_SERVER001 (if more than one BIND server is defined)
TCPIP$BIND_SERVER002 (if more than one BIND server is defined)
TCPIP$DEVICE = BG:
TCPIP$INET_DEVICE = BG:
TCPIP$INET_HOST
TCPIP$INET_HOSTADDR
TCPIP$IPC_SHR = MULTINET:UCX$IPC_SHR

 

Associating Command Procedures with Services

You can specify DCL command procedures (.COM files) as the programs associated with MultiNet services. When a service is initiated, MultiNet calls LOGINOUT to invoke the user's LOGIN.COM file and the specified DCL command procedure. When called, the DCL and CLI are mapped for use by the process. This feature gives the system manager a "hook" into a service with an easy-to-create command procedure. Note, however, that the command procedure cannot use SYS$INPUT. Therefore, do not use the READ SYS$INPUT or INQUIRE commands in the command procedure or a user's LOGIN.COM file.

Make sure that all command procedures associated with services include a command that assigns SYS$INPUT to SYS$OUTPUT as follows:

$ DEFINE /USER SYS$INPUT SYS$OUTUT

This command must appear immediately before any command that runs an image, but is only in effect while the image is running. To ensure the assignment lasts for the duration of the entire command procedure, use the above command without the /USER qualifier:

$ DEFINE SYS$INPUT SYS$OUTPUT

 

Setting Keepalive Timers

Keepalives are useful when other systems that connect to services provided by your system are subject to frequent crashing, resets, or power-offs (as with personal computers). TCP/IP connections must normally pass through a three-way handshake sequence to be closed and removed from the connection table. If a connection is open but idle, and the remote system is shut down, reset, or crashes, the connection is not closed down until your system attempts to communicate with the remote system. If an application or service does not attempt to communicate, a keepalive probe can clean up these dormant connections.

The format for the SET KEEPALIVE-TIMERS function is:

SERVER-CONFIG>SELECT service

SERVER-CONFIG>SET KEEPALIVE-TIMERS idle-time probe-interval probe-count

 

idle-time

is the amount of time, in seconds, that a connection should be idle before the first keepalive probe is sent.

probe-interval

is the number of seconds between keepalive probes (75 seconds minimum).

probe-count

is the number of probes sent, with no reply from the other side of the connection, before the connection is destroyed.

 

Setting any of these parameters to 0 retains its default setting.

If you set the SO_KEEPALIVE socket option for a service, but you do not explicitly set KEEPALIVE-TIMERS, the default values are:

·         idle-time is 2 hours.

·         probe-interval is 75 seconds.

·         probe-count is 8.

If you do not set the SO_KEEPALIVE socket option for a service, no keepalive probes are sent for connections to that service.

 

Configuring TFTP (Trivial File Transfer Protocol)

The MultiNet TFTP service uses standard Internet TFTP to perform file transfers. Like FTP, TFTP can also be used to transfer files between a host running OpenVMS and a remote host. Unlike FTP, TFTP cannot perform operations other than transferring files between a local system and a remote one; that is, TFTP cannot list directories, delete files, and so on.

TFTP does not perform any authentication when transferring files, so a user name and password on the remote host are not required. In general, only files with world-read (W:R) access in certain directories on the remote host are available for reading, and only certain directories are available for writing.

Use SERVER-CONFIG to enable TFTP as follows:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.6(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE TFTP
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]|            SERVICES.MASTER_SERVER]
$

 

Note: The permissions of the accessed directories are not checked before the access is attempted. Because the TFTP protocol does not specify any user login or validation, the TFTP server permits only WORLD-readable files to be accessed.

 

 

The TFTP server normally requires full file system pathnames, as it operates without a default directory. If you are using TFTP to download network servers which may not be able to provide full pathnames, you can set a TFTP default directory using the NET-CONFIG SET TFTP-DIRECTORY command.

 

Note: The TFTP mail option, as defined in RFC-783, is obsolete and not supported under the MultiNet TFTP server.

 

 

 

Note: The TFTP server supports the BLKSIZE option (RFC 2348) with a minimum of 512 and maximum of 8192.  For image (octet) transfers the size must be a multiple of 512.

 

 

 

TFTP File Name Translations

The MULTINET:TFTP.FILENAME-TRANSLATIONS file can be used to translate between TFTP client file names and OpenVMS file names, and restrict TFTP access to certain files or directories. The following is an example of a MULTINET:TFTP.FILENAME-TRANSLATIONS file:

#
# TFTP filename fixups for broken TFTP
# loaders & file access restrictions
#
RESTRICT-ACCESS
#
# This is a translation for a single file
#
/Foo/bar.dat                    SYS$MANAGER:BAR.DAT
#
# These two translations map an entire OpenVMS directory
#
/usr/lib/X11/ncd/configs/*      NCD_CONFIGS:[000000]
/ncd_fonts/dw75dpi/*            NCD_FONTS:[DW75DPI]
#
# This translation is a file access restriction
#
SYS$SYSROOT:[SYSFONT.DECW.*        SYS$SYSROOT:[SYSFONT.DECW.

Use either # or ! to start a comment.

If the keyword RESTRICT-ACCESS is on a line by itself in the file, only files that match one of the translation specifications are accessible. This restricts TFTP access to specific directory hierarchies. If this string is not specified in the FTP.FILENAME-TRANSLATIONS file, all WORLD-readable files are accessible to TFTP clients.

The first translation causes a client reference to /Foo/bar.dat to access the OpenVMS file SYS$MANAGER:BAR.DAT (note that comparisons are not case-sensitive). This is an example of a translation for a single file.

The next two translations are examples of mapping an entire OpenVMS directory. If the client reference matches everything up to the asterisk (*), the rest of the client reference is appended to the translation string. For example, /usr/lib/X11/ncd/configs/foo.dat becomes NCD_CONFIGS:[000000]FOO.DAT.

The last translation is an example of a file access restriction. The result of the translation is the same as the client-specified file. The TFTP server disallows subdirectory specifications that include ".-" to ensure you cannot bypass access restrictions by going back up the VMS directory hierarchy.

If the file MULTINET:TFTP.FILENAME-TRANSLATIONS is edited, NETCONTROL must be used to RELOAD it:

$ MULTINET NETCONTROL TFTP RELOAD

 

Configuring "R" Services

This section describes configuration of the "R" services, RLOGIN and RSHELL.

·         RLOGIN provides a means of logging in to another system.

·         RSHELL executes commands remotely on another system.

These services are enabled when MultiNet is installed.

The authentication scheme used by RLOGIN and RSHELL is based on trusted users and trusted hosts specified in files on the destination system. The MULTINET:HOSTS.EQUIV file (/etc/hosts.equiv on UNIX systems) grants access on a system-wide basis. The file SYS$LOGIN:.RHOSTS (~/.rhosts on UNIX systems) can be used by individual users on a system to grant remote users access to their accounts.

 

Note: Do not use IP addresses in the HOSTS.EQUIV or .RHOSTS file.

 

 

Access control requirements differ between RLOGIN and other R services. RLOGIN requires both NETWORK and LOCAL access, while RSHELL, REXEC, RMT, and RCP only require NETWORK access.

If you remove a user's NETWORK access, the user can still log in until their RLOGIN cache entry expires or is flushed. However, if you remove that user's LOCAL access, the user is denied access immediately, even if they have a current cache entry.

The format of an entry in the HOSTS.EQUIV or .RHOSTS file is:

hostname        [username]

If an entry containing only the host name is in the file MULTINET:HOSTS.EQUIV (or /etc/hosts.equiv) on the target system, all users on hostname with the same user name as on the target system can access the target without specifying a user name or password.

Both MULTINET:HOSTS.EQUIV and SYS$LOGIN:.RHOSTS accept "wildcards" in host names. For example, to specify all hosts at EXAMPLE.COM, include the following line:

*.EXAMPLE.COM

If an entry in SYS$LOGIN:.RHOSTS or a user's ~/.rhosts file contains the following format, the specified username on the hostname system can access the user's account on the target system without specifying a password (or a user name if the user names are identical on the two systems):

hostname        username

The next example shows a HOSTS.EQUIV file on the host SALES.EXAMPLE.COM that gives users on SALES.EXAMPLE.COM RLOGIN and RSHELL access to their own accounts on the system (this is allowed by the first two entries).

In this example, EXAMPLE.COM and BUBBA.EXAMPLE.COM are identified (in the last two entries) as trusted hosts, allowing any user on either of these systems to have RLOGIN and RSHELL access to the account of the same name on SALES.EXAMPLE.COM without specifying a user name or password.

localhost
sales.example.com
example.com
bubba.example.com

This example shows a .RHOSTS file that belongs to a user on SALES.EXAMPLE.COM:

example.com       system
unix.example.com  root

The first entry grants access to the user's account on the host SALES.EXAMPLE.COM to user SYSTEM on host EXAMPLE.COM. The second entry grants access to the user's account to user root on host UNIX.EXAMPLE.COM. Hence, either of these two remote users can use RLOGIN or RSHELL to access the user's account on SALES.EXAMPLE.COM without specifying a password.

Note! When specifying a user in any of the authentication files (particularly on the UNIX operating system), make sure to specify the user name in the correct case. ROOT and root are treated as different user names under case-sensitive systems such as UNIX.

The host initiating the RLOGIN or RSHELL request must be listed in the destination host's hostname database or must be resolvable within the Domain Name System (DNS), if domain name service is enabled. If the destination host cannot determine the initiating host's name from the IP address in the connection request, it rejects the request.

The RLOGIN server parameters INCLUDE-AUTHENTICATION-INDICATION, INCLUDE-PORT-NUMBER and INCLUDE-SEND-LOCATION cause an authentication indication, a port number, or a send location (or all three) to be placed in the TT_ACCPORTNAM field of the NTY device control block. These parameters are disabled by default. To enable them, use SERVER-CONFIG (MULTINET CONFIGURE /SERVER).

 

Disabling the Standard Error RSHELL Connection

The RSHELL /NOSTDERR option disables creation of the connection from the remote RSHELL server back to the client for "standard error" output. This allows you to use the RSHELL command through firewalls that do not allow TCP connections that originate from outside the local network. When you use this option, the remote RSHELL server sends messages to the "standard output" connection, so error messages are still displayed.

 

RLOGIN and RSHELL Authentication Cache

The MultiNet RLOGIN and RSHELL servers cache the contents of the .RHOSTS and HOSTS.EQUIV files and authentication information from the SYSUAF file in memory for ten minutes to improve performance. This means that changes made to these files may not be noticed by the network immediately. Use the following command to flush the cache before the timeout period:

$ MULTINET NETCONTROL RLOGIN FLUSH

You can use SERVER-CONFIG to change the timeout on these caches by setting the RHOSTS-TIMEOUT or UAF-TIMEOUT parameters for RSHELL, RLOGIN, or REXEC. The default value for these parameters is 600 seconds. Setting a value of 0 (zero) disables the cache. Because the "R" services share a common authentication cache, you need only set these parameters for one service. If you set different values for different servers, only one of the values is used, so set these parameters on only one server. The following example shows how to set the timeout parameter.

$ MULTINET CONFIGURE/SERVER
MultiNet Server Configuration Utility 5.6(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT RLOGIN
[The Selected SERVER entry is now RLOGIN]
SERVER-CONFIG>SET PARAMETERS
Delete parameter "rhosts-timeout 0" ? [NO] YES
[Parameter  "rhosts-timeout 0" deleted from RLOGIN]
You can now add new parameters for RLOGIN.  An empty line terminates.
Add Parameter: RHOSTS-TIMEOUT 3600
Add Parameter: UAF-TIMEOUT 60
Add Parameter:
[Service specific parameters for RLOGIN changed]
SERVER-CONFIG>

The UAF access type specification for RSHELL access is NETWORK. MultiNet checks all access times.

The MULTINET NETCONTROL RLOGIN SHOW command shows the time the information read in from specific .RHOSTS files will expire. This is the time remaining until the .RHOSTS file is read in again.

 

Note: A non-existent .RHOSTS file is treated the same as an empty .RHOSTS file.

 

 

Controlling RSHELL and REXEC Process Deletion

If a client closes a connection before the remote process finishes, the RSHELL and REXEC servers may delete the process. This behavior affects PC-based X servers that use REXEC to launch X applications.

This default action can be changed by using SERVER-CONFIG to SET PARAMETER as in the following example:

$ MULTINET CONFIGURE /SERVER
. . . startup messages . . .
SERVER-CONFIG>select rshell
[The Selected SERVER entry is now RSHELL]
SERVER-CONFIG>set parameter
You can now add new parameters for RSHELL.  An empty line terminates.

Add Parameter: ?

parameter, one of the following:
DEBUG          DISALLOW-RHOSTS           DISALLOW-X-DISPLAY
PREVENT-PROCESS-DELETION  RHOSTS-TIMEOUT            UAF-TIMEOUT
or confirm with carriage return
Add Parameter: PREVENT-PROCESS-DELETION
Add Parameter:
[Service specific parameters for RSHELL changed]
SERVER-CONFIG>

 

Controlling Automatic WSA Device Creation

By default, MultiNet R services create WSA devices and set displays to simplify setup for X client users, allowing users to run X clients without explicitly issuing the SET DISPLAY command. To disable this feature, set DISALLOW-X-DISPLAY with the SET PARAMETER command (in SERVER-CONFIG).

 

Inhibiting Output in Command Procedures for "R" Services

Problems arise when remote users log into systems using a login command procedure (SYS$LOGIN:SYLOGIN.COM or SYS$MANAGER:SYLOGIN.COM) that requires screen output. To inhibit this behavior, make sure the following lines are included at the top of all login command procedures:

$ VERIFY = 'F$VERIFY(0)                 ! Turn off verify without echoing
$ IF F$MODE() .EQS. "OTHER" THEN EXIT   ! If a DETACHED process (RSHELL)
. . .
$ IF VERIFY THEN SET VERIFY             ! If a batch job, may want to turn
                                        ! verify back on.

 

Permitting "R" Service Access to Captive or Restricted Accounts

In general, R services should not be permitted access to captive or restricted OpenVMS accounts. However, if your users depend on such access, define the following logical to allow access to these types of accounts:

$ DEFINE/SYSTEM/EXEC MULTINET_RSHELL_ALLOW_CAPTIVE "TRUE"

 

Configuring the TELNET Server for Kerberos V5

Enable the Kerberos V5 functionality with the following commands:

$ MULTINET CONFIGURE /SERVER
... startup messages...
SERVER-CONFIG>SELECT TELNET
(The Selected SERVER entry is now TELNET)
SERVER-CONFIG>SET PROGRAM MULTINET:LOADABLE_KTELNET_CONTROL
(Program to run for TELNET set to MULTINET:LOADABLE_KTELNET_CONTROL)
SERVER-CONFIG>SET INIT Merge_Image
(Init action of TELNET set to Merge_Image)

After the values are saved and the Master Server is restarted, Kerberos 5 functionality is available.

The authentication behavior on the TELNET Server is determined by the system logical MULTINET_TELNET_AUTH. It has 3 possible values: ALLOWED, REQUIRED, and DISABLED.

 

Note: Not all configuration options are available with the Kerberos V5 Server. While the Kerberos V5 Server is started and terminated by the Master Server, it runs as a separate process. It uses a limited subset of server control options. Server control options currently supported are: INIT, Program, Priority, and Log-Accepts. To set the SOCKET-PORT option, use the system logical MULTINET_TELNET_PORT.

 

 

The default is DISABLED; a login prompt will result. When the value is REQUIRED, any user without a valid Kerberos V5 Ticket Granting Ticket (TGT) will be rejected. Finally, if the value is ALLOWED, the user can log-in to the server with or without a valid Kerberos V5 TGT (with a login prompt resulting if no TGT).

For example, to force authentication by any remote telnet client, set the logical as follows:

$ DEFINE/SYSTEM MULTINET_TELNET_AUTH REQUIRED

 

Note: Kerberos V5 requires Kerberos for OpenVMS (Version 2.0), which is available from the HP Web site. The Kerberos V5 applications can also run with any Kerberos V5-compliant Key Distribution Center (KDC) software. Kerberos V5 applies to VMS V7.0 or higher, and VMS Alpha V7.2-2 or higher.

 

 

Configuring the TELNET Server for NTY Devices

The TELNET server parameters INCLUDE-AUTHENTICATION-INDICATION, INCLUDE-PORT-NUMBER and INCLUDE-SEND-LOCATION cause an authentication indication, a port number, or a send location (or all three) to be placed in the TT_ACCPORNAM field of the NTY device control block. These parameters are disabled by default. To enable them, use SERVER-CONFIG (MULTINET CONFIGURE /SERVER).

 

Note: These parameters will not function with the Kerberos 5 Telnet server, as it uses pty devices.

 

 

Enable these parameters with the following commands:

$ MULTINET CONFIGURE /SERVER
. . . startup messages . . .
SERVER-CONFIG>SELECT TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET PARAMETERS
You can now add new parameters for TELNET. An empty line terminates.
Add Parameter: INCLUDE-AUTHENTICATION-INDICATION
Add Parameter: INCLUDE-PORT-NUMBER
Add Parameter: INCLUDE-SEND-LOCATION
Add Parameter: RETURN
[Service specific parameters for TELNET changed]
SERVER-CONFIG>

If these parameters are defined, the appropriate information is stored in the TT_ACCPORNAM field.

These parameters appear in the Remote Port Info field of the SHOW TERMINAL and SHOW USERS command output. The INCLUDE-SEND-LOCATION parameter enables support for RFC 779 in the Telnet server. In the following example, the port number is 1021, and the /AUTH qualifier indicates that WHORFIN used authentication to log in from LOT49.EXAMPLE.COM.

$ SHOW TERMINAL

Terminal: _VTA84:  Device_Type: VT100            Owner: WHORFIN        Physical terminal: _NTY3:                                                Remote Port Info:  LOT49.EXAMPLE.COM/1021/AUTH                         Input:   9600      LFfill:  0      Width:  80    Parity: None         Output:  9600      CRfill:  0      Page:   24

Terminal Characteristics:                                          Interactive     Echo              Type_ahead         No Escape
No Hostsync     TTsync            Lowercase          Tab
Wrap            Scope             Remote             No Eightbit
No Broadcast    No Readsync       No Form            Fulldup
No Modem        No Local_echo     Autobaud           Hangup
No Brdcstmbx    No DMA            Altypeahd          Set_speed
No Commsync     Line Editing      Insert editing     No Fallback
No Dialup       No Secure server  Disconnect         No Pasthru
No Syspassword  No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad  ANSI_CRT          No Regis           No Block_mode
Advanced_video  No Edit_mode      DECEC_CRT2
No DEC_CRT3     No DEC_CRT4       VMS Style Input
$

Authentication information is not valid if someone uses the LOGOUT /NOHANG command and then logs in again.

 

Configuring SYSLOG

SYSLOG receives messages from remote IP nodes that have been configured to forward SYSLOG messages to the MultiNet host. SYSLOG then directs the messages to a file, terminal, or OPCOM. In addition, messages can be forwarded elsewhere. (Forwarding messages are specified with the Forwarding command in the SYSLOG configuration file)

SYSLOG is provided with MultiNet, and you can enable it with SERVER-CONFIG. By default, when MultiNet is installed, SYSLOG is disabled.

 

Note: Messages generated by the MULTINET_SERVER process are not sent via SYSLOG, but are instead directed to OPCOM. OPCOM copies the messages to the SYS$MANAGER:OPERATOR.LOG file.

 

 

With SYSLOG enabled, you can determine the precise output of message classes and specify how priority messages are handled. Message classes and facility keywords are described below.

Message Type

Facility Keyword

Authorization messages

auth

BOOTP messages

bootpd

Daemon (background processes) messages

daemon

Domain Name System messages

named

GATED (gateway messages)

gated

Kernel messages

kern

LPR messages

lpr

mesages from local facilities

local0 - local7

NEWS messages

news

Mail utility messages

mail

Network Time Protocol (NTP) messages

ntpd

PPP messages

ppp

Security services messages

security

Messages generated by user programs

user

 

Enabling SYSLOG

Enable SYSLOG with SERVER-CONFIG and modify the file MULTINET:SYSLOG.CONFIGURATION. Enable SYSLOG as follows:

$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.6(nnn)

                     

[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]    

SERVER-CONFIG>ENABLE SYSLOG

SERVER-CONFIG>EXIT

 [Writing configuration to MULTINET_COMMON_ROOT:[MULTINET] SERVICES.MASTER_SERVER]                                                       $

Add entries to the configuration file in the following form:  selector action

Separate the fields with tabs. The selector is a semicolon-separated list of priority specifications in this form:  

facility.level[;facility.level]

 

facility is a keyword (see the above table for a list of SYSLOG facility keywords).

Both facility and level are generated by applications on the remote host. The action specifies how SYSLOG responds to these messages. If the applications on the remote host do not write messages to SYSLOG, they are not displayed.

Possible values for facility are auth, bootpd, daemon, gated, kern, mail, named, ntpd, security, user, and asterisk (*). (Specify an asterisk to include all messages written to SYSLOG of the specified priority.)

Each facility represents a different source of system message. The level is the priority level for each message. Possible values ranging from most severe to least severe are panic, emerg, alert, crit, err, error, warn, warning, notice, info, debug, and asterisk (*). (Specify an asterisk to include all messages for the specified level.)

Examples of facility.level statements are:

Example

Description

*.debug

All debug messages

ntp.info

Network Time Protocol information messages

gated.warn

GATED warning messages

 

The action is the destination of the message. Possible message destinations include:

Destination

Specified As

Example

Broadcast  (RWALL)

Asterisk

*

Console

Use OPCOM

/OPCOM

File

Precede the fully specified file name with a slash

/USERS:[HOLMES]OUTFILE.

Forwarding

Precede the IP address or host name with an at sign (@)

@192.92.38.1

OPCOM

Precede with a slash

/OPCOM

Terminal

Precede the terminal name with a slash and end name with a colon

 /TXA3:

 

Each message handled by SYSLOG includes a time stamp, the facility name at the beginning of the message, and a newline character at the end of the message.

Comments are entered in the SYSLOG.CONFIGURATION file as pound signs (#) at the beginning of the line.

 

SYSLOG Configuration File Examples

Some example SYSLOG.CONFIGURATION file entries are shown below:

# SYSLOG.CONFIGURATION examples
#
# Each entry is tab-separated and has this form:
#         selector      action
#
*.debug                         /OPCOM
kern.panic;kern.warning         /OPCOM
syslog.info                     /users:[treefrog]syslog_info_messages.
*.error                         @forwardhost
user.*                          /users:[treefrog]all_user_messages.