admrelease(1M) DG/UX R4.11MU05 admrelease(1M)
NAME
admrelease - manage software release areas
SYNOPSIS
admrelease -o check [ -c clients ] [ -f format ] [ -O options ]
[ -U ] [ -qv ] release-area
admrelease -o copy -S source-release-name [ -c clients ]
[ -O options ] [ -U ] [ -pqv ] release-area
admrelease -o create [ -g share-directory ] [ -r root-directory ]
[ -s swap-directory ] [ -u usr-directory ] release-area
admrelease -o create -S source-release-name [ -c clients ] [ -d
"physical-disk" ] [ -M file-system-type ] release-area
admrelease -o delete [ -p ] release-area ...
admrelease -o get -O options [ -c clients ] [ -U ] [ -qv ] release-
area
admrelease -o inform [ -O noaction ] [ -C about-client(s) ] [ -a
about-release-area(s) ] -c inform-client inform-release-
area
admrelease -o list [ -qv ] [ -f format ] [ release-area ... ]
admrelease -o name_primary [ -m size:mount-point-list ] [ -qv ]
release-area
admrelease -o set -O options [ -c clients ] [ -m size:mount-point-
list ] [ -U ] [ -qv ] release-area
DESCRIPTION
The admrelease command is used to manipulate software release areas.
A release is a collection of software packages intended for a
specific architecture and operating system. Multiple versions of the
operating system software or application packages can be installed on
a single machine by using several independent release areas. A
release area is a directory tree that contains the host-independent
portion of a release (the /usr part) as well as a prototype of the
host-specific part (the / or root part). When client machines are
associated with a release, the host-specific prototype is copied to a
private portion of the release area reserved for use by that host,
and the host-independent portion is shared with other clients.
The PRIMARY release area is created automatically and cannot be
deleted. This name serves as an alias and access path for the
release area that is currently booted on this host. On systems with
one and only one release area, it holds the main operating system on
servers and stand-alone machines. Other releases are secondary,
which means they are not currently booted. They have identifying
names and other attributes assigned by the system administrator
during the create operation.
Release areas are maintained as a set of directory trees under
/srv/release/<release-area>/usr and /srv/release/<release-
area>/root/<client>. These directories and access points are used by
adm commands that allow for the specification of a release area name
in the command line. In general, you should not change to one of the
/srv directories to manage or fix a release area. The adm or sysadm
interfaces are the recommended method of operating on a release area.
After a release area is created and the appropriate file systems
mounted under the release area's srv tree, software can be loaded
into it using admpackage(1M). Client machines are associated with a
release area using admclient(1M).
Operations
check Check the integrity of an existing release area. This
operation checks the actual set of virtual disks and
file systems associated with a release area against
the definition of the release area.
The name_primary option returns the name given the
PRIMARY release area with the -o name_primary
operation.
The release_name option returns the name of the
release area last booted on the client specified by
the -c client-name option. If no -c client-name
option is specified the client name will default to
the host name of the system on which the command is
executing. This option is useful in a cluster when
one node needs to know which release area another node
has most recently booted. If the other node is up and
running, then it is running the release area returned
by the -o check -O release_name operation.
The defined option checks the following conditions for
each file system and virtual disk in the release
area's definition: does a virtual disk of the defined
name exist; is there only one virtual disk by that
name; is the virtual disk the defined size; is the
virtual disk on the defined type of physical disk
(clustered or local); is the defined file system
mounted as expected under the /srv directory; is the
file system under the /srv directory mounted with the
defined type (nfs, dg/ux or dg/cfs); if the release
area being checked is currently running, then is the
defined file system mounted as expected under the
actual root directory; if the release area being
checked is currently running, then is the file system
under the actual root directory mounted with the
defined type (nfs, dg/ux or dg/cfs).
With the -q quiet flag, each entry of the output will
contain 26 fields where each field is separated by a
colon ":".
Field 1 identifies the frequency with which the file
system should be created (FS_USR, FS_ROOT, VD_CLIENT,
...).
Field 2 identifies the data base from which the
definition is derived (R for Release, C for Client).
Field 3 identifies the status of the virtual disk
mount. If the defined virtual disk is mounted as
expected, then this file will read mtPt=ok; otherwise
it will read mtPt=err.
Field 4 identifies the defined mount point under the
root.
Field 5 identifies the mount point under the /srv
directory.
Fields 6 through 26 are organized as triplets of three
fields each. The first field of the triplet
identifies the attribute being checked and its check
status, the second field identifies the defined value
of the attribute, and the third field identifies the
actual value of the attribute.
Fields 6, 7, and 8 provide information about the
existence of the virtual disk.
Fields 9, 10, and 11 provide information about the
virtual disk size.
Fields 12, 13, and 14 provide information about the
physical disk type.
Fields 15, 16, and 17 provide information about the
srv mount type.
Fields 18, 19, and 20 provide information about the
srv mount source.
Fields 21, 22, and 23 provide information about the
root mount type.
Fields 24, 25, and 26 provide information about the
root mount source.
The missing_vdisks option simply lists discrepancies between virtual
disks defined for the release area and existing virtual disks.
Before you add clients to a release area, it is prudent to check the
integrity of the release area. If you check the integrity of the area
for the client about to be added, you will get a list of the client-
specific file systems that are defined for this release and this
client.
copy Copy the contents of the file systems defined for the
source release area into the file systems defined for
the target release area. This operation replaces the
contents of the target release area with the contents
of the source release area. Options allow for copying
the "usr" type file systems separately from the "root"
type file systems.
By default, the two release areas must be equivalent
(the layout of file systems is the same, and each
corresponding target file system is as large as or
larger than its source file system). This guarantees
that the source will fit into the target release area.
The target release area's file systems are purged
before the copy begins to avoid leaving stale files in
the target area which do not exist in the source area.
You can suspend the size check by using the option -O
nosize.
You can suspend the check for a matching source file
system for each of the target file systems by using
the option -O nomatch.
You can suspend the purge of the file systems before
the copy by using the option -p.
In order to copy /usr file systems, you must specify
the -U option on the command line.
In order to copy a client's root file systems, you
must specify the appropriate -c client option on the
command line. By default, several corrections are
made to the target root as part of the copy operation.
Various etc files (fstab, exports) in the client's
target root are corrected so that when the target
release area is booted it will be mapped in as the
PRIMARY release area and the source release area will
be mapped in as a secondary area. Corrected etc/fstab
entries are limited to those defined for the source
and target release areas. You can use the -o check or
-o get operations to see what has been defined for a
release area. Also note that in correcting the
/etc/fstab entries, the order of the file will be
modified. All entries derived from the definitions of
the source and target release areas will be written to
the beginning of the file.
As part of the copy operation, the target's
usr/root.proto files are recopied into the target's
root so that the correct root executables are in the
target root after the copy.
You can suspend the correction of /etc files by using
the option -O noetc. You can suspend the recopying of
the root.proto files by using the option -O noproto.
create Construct a new release area. The create operation
has two forms.
In the first form (no -S option), the release area is
defined in an administrative database, and directory
trees for the release area are created. A release
area name must be specified, and, optionally, path
names to be used for /usr software, client roots,
client swap files, and shared software. If you want a
release area created in this way to be useful, you
must also create file systems and mount them at the
appropriate points in the directory tree.
In the other form (distinguished by use of the -S
source-release-area option), the release area is also
defined, and directory trees are created for it. In
addition, virtual disks and file systems for the
release area are also created and mounted. The file
system mount points are derived from the definition of
the source release area. The sizes are derived from
the actual sizes of the source release area virtual
disks.
When the create operation is invoked with the -S
option, the name of any virtual disk that is created
is formed from the mount-point, release area name,
and, when necessary, a client name.
The formation of virtual disk names is done on the
following basis. The mount point / translates to the
word "root". In mount points below root, the slash, /,
is translated into the underscore character, _. For
names of file systems under /usr, the translated mount
point is followed by "." release-area name. Other
file systems are assumed to be root or client-specific
file systems, and the translated mount point and
release area name are followed by "." client-name. For
example, in the release area named R410, for the
client named "moe" the mount point / translates to
root.R410.moe. The mount point /usr/opt/X11 translates
to usr_opt_X11.R410.
The file systems will be created starting on the first
registered physical disk with free space as reported
by admpdisk -o list. Virtual disks will be created as
multi-piece when the next available free space is less
than the total required for the virtual disk.
The create operation is not idempotent. If a
definition for the release area already exists, the
operation will fail. The release area must first be
removed from the system before it can be (re)created.
When you use either the -m or -S options, only file
systems of the derived virtual disk name that do not
already exist on a registered disk will be created.
Existing virtual disks will remain unchanged.
delete Erase files and remove the directory trees associated
with a release area that was created by the create
operation. The PRIMARY release area cannot be
deleted. Release areas that are still in use cannot
be deleted. (Use the admclient's delete operation to
disassociate client machines from a release area.)
Deleting a release area does not remove the virtual
disks associated with the release area's file systems.
get The get operation displays information about a release
area's definition. (The set) operation can be used to
create or modify a release area's definition.) An
area's definition is partitioned into a release-
specific part and zero or more client-specific parts.
The - U switch must be used to reveal the release-
specific parts. The -c <client> argument must be used
to reveal the appropriate client-specific parts.
inform The inform operation will "inform" the etc/fstab and
etc/exports in the "inform" root of the "inform"
release area of the appropriate entries required to
maintain access to the file systems associated with
the "about" client in the "about" release area. In
other words, if you inform client c1 in release area
R411 about client c9 in release area R412 the fstab
and exports files in the R411 root for c1 will be
modified to have entries that reference c9's R412 file
systems. The client c1, running R411 will be able to
access c9's R412 file systems.
If you use the -O noaction option you can view the
entries that would be added to the fstab and exports
file without actually modifying the files. This can be
useful if you want to verify virtual disk names or
other aspects of a client or area definition.
list Provide information about release areas. If release
area names are given, all the information about a
release is displayed, including its directory
structure and installed packages. If all is specified
instead of a release area name, a short list of all
release areas and their /usr directories are
displayed, or just the release area names are
displayed if the -q option is used too.
name_primary Establish a functional name for the PRIMARY release.
This operation must be performed before creating a
second release area. In addition, you must have a
separate file system mounted at /srv before using this
operation. The srv databases cannot reside in a root
virtual disk if there is more than one root.
Any system that is going to manage and boot from more
than one release area must establish a functional name
for the PRIMARY release area. The PRIMARY area is
automatically created during the first installation of
DG/UX on the system. As long as there is one and only
one release area on a system, this name serves as an
adequate reference for that one area. However, since
the PRIMARY area for a given system always refers to
the booted / and /usr file systems, the name PRIMARY
becomes ambiguous in a multi-release area environment.
With two or more release areas, the release referred
to as PRIMARY is more accurately considered to be the
BOOTED area.
By renaming the PRIMARY area, an administrator can
manage the "original" release which had always been
referenced as PRIMARY by its new name regardless of
which release is currently booted.
By default, the operation will copy the PRIMARY
database to a new release database named by the
argument to the operation. Existing client databases
of the PRIMARY area will also be copied. If no file
systems are specified with the -m option, definitions
for the currently mounted root and usr file systems
will be added to the new release area definition. By
default, the server-name will be set to the host name
on which the name_primary operation is executed.
You can use the -o set operation to explicitly define
mount points that should be included in the named
definition before using the name_primary operation.
This is especially useful if you want to override the
default frequency settings for one of the file
systems.
This operation can be executed more than once, but
each execution will result in a redefinition of the
named release's file system so that it matches the
file systems found in whatever release is currently
booted as the PRIMARY release.
By using the -O rename_vdisk option the operation will
rename any virtual disks mounted at the defined mount
points to the canonical name for that virtual disk.
See the section below for the -O option used with the
-o set operation for a description of canonical
virtual disk names. By default Virtual disks are not
renamed.
After naming the PRIMARY area, it is prudent to use -o
check -O defined to check the definition (to make sure
it is appropriate) before adding any clients to the
newly named area.
set Set attributes of a file system or virtual disk
associated with a release area definition. Once a
release area is established (by use of the
name_primary or create operation), its definition can
be modified or enhanced by use of the set operation. A
release area's definition contains specifications for
file systems and virtual disks. These specifications
indicate the creation frequency of the file system or
virtual disk (one per client, one per release, one per
client per release, one per server), the size of the
file system or virtual disk, and the mount point for
the file system.
The release area's definition of file systems and
virtual disks is used when it is used as a source
during the creation of another release area using
admrelease -o create -S <source-release-area>, or, in
the case of client-specific file systems and virtual
disk, when a client is added to the release area using
admclient -o add -C.
The following file system and virtual disk
specifications can be modified by the set operation.
For further details about the attributes associated
with each of these types, see the description of the
option -O.
FS_SRV refers to file systems that are created one per
server regardless of the number of release areas or
clients that that server is serving. These file
systems are mounted under /srv/release/<release-
area>/root/<client>.
FS_SRV_USR refers to file systems that are created one
per server regardless of the number of release areas
that that server is serving. These file systems are
mounted under /srv/release/<release-area>/usr.
FS_USR refers to a file system that is created one per
release area.
FS_CLIENT refers to file systems that are created one
per client regardless of the number of release areas
to which that client is added.
FS_ROOT refers to file systems that are created one
per client, one per release area.
VD_SRV refers to virtual disks that are created one
per release area server.
VD_CLIENT refers to virtual disks that are created one
per client. Typically, these are for the required
swap disk and the optional dump disk.
Setting one of these file systems or virtual disks
involves
FS_USR refers to a file system that is created one per
release area.
FS_CLIENT refers to file systems that are created one
per client regardless of the number of release areas
to which that client is added.
FS_ROOT refers to file systems that are created one
per client, one per release area.
VD_SRV refers to virtual disks that are created one
per release area server.
VD_CLIENT refers to virtual disks that are created one
per client. Typically, these are for the required
swap disk and the optional dump disk.
Setting one of these file systems or virtual disks
involves specifying the creation frequency as an
option to the set operation (e.g., -O FS_ROOT), and
the size and mount point using the -m
<size>:<mount_point> argument (e.g., -m 60000:/).
For example, the command line admrelease -o set -O
FS_ROOT -m 50000:/opt/app R100 would define an FS_ROOT
type of file system with a size of 80,000 blocks to be
mounted at /opt/app.
Each time a client is added to the release area R100,
a file system named opt_app.R100.<client-name> and
sized at 50,000 blocks will be created, and the
client's /etc/fstab will be modified so that the newly
created file system will be mounted at /opt/app.
File system specifications must be unique by mount
point. Virtual disk specifications must be unique by
name. One may have as many FS_ROOT specifications as
long as each has a different mount point (e.g., /,
/opt, /var/opt, /tmp, /mail).
To remove a mount point definition, set the size to
"none". The command admrelease -o set -O FS_ROOT -m
none:/opt/app R100 removes the mount point /opt/app.
An exception to the unique mount point or disk name
rule is made for the client-specific file systems and
virtual disks. This allows definitions of multiple
clients in the same release area with different sized
file systems and different root tree organizations.
The release-area-wide specification applies to all
clients of the release area. The client-level
specification is maintained on a per-client basis. A
specification at the client level overrides
definitions for the same mount point or virtual disk
at the release area level for that client.
In order to set a client-specific definition, you must
explicitly reference the client by use of the -c
client-name option.
Options
-a <mount-point-alias>
This option specifies an alias for the mount point portion of
the canonical virtual disk name that is defined for the
release area with the -o name_primary or -o set operations.
It is only appropriate with the -o set operation. Use of this
alias allows you to override the default canonical name. This
is useful for long mount points like /var/opt/networker which
translates to the canonical virtual disk name
var_opt_networker.<host-name>. Longer mount points can cause
virtual disk names that exceed the length limit on virtual
disk names.
If you elect to alias a mount point you should not change the
alias later. The admrelease command will not keep track of
old to new name mappings. Nor will fstab files be
automatically updated when you change mount point alias.
-c <clients>
This option specifies a list of release-area clients. For the
check operation, this is the list of clients that should be
checked for the specified options. For the copy operation,
this is the list of clients for which all "root" type source
file systems should be copied to the appropriate "root" type
target file systems. For the get and set operations, it is
the list of clients for which attributes should be gotten or
set.
-C about-client(s)
This option specifies the about-client(s), or those client(s)
whose file system definitions should be added to the fstab and
exports files of the inform-client. The option is only used in
the inform operation.
-d "<physical-disk>"
This option specifies the name of a registered physical disk
to be used for the virtual disks that may be created as a
result of an admrelease -o create or admclient -o add
operation. Note that this option requires quotation marks
since the bracket characters embedded in the physical disk
specification have special meaning to the shell.
If this option is specified for the create operation, all
virtual disks will be created on the physical disk. If not
specified, the physical disk on which the virtual disk
associated with the mount point /usr for the release area will
be used. If there is not enough free space on the virtual
disk for all specified virtual disks, the operation will fail
eventually. To recover, create the virtual disks (using the
canonical name) one-by-one on whatever physical disks are
appropriate.
-f format This option specifies a format for the list or check
operations. Possible values are:
long For the list operation, display all information
about release areas. For the check operation,
display all correct, warning, and error
information. This is the default for the list
operation except when listing all release areas.
It is also the default for the check operation.
short For the list operation, display only the release
area name and /usr directory root. For the check
operation, display only warning and error
information. This is the default for list
operation when listing all release areas.
names For the list operation, display only the names of
release areas.
clients For the list operation, display only the clients
of the indicated release areas.
packages For the list operation, display only the packages
that have been installed in the indicated release
areas.
-g share-directory
This option specifies the name of the directory
for shared software. If not specified, the
default is /srv/share.
-m size:mount-point-list
This option specifies a list of virtual disk
sizes (in blocks) and corresponding mount points.
When more than one mount/point:size pair is
specified, the pairs must be separated by commas
or enclosed in double quotation marks and
separated by spaces. For example,
-m "/:40000,/usr:300000,/usr/opt/app:140000"
The specified mount point should be the path one
expects when this release area is the booted
release area. The usr file system would have a
mount point of /usr. Root would have a mount
point of /.
-M dg/ux | dg/cfs
This option allows you to override the default
behavior used when mounting file systems.
Instead of using the default behavior when
mounting file systems, they will be mounted
specified by the argument regardless of whether
NFS is available or the system is currently
clustered. On a non-clustered system, the
default is dg/ux. On a clustered system, the
default when the file system is on a shared
device is dg/cfs.
-O options This option specifies options that are used to
control the behavior of an operation.
etc | noetc For the copy operation, noetc specifies that
various target release area etc files (fstab
and exports) should not be corrected as part
of the copy operation. The default setting
for this option is etc. You may explicitly
set the option to etc. The default behavior
of correcting the etc files ensures that
entries in these files accurately reference
the target's resources instead of the
source's. For example, the entry for the /
mount point in the target release fstab will
reference the virtual disk associated with
the target's root.<SRC>.<CLIENT> virtual
disk. During the copy to the source release
area this entry will be corrected to
reference the source release area's
root.<TRG>.<CLIENT> virtual disk.
match | nomatch
For the copy operation, nomatch specifies
that the copy should be attempted even if
the file systems defined for the source
release area do not match one-to-one the
file systems defined for the target release
area. The default setting for this option
is match. You may explicitly set the option
to match. The default behavior prevents
copying a target release area's file systems
into a differently configured source release
area.
noaction For the inform operation, this specifies
that the command should simply report which
entries fstab and exports would be modified
without actually modifying them.
proto | noproto
For the copy operation, noproto specifies
that the root.proto of the target release
area should not be recopied to the target
root as part of the copy operation. The
default setting for this option is proto.
You may explicitly set the option to proto.
The default behavior ensures that the
target's root executables persist in the
release area after the copy.
setup | nosetup
For the copy operation, nosetup specifies
that the original root setup scripts that
have been successfully executed in the
source root should not be recopied to the
target root as part of the copy operation.
The default setting for this option is
setup. You may explicitly set the option to
setup. The default behavior requires the
user to re-setup packages in the target
release area.
size | nosize For the copy operation, nosize specifies
that the copy should be attempted even if a
target file system is smaller than its
corresponding source file system. The
default setting for this option is size. You
may explicitly set the option to size. The
default behavior prevents copying a larger
source file system into a smaller target
file system.
strict | nostrict
For the set operation, nostrict indicates
that the set should occur even if the
release or client database file does not
already exist. This can be used to define a
client's file systems before adding the
client so that the appropriately sized
virtual disks are created.
name_primary With the -o check operation, this option
returns the name given the PRIMARY release
area with the -o name_primary operation.
last_booted For the set operation, this option causes
the name of release area currently booted to
be logged in /srv/admin/clients. The -c
client-name option has no effect on the set
operation. The client name is always the
host name of the system on which the command
is executing. A system may not set the
release name for another system. A cluster
specific rc script (chk.cluster) is executed
at boot time to update the release name for
each node as it boots.
release_name With the -o check operation, the return code
is 0 and the release_name option returns the
name of the release area last booted on the
client specified by the -c client-name
option. If the release area name has not
been set, then no output is produced and the
return code is 1. If no -c client-name
option is specified, the client name will
default to the host name of the system on
which the command is executing.
This option useful in a cluster when one
node needs to know which release area
another node has most recently booted. If
the other node is up and running, then it is
running the release area returned by the -o
check -O release_name operation.
defined For the check and get operations, this
option indicates that information about
virtual disk, file system, and mount point
relationships should be displayed. For the
get operation, the primary_name is also
displayed.
The defined option checks the following
conditions for each file system
FS_SRV For the get and set operations, this option
specifies file systems that are defined to
be one per server regardless of the number
of release areas or clients associated with
that server. All clients of the release
area will mount file systems of this type in
the same location under
/srv/release/<release-area>/root/<client>.
In a cluster, a file system of this type
would indicate that a single instance of the
file system should be shared by all clients
in the cluster regardless of which release
any given client has booted. File systems
that have mount points that start with /srv
are, by default, type FS_SRV. Some packages
contain /var/opt file systems that are
expected to be defined as a one-per-server
type file system.
The canonical name for this type of file
system is mount_point. For example, a file
system mounted under /srv for release area
R100 would be named srv.
FS_SRV_USR For the get and set operations, this option
specifies file systems that are defined to
be one per server regardless of the number
of release areas or clients associated with
that server. All clients of the release
area will mount file systems of this type in
the same location under
/srv/release/<release-area>/usr. In a
cluster, a file system of this type would
indicate that a single instance of the file
system should be shared by all releases in
the cluster regardless of which release any
given client has booted.
The canonical name for this type of file
system is mount_point. For example, a file
system mounted under /usr/opt/netware for
release area R100 would be named
usr_opt_netware.
FS_USR For the get and set operations, this option
specifies file systems that are defined to
be one per release area regardless of how
many clients are associated with any given
release area. All clients of the release
area will mount file systems of this type in
the same location under /usr. Typically,
all file systems that are to be mounted
under /usr and which are to be shared by all
clients running from this release area,
should be defined as FS_USR.
The canonical name for this type of file
system is mount_point.release-name. The
slash (/) in the mount point is translated
into the underscore character (_). For
example, a file system mounted under
/usr/opt/networker for release area R100
would be named usr_opt_networker.R100.
FS_CLIENT For the get and set operations, this option
specifies file systems that are defined to
be one-per-client regardless of the number
of release areas associated with that
client. These are for file systems that
contain client-specific files that can be
shared across release areas. File systems
with mount points that start with /var or
/tmp are, by default, FS_CLIENT file
systems.
The canonical name for this type of file
system is mount_point.client-name. For
example, a file system mounted under
/var/opt/app for release area R100 for the
client acct122 would be named
var_opt_app.acct122.
FS_ROOT For the get and set operations, this option
specifies file systems that are defined to
be one-per-client per release area. This
means that the file system is intended to
contain client-specific and release-specific
files. Each client in the release area will
have its own unique file system associated
with each defined FS_ROOT. These will not be
shared with other clients or by the same
client across different release areas. File
systems that do not begin with /usr, /srv,
/tmp, or /var are, by default, type FS_ROOT
file systems.
The canonical name for this type of file
system is mount_point.release-name.client-
name. The mount point / is given the special
name root. For example, a file system
mounted under / for release area R100 for
the client acct122 would be named
root.R100.acct122. A file system mounted
under /opt/app for release area R100 for the
client acct122 would be named
opt_app.R100.acct122.
VD_SRV These are just like FS_SRV file systems
except that no file system is created. The
virtual disk for the cluster_db area is an
example of a srv-specific virtual disk.
The canonical name for this type of virtual
disk is disk-id. For example, the
cluster_db virtual disk would be named
cluster_db.
VD_CLIENT These are just like FS_CLIENT file systems
except that no file system is created. The
virtual disks for swap and dump areas are
examples of client-specific virtual disks.
The canonical name for this type of virtual
disk is disk-id.client-name. For example, a
virtual disk used by client acct122 for
swapping should have a disk-id of swap and
would be named swap.acct122. A virtual disk
used by client acct122 for system dumps
should have a disk-id of dump and would be
named dump.acct122.
-p Preserve the release area contents when
deleting or copying a release area. The
default behavior When copying a release area
is to purge the contents of the target file
systems prior to copying from the source.
This eliminates files which may exist in the
target release's file systems but don't
exist in the source release.
-q This flag specifies quiet behavior. For the
list operation, header lines are not
displayed and the fields are separated by a
space. For the check operation, header
lines are not displayed and the fields are
separated by a colon ( : ).
-r root-directory
This option specifies the name of the
directory for the clients' root directory
parent. If not specified, the default is
/srv/release/release-area/root. The root
(host-specific) directory for a client will
be named for the client and appear under
this directory.
-s swap-directory
This option specifies the name of the
directory for clients' swap space. If not
specified, the default is /srv/swap. A file
for each client, named for the client, will
be created under this directory to serve as
the client's swap area.
-S source-release-area
This option specifies the name of an
existing release area. The file system
definitions in the source will be used by
the create operation to create required file
systems, and by the copy operation to copy
the contents of the source release area file
systems into the target release area file
systems. By default, the copy operation
will occur only if there is equivalence
between both the source and target file
system definitions.
-u usr-directory
This option specifies the name of the
directory for the /usr file system. If not
specified, the default is
/srv/release/release-area/usr. The
prototype of the host-specific portion of
the release will eventually get loaded into
the root.proto directory under this
directory.
-U This flag indicates that the operation
should apply to the usr portion of the
release area definition. When used in the
check operation, definitions for non-client-
specific file systems will be reported.
When used in the copy operation, this flag
specifies that all "usr" type source file
systems should be copied into the
appropriate target "usr" type file systems.
-v This flag indicates verbose mode. This is
the default behavior for the list and check
operations. Header lines are always
displayed for the check operation. For the
list operation, header lines are displayed
when the release area is all or null.
EXAMPLES
To create a new release area named version2 with the default
directory structure, use
admrelease -o create version2
To create a new release area named "newArea" based on the definition
of an existing release area named "oldArea" so that any virtual disks
or file systems required for the new area are created on the physical
disk "sd(ncsc(4,3),E,1)", use
admrelease -o create -S oldArea \
-d "sd(ncsc(4,3),E,1)" newArea
To define client-specific sizes for the systems and/or virtual disks
of a new client "newClient" before that client is added to an
existing release area "oldArea" with the admclient command, use
admrelease -o set -O nostrict,FS_ROOT -m 75000:/ \
-c newClient oldArea
To check the correctness of the release area "R411" that has the
clients "c100", "c101", and "c102" associated with it, use
admrelease -o check-O defined -U \
-c all R411
From c100: admrelease -o check -O defined -U -c all R411
1 ok vDisk = usr_opt_netware size = 60000
frequency = FS_SRV_USR (one per OS Server) DB = release
srv mount = /srv/release/R411/usr/opt/netware type = nfs
root mount = /usr/opt/netware type = dg/cfs
2 ok vDisk = usr.R411 size = 280000
frequency = FS_USR (one per release) DB = release
srv mount = /srv/release/R411/usr type = nfs
root mount = /usr type = dg/cfs
3 ok vDisk = usr_opt_sdk.R411 size = 60000
frequency = FS_USR (one per release) DB = release
srv mount = /srv/release/R411/usr/opt/sdk type = nfs
root mount = /usr/opt/sdk type = dg/cfs
4 ERR vDisk = usr_opt_X11.R411 size = 90000
frequency = FS_USR (one per release) DB = release
srv mount = /srv/release/R411/usr/opt/X11 type = nfs
root mount = /usr/opt/X11 type = dg/cfs
Error: No file system at /srv/release/R411/usr/opt/X11
expected c100:/usr/opt/X11 as nfs
Error: Wrong filesystem mounted at /usr/opt/X11
c233:/usr/opt/X11 mounted, expected /dev/dsk/usr_opt_X11.R411
Error: Wrong mount type: /usr/opt/X11 is nfs, expected dg/cfs
5 ok vDisk = srv size = 20000
frequency = FS_SRV (one per OS Server) DB = release
srv mount = /srv/release/R411/root/c100/srv type = nfs
root mount = /srv type = dg/cfs
6 ok vDisk = root.R411.c100 size = 60000
frequency = FS_ROOT (one per release per client) DB = release
srv mount = /srv/release/R411/root/c100 type = nfs
root mount = / type = dg/cfs
7 ok vDisk = swap.c100 size = 50000
frequency = VD_CLIENT (one per client) DB = release
8 ok vDisk = srv size = 20000
frequency = FS_SRV (one per OS Server) DB = release
srv mount = /srv/release/R411/root/c101/srv type = nfs
root mount = /srv type = dg/cfs
9 ERR vDisk = root.R411.c101 size = 60000
frequency = FS_ROOT (one per release per client) DB = release
srv mount = /srv/release/R411/root/c101 type = dg/cfs
Error: Missing virtual disk root.R411.c101
Error: No file system at /srv/release/R411/root/c101
expected /dev/dsk/root.R411.c101 as dg/cfs
10 ok vDisk = swap.c101 size = 50000
frequency = VD_CLIENT (one per client) DB = release
Note: Wrong pDisk type: swap.issm116 on local, expected clustered
11 ok vDisk = srv size = 20000
frequency = FS_SRV (one per OS Server) DB = release
srv mount = /srv/release/R411/root/c102/srv type = nfs
root mount = /srv type = dg/cfs
12 ok vDisk = root.R411.c102 size = 80000
frequency = FS_ROOT (one per release per client) DB = client
srv mount = /srv/release/R411/root/c102 type = dg/cfs
13 ok vDisk = swap.c102 size = 100000
frequency = VD_CLIENT (one per client) DB = client
The first line of the report indicates which client ran the command
and the command line arguments used for the check.
The rest of the report provides numbered entries for each defined
file system or virtual disk. The first few lines provide a summary of
the definition for the entry. The first field after the entry's
number indicates whether the check found no errors (ok) or at least
one error (err).
This particular example indicates errors in two defined file systems
and notes a discrepancy with a defined virtual disk.
No file system for the /usr/opt/X11 mount point is mounted under the
/srv directory as expected. In addition, the file system mounted
under the root tree (/usr/opt/X11) is a remote NFS mount from the
c233 system when a local dg/cfs mount was expected.
The virtual disk for the defined root mount point for the client c101
does not exist and no other file system is mounted as expected under
the /srv directory.
To check the correctness of the release area "R411" for the file
systems associated with c100, and to limit messages to the brief
format with only errors and warnings reported, use
admrelease -o check-O defined -c c100 -f short -q R411
FILES
/srv/release/release-area Release area root
/srv/admin/releases Release database
OUTPUT
The list operation writes to stdout. The long format shows the
directory structure, installed packages, and attached clients. The
short format shows only the release area name and the name of the
/usr file system for each release. Other formats show only the
information requested.
DIAGNOSTICS
Warnings
Attempts to delete a release area that does not exist are indicated,
and the operation on that release area is skipped.
Errors
It is not possible to delete the PRIMARY release area or a release
area that still has clients associated with it.
It is an error to add a release area that already exists.
Exit Codes
0 The operation was successful.
1 The operation was unsuccessful.
2 The operation failed due to access restrictions.
3 There was an error in the command line.
NOTES
The /srv directory structure must be established appropriately before
admrelease or admpackage can function. Both commands will check the
directory structure and establish the /srv directory tree if
necessary.
You must have appropriate privilege to perform the create and delete
operations.
On a generic DG/UX system, appropriate privilege means that your
process has an effective UID of root. See the
appropriate_privilege(5) man page for more information.
On a system that supports the DG/UX Capability option, appropriate
privilege is defined as having one or more specific capabilities
enabled in the effective capability set of the user. See the
cap_defaults(5) man page for more information.
SEE ALSO
admclient(1M), admpackage(1M), sysadm(1M), appropriate_privilege(5).
Installing the DG/UX System and Managing the DG/UX System.
Licensed material--property of copyright holder(s)