zones man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

ZONES(5)							      ZONES(5)

       zones - Solaris application containers

       The zones facility in Solaris provides an isolated environment for run‐
       ning applications. Processes running in a zone are prevented from moni‐
       toring  or  interfering	with  other  activity in the system. Access to
       other processes, network interfaces, file systems, devices, and	inter-
       process	communication facilities are restricted to prevent interaction
       between processes in different zones.

       The privileges available within a zone are restricted to prevent opera‐
       tions with system-wide impact. See privileges(5).

       You  can	 configure  and	 administer  zones  with  the  zoneadm(1M) and
       zonecfg(1M) utilities. You can  specify	the  configuration  details  a
       zone, install file system contents including software packages into the
       zone, and manage the runtime state of the zone. You can	use  the  zlo‐
       gin(1)  to  run commands within an active zone. You can do this without
       logging in through a network-based login server such as	in.rlogind(1M)
       or sshd(1M).

       The  autobooting of zones is enabled and disabled by the zones service,
       identified by the FMRI:


       See zoneadm(1M). Note that a zone has an autoboot property,  which  can
       be set to true (always autoboot). However, if the zones service is dis‐
       abled, autoboot will not occur, regardless of the setting of the	 auto‐
       boot property for a given zone. See zonecfg(1M).

       An alphanumeric name and numeric ID identify each active zone. Alphanu‐
       meric names are configured using the zonecfg(1M) utility.  Numeric  IDs
       are  automatically  assigned  when  the zone is booted. The zonename(1)
       utility reports the current zone name, and the zoneadm(1M) utility  can
       be used to report the names and IDs of configured zones.

       A zone can be in one of several states:

			Indicates that the configuration for the zone has been
			completely specified and committed to stable storage.

			Indicates that the zone	 is  in	 the  midst  of	 being
			installed  or  uninstalled,  or was interrupted in the
			midst of such a transition.

			Indicates  that	 the  zone's  configuration  has  been
			instantiated   on   the	 system:  packages  have  been
			installed under the zone's root path.

			Indicates that the "virtual platform" for the zone has
			been established. For instance, file systems have been
			mounted, devices have been  configured,	 but  no  pro‐
			cesses associated with the zone have been started.

			Indicates that user processes associated with the zone
			application environment are running.

			Indicates that the zone is being halted. The zone  can
			become stuck in one of these states if it is unable to
			tear down the application environment state  (such  as
			mounted	 file  systems) or if some portion of the vir‐
			tual platform cannot be destroyed. Such cases  require
			operator intervention.

   Process Access Restrictions
       Processes  running  inside  a  zone  (aside  from the global zone) have
       restricted access to other processes. Only processes in the  same  zone
       are  visible  through  /proc (see proc(4) or through system call inter‐
       faces that take process IDs such as kill(2) and	priocntl(2).  Attempts
       to  access  processes  that  exist in other zones (including the global
       zone) fail with the same error code that would be issued if the	speci‐
       fied process did not exist.

   Privilege Restrictions
       Processes  running  within a non-global zone are restricted to a subset
       of privileges, in order to prevent one zone from being able to  perform
       operations  that might affect other zones. The set of privileges limits
       the capabilities of privileged users (such as the  super-user  or  root
       user)  within  the zone. The list of privileges available within a zone
       can be displayed using the ppriv(1) utility. For more information about
       privileges, see privileges(5).

   Device Restrictions
       The  set of devices available within a zone is restricted, to prevent a
       process in one zone from interfering with processes in other zones. For
       example, a process in a zone should not be able to modify kernel memory
       using /dev/kmem, or modify the contents of  the	root  disk.  Thus,  by
       default,	 only  a  few  pseudo devices considered safe for use within a
       zone are available.  Additional devices can be  made  available	within
       specific zones using the zonecfg(1M) utility.

       The  device  and privilege restrictions have a number of effects on the
       utilities that can run in a non-global  zone.  For  example,  the  eep‐
       rom(1M),	 prtdiag(1M),  and prtconf(1M) utilities do not work in a zone
       since they rely on devices that are not normally available.

       A zone may be assigned a brand when it is initially created. A  branded
       zone  is	 one  whose software does not match that software found in the
       global zone. The software may include Solaris  software	configured  or
       laid  out differently, or it may include non-Solaris software. The par‐
       ticular collection of software is called	 a  "brand"  (see  brands(5)).
       Once  installed,	 a  zone's brand may not be changed unless the zone is
       first uninstalled.

   File Systems
       Each zone has its own section of the file system hierarchy, rooted at a
       directory  known as the zone root. Processes inside the zone can access
       only files within that part of the hierarchy, that is, files  that  are
       located beneath the zone root. This prevents processes in one zone from
       corrupting or examining file system data associated with another	 zone.
       The chroot(1M) utility can be used within a zone, but can only restrict
       the process to a root path accessible within the zone.

       In order to preserve file system space, sections of the file system can
       be  mounted  into  one  or more zones using the read-only option of the
       lofs(7FS) file system. This allows the same  file  system  data	to  be
       shared in multiple zones, while preserving the security guarantees sup‐
       plied by zones.

       NFS and autofs mounts established within a zone are local to that zone;
       they  cannot  be	 accessed from other zones, including the global zone.
       The mounts are removed when the zone is halted or rebooted.

       A zone has its own port number space for TCP, UDP,  and	SCTP  applica‐
       tions and typically one or more separate IP addresses (but some config‐
       urations of Trusted Extensions share IP address(es) between zones).

       For the IP layer (IP routing, ARP, IPsec, IP Filter, and so on) a  zone
       can  either  share  the configuration and state with the global zone (a
       shared-IP zone), or have its distinct IP layer configuration and	 state
       (an exclusive-IP zone).

       If  a  zone is to be connected to the same datalink, that is, be on the
       same IP subnet or subnets as the global zone, then  it  is  appropriate
       for the zone to use the shared IP instance.

       If  a  zone  needs  to  be isolated at the IP layer on the network, for
       instance being connected to different VLANs or different LANs than  the
       global  zone and other non-global zones, then for isolation reasons the
       zone should have its exclusive IP.

       A shared-IP zone is prevented from doing	 certain  things  towards  the
       network	(such as changing its IP address or sending spoofed IP or Eth‐
       ernet packets), but an exclusive-IP zone has  more  or  less  the  same
       capabilities  towards  the network as a separate host that is connected
       to the same network interface. In particular, the superuser in  such  a
       zone can change its IP address and spoof ARP packets.

       The  shared-IP  zones  are assigned one or more network interface names
       and IP addresses in zonecfg(1M). The  network  interface	 name(s)  must
       also be configured in the global zone.

       The exclusive-IP zones are assigned one or more network interface names
       in  zonecfg(1M).	 The  network  interface  names	 must  be  exclusively
       assigned	 to  that  zone,  that is, it (or they) can not be assigned to
       some other running zone, nor can they be used by the global zone.

       The full IP-level functionality in the form of DHCP client,  IPsec  and
       IP  Filter,  is	available  in  exclusive-IP zones and not in shared-IP

   Host Identifiers
       A zone is capable of emulating a 32-bit host identifier, which  can  be
       configured via zonecfg(1M), for the purpose of system consolidation. If
       a zone emulates a host identifier, then commands such as hostid(1)  and
       sysdef(1M) as well as C interfaces such as sysinfo(2) and gethostid(3C)
       that are executed within the context of the zone will display or return
       the  zone's  emulated  host  identifier	rather than the host machine's

       hostid(1),  zlogin(1),  zonename(1),  in.rlogind(1M),  sshd(1M),	  sys‐
       def(1M),	 zoneadm(1M),  zonecfg(1M),  kill(2), priocntl(2), sysinfo(2),
       gethostid(3C), getzoneid(3C),  ucred_get(3C),  proc(4),	attributes(5),
       brands(5), privileges(5), crgetzoneid(9F)

				 Jan 29, 2009			      ZONES(5)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net