• Name
• Nomenclature
• See Also
• Author
• Version

Name

UNIX Password, Roles & Node Management: Nomenclature

Nomenclature

There's a few concepts and terms that are thrown around when working with Password Management. This document attempts to clear up a few things.

• node
  
A node is a discrete server or other thing on a network. It can be a standalone server, or a switch, or firewall, or load balancer. It can also be a virtual server running on a real server (for example, Solaris 10 zones).

Essentially, if it's on a network, and it's managed, then it can be classified as a node.

There are two different classifications of nodes: local, and remote:

• local node
  
This is a node that is directly connectable by a Password Management instance. It's considered local from the perspective of the Password Management instance: Password Management can directly ssh to this node and manage it. Even nodes that are not managed by Password Management but are directly connectable are considered local. The simpliest example would be two nodes on the same layer 3 network:

  pw-source01.domain.com  192.168.10.10
  pw-node01.domain.com    192.168.10.11

In this example, pw-source01 is the Password Management control instance, and pw-node01 is local to the source.

• remote node
  
A remote node is one that is not directly connectable by a Password Management instance, but still managed by it. This is accomplished by proxing the R ``remote'' API through N-number of HTTP proxies.

Nodes have several attributes, which are detailed in a seperate document. These attributes are called tags, or ``plus-tags'' (because they take the form of +TAG).

All the node attributes are stored in a Node Control File (NCF). In order for a NCF to be considered valid, it must have the following two attributes set:

• +ENV={environment}
  
The +ENV tag specifies the environment this node belongs to. {environment} is one of the environments you create under the environments directory. You can have multiple environments, seperated by a comma-whitespace, like so:

  +ENV=prod, prod/billing

Or you can have multiple lines, like so:

  +ENV=prod
  +ENV=prod/billing

• +OS={os_specification}
  
The +OS tag defines what operating system, machine architecture, and revision this node runs. It's syntax looks like this:

  os_name/machine_arch/os_version

For example, if you have a Solaris 8 node running on Sparc, the os_specification would look like:

  solaris/sparc/5.8

You can only have one +OS tag per node.

The following operating systems are known:

• solaris
  
• linux
  
• cyclades
  

The following architectures are known:

• sparc
  
• x86
  
• amd64
  
• ppc
  

Nodes are assigned to one or more valid environments via the +ENV environment tag, as shown above.

See also the Covad::Pwman::Tags documentation.

• user
  
A user is a UNIX user. It may be a real person (eg, alice, bob), or a system-type account (eg, nobody, root, daemon). Each user has the following attributes:
• username
  
• password
  
• user-id
  
• group-id
  
• GECOS
  
• home directory
  
• default shell
  

(If you're familiar with the passwd file format, these should be pretty obvious.)

There are two basic types of users: real users, and system users.

• real users
  
A real user is an individual, a person. It represents a real live breathing human with soft skin. This person, via his or her UNIX user account may access nodes. He or she may also execute commands as other accounts, via sudo. If this person breaks something, in theory they could be held accountable for their actions.

Real users should gain access to nodes via one or more roles under the roles directory.

• system users
  
A system user is an account that generally doesn't log in. Accounts like daemon, sys, and root fall into this category. They generally fullfill the purpose of an account to which a particular service or application is run as that isn't a real user (which can be terminated based on association to your organization; employees sometimes quit or get fired) and that isn't root (in general, running everything as root is considered poor discipline as well as a security risk).

System users should gain access to nodes via direct installation into one or more environments under the environments tree via the system-users files.

• role
  
A role is a logical group of users, analagous to a team or department in a business. A role can have an owner (usually the manager or project lead of the business unit) who must also be a user. A role can also have assigned to it any number of sudo directives that are applied to the users in that role.

Think of a role as a group of users that fullfills a specific purpose. You could, for example: have a role called AdminUsersFulltime containing all of your fulltime system admins, with pretty broad access and ``ALL:ALL'' sudo directives; a role called AdminUsersHelpdeskSupport containing all your helpdesk users, with not-so-broad access and a limited subset of commands; a role called EngBillingSupport for all your engineers that support the billing applications, who can only access the billing servers and might not have any sudo commands. Users can of course be members of more than one role (some companies enjoy matrix reporting; some engineers wear several different hats), and that user effectively receives the union of all those roles.

A role is assigned to one or more environments under the environment tree via the role-users files.

• environment
  
An environment is a taxonomy of nodes, usually by service or by location. It's represented as a heirarchial structure, like a directory listing.

 dev
 dev/www
 prod
 prod/www
 prod/printers
 prod/dns

Each tree leaf is an environment (even ``prod'' and ``dev'', in the above example). You can specify multiple environments, and get the union of roles from both. Environments inherit attributes and roles from those that come before it. For example, the attributes and roles installed in ``prod'' would also be applied to ``prod/www'' and ``prod/printers''. Environments can be marked to not follow this behavior, but rather to ignore higher-up environments; this is called ``no-inherit''. Environments can also be ``exclusive'', which not only would ignore parent environments but other environment (there's much more on inheritance and exclusivity later).

You can break down your taxonomy of environments in whatever way suits your organization or installation. You might have them broken down by geographical region, or by organizational owner, or by functional role, or even flat and non-organized; whatever best matches how you do categorize your nodes. This is entirely up to you, and completely freeform. A few examples are below:

• By Location
  
You may want to break down your installations by location. Say you've got one datacenter in San Jose, CA, and another datacenter in Atlanta, GA. Each site has a cluster of webservers, a few database servers, some async management consoles, and other miscellaneous nodes. You could do something like this:

  san_jose_ca/
  san_jose_ca/www
  san_jose_ca/database
  san_jose_ca/console
  san_jose_ca/misc
  atlanta_ga/
  atlanta_ga/www
  atlanta_ga/database
  atlanta_ga/console
  atlanta_ga/misc

Or even something like this, in case you expect a new datacenter somewhere in California someday:

  ca/
  ca/san_jose/
  ca/san_jose/www
  ca/san_jose/database
  ca/san_jose/misc
  ca/san_jose/misc/console
  ga/
  ga/atlanta/
  ga/atlanta/www
  ga/atlanta/database
  ga/atlanta/misc
  ga/atlanta/misc/console

• By Service
  
If you treat your nodes by the service they provide, you could break down your installations that way, too. Say you've got a billing service (which includes nodes that run some billing software, and some nodes that contain the billing database), an order service, and an authentication service (let's go all out and say it supports both RADIUS and TACACS). It might look something like this:

  billing/
  billing/application
  billing/database
  order-mgmt/
  aaa/
  aaa/radius
  aaa/tacacs
  aaa/unified-database

If you wanted to take this a step further and replicate these environments for your software development group, you could do this:

  prod/
  prod/billing/
  prod/billing/application
  prod/billing/database
  prod/order-mgmt/
  prod/aaa/
  prod/aaa/radius
  prod/aaa/tacacs
  prod/aaa/unified-database
  dev/
  dev/billing/
  dev/billing/application
  dev/billing/database
  dev/order-mgmt/
  dev/aaa/
  dev/aaa/radius
  dev/aaa/tacacs
  dev/aaa/unified-database

• By Organization
  
If your nodes are ``owned'' (but not operated) by various groups in your company or organization, you can break it down that way, too. Let's say that your Finance department has a group of nodes they use for running reports and printing out documents, and your HR department has a dedicated series of printers, and your R&D department has a whole mess of nodes, and none of these organizations share these resources. Ok, so things might look like this:

  finance/
  finance/reporting
  finance/print-svr
  hr/
  hr/shared-nas
  hr/printers
  rnd/
  rnd/misc

See Also

passwd(4), mkdir(!), the Covad::Pwman::Tags manpage

Author

Jon Gilbert <jong@jong.org>

Version

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