This document provides a description of "most" of the attributes that are used and what purpose they serve. When an attribute alters the functionality of a tool our intent is to list that tool in the following description of the attribute. BEWARE this document is an attempt to help the new user in understanding the use of attributes, it is not the essential guide to CIT attributes.

The attributes are used to describe the types of objects that can be represented in CIT, including: nodes, interfaces, consoles, remote power controllers, terminal servers, and switches.

NOTE: When a path to a tools is specified it is assumed that /cluster is the root directory of the CIT installation.


The bootflags attribute specifies any arguments that will be passed to the kernel during initialization. These arguments are used when generating the pxelinux.cfg for diskless booting or the grub.conf file for diskfull booting.

To set the bootflags attribute, use the device_mgr, and first specify the device to add the attribute to, then the attribute (--bootflags), followed by the value for that attribute: #device_mgr --set n1 --bootflags console=tty0


The bootmode attribute specifies how a given device should boot. In particular, the bootmode flag points to a label in the pxe configuration file under /tftpboot/pxelinux.cfg which contains instruction on how a given node should boot. Valid values for this attribute include ``diskless'', ``initrd'', ``diskfull'', ``dos'', and ``hybrid''. The default value is ``diskless''.

To set the bootmode attribute, use the device_mgr to specify the device to add the attribute to, then the attribute (--bootmode), followed by the value for that attribute: #device_mgr --set n1 --bootmode diskless


The console attribute specifies the name of the device which provides console access.


The console_port attribute specifies the direct port number.


The console_via_port attribute specifies the port number of the device, if it is not direct. This allows console access by traversing through through another device.


The disks attribute specifies additional devices, partitions, or nfs filesystems to be mounted on a node. If you specify this attribute, you should also specify the following sub-attributes, which are necessary to create the fstab configuration file: partition number (--num), mountpoint (--mount), path (--path). For an nfs mount, you will also have to specify the server (--server). If the filesytem is anything other than nfs, indicate the file system type (--fstype) and size (--size) of the partition. For example, to nfs-mount the /home directory from an admin node (admin0) onto a collection of nodes, use the following command: # device_mgr nodes --set --disk nfs --num 0 --mount /home --server admin0 --path /home Similarly, to mount a local partition on each of the nodes: # device_mgr nodes --set --disk hda --part 5 --fstype ext2 --mountpoint /var/tmp --size 35G


The image attribute is used to specify the kernel name that the node will use during initialization. Depending on the method of initialization this filename will either appear in the dhcpd.conf file or the nodes pxe configuration file.

If paired with the pxeimage attribute the file specified by the image attribute will be inserted into the pxe configuration file for that node. /cluster/lib/MkConf/ /cluster/lib/MkConf/ /cluster/lib/MkConf/ /cluster/bin/cclone


The initrd attribute represents the name of your initrd file, and is required if you wish to boot a compute node using an initrd. This attribute must be defined in conjunction with the bootmode attribute. For example, the following values will trigger mk_conf to create your pxe configuration file with the correct attributes. bootmode => initrd initrd => initrd_test


The interface attribute is a complex attribute with a number of sub-attributes that together describe a network interface. To set an interface attribute, use the --set flag followed by the name of the device (as one would for any other attribute). Additionally, the interface attribute requires the --interface flag followed by the number of the interface, and then the subattributes, which are detailed below. At a minimum the --address, --hostname, --name, and --net_mask attributes must be specified. For example:

#device_mgr --set sky4  --interface 1 --address 
         --hostname  myri0.sky4  --name  myri0  --net_mask


The address sub-attribute of the interface attribute specifies the IP address of a given interface, and is rendered in dotted quad decimal notation. The address sub-attribute is used in conjuction with the netmask sub- attribute to define the network interface.


The boot_if attribute is a sub-attribute associated with the complex attribute interface. The boot_if attribute is used in conjunction with the server_if attribute to specify network booting interface relationships. For example the boot_if attribute is set to a value of 1 (as a sub-attribute) for the interface that the client node will use to request boot information. The server_if attribute is set to a value of 1 (as a sub-attribute) for the interface that the server node will respond to boot requests on. When configuration files like dhcpd.conf are generated the tools use this information to generate an entry for each interface that is responding to requests (specified by server_if), for each node that both shares the server interfaces network and has the boot_if attribute set for that interface.

As mentioned in the USE, the boot_if attribute is closely related to the server_if attribute. /cluster/lib/MkConf/ /cluster/lib/


The hostname attribute specifies the hostname that will be associated with a given interface. This attribute is used when generating key configuration files, such as the hosts file as well as dhcpd.conf.

=head3 is_primary:

Historically, the is_primary attribute was used to help generate routing tables. Currently, it provides a means to characterize the functionality of multiple interfaces on a given device; for example, it allows one to distinguish between the interface that might be used to boot a nood versus one dedicated to a management network.


The optional mtu attribute allows you to specify the maximum transfer unit for a given interface. This is useful in dealing with high-speed interconnects whose performance may be optimized by setting this to a particular value. After adding or changing this attribute, you will generally want to re-generate the network files using the mk_conf tool.

# device_mgr nodes --set -i 1 --mtu 9000 # mk_conf --if nodes


Not to be confused with the main name attribute or the hostname attribute (both of which must be unique), the name sub-attribute of an interface is intended to describe more generally the type of a given interface; for example, eth0 or myri0. Therefore, multiple nodes could, and probably will have the same interface sub-attribute name. This information is used to generate the interface configuration files for the individual network devices.


The netmask sub-attribute defines the subnet mask that is used to describe a network interface. Like the address attribute, the netmask attribute is rendered in dotted quad decimal notation.


The nic attribute specifies the number of the network interface card, and is used to generate interface configuration files; such as the ifcfg-eth<X> file.


The mac_address sub-attribute designates the Media Access Control (MAC) hardware address that uniquely identifies a given device. Typically, these are represented in the database without semi-colons or other limiters; for example: 00D0585A0C80.


The server_if attribute is a sub-attribute associated with the complex attribute interface. The server_if attribute is used in conjunction with the boot_if attribute to specify network booting interface relationships.

The server_if attribute is set to a value of 1 for the interface on which server a node will respond to boot requests. Correspondingly, the boot_if attribute is set to a value of 1 on the interface that a client node will use to request boot information.


The optional switch sub-attribute specifies the name of the switch to which an interface is connected. The name of the switch must correspond to an existing switch device within your database. For example, the following entry represents a switch: console => sw1 console_port => 23 interface => 0 address => boot_if => 1 hostname => sw1 mac_address => 000E7F01B840 net_mask => nic => 0 isa => Device::Network::Ethernet::Switch::HPProCurve::2848 name => sw1

Then the corresponding switch attribute for another device should have the value of sw1:

     switch => sw1

Note that CIT will not let you specify the switch attribute unless this device exists within your database.


If you specify a value for the switch attribute, then you must also set a value for the switch_port attribute, which identifies the port on the switch to which your device is connected. If you do not set this explicitly when you set the switch attribute, then CIT will assign switch_port a default value of 1.

You can use the switch and switch_port attributes to support auto- discovery of MAC addresses. First, create a switch object, set the switch and switch_port attributes for you nodes, then execute the discover command with the following flags:

#discover --useswitch --nopowercycle nodes

=head2 isa:

The isa ("is a") attribute specifies the type or class of a device. For example, a switch is designated as such by setting the isa attribute to a specific type of switch; for example: "isa => "Device::Network::Ethernet::Switch::Cisco::C2900". Similarly, a power controller's isa attribute, may be set to "Device::Power::RPC3" whereas a node's to "Device::Node::x86::ia32::CPQ1850". The isa attribute is particularly important because different devices may otherwise share many of the same attributes. However, the specific function of these attributes will be determined the the type of the device.


The leader attribute specifies the device that acts as the leader of the device described by the object. The leader denotes a device, usually a node type device, that has some responsibility for the device that specified it as its leader. The most common example of this relationship is the leader is the boothost for the device that specified it as its leader.

The leader attribute is commonly paired with the role attribute to determine associations between devices. Tools that use this attribute include: /cluster/bin/console /cluster/bin/watch_console /cluster/bin/status /cluster/lib/ /cluster/lib/ /cluster/lib/Device/ /cluster/lib/MkConf/ /cluster/lib/MkConf/ /cluster/lib/MkConf/ /cluster/lib/MkConf/ /cluster/lib/MkConf/


The name attribute is probably the only strictly required attribute of an object. However, note that without other attributes the object won't be of much use! The name generally denotes the name of the device, and is used to lookup the object within the database. For this reason, the name must be unique for a given database.

All tools that operate by getting information from the database use this name to retrieve (or fetch) an object from the database.


The overlay attribute provides a granularity to make the management of nodes as easy as possible or to provide a mechanism for installing software that requires very specific paths (for example, see the overlay for the torque-maui module). In short, an overlay provides the ability to override the base functionality of a given node. For a more detailed discussion of overlays, see the ``diskless.hierarchy'' document in the diskless module or the ``ADDING.overlay'' document in the distros module. If the overlays attribute is not defined for a node, then the default_overlays from is used. To switch from the default root_rlogin to pre-defined root_ssh_login overlay, you will need to explicitly set the overlays attribute.

# device_mgr --set --overlays 'root_ssh_login DEFAULT' n5 # build_diskless n5 --update

The DEFAULT keyword simply does what is specified by default_overlays in, and you almost always want to include it. The precedence order for the overlays attribute is left to right, so the root_ssh_login receives higher precedence than the DEFAULT.


The power attribute specifies the name of the device which supplies power. As with the switch attribute, a object of type ``Device::Power'' must already exist in your database before assigning the power attribute. Typically, if you specify the power attribute then you must also specify either the power_port or power_via_port attribute.


The power_port attribute specifies the port on the power controller to which your device is connected. If there is not a direct connection to the device, then you would employ the power_via_port attribute.


Like the console_via_port attribute, the power_via_port attribute specifies the port number of the device, if it is not direct. This allows power access by traversing through another device.


The pxeimage attribute specifies the file name for the first stage pxe initialization. This filename normally will be inserted into the dhcpd.conf file.

The pxeimage and image attributes are commonly used together for nodes that boot over the network. /cluster/lib/MkConf/ /cluster/lib/MkConf/


The sysarch attribute specifies the software system architecture that is used by the node. This value typically represents a distribution name and version and hardware architecture. For example suse-9.0-x86_64 would represent a Linux distribution from Suse, version 9.0 for hardware architecture x86_64. There is no requirement to follow the conventions that we have used thus far. Note that multiple software system architectures are supported per cluster by the diskless module and the CIToolkit. /cluster/lib/ /cluster/lib/MkConf/ /cluster/lib/MkConf/ /cluster/bin/build_diskfull /cluster/bin/cclone /cluster/bin/build_diskless


The role attribute specifies the role or function of a particular node. Within, CIT, certain values for the role attribute will trigger the generation of configuration files. If a node has the attribute of ``leader'' or ``admin'' then a dhcpd.conf file may be generated for that node, otherwise it may be generated for that object's leader. Objects with role set to ``leader'' or ``admin'' are also candidates for inclusion in the .rhosts file. If set to ``monitor'', or if set to ``admin'' and there are no nodes assigned the role of ``monitor'', then syslog-ng.conf will be created to write syslog messages to the local disk. Otherwise, they are forwarded to the host specified by the leader attribute. If a node's role is not one of ``leader'', ``admin'', or ``monitor'', the it falls generically under the category of ``non-leader''. Generally, these non-leaders are assigned a value that describes their functionality, such as ``compute'', ``service'', or ``login''. Also see the description of the leader attribute.


The vmname attribute is used to define the "virtual machine name" that will be initialized when node initialization is complete.

The CIToolkit provides a linkage in the form of the rte (runtime environment) script that makes a call to determine to determine which vmname should be initialized after the node initialization is complete. If the vmname is nomnt or is not set then no further run-time initialization is accomplished. If a vmname is specified then a linkage is provided to start that run-time system. In the case of disk-less booting this is accomplished by first mounting the vmname generally located in /cluster/vms/vmname and then executing the rte script contained in that mountpoint.