PyDECnet uses a configuration file to describe the DECnet node it implements. This file is somewhat analogous to the DECnet configuration database described in the DNA Network Management architecture specification. The configuration file is a text file; each line in the file is formatted somewhat like a Unix shell command line. Comment lines have a "#" in column 1; these and blank lines are ignored. Lines beginning with "@" are include file references. The file name follows the @ sign. That file is read at this point and processed as if its text were included in the top level config file. Includes may be nested to any level that does not overflow the Python stack. An alternate include file reference looks like "component @filename", for example "node @nodenames.dat". This will read the named file and process each line in it, but with the component name prefixed onto each line. The HECnet standard "nodenames.dat" file contains node definitions in the same form as the arguments to the "node" component line, so "node @nodenames.dat" will read the PyDECnet node definitions from that file. At startup, PyDECnet reads the config file(s) named in the command line, and any includes mentioned. After the config file has been fully parsed, execution begins provided no errors were found during config file reading. Each top level config file defines either a DECnet node (instance of "routing"), an Ethernet bridge, or the HTTP and API access features. So each config file must contain either a "routing", a "bridge", or one or both of the "api" and "http" components -- but no other combination of these. Each config file line resembles a Unix command invocation, with GNU-style flexible order: component --switch swarg --switch cmdarg cmdarg2 component --switch cmdarg cmdarg2 swarg --switch for example: circuit eth-1 Ethernet en1 --cost 3 The components roughly correspond to those listed in the DECnet architecture specifications, and many of the switch names are taken from the names of configuration variables in those specifications. The supported components, switches, and arguments are described in detail below. Switches are always optional. Command arguments may be required or optional, as described below. Components circuit, node, and object may occur more than once, where each occurrence describes a particular circuit, node, or object distinguished by name and/or address or number. A given name or number may occur more than once, so long as any attribute values in the earlier occurrence are matched in the later one. So a later occurrence can simply be a duplicate, or it can add a parameter value that was omitted in the earlier occurrence. If these rules are violated, a "Conflicting entry" error results. A typical case is the use of a common node name definition file that only specified address and name for each node, followed by a specific override for some of these nodes to add verification strings. For example, the following is legal node 1.2 test node 1.2 test --inbound-verification password but this is not: node 1.2 test node 1.2 other nor this: node 1.2 test --inbound-verification password node 1.2 test --outbound-verification mystring (since the inbound-verification parameter was not present in the second occurrence) Component "http" This optional component enables HTTP and/or HTTPS access for monitoring. It has several optional switches. If there is no "http" component in any config file, HTTP(S) is disabled. --http-port: an integer in the range 0..65535, the TCP port number for the HTTP listener. Default is 8000. The value 0 disables HTTP. --https-port: an integer in the range 0..65535, the TCP port number for the HTTP listener. Default is 8443. The value 0 disables HTTPS. --certificate: the file name of an X.509 certificate file (.pem file) containing the SSL server certificate to be used for HTTPS. Default is "decnet.pem". -4: enable HTTP access via IPv4. -6: enable HTTP access via IPv6. These two switches are supported only if the platform has dual-stack support (which Windows, Linux, and Mac OS all do) as described in RFC 3493. If neither switch is present, both IPv4 and IPv6 are accepted; if only one is, then only that IP protocol is accepted. --local-address: local IP address to use, for both HTTP and HTTPS. Defaults to accepting any local address (i.e., HTTP and HTTPS connections to any of the host's addresses are accepted). --http-root: directory which contains the "resources" subdirectory, from which fixed files such as the decnet.css and icon files are served. Defaults to the directory containing the PyDECnet source files. --mapper: argument is a string which is the map title. This option enables the network mapper, which uses information collected from NICE management queries of reachable nodes to construct a map of the network. PLEASE NOTE: on the HECnet, this SHOULD ONLY be enabled after prior approval from Johnny Billquist and Paul Koning, to prevent excessive load on network nodes due to polling from too many places. One or two mappers per network is sufficient. TODO: define authorization mechanisms. Component "api" This optional component enables the Unix socket based general API, documented in detail in doc/api.txt. If there is no "api" component in any config file, the general API is disabled. The "api" component may be combined with "http" in a config file, but neither may be combined with "routing" or "bridge". name: an optional file name argument specifies the name of the Unix socket to be used for the API. The default is /tmp/decnetapi.sock. --mode: an octal integer in the range 000 to 777, which specifies the file mode for the socket. The default is 666, which allows any process on the system to read and write the socket. You can use more restrictive modes to limit access to the API via the standard Unix access rules. Component "routing" This component is required for a DECnet node. It describes the DNA Routing layer. Many of the parameters correspond to those mentioned in the DNA Routing specification, generally by the same name. Please refer to that specification for a full description. Note that some DNA Routing layer parameters are not used by PyDECnet; for example, some are used to implement size limitations on tables where PyDECnet has no need to limit those tables. Argument: node ID. The "routing" entry requires the node address of this node as argument. The node address has the usual form, either an integer, or a dotted pair. Note that it must be an integer for Phase III or Phase II nodes, since those don't have areas. There must be a node name definition (in the "node" section) for this node address. --type: Routing layer type, one of "l2router", "l1router", "endnode", "phase3router", "phase3endnode", "phase2". Default is "l2router". --maxhops: Maximum number of hops on the path to a node within the area before that node is considered unreachable. Argument is an integer in the range 1..30, default is 16. --maxcost: Maximum path cost to a node within the area before that node is considered unreachable. Argument is an integer in the range 1..1022, default is 128. --amaxhops: Maximum number of hops on the path to an area before that area is considered unreachable. Argument is an integer in the range 1..30, default is 16. --amaxcost: Maximum path cost to an area before that area is considered unreachable. Argument is an integer in the range 1..1022, default is 128. --maxvisits: Maximum number of hops a packet may visit before it is considered undeliverable. Argument is an integer in the range 1..63, default is 32. --maxnodes: Maximum node number in the area. Argument is an integer in the range 1..1023, default and maximum is 1023 for Phase IV nodes, 255 for Phase III nodes. --maxarea: Maximum area number. Argument is an integer in the range 1..63, default is 63. --t1: Background routing message transmission interval, in seconds, for point to point circuits. Argument is an integer, default is 600 (i.e., 10 minutes). --bct1: Background routing message transmission interval, in seconds, for LAN circuits. Argument is an integer, default is 10. Component "node": This config line defines an entry in the node database, i.e., a mapping between node ID and node name. These are all optional (it is valid to have no names defined) with one exception: there must be a name defined for the local node, the one whose address is the argument of the "routing" configuration line. Arguments: id name. Node ID is a node address either as an integer or a dotted pair. Note that it must be an integer if the local node type (from the "routing" configuration statement) is Phase III or Phase II, since those don't have areas. Name is the node name, which must conform to DECnet node name rules (1 to 6 characters, alphanumeric, at least one letter). The name may be supplied in either case but is converted to upper case. --inbound-verification: Verification value required from this node, if it is the neighbor on a point to point circuit which has --verify specified to require inbound verification. Maximum length is 64 characters except when communicating with Phase II nodes, in which case the limit is 8 characters. --outbound-verification: Verification value to send to this node, if it is the neighbor on a point to point circuit and requests verification. The value is a string. If this argument is omitted and the node requests verification, a null string is sent (which may or may not be accepted by the remote node). Maximum length is 64 characters except when communicating with Phase II nodes, in which case the limit is 8 characters. Component "circuit": This config line defines a circuit. End nodes must have exactly one circuit (since DNA requires this for Phase III or Phase IV end nodes). Routers and Phase II nodes must have at least one circuit. There is no specific upper bound on the number of circuits (PyDECnet will support any number until you run out of Python memory or execution becomes too slow). Argument: name. This is the name by which the circuit is referenced internally. It has no particular significance but must be unique; it is converted to upper case. There is a DECnet convention that circuit names consist of a device name, hyphen, and unit number, for example ETH-0. Argument: Circuit type. One of "DDCMP", "Ethernet", "Multinet", "GRE". Default is Ethernet. Ethernet and GRE are "LAN" type circuits; DDCMP and Multinet are point to point type circuits. Note that Multinet over UDP does not work well (defective protocol design, there's nothing the implementation can do about that) and is not recommended -- Multinet over TCP is ok. Optional argument: Device name or connection data. The meaning of this string depends on the circuit type. In previous versions, this argument might contain several parts separated by colons, especially for IP based connectivity. That form is still supported for backward compatibility but not recommended because the syntax varies and is not easy to remember. It is optional in the sense that some circuit specifications do not use it, but others require it; see the details below for the different "mode" values. Network configuration arguments: these four optional arguments are used to specify network parameters for any of the circuit types that communicate over IP based protocols. --local-address: Local IP address to use. If not specified, the OS default is used. --local-port: Local TCP or UDP port number to use. For TCP, this specifies the listen port (for incoming connections). But with Multinet it can also be used with outbound connections ("connect" mode), in case the other end requires a specific sending port number. --remote-address: Remote IP address. If omitted or specified as "*", for inbound TCP modes, any destination address is accepted. For UDP and GRE, this is not yet allowed, a specific address must be specified. --remote-port: Remote TCP or UDP port number. For TCP inbound connections, this is typically omitted in which case the port number is not checked. -4: IPv4 allowed -6: IPv6 allowed Source and destination may be numeric addresses, or DNS names. If a name is used, this is resolved at startup and again every hour, to allow for dynamic addresses. Source must be a single address; if a name is used that must translate to a single address (from among the address families allowed by the -4 and -6 switches). Address families: if -4 or -6, but not both, are supplied, only that address family is enabled. If both are present, both are enabled if the system supports it. The default is -4 -6, i.e., both enabled. If names are used, the addresses found by the lookup are used in random order. But -4 or -6 can be repeated to give preference to that family. For example, --remote-address google.com -466 will try any of that hosts's addresses, but all its IPv6 addresses will be tried before the IPv4 addresses. This applies to outbound traffic; inbound any enabled address will be accepted and that address will then be used. --mode: Datalink connection mode, for datalinks that can communicate in several different ways. Allowed values, for the various datalink types, are: Ethernet: tap: TUN/TAP accessing the TAP device named by the device argument. pcap: PCAP library accessing the Ethernet interface named by the device argument. bridge or udp: Attach this Ethernet to a Billquist bridge (using UDP). Network addressing is done by the network configuration arguments listed above. Multinet: udp: Multinet over UDP. Not recommended (not reliable) connect: Multinet over TCP, this side originates the connection. listen: Multinet over TCP, other side originates the connection. GRE: not used Note that GRE uses the source and destination address arguments but not source and dest port since the GRE protocol number is fixed. GRE supports IPv6 or IPv6, but it does not support both concurrently. For now, use the -4 or -6 switch to tell it which you want. DDCMP: serial: DDCMP over a (real) UART. The device argument is the device name, optionally followed by :speed (the default is 9600 baud). On a BeagleBone, if the Adafruit_BBIO module is installed, the additional field :uartport can be added, which is the port name of the UART device to be used. sync: DDCMP over a synchronous connection using the USB to DDCMP sync framer board. ("framer" can be used as a synonym for "sync".) The device argument is the device name (an Ethernet interface, which will be accessed using the pcap library) followed by :mode and then optionally :speed. Mode is "rs232_dte", "rs232_dce" or "integral" for RS-232 signalling with modem-supplied clocks, RS-232 signaling with framer supplying the clock, and "integral modem" (high speed coax connection) respectively. "coax" is also accepted as a synonym for "integral". Speed is the data rate in bits per second; this is required in rs232_dce and internal modes, not applicable for the rs232_dte (modem supplied clock) case. The interface name may be given as "*" if there is exactly one framer connected to the system; in that case its interface name will be looked up. For more information on the framer including documentation, firmware, and design files, see https://github.com/pkoning2/ddcmp udp: DDCMP over UDP. tcp: DDCMP over TCP. Unlike Multinet, both sides both connect and listen, compatible with how SIMH does it. telnet: DDCMP over TCP, with Telnet data encapsulation. Use this when the other end is a Telnet server connected to a DDCMP serial port, to enable proper Telnet escape character processing. Note that outbound connections are not made if --remote-address is omitted ("any remote adddress" mode). --cost: Circuit cost. Argument is an integer in the range 1..25, default is 4. --latency: Circuit round-trip latency, used to compute cost via the formula recommended by Johnny Billquist. Units are milliseconds, in the range 1 to 439. The intent is to measure (with ping or equivalent) the round trip latency to the destination of this circuit, and use the measured latency as the argument. PyDECnet will then compute the cost to be used. This parameter is legal for LAN circuits but not really sensible there. --t1: Background routing message interval override. Argument is an integer. Default is the routing setting of t1 or bct1, depending on what type of circuit this is. In DNA, the background routing message interval is an executor parameter (it depends on circuit type but not on the specific circuit). In PyDECnet, it may sometimes make sense to set a different value for a specific circuit. For example, the routing parameter t1 defaults to 600 (10 minutes) which is a sensible default for conforming point to point circuits, but Multinet over UDP should use a much lower value. --t3: Hello interval. Argument is an integer, specifying a time in seconds. Default is 10 for LAN circuits, 60 for point to point circuits. --nr: Number of adjacenct routers. Argument is an integer in the range 1 to 33. This value specifies how many other routers may be present on this Ethernet. Note that the DNA spec says this is a number in the range 1..255, but this is wrong: the list of adjacent routers appears in the Router Hello message, and the size limit of that field in the message implies a limit of 33 routers. --priority: Designated router priority. Argument is an integer in the range 0 to 127, default is 64. --verify: if supplied, verification is required during circuit initialization. This is applicable only for point to point circuits. The remote node must supply a verification value that matches the --inbound-verification switch value for that node in the node list. If it doesn't match, or if no inbound verification value is defined for the remote node, initialization is rejected. --loop-node: Loop node name to associate with this circuit. The name must not already be in use as a regular node name. If omitted, no loop node name is assigned to this circuit. Loop nodes are only valid for point to point circuits (Multinet or DDCMP), not for Ethernet-type circuits (Ethernet or GRE). --mop: applies only to bridge circuits. By default, only DECnet Phase IV packets are accepted from and sent to this circuit. If --mop is supplied, MOP, LAT, and loopback protocol packets are also accepted. This corresponds to the [lat] section in the bridge.conf file for the original bridge.c program. --mop: applies only to bridge circuits. By default, only DECnet Phase IV packets are accepted from and sent to this circuit. If --ip is supplied, IP related packets (including ARP) are also accepted. --phase-5: applies only to bridge circuits. By default, only DECnet Phase IV packets are accepted from and sent to this circuit. If --phase5 is supplied, OSI packets (802.3 format packets with SAP address 0xFE) are also accepted. --console: if present, enables the console carrier server in MOP for this circuit. The argument is the verification string, which must be supplied in console carrier client requests to access this console carrier. The console carrier is somewhat like a rudimentary telnet client; you probably don't want to turn this on in most cases. This feature is not available on Windows. --qmax: applies to DDCMP only. Sets the max number of sent but not yet acknowledged frames to the supplied value. Valid range is 1 to 255; default is 7 to match DMC-11 and similar hardware. If the other end gets overrun because it can't supply buffers fast enough, reducing this limit may be helpful. Note that DDCMP retransmits from the point of loss if a packet is lost, and does not have out of order packet handling as NSP does. TCP should not see packet loss, but UDP may, including apparent loss due to reordering in the Internet. The use of qmax values larger than what is needed to deal with the transmission latency will result in lots of packets being retransmitted in a burst if any loss occurs, which may be undesirable. Ethernet circuit addressing: PyDECnet supports the DECnet architectural notion of a datalink with multiple MAC addresses, one per client. Many but not all DEC Ethernet interfaces support this, for example the DEQNA or the SGEC and later Ethernet chips. The DEUNA does not, however, and PyDECnet can also be configured in a mode that emulates this "single MAC address for the whole interface" behavior. If so, MOP will use the DECnet style address, but in the default multiple address mode, MOP will use the hardware address (for example, in periodic SysID messages). Every Ethernet circuit must have a hardware address, which serves as the default MAC address. There are three ways in which the hardware address can be set. One of these must in effect or the circuit will not start. --hwaddr: specify the hardware address explicitly. It must be an individual address (first byte even) and should be a locally administered value for strict IEEE compliance The address is given as the argument, in the usual form of 6 hex bytes separated by hyphens. --random-address: Generate a random 46 bit value prefixed by 01 (for "individual address" and "locally administered"). If neither of these switches is specified, PyDECnet attempts to obtain the hardware address from the host interface corresponding to this circuit, for pcap or tap type interfaces. This does not apply to "bridge" type interfaces, so for those one of the two above switches is required. --single-address: if specified, the circuit operates in single address mode, where the MAC address of all circuit clients changes when DECnet sets its MAC address to aa-00-04-00 plus the node address. If omitted, each client has its own MAC address and others (such as MOP) keep the default MAC address -- the hardware address -- after DECnet starts. Component "nsp" This component defines the NSP (also called ECL) layer of DNA. --max-connections: Specifies the total number of connections that may terminate at this node. Allowed values are 255, 511, 1023, 2047, 4095, 8191, 16383, 32767. For an explanation why, see the Phase II specification, specifically the section discussing "intercept" operation. -- nsp-weight: the weighing factor for calculating the weighted average round trip delay. Default is 3, values are 1..255. --nsp-delay: round trip delay factor. The estimated round trip delay is multipled by this value to derive the ack timeout. Default is 2, range is 1 to 15.94. --qmax: Maximum number of unacknowledged data segments in the queue for any given connection. Default is 20, range is 1 to 2047. This is primarily a test tool; the default should normally work fine. Very small values will impair performance. Large values may cause congestion problems for DECnet implementations that do not use explicit flow control, such as DECnet/E. A modern Python system can send much faster than those nodes can handle, and can queue up much more traffic than these nodes expect. While nothing should break, setting the queue limit much higher than the default is likely to make things run very slowly. Component "object" This defines a session control object -- an application that can be started by inbound connection requests matching the supplied name or number. Some objects are built into PyDECnet, for example object 25 ("MIRROR"). Those can still be overridden by definitions in the config file, or turned off by an entry that has the --disable switch. For details on the built-in objects, see the section at the end of this document. --number: Object number, in the range 1 to 255. Numbers 1 through 127 are defined by Digital, higher values are "for customer use". --name: Object name, a string of up to 16 characters. It will be converted to upper case. For each object, at least one of name and number must be specified; if both are specified then the object can be referenced either by connections that ask for a number, or ones that ask for the object by name. --file: Command to run. If this is a name without directory specifications, it is looked up in PATH, as the shell would do for a shell command. If it is a relative path spec, it is interpreted relative to the directory where the decnet modules live (so, for example, the sample mirror object would be applications/mirror.py). A file name ending in ".py" will be read as a script by the same Python as is running PyDECnet; any other file must be executable and will be run directly. Conflicts with --module and --disable. --module: Python module specification, for an object that is executed within PyDECnet. The argument is a Python module identifier, for example "decnet.modules.mirror". Conflicts with --disable and --file. --disable: If specified for an entry that matches a built-in object (for example --number 25, which is MIRROR), disables that object. Conflicts with --file and --module. Attempts to disable an object that is not built-in will produce a "debug" level log message but are otherwise ignored. --argument: An optional argument to pass to the application when it is started. May be repeated to pass a list of arguments. PyDECnet does not interpret this. --authentication: Can be "off" (the default), "on", or "login". "on" or "login" means that PyDECnet will verify the supplied authentication information, "off" means that information is not needed and is ignored if present. Not supported if the python-pam library module is not installed. "login" is valid only for file objects; it means that the subprocess created when the object is run will be logged in as the user identified by the authentication parameters given. Note that the use of "login" requires running PyDECnet as root. --uid: Argument is a user name or numeric user id (uid). This option is available only if PyDECnet is run as root. If a name is given, it is looked up and the uid, gid, and home directory will be used for this object. If a number is given, only the uid is set (but gid may be supplied separately via the --gid switch) and no home directory is applied. This switch is valid only for file objects. The significance of this switch depends on the --authentication setting. For "off" and "on", the subprocess will run in the indicated uid and gid, and the working directory will be the home directory if a user name was used. For "login" authentication, these parameters apply only if no authentication parameters were used in the connection request, i.e., they are the "default" identify. Also, for "login" authentication, if --uid is not supplied, access control parameters are required, there is no default. --gid: Numeric group ID to use. This option is available only if PyDECnet is run as root. Only valid for file objects; not meaningful if --uid is used with a user name (in that case, the gid associated with the user name is used instead). Component "system" This is used to specify some general parameters that don't belong to a particular layer. Or they can be viewed as belonging to network management, which in this implementation isn't modeled as a layer. This is an optional component of DECnet nodes; it is not applicable to bridges. --identification "string" Set the identification string shown as the NICE protocol executor parameter "Identification". The default is "DECnet/Python" plus version numbers. Component "bridge" This component is required for a Billquist bridge node. Its only argument is the name of the bridge. A bridge has one or more circuits, which must be Ethernet. It will provide simple bridge services among all those circuits, flooding multicast and unknown address packets, and directly forwarding packets whose destination address is known. It is compatible with the C based bridge implementation by Johnny Billquist. Note that this is a "simple bridge", it does not implement any spanning tree protocol. You need to be careful not to configure any redundant paths involving only these simple bridges, otherwise packets will loop indefinitely. Component "logging" This is used to handle the processing of DECnet events generated by PyDECnet. The capabilities of this component roughly correspond to the event logging facilities described by the DECnet network management architecture spec. There are three types of "logging sinks": console, file, and monitor. Any of these may be local or remote. In either case, event filters may be specified, and for some sink types other parameters apply as well. The local console sink corresponds to the Python log facility, i.e., the logging destination specified by the -l, -E, or --log-config command line arguments. The local file sink refers to a file that receives event messages. The events are written in RMS variable length record format, i.e., a 2 byte little endian record length followed by the event in NICE encoding. The local monitor sink is not normally used, but if the network mapper is enabled it will act as the logging monitor to process circuit, node, and area change events to trigger map updates. Common parameters: --events event-list This specifies the events to be accepted by the specified sink. In DECnet, events are identified by class.type, for example 4.15 is "Adjacency up". Entries in the event-list are separated by commas. Each consists of a class.type, class.type-type2, type, or type-type2. The range type-type2 specifies all events with type numbers in the given range (inclusive). If class is not specified, the same class as in the previous entry is used. In place of a type number, "*" may be used to specify all events of that class. An events list that consists simply of *.* specifies all events (what the Network Management architecture calls "known events"). For example, this specification: 2.0,1,4.1,7,11-14 enables events: 2.0, 2.1, 4.1, 4.7, 4.11, 4.12, 4.13, and 4.14 For the local console sink, if the --events parameter is omitted, the default is *.* (known events). For all other sinks including all remote sinks, the default is no events. That doesn't necessarily make the sink useless; for example, a local file sink with no events specified will log no local events, but it will still log any file events directed to it from remote file sinks at other nodes that point to this node. --sink-node If omitted, the specified sink is a local sink. If specified, it is a remote sink: the events that pass the filter are sent to the event listener object at the specified node. --sink-username --sink-password --sink-account These three parameters specify optional access control values for the connection to the specified sink node. For local sinks these parameters are unused. Sink specific parameters: --sink-file For the local file sink, this specifies the name of the file that will receive events logged by this sink. Most DECnet events are logged as log level INFO. A few have other levels: events 2.1, 4.6, 4.7, 4.8, 4.18 and 34.1 are level WARNING, and events 3.0, 3.1, 4.0, 4.1, and 4.4 are level DEBUG. These levels are currently fixed in the source code. The built-in DECnet objects: By default, PyDECnet defines a number of objects. These settings can be modified or the objects disabled if desired, but typically it is reasonable to keep them. The descriptions below are given in the form of the equivalent "object" config lines. Note that all the built-in objects have "off" authentication and no UID or GID. object --number 19 --name nml --module decnet.modules.nml This is the network management listener; it provides remote access via the NICE protocol. Currently, only read information ("show" commands) and test ("loop" commands) are supported. object --number 25 --name mirror --module decnet.modules.mirror This is the "loop node" responder, the object used when the NCP command "loop node xyz" is used. object --number 26 --name evl --module decnet.modules.evl This is the event log listener. If another DECnet node specifies this node as a remote sink node, those messages will be sent to EVL, which will feed them into the PyDECnet log. object --name topol --module decnet.modules.topol This is a helper application used by TOPS-20 V4.1 (Phase II) to discover the network topology of the connected network. It is only used if you have such nodes as adjacent nodes. object --number 123 --name psthru --file applications/pmr.py This is the "poor man's routing" or "passthrough" object. As described above, explicit "object" statements can be used if desired to override some of the default setting of these standard objects. For example, with several of them it would be possible to set authentication to "on" which would limit access to users who supply valid username/password credentials. This is not meaningful for EVL (there is no facility in DECnet to supply event sink access control parameters), nor for TOPOL or PSTHRU, but it can be done for NML and even MIRROR. It is also possible, but does not appear particularly useful, to set a UID/GID for file objects (PSTHRU and, if one of the sample file based MIRRORs is used, that one as well). If desired any of the default objects can be disabled. DECnet/Python objects not configured by default: Additional objects are included with PyDECnet that are not enabled by default. Currently there is one: FAL -- the file access listener, i.e., the server side of the DAP protocol. If enabled this will provide remote file access. Currently only file read and directory listing are supported. The FAL object is an example where "login" authentication is useful, because that will enable an authenticated user to access files according to that user's access permissions (just as if the user had logged in to the host via ssh or telnet). The --uid parameter may be used to provide default access. Other authentication settings for FAL are NOT RECOMMENDED. FAL accepts one argument, which is the root directory for default access. It is not relevant if explicit authentication is done, but if default access was used and the argument is present, all file access is forced to be within the named subtree. The effect is as if a "chroot" of that path was done, though the actual chroot operation is not used because it complicates the running of the code. Example configuration line: object --number 17 --name FAL --file applications/fal.py --auth login --uid nobody --arg /home/decnet-def This enables default access, for which the user parameters of user "nobody" will be used, and in that case, the visible data is limited to the subtree under /home/decnet-def.