Logical models for defining zones

Because the zone design uses hierarchical zones, you can override attributes at any zone or computer level to deal with conflicts in legacy profile data. With this flexibility, you can experiment with different possible designs, for example, based on delegated administrative authority or physical location. Some common models for grouping a set of computers, users, groups, roles, and rights in the same zone include:

  • By shared identity store. For example, existing identity stores, such as NIS domains or a centralized user and group database, often provide a natural boundary for zones. This strategy is especially effective if each identity store has a consistent namespace, without profile conflicts. It is less effective if the computers that share a common administrative group use local /etc/passwd and /etc/group file to store account information.
  • By application or function. For example, you might want to groups all of your database servers or web farm servers into their own zones. As part of this design, you might need to evaluate whether you are combining development computers with production servers and what role assignments you’ll need to control what users can do on each type of computer.
  • By geographical region or line of business. For example, all of the UNIX computers that support a business unit could be logically grouped together. As part of this design, you might evaluate whether different business units should be responsible for provisioning users or assigning roles within their own business unit.
  • By host name. If you already have a meaningful host name convention that identifies machine owners or primary function, you may want to create zones based on that naming convention.
  • By platform and operating system. You can use this strategy, for example, to create separate zones for Red Hat Linux workstations and Sun Solaris UNIX workstations.
  • By department or user community. You can use this strategy, for example, to create separate zones for the computers that host financial applications and computers used by software developers.

You are not required to create child zones. You could control access to the parent zone through role assignments. For most organizations, however, one or more child zones makes it easier to assign roles and manage group membership.

Depending on your target set of computers, you may decide to start with one or two child zones or skip the creation of a child zone.