Using /cfg for configuration

The /cfg directory can be used for a lot of custom configuration of terminals and servers. The configuration are per machine, and not per user. For user customization, see $home/lib/profile/

The entries in the config directory are divided into 2 types; Directories for specific machines. A single directory for machines that boot via PXE.

PXE

The PXE directory is rather simple. In /cfg/pxe you make a file named with the mac address of the machine that will PXE boot. For example; /cfg/pxe/54bf64604a09 .

This file will act as the plan9.ini for that specifc computer, and follows the exact same conventions as the plan9.ini used in the 9fat or esp partition when booting from local storage.

System Specific

Under /cfg can also be added directories named with the system names of any machines the run off the local file server. Any sort of diskless device, both terminals and CPU servers. For example; /cfg/FileBox .

When a system boots, it will either run /rc/bin/termrc if it is a terminal, or /rc/bin/cpurc if it is a CPU server. In both those scripts, there are point at the early part that check /cfg/$sysname for 2 files, cpurc or termrc. And for CPU server, another later in the script for cpustart.

Early in the script it will check for /cfg/$sysname/cpurc or termrc. This can be used to start progams or bind in specific kernal devices or namespaces to be used later by the standard start up script. An example would be; To start a custom aux/timesync, as the default script will later check to see if timesync is already running and skip the default timesync settings.

The later script for CPU servers is /cfg/$sysname/cpustart . This will be ran after all the default configuration and is handy for things that require a network connection, because the default network setup has already been completeed.

Keep in mind, these are rc scripts, so the files need to start with #!/rc/bin in order to work.

Site Wide

Additionally, there is also the option of using /lib/termrc.local or /lib/cpurc.local . For these scripts, they are used for running things that will be done for every computer that boots from the central file server. For example; wanting every computer on the network to use a custom aux/timesync.

As with the system specific scripts, these are rc scripts, so #!/rc/bin

Serivce

In /cfg/$sysname, if the system is a CPU server, /rc/bin/cpurc also check for /cfg/$sysname/service . This directory is analogous to /rc/bin/service and takes the same sort of files. Keep in mind, /rc/bin/cpurc will run /cfg/$sysname/service in place of /rc/bin/servce, not in addtion to. So if you want to want to add a web server to a specific you file server, and add /cfg/FileBox/service with a tcp80 script, but don;t also add the tcp17019, you will lose the ability to rcpu the file server.

Since /cfg/$sysname/service is still called by aux/listen, it otherwise follows all the same rules as what is found in /rc/bin/service.

Also, this does not apply to setting up /aux/listen to handle auth requests. /rc/bin/cpurc only uses /rc/bin/service.auth for that. So a system the does both auth and a custom service will use /cfg/$sysname/service for the custom services, and use /rc/bin/service.auth for the listner on tcp567.

Namespace

The default namespace recipe is /lib/namespace . It also checks for /cfg/$sysname/namespace, which will be used in addtion to the default namespace. So this is used for adding things, not in place of the default namespace. See auth/newns for setting up a completely custom namespace. As a system spefic namespace, added to the default, anthing in it will be in any process ran on that system. For example; any new window in rio will have those mount or binds, or any service started by aux/listen that doesn't get it's own custom namespace.

/lib/namespace also looks for /lib/namespace.$sysname as another way of doing system specifc namespaces.

There is also a site wide option for /lib/namespace.local .

Other

I also find /cfg and /cfg/$sysname a good place to stash scripts or programs that are used by custom start ups. For example; A script that sets up additional Ethernet ports and then configures them to do NAT. Rather then keep it in /rc/bin, if it is kept in /cfg, then backing up system configuration settings is simplified to just copying /cfg. Especially since a script only ran once at start up doesn't need the $PATH like convinience /rc/bin being bound to /bin. You can have a /cfg/TheRouter/cpurc call /cfg/TheRouter/natsetup .