NS

Name	hierarchy/XNMS Domain Server
MSRP	L$ 1500
XVS server	xvendor:0
Permissions	copy, modify
Land impact	7
Attachment point	—
Function	Unit domain control
SKU	98-1009-A
Requirements	none
First release	XXXX
Latest release	3.0
Related products	TBD

▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇

NANITE SYSTEMS CONSUMER PRODUCTS

xanadu/1440m cluster controller

hierarchy/XNMS 3.0 server appliance

CPD-98-1009-A

▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

OVERVIEW
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The domain server is a critical part of the XNMS infrastructure, holding the configuration and settings for up to hundreds of units over dozens of roles. With a domain server, a single configuration file change can result in the spontaneous update of each unit the domain oversees the next time it visits the region.

IMPORTANT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Starting with Companion 8.6.2 build 20210812, the domain client is not compatible with versions of the server older than 3.0.

Likewise, XNMS 3.0 is not compatible with versions of Companion older than 8.6.2 build 20210812.

This is because of a necessary protocol change.

Server version 3.0 does not introduce any new features relative to version 2.0.1, so customers with LTS units may continue using the older version with their devices. Newer servers will continue to appear in the server list for older units but will be otherwise unresponsive. Additionally, servers cannot share a name, even if they are different versions.

GLOSSARY
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Domain	The hierarchy to which the unit belongs. A unit may only belong to one domain at a time.
XNMS	Xanadu Network Management Service, the protocol used to interface between domain servers and units.
hierarchy	The Companion implementation of the XNMS client software.
AT/XNMS	The ATOS version of this server, which additionally defines combat-friendly zones and chassis configurations. (Not yet available.)
Candidate	A unit that has petitioned to join the domain.
Role	A category of unit as defined by the domain server. Every unit in the same role will have the same settings.
Manager	A user (unit or person) that will receive level 1 access on all units within a given role.
Administrator	A user (unit or person) that will receive level 2 (owner) access on all units in the domain. The owner of the domain object is automatically an administrator.
Synchronization	The process of updating the unit's configuration to match that on the server.
Home region	the region (SL sim) where the domain server resides.
Pending	A unit that needs to synchronize. Units will be marked as pending if global settings change in the configuration file, or if their role changes. Units that are pending will automatically synchronize whenever they join the domain server's home region.

SETUP
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Install the domain server in an appropriate facility, edit the included _domain notecard, and then drop it into the server. The domain configuration file has the following fields:

name <name>	The name of the domain. This is what units will see when searching for a domain to connect to. To join a domain, units must type "@domain set <name>". Once connected, the domain server's UUID is recorded, so it cannot be moved or usurped without requiring a re-installation on the unit.
organization <name>	The name of the domain's organization. The unit's authority field will be set to match.
candidates private	Disables joining the candidate role by unauthorized units.
candidates group <id>	Allows joining the candidate role by members of the SL group indicated by UUID <id>.
candidates public	Allows joining the candidate role by any unit.
admin <id>	Specifies an administrator. Additional text on this line is ignored, so you can safely put the name of the user after it for convenience, e.g. admin d69ca06e-aa22-49e4-86e1-42677e26f3f5 rhet0rica
role <role name>	Specifies the start of a role. Certain fields specified after this one will then apply only to that role. They are described in the next section. To define multiple roles, append them successively.
query <id>	Reports the role of the specified UUID. This command is mainly useful not in a configuration file, but issued separately through an interface device, security orb, or similar.
dump	Shows all internal tables. This information is mainly useful for verifying and exporting the server's current state.
ban <id>	Bans the avatar indicated. It will not be stripped of any role memberships, managerships, etc.; these must be removed separately. Banned avatars cannot join the domain and cannot be granted managerships etc.; if these appear later in the configuration file (or are issued by command; see 'CONSOLE CONTROL', below), they will be ignored and an error will be generated.
remove ban|member|admin <id>	Deletes the record indicated.
remove role <name>	Deletes the indicated role. Existing members are moved into the candidate role. If you delete the candidate role (see 'CANDIDATES', below), it will lose all of its settings but its members will remain.

ROLE SETUP
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

policy-file <name>	Indicates the name of a command script to run on units after they synchronize. Changes to this file will mark the unit as pending (see glossary).
member <id>	Specifies that a unit is part of the indicated role. A unit may only belong to one role at a time. As with the 'admin' field, text after the key is ignored, so you can safely include the unit's name after the key for mnemonic purposes.
user <id>	Specifies a person or unit to be given level 0 (user) access to the role. As with the 'admin' field, text after the key is ignored, so you can safely include the manager's name after the key for mnemonic purposes.
manager <id>	Specifies a person or unit to be given level 1 (manager) access to the role. As with the 'admin' field, text after the key is ignored, so you can safely include the manager's name after the key for mnemonic purposes.
remove manager|user <id>	Removes a manager or user from the current role. Mainly useful for command-line usage (see 'CONSOLE CONTROL', below.)
flags <flags>	A series of keywords separated by spaces: USERS_POOL, LOCK_USERS, MANAGE_SELF, and NO_SELF. USERS_POOL: Other members of the group will automatically be given level 0 access on their siblings. LOCK_USERS: The unit's user list cannot be changed locally and must be changed through the domain. The unit must leave the domain to re-enable user control. WARNING: This disables the 'keychain reset' command. MANAGE_SELF: The unit is granted level 1 access over itself. NO_SELF: The unit is not added to its user list at all. Takes priority over MANAGE_SELF. By default, a unit is granted level 0 access over itself.
prefix <name>	Changes the unit's prefix to <name>. This will revert to the value set in the unit's OEM table if it leaves the domain.

CANDIDATES
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When a new unit joins the domain voluntarily, it is automatically added to a role named 'candidate'. This role can be altered like any other by adding "role candidate" to the configuration file followed by role setup fields (see above).

CONSOLE CONTROL
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Although there is still no easy user interface for managing a domain server, you can use the included "XNMS Remote Interface HUD" to interact with it directly over channel 4040. Commands are issued through the HUD by clicking on it, and are identical to the directives described earlier in this document under the SETUP and ROLE SETUP sections.

Here are some useful examples. The key b2e91c67-c32c-4c8e-9c03-9397dd25eddc belongs to NaniteSystems Resident.

role candidate
member b2e91c67-c32c-4c8e-9c03-9397dd25eddc


query b2e91c67-c32c-4c8e-9c03-9397dd25eddc


ban b2e91c67-c32c-4c8e-9c03-9397dd25eddc


SUPPORT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For additional support, send a notecard to rhetorica.resident or reach out to the Nanite Systems User Group