• Name
• Node Inventory
• What Is An NCF
• All About +TAGs
• Populating Data, Building NCFs
• Using Inventory Data For OS Deployment
• Cross Checking Inventory Data
• See Also
• Author
• Version

Name

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 domain.com, the following is true:

• FQDN: host01.domain.com.
  
• nodename: host01.domain.com
  
• hostname: host01
  
• domainname: domain.com
  

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:

  +TAGNAME=value

...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 Covad::Pwman::Tags::CONSOLE.pm, 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

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

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:

• ATTACHED: additional information, like SCSI disks, in a seperate file
  
• CFG_CPUNUM: current number of CPUs in this node
  
• CFG_CPUSPD: speed of the CPUs in this node in Mhz
  
• CFG_MEMSIZE: current memory configuration
  
• CONSOLE: async console information
  
• DESCRIPTION: freeform description about this node's use
  
• ENV: environment specification for this node
  
• HOSTID: defines the system host-id for this node
  
• LOCATION: physical location of this node
  
• MAC: defines hardware Ethernet interfaces and their MAC addresses
  
• MODEL: release model name
  
• NOGEN: this is not a generate-able node. Implies NOPUSH.
  
• NOPUSH: this is not a push-able node
  
• OS: current node operating system
  
• OSDEP_BOOTENV: name of bootstrap environment file
  
• OSDEP_NAME: name of OS deployment image to use
  
• OSDEP_TYPE: type of OS deployment
  
• PONUM: specific purchase order information, including vendor name and dates
  
• REMOTE: specifies that this node is pushed via a remote R instance
  
• SERIAL: node chassis serial
  
• SUPPORT: defines the support available for this node
  
• UPLINK: defines parameters of an Ethernet uplink
  
• VENDOR: hardware vendor name
  
• ZONE: nodename of the global zone master
  

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.

• Option 1:
  
Run the ./util/build_ncf.pl script. It's arguments are nodenames. For each node that you specify, it will connect to the node and gather a bunch of data, and then try to write an NCF for that node. Note that it'll be pretty sparsely populated, since the only real information that you can programmatically glean at this point are properties of the CPU and memory, the OS, any network MAC address information and potentially the model and vendor. You'll still need to edit the generated NCF to add an +ENV and a +DESCRIPTION, as well as all the other information (like +LOCATION and +SERIAL and such, which will require a physical look-see).
• Option 2:
  
Write the NCF by hand. This has the potential for tag mispelling and so on. You really should use Option 1, at least at first, to get the hang of things.

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.

• +OS
  
Practically speaking, the +OS tag should contain the basic information nessecary for (re)loading an operating system onto a specific node. It's syntax:

  os-name/machine-arch/os-rev

contains the base information (the name of the OS, eg solaris; the machine architecture, eg amd64; and the major operating system revision, eg 5.10) needed to construct an appropriate /etc/bootparams. Note that you'll of course need to check the +MAC tag for the Ethernet address, as well as the nodename, to completely populate /etc/ethers and /etc/jumpstart-hosts.

• +OSDEP_BOOTENV
  
Some automatic installs (Jumpstart, Kickstart) can employ a bootrc file argument during the initial OS loading. You may have subnet- or environment-specific bootrc files that you'd want to apply to a node when deploying a new OS to it. This tag defines what the file name of the appropriate bootrc is.
• +OSDEP_NAME
  
The literal name of the deployment image to use. Say for example you had an OS image of sunos510 for your production subnets, and a slightly different build for your development subnets; you could name them, well, production and development, and use that name in the appropriate +OSDEP_NAME tag.
• +OSDEP_TYPE
  
The literal type of the OS to deploy. For example, say you have a OS build of sunos510_production for regular nodes, and a sunos510_production that specifically loads database settings (a modified /etc/system and filesystem management of VRTSvxfs, for example), then you could set this type in your /etc/bootparams for Jumpstart to pick out during the post-install phase.

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:

  +LOCATION=headquaters/datacenter-01/01-04

...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:

  +LOCATION=headquaters/datacenter-01/01-04/bladeshelf01.domain.com/03

...indicating that it sits in slot 3 of the device called bladeshel01.domain.com. This is all well and good. If you were to move bladeshel01.domain.com, 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

Author

Jon Gilbert <jong@jong.org>

Version

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