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.
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.
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.
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.5(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]
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 |
|
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.
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.
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.5(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
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>
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.5(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>
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.5(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)
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.
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.
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
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! The TELNET service complies with RFC-779 and provides location information.
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: MILLER UIC: [SYSTEM]
Account: <net> Finish time: 23-JUN-2015 21:27:34.47
Process ID: 21200124 Start time: 23-JUN-2015 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
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
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
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.
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.5(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.
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
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).
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.
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.5(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.
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>
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).
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.
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"
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_AUTH_TELNET. 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 HP 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.
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.
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 |
|
|
Network Time Protocol (NTP) messages |
ntpd |
|
PPP messages |
ppp |
|
Security services messages |
security |
|
Messages generated by user programs |
user |
Enable SYSLOG with SERVER-CONFIG and modify the file MULTINET:SYSLOG.CONFIGURATION. Enable SYSLOG as follows:
$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(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.
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.