UNIX Password, Roles & Node Management: Node Inventory

Node Inventory

What Is An NCF

A Node Control File, or NCF, defines attributes about nodes. It's a regular text file whose name is the nodename of the node, and that contains +TAGs. The nodename (which is based off of the fully-qualified domainname, or FQDN) is interpreted at parse time for the hostname and domainname of the node (the hostname is defined to be the first part of the nodename up to and not including the first dot .; the domainname is everything after the first dot .). Note that the nodename does not include the DNS qualifying dot ., and neither does the domainname.

For example, given a node called host01 in the DNS domain, the following is true:

Just about everything in Password Management is based off of the nodename of a node, to prevent overt confusion.

All About +TAGs

Tags represent information about a node. They can be concrete, material attributes such as the node's model and vendor. They can also be more abstract, such as a description of the node, or the environment this node services. Tags can represent how much memory is currently installed (which may then be interpreted as how much memory should be installed), or what operating system is to be deployed to this node (again, which may be interpreted as what OS is installed).

Tags (sometimes also called ``plus-tags'', because of their syntax) take the following form:


...where TAGNAME is the name of the tag, and value is the value for this tag on this node.

Tags can have various syntax restrictions and count limitations. For example: the +OS tag is only permitted to exist once in any given NCF, as with the +CFG_MEMSIZE tag; the +LOCATION tag has a specific syntax that must be met; the +DESCRIPTION tag has no syntax and no limitation on how many can exist. Each tag has a syntax attribute, and a syntax check subroutine (if nessecary and possible).

Tags for nodes are defined by Covad::Pwman::Tags. Each tag is a seperate object class that is loaded based on what the Covad::Pwman::Tags class is working with at this time. If you were to load up a new object for a +CONSOLE tag, then Covad::Pwman::Tags would load, and use that for it's defaults, syntax, minimum and maximum occurance counts, and so on.

Tags that can support multiple values can be either specified mulitple times, such as


or as comma-whitespace seperated entries, such as:

  +MAC=hme0/08:00:20:1a:2b:3c, hme1/08:00:20:1a:2b:3d

Tags can appear in any order in a NCF.

At the time of this writing, the following node tags are defined:

In order for a NCF to be valid, you must defined one +OS tag and at least one +ENV tag.

Populating Data, Building NCFs

To populate data and build an NCF, you can two options.

Once you've got the initial NCF, you'll want to edit it. Naturally you'll want to edit the +ENV and +DESCRIPTION tags. If there's other info you know, fill that in too. Remember, pwman is only useful if your NCFs are up-to-date. In some cases, bad data is worse than no data, and since a lot of information the NCF can work with and provide isn't always programmatic in nature (it's difficult to automate examining a chassis for serial numbers or verifing P.O. numbers), you'll need to create some self-discipline to keep this information current.

Using Inventory Data For OS Deployment

There are four tags specific to operating system selection and deployment. These tags are designed with Sun's Jumpstart in mind, however, they can be adapted to your own use.

Cross Checking Inventory Data

You will, from time to time, need to verify that duplicate information has not been inserted across nodes. This is because, with disassociated text files, there is no automatic referential integrity. Addition or update of information (such as +MAC tags) might introduce duplication of data where you don't want any (you really don't want the same Ethernet MAC address on two seperate nodes' interfaces).

To help prevent this, certian tags will identify themselves as unique. If a tag's unique parameter is set, you should double-check all other active inventory nodes' tags to ensure that you aren't accidentally duplicating data.

In addition to duplication, you should also worry about forward linking. For example, a Sun B100 bladeserver can have a +LOCATION tag assigned to it. However, the B1600 blade shelf that it sits in can be managed (or at least, inventoried) by Password Management, and it too has a +LOCATION tag; it might look like this:


...indicating that it sits in rack 4, row 1 of ``datacenter-01'' in the headquaters building. The blade's +LOCATION tag should look something like this:


...indicating that it sits in slot 3 of the device called This is all well and good. If you were to move, however, you might forget to update all 16 blades sitting in it. So you'll also want to check linkage across nodes and nodes' tags, too.

Currently there isn't a quick method (or even a simple one) to accomplish this. One is forthcoming, however.

See Also

the Covad::Pwman::Parsers manpage, the Covad::Pwman::Tags manpage


Jon Gilbert <>


$Id: pwman_docs_inv_mgmt.pod,v 1.2 2005/10/20 08:46:34 jgilbertsjc Exp $ Logo