'\" te .\" Copyright (c) 2011, 2012, Oracle and/or its affiliates. All rights reserved. .TH aimanifest 1M "19 Jun 2012" "SunOS 5.11" "System Administration Commands" .SH NAME aimanifest \- Modify an XML file used by Automated Installer (AI) .SH SYNOPSIS .LP .nf /usr/bin/aimanifest [-h] .fi .LP .nf aimanifest add [-r] \fIpath\fR \fIvalue\fR .fi .LP .nf aimanifest delete \fIpath\fR .fi .LP .nf aimanifest get [-r] \fIpath\fR .fi .LP .nf aimanifest set [-r] \fIpath\fR \fIvalue\fR .fi .LP .nf aimanifest load [-i] \fIfilename\fR .fi .LP .nf aimanifest validate .fi .SH DESCRIPTION .sp .LP The \fBaimanifest\fR command creates a new XML manifest or modifies an existing one. While \fBaimanifest\fR can be used with any XML file that contains a valid \fB!DOCTYPE\fR reference to a DTD definition, it is intended for creating derived manifests used by the Automated Installer (AI). See \fIInstalling Oracle Solaris 11 Systems\fR for information about AI derived manifests. .sp .LP The \fBaimanifest\fR command can be invoked multiple times to develop a manifest. The \fBAIM_MANIFEST\fR environment variable specifies the location of the manifest for \fBaimanifest\fR to modify. \fBAIM_MANIFEST\fR must be set. Each invocation of the \fBaimanifest\fR command with the \fBload\fR, \fBadd\fR, or \fBset\fR subcommand opens, modifies, and saves the \fBAIM_MANIFEST\fR file. .sp .LP The minimum \fBAIM_MANIFEST\fR file that the \fBaimanifest\fR command can modify must contain both of the following pieces: .RS +4 .TP .ie t \(bu .el o A \fB!DOCTYPE\fR reference to a DTD that is valid for the XML manifest being developed. .RE .RS +4 .TP .ie t \(bu .el o The root element for this manifest. .RE .sp .LP If you start with an empty \fBAIM_MANIFEST\fR file, as when AI is executing a derived manifests script, then the first \fBaimanifest\fR command must specify the \fBload\fR subcommand to load at least the minimum required \fBAIM_MANIFEST\fR file. Subsequent \fBaimanifest\fR commands that modify the manifest use the DTD to determine where to add elements in the developing manifest. .sp .LP To save error and informational messages to a file in addition to displaying messages to \fBstdout\fR and \fBstderr\fR, set the \fBAIM_LOGFILE\fR environment variable to a log file location. Information is appended to the log file. The log file is not cleared. .SH OPTIONS .sp .LP The \fBaimanifest\fR command has the following option: .sp .ne 2 .mk .na \fB\fB-h\fR, \fB--help\fR\fR .ad .sp .6 .RS 4n Show the usage help message. .RE .sp .LP The \fBadd\fR, \fBget\fR, and \fBset\fR subcommands of the \fBaimanifest\fR command have the following option: .sp .ne 2 .mk .na \fB\fB-r\fR, \fB--return-path\fR\fR .ad .sp .6 .RS 4n Return the path of each XML element that this \fBaimanifest\fR command creates or operates on. Each returned path is a chain of node IDs. You can save these returned paths to use in subsequent calls to \fBaimanifest\fR. Using the path returned by the \fB-r\fR option is more reliable than specifying the path using XML element and attribute values, since the values can change as the AI manifest is being built. See the "Return Paths" section for more information about the paths returned by the \fB-r\fR option. .RE .sp .LP The \fBload\fR subcommand of the \fBaimanifest\fR command has the following option: .sp .ne 2 .mk .na \fB\fB-i\fR, \fB--incremental\fR\fR .ad .sp .6 .RS 4n Do not clear existing \fBAIM_MANIFEST\fR data before adding new data. .RE .SH SUB-COMMANDS .sp .LP The following subcommands are supported: .sp .ne 2 .mk .na \fB\fBaimanifest add [-r | --return-path] \fIpath\fR \fIvalue\fR\fR\fR .ad .sp .6 .RS 4n Add a new element to an XML manifest. Add the new element at \fIpath\fR and with value \fIvalue\fR. See the "Operands" section for more information about \fIpath\fR. If \fIpath\fR ends in an attribute (\fB@\fIattr\fR\fR), then the new element has the \fIattr\fR attribute, and \fIvalue\fR is the value of the attribute. .sp No validation is performed except to examine parent/child relationships in \fIpath\fR. .sp The \fB-r\fR option returns a path to the newly-added node. See the "Return Paths" section for more information. .sp If the parent path matches an element in the \fBAIM_MANIFEST\fR file, it must match only one element. The new element is created as a child of the matching parent element. The path can specify element and attribute values to match a unique parent element, as shown in "Example 2: Path With a Value" in this section. .sp .LP If the parent path does not match an element in the \fBAIM_MANIFEST\fR file, new elements are created as necessary, and the new child element is added to the new parent. The path to an added element is split off from the preexisting elements according to the following rules: .RS +4 .TP .ie t \(bu .el o The split occurs after all parts of the path that specify a value. .RE .RS +4 .TP .ie t \(bu .el o The split occurs at the first place where multiple relevant same-tagged elements are allowed by the DTD, after all parts of the path that specify a value. .RE .sp .LP Use this XML manifest schema to analyze the following examples: .RS +4 .TP .ie t \(bu .el o The manifest begins with a single A node. .RE .RS +4 .TP .ie t \(bu .el o The A node can have only one B node child. .RE .RS +4 .TP .ie t \(bu .el o The B node can have multiple C node children. .RE .RS +4 .TP .ie t \(bu .el o A C node can have multiple D node children. .RE \fBExample 1: Simple Path\fR. The AI manifest has one A node, one B node, and one C node: \fB/A/B/C\fR. An \fBadd\fR subcommand is issued with a \fIpath\fR of \fB/A/B/C/D\fR. In this case, a new C node is created because C nodes are the first nodes along the path that can have same-tagged siblings. A new D node is added as a child to the new C node. The resulting manifest has the structure \fB/A/B/{C,C/D}\fR. Issuing the same command for a different value of D results in three C nodes: \fB/A/B/{C,C/D,C/D}\fR. .sp \fBExample 2: Path With a Value\fR. The AI manifest has one A node, one B node, and two C nodes. Only one of the C nodes has a value of 1 so that the manifest has the structure \fB/A/B/{C,C=1}\fR. An \fBadd\fR subcommand is issued with a \fIpath\fR of \fB/A/B/C=1/D\fR and a \fIvalue\fR of 10. In this case, no new C node is added because specifying the value of 1 for C identifies a unique node, and the path cannot be split at or before a branch where a value is specified. The first place where this path can be split is at D. A new D node with a value of 10 is added as a child of the C node that has a value of 1. The resulting manifest has the structure \fB/A/B/{C,C=1/D=10}\fR. Issuing the same command with a value of 20 for D results in \fB/A/B/{C,C=1/{D=10,D=20}}\fR. .RE .sp .ne 2 .mk .na \fBaimanifest delete \fIpath\fR\fR .ad .sp .6 .RS 4n Delete all nodes or attributes which match path. If a path specifies nodes, delete the subtree rooted at each node which matches path. If a path matches attributes, delete all attributes which match path; do not delete any nodes. See "The Path Operand" section for more information about path. .sp The number of matches is printed to \fBstdout\fR on success: .sp .in +2 .nf 5 element(s)/subtree(s) deleted 5 attribute(s) deleted .fi .in -2 .sp .RE .sp .ne 2 .mk .na \fB\fBaimanifest get [-r | --return-path] \fIpath\fR\fR\fR .ad .sp .6 .RS 4n Retrieve the value of each element or attribute which matches path. An empty string (\fB""\fR) is displayed for empty element or attribute values. See "The Path Operand" section for more information about path. .sp The \fB-r\fR option returns a path to each accessed node as a second returned string per node. See the "Return Paths" section for more information. .RE .sp .ne 2 .mk .na \fB\fBaimanifest set [-r | --return-path] \fIpath\fR \fIvalue\fR\fR\fR .ad .sp .6 .RS 4n Change the value of each element or attribute which matches path, or create a new attribute of an existing element which matches path. No validation is performed. See "The Path Operand" section for more information about path. .sp When setting the value of an attribute, the attribute does not need to exist, but the element to which the attribute belongs must exist. .sp If the \fB-r\fR option is not specified, the number of matches is printed to \fBstdout\fR on success: .sp .in +2 .nf 5 element(s) set 5 attribute(s) set .fi .in -2 .sp .RE .sp .ne 2 .mk .na \fB\fBaimanifest load [-i | --incremental] \fIfilename\fR\fR\fR .ad .sp .6 .RS 4n Load an XML manifest or partial XML manifest from the file \fIfilename\fR. No validation is performed except to examine parent/child relationships of elements. .sp When the \fB-i\fR option is not specified, overwrite any existing XML data. All data in the \fBAIM_MANIFEST\fR file is replaced with the contents of the \fIfilename\fR file. The \fIfilename\fR file must include a \fB!DOCTYPE\fR reference to a DTD so that subsequent \fBaimanifest\fR commands can modify the file. .sp When the \fB-i\fR option is specified, do not clear the \fBAIM_MANIFEST\fR data before adding new data. Instead, incrementally insert or merge the new data with the existing XML data. The DTD given by the \fB!DOCTYPE\fR reference in \fBAIM_MANIFEST\fR is used to determine how and where to merge the \fIfilename\fR data. If the \fB!DOCTYPE\fR reference is missing, the AI manifest DTD at \fB/usr/share/install/ai.dtd\fR is used. If the data in \fIfilename\fR cannot be reconciled with the DTD, a non-zero error status is returned. .sp .LP The following considerations affect where new data is inserted into the \fBAIM_MANIFEST\fR manifest: .RS +4 .TP .ie t \(bu .el o To what extent the tags of elements near the beginning of the \fBAIM_MANIFEST\fR data paths and \fIfilename\fR data paths match .RE .RS +4 .TP .ie t \(bu .el o What child elements are allowed under those \fBAIM_MANIFEST\fR data elements .RE .RS +4 .TP .ie t \(bu .el o Where same-tagged sibling elements are allowed .RE .RS +4 .TP .ie t \(bu .el o Where childless \fBAIM_MANIFEST\fR data nodes are located .RE .sp .LP As each element of \fIfilename\fR data is processed, if all of the following conditions are true, then in general a new node is not created for this element in the \fBAIM_MANIFEST\fR data. Instead, an existing node is replaced with the new data. .RS +4 .TP .ie t \(bu .el o Both sets of data contain a node with the same tag and same location. .RE .RS +4 .TP .ie t \(bu .el o The DTD given by the \fB!DOCTYPE\fR reference in \fBAIM_MANIFEST\fR does not allow both of these nodes to exist together as same-tagged sibling elements. .RE .RS +4 .TP .ie t \(bu .el o The \fIfilename\fR data element has children. .RE When an element from \fIfilename\fR is inserted, the split where new nodes start to be created is done as close as possible to the \fBAIM_MANIFEST\fR data root. The first new node of the split is created at the earliest point where same-tagged sibling elements are allowed, or at the earliest appropriate point when no same-tagged element exists in \fBAIM_MANIFEST\fR. .sp .LP Use this XML manifest schema to analyze the following examples: .RS +4 .TP .ie t \(bu .el o The manifest begins with a single A node. .RE .RS +4 .TP .ie t \(bu .el o The A node can have only one B node child. .RE .RS +4 .TP .ie t \(bu .el o The B node can have multiple C node children. .RE .RS +4 .TP .ie t \(bu .el o The B node can have only one E node child. .RE .sp .LP \fBExample 1: Inserting Same-Tagged Elements\fR. If the content of \fBAIM_MANIFEST\fR is \fB/A/B/C1/D1\fR and the content of \fIfilename\fR is \fB/A/B/C2/D2\fR, then after the \fBload -i\fR command, the content of the \fBAIM_MANIFEST\fR file is \fB/A/B/{C1/D1,C2/D2}\fR. The C node is the first place where new nodes can be added. The C node from the \fIfilename\fR data is added after the existing C node in the \fBAIM_MANIFEST\fR data. If the two A elements have different values or if the two B elements have different values, the value of the \fIfilename\fR element replaces the value of the \fBAIM_MANIFEST\fR element. If the two A elements have different attributes, or if the two B elements have different attributes, the attribute values are merged. .RS +4 .TP .ie t \(bu .el o Attributes of A and B that exist in both the \fBAIM_MANIFEST\fR file and the \fIfilename\fR file have the values from the \fIfilename\fR file in the merged file. .RE .RS +4 .TP .ie t \(bu .el o Attributes of A and B that exist in either the \fBAIM_MANIFEST\fR file or the \fIfilename\fR file but not in both files are all retained in the merged file. .RE \fBExample 2: Inserting Differently Tagged Elements\fR. If the content of \fBAIM_MANIFEST\fR is \fB/A/B/C/D\fR and the content of \fIfilename\fR is \fB/A/B/E/F\fR, then after the \fBload -i\fR command, the content of the \fBAIM_MANIFEST\fR file is \fB/A/B/{E/F,C/D}\fR. The E node is added at the first location where it is allowed by the DTD. The values of elements A and B are the values from \fIfilename\fR, and the attributes of A and B are merged from \fIfilename\fR to \fBAIM_MANIFEST\fR as described in Example 1 above. .sp Sometimes the correct merge location cannot be determined. This can happen if a sibling that is required to follow a node to be merged has not yet been added. To avoid this issue, add multiple nodes or subtrees to a common parent node in the order mandated by the DTD. A node is placed at the end of its list of new siblings if its proper place among them cannot be determined. .RE .sp .ne 2 .mk .na \fB\fBaimanifest validate\fR\fR .ad .sp .6 .RS 4n Validates the \fBAIM_MANIFEST\fR manifest against the DTD referenced in the \fB!DOCTYPE\fR statement. Errors are printed to \fBstderr\fR. A non-zero status is returned if validation fails. .RE .SH OPERANDS .sp .LP The following operands are required. .SS "The Filename Operand" .sp .LP The \fBload\fR subcommand requires the \fIfilename\fR operand, which is the name of a full or partial manifest to load to the \fBAIM_MANIFEST\fR manifest. .SS "The Value Operand" .sp .LP The \fBadd\fR and \fBset\fR subcommands require the \fIvalue\fR operand. The \fIvalue\fR operand is a valid value of the element or attribute specified by the \fIpath\fR operand. .SS "The Path Operand" .sp .LP The \fBadd\fR, \fBdelete\fR, \fBget\fR, and \fBset\fR subcommands of the \fBaimanifest\fR command require the \fIpath\fR operand. The path defines a node in an XML hierarchy of elements and attributes. .sp .LP The XML element hierarchy structure is also called an XML tree. In the following partial AI manifest, the \fBauto_install\fR element is the root of the tree, and the \fBai_instance\fR and \fBsoftware\fR elements are branches or the roots of subtrees. .sp .in +2 .nf .fi .in -2 .sp .LP In \fBaimanifest\fR path syntax, use forward slash characters (/) to indicate branches in the tree structure. In the current example, the path to the \fBsoftware\fR element is \fB/auto_install/ai_instance/software\fR. .sp .LP Attributes are bound to an element. In \fBaimanifest\fR path syntax, use an at symbol (@) to identify an attribute name. The path to the \fBtype\fR attribute of the \fBsoftware\fR element is \fB/auto_install/ai_instance/software@type\fR. .sp .LP An \fBaimanifest\fR path operand may correspond to several elements. If you want or need to target a specific element, include element and attribute values as necessary to make the path unique. For example, to specify a size for the second slice defined in the following partial AI manifest, you could use the path \fB/auto_install/ai_instance/target/disk/slice[@name="4"]/size@val\fR to identify which slice you are specifying the size for. .sp .in +2 .nf .fi .in -2 .sp .LP The \fBget\fR, \fBset\fR, and \fBdelete\fR subcommands accept a path which can correspond to several elements. The \fBadd\fR subcommand requires a path which matches a single (parent) element. .sp .LP Relative paths are permitted. The \fBslice\fR path shown in the previous paragraph could be specified starting at \fBai_instance\fR, \fBtarget\fR, \fBdisk\fR, or \fBslice\fR , since there is only one \fBslice\fR with a \fBname\fR attribute value of 4. For example, you could use the path \fBslice[@name="4"]/size@val\fR. .sp .LP If a \fIvalue\fR within a \fIpath\fR contains forward slash characters, then that value must be enclosed in single or double quotation marks, as in \fB/name="pkg:/entire"\fR. .sp .LP When the \fBaimanifest\fR call is in a shell script, values that contain quotation marks might require additional special treatment. Within a shell script, quotation marks in \fBaimanifest\fR path values might need to be escaped with a preceding backslash character (\e) so that the shell does not remove or interpret the quotation marks. Check the rules of the shell you are using. The following example shows a value with a forward slash character in a \fBksh93\fR script: .sp .in +2 .nf /usr/bin/aimanifest get software_data[name=\e"pkg:/entire\e"]@action .fi .in -2 .sp .LP Most examples in this man page omit backslash escape characters because this man page does not assume that \fBaimanifest\fR is being called in a script or in a particular shell. See \fIInstalling Oracle Solaris 11 Systems\fR for information about AI derived manifests scripts. .sp .LP The following forms of branches show how to construct a path to an element or element attribute. .sp .ne 2 .mk .na \fB\fB/A\fR\fR .ad .sp .6 .RS 4n \fBA\fR is the tag name of an element, as in \fB/auto_install\fR. This branch specification is also called a simple branch. Paths with only simple branches are called simple paths. .RE .sp .ne 2 .mk .na \fB\fB/A=\fIvalue\fR\fR\fR .ad .sp .6 .RS 4n \fBA\fR is the tag name of an element, and \fIvalue\fR is the value of that element, as in \fB/name="pkg:/entire"\fR. .RE .sp .ne 2 .mk .na \fB\fB/A[B/C=\fIvalue\fR]\fR\fR .ad .sp .6 .RS 4n \fBA\fR is an element, \fBB\fR is an element that is a child of \fBA\fR, \fBC\fR is an element that is a child of \fBB\fR, and \fIvalue\fR is the value of the \fBC\fR element. This path form specifies the \fBA\fR element that has a grandchild element \fBC\fR that has value \fIvalue\fR. For example, if your AI manifest has more than one software section, you could use this form to operate on the software section that installs package \fBpkg:/entire\fR, as in the following path: .sp .in +2 .nf software[software_data/name="pkg:/entire"] .fi .in -2 .RE .sp .ne 2 .mk .na \fB\fB/A[@Aattr=\fIvalue\fR]\fR\fR .ad .sp .6 .RS 4n \fBA\fR is an element, \fBAattr\fR is an attribute of \fBA\fR, and \fIvalue\fR is the value of the \fBAattr\fR attribute. This path form specifies the \fBA\fR element that has attribute \fBAattr\fR with value \fIvalue\fR. For example, if your AI manifest defines more than one slice, you could use this form to operate on the slice that has a \fBname\fR value of 4, as in \fBslice[@name="4"]\fR .RE .sp .ne 2 .mk .na \fB\fB/A[B/C@Cattr=\fIvalue\fR]\fR\fR .ad .sp .6 .RS 4n \fBA\fR is an element, \fBB\fR is a child of \fBA\fR, \fBC\fR is a child of \fBB\fR, \fBCattr\fR is an attribute of \fBC\fR, and \fIvalue\fR is the value of the \fBCattr\fR attribute. This path form specifies the \fBA\fR element that has a grandchild element \fBC\fR that has attribute \fBCattr\fR with value \fIvalue\fR. For example, if your AI manifest has more than one software section, you could use this form to operate on the software section that has a publisher section with a name value of \fBsolaris\fR, as in the path \fBsoftware[source/publisher@name="solaris"]\fR. .RE .sp .ne 2 .mk .na \fB\fB/A[1]\fR\fR .ad .sp .6 .RS 4n \fB/A[1]\fR specifies the first instance of an \fBA\fR element in the manifest. For example, if your AI manifest has more than one software section, you could use this form to operate on the second software section, as in \fB/auto_install[1]/ai_instance[1]/software[2]\fR. .sp This is the form of path that is returned by the \fB-r\fR option. See the "Return Paths" section. .RE .sp .ne 2 .mk .na \fB\fB/A@Aattr\fR\fR .ad .sp .6 .RS 4n This path specifies the \fBAattr\fR attribute of the \fBA\fR element. This path does not specify the \fBA\fR element but rather the \fBAattr\fR attribute. Use this form to set or get the \fBAattr\fR attribute. .RE .sp .ne 2 .mk .na \fB\fB/A[B/C=\fIvalue\fR]@Aattr\fR\fR .ad .sp .6 .RS 4n This path specifies the \fBAattr\fR attribute of the \fBA\fR element that has a grandchild element \fBC\fR that has value \fIvalue\fR. .RE .sp .ne 2 .mk .na \fB\fB/A[B/C@Cattr=\fIvalue\fR]@Aattr\fR\fR .ad .sp .6 .RS 4n This path specifies the \fBAattr\fR attribute of the \fBA\fR element that has a grandchild element \fBC\fR that has attribute \fBCattr\fR with value \fIvalue\fR. .RE .sp .ne 2 .mk .na \fB\fB/A/B=\fIvalue\fR@Battr\fR\fR .ad .sp .6 .RS 4n This path specifies the \fBBattr\fR attribute of the \fBB\fR element with value \fIvalue\fR. The \fBB\fR element is a child of the \fBA\fR element. .RE .SH RETURN PATHS .sp .LP With the \fB-r\fR option, the \fBadd\fR, \fBget\fR, and \fBset\fR subcommands return the address of each element that was created or accessed by the subcommand. These returned addresses are in the form of a chain of node IDs. These returned addresses can be used to access returned elements again, even if values associated with those elements have changed. .sp .LP The following examples show that the address returned by the \fB-r\fR option can be much easier to use than a path that specifies element and attribute values. Start with the following node tree: .sp .in +2 .nf auto_install | ai_instance | target | disk attribute: whole_disk=true | disk_name attribute: name=data1 attribute: name_type=volid .fi .in -2 .sp .LP Add a new \fBdisk\fR node with \fBname\fR attribute value \fBdata2\fR and \fBname_type\fR attribute value \fBvolid\fR: .sp .in +2 .nf auto_install | ai_instance | target | |----------|----------| disk disk whole_disk=true whole_disk=true | | disk_name disk_name name=data1 name=data2 name_type=volid name_type=volid .fi .in -2 .sp .LP A new \fBdisk_name\fR element with one attribute can be added easily with a single command. To add the second and third attributes, you must specify which \fBdisk_name\fR element to change. Compare the following two methods for accessing the same node multiple times. .SS "Specifying Paths By Using Values" .sp .LP The commands in this example specify paths using values. Note that you must assign a unique value in the first command so that you can use that value to specify a unique path in the subsequent commands. This method could yield an incorrect result if the values are changed. .sp .in +2 .nf $ \fBaimanifest add target/disk/disk_name@name data2\fR $ \fBaimanifest set \e\fR > \fBtarget/disk/disk_name[@name=data2]@name_type volid\fR $ \fBaimanifest set \e\fR > \fBtarget/disk[disk_name@name=data2]@whole_disk true\fR .fi .in -2 .sp .SS "Specifying Paths By Using Returned Paths" .sp .LP The most reliable way to access the same node multiple times is to save the path to the new \fBdisk_name\fR element, and then use that saved path for subsequent accesses. .sp .in +2 .nf $ \fBNewDisk=$(aimanifest add -r target/disk@whole_disk true)\fR $ \fBaimanifest add ${NewDisk}/disk_name@name data2\fR $ \fBaimanifest add ${NewDisk}/disk_name@name_type volid\fR .fi .in -2 .sp .sp .LP The path that is returned to \fB$NewDisk\fR through the \fB-r\fR option expresses the node in terms of IDs and is free of values: .sp .in +2 .nf $ \fBaimanifest add -r target/disk/@whole_disk true\fR /auto_install[1]/ai_instance[1]/target[1]/disk[2] .fi .in -2 .sp .SH EXAMPLES .sp .LP To try these examples, you need to set \fBAIM_MANIFEST\fR. .sp .in +2 .nf $ \fBexport AIM_MANIFEST=/tmp/aimtest.xml\fR .fi .in -2 .sp .sp .LP The minimum \fBAIM_MANIFEST\fR file that the \fBaimanifest\fR command can modify must contain both of the following pieces: .RS +4 .TP .ie t \(bu .el o A \fB!DOCTYPE\fR reference to a DTD that is valid for the XML manifest being developed. .RE .RS +4 .TP .ie t \(bu .el o The root element for this manifest. .RE .sp .LP The following example shows the minimum \fBAIM_MANIFEST\fR manifest file for an AI manifest: .sp .in +2 .nf .fi .in -2 .sp .LP Usually, you will use the \fBaimanifest\fR command in a derived manifests script that operates on an existing valid AI manifest. To try these examples, you can copy \fB/usr/share/auto_install/manifest/default.xml\fR and then define \fBAIM_MANIFEST\fR to refer to this copy. Make sure the copy is writable. .LP \fBExample 1 \fRSet the \fBauto_reboot\fR Attribute .sp .in +2 .nf $ \fBaimanifest set /auto_install/ai_instance@auto_reboot false\fR .fi .in -2 .sp .LP \fBExample 2 \fRGet the \fBauto_reboot\fR Value .sp .in +2 .nf $ \fBaimanifest get /auto_install/ai_instance@auto_reboot\fR false .fi .in -2 .sp .LP \fBExample 3 \fRAdd a Publisher by Using Values Paths .sp .LP The package repository in this example is a file repository at \fBfile:///net/host2/export/extras_repo\fR. The publisher is \fBextras\fR. Since a \fBsoftware\fR element can have only one \fBsource\fR element, this example adds the new \fBpublisher\fR element to the \fBsource\fR element that contains the \fBsolaris\fR publisher. .sp .in +2 .nf $ \fBaimanifest add \e\fR > \fBsoftware[@type=IPS]/source[publisher@name=solaris]/publisher@name \e\fR \fBextras\fR $ \fBaimanifest add \e\fR > \fBpublisher[@name=extras]/origin@name \e\fR > \fBfile:///net/host2/export/extras_repo\fR .fi .in -2 .sp .sp .LP These \fBaimanifest\fR commands result in the following AI manifest entries if you started with the \fBdefault.xml\fR AI manifest. The \fBdestination\fR and \fBsoftware_data\fR elements are omitted for brevity. .sp .in +2 .nf .fi .in -2 .LP \fBExample 4 \fRAdd a Publisher by Using Returned Paths .sp .LP This example is the same as the previous example but uses a different method to achieve the same result. .sp .in +2 .nf $ \fBNEW_PUB=$(aimanifest add -r \e\fR > \fBsoftware[@type=IPS]/source[publisher@name=solaris]/publisher@name \e\fR \fBextras)\fR $ \fBecho $NEW_PUB\fR /auto_install[1]/ai_instance[1]/software[1]/source[1]/publisher[2] $ \fBaimanifest add ${NEW_PUB}/origin@name \e\fR \fBfile:///net/host2/export/extras_repo\fR .fi .in -2 .sp .LP \fBExample 5 \fRAdd a Publisher By Adding a Manifest Fragment .sp .LP This example adds the \fBextras\fR publisher by loading a file that contains a partial AI manifest. In this case, the result is a separate, additional \fBsoftware\fR element of type IPS with the \fBextras\fR publisher defined. This new \fBsoftware\fR element is inserted after the original IPS \fBsoftware\fR element that defines the \fBsolaris\fR publisher. Packages named in \fBsoftware_data\fR elements within this new \fBsoftware\fR element are only searched for from the \fBextras\fR publisher or other publishers defined in this new \fBsoftware\fR element. This manifest fragment also defines a package to install, since a \fBsoftware\fR element with no software to install is not useful. .sp .LP Create a file named \fBextras.xml\fR with the following content: .sp .in +2 .nf pkg:/package/from/extras_repo .fi .in -2 .sp .LP Even though you only want the \fBsoftware\fR section, you must include the \fBauto_install\fR and \fBai_instance\fR elements as well. If the loaded file specifies attributes for the \fBauto_install\fR or \fBai_instance\fR elements, then those attribute values replace existing values or are added. .sp .LP Use the following command to add this \fBsoftware\fR section to the \fBAIM_MANIFEST\fR manifest: .sp .in +2 .nf $ \fBaimanifest load -i extras.xml\fR .fi .in -2 .sp .LP \fBExample 6 \fRAdd a Package by Using a Values Path .sp .LP This example adds a package to the \fBsoftware\fR element that has a \fBpublisher\fR element with name \fBsolaris\fR by specifying the publisher name as a value in the path. .sp .in +2 .nf $ \fBaimanifest add \e\fR > \fBsoftware[source/publisher@name=solaris]/software_data/name \e\fR > \fBpkg:/system/utils\fR .fi .in -2 .sp .sp .LP This \fBaimanifest\fR command adds the second \fBsoftware_data\fR element shown below if you started with the \fBdefault.xml\fR AI manifest. .sp .in +2 .nf pkg:/entire@latest pkg:/group/system/solaris-large-server pkg:/system/utils .fi .in -2 .LP \fBExample 7 \fRAdd a Package by Using a Returned Path .sp .LP This example is the same as the previous example but uses a different method to achieve the same result. This example uses the \fBget\fR subcommand with the returned path option to add the package to the \fBsoftware\fR element where the \fBsolaris\fR publisher is defined. .sp .in +2 .nf $ \fBNEW_PKG=$(aimanifest get -r \e\fR \fBsoftware[source/publisher@name=solaris] | awk '{print $2 }')\fR $ \fBecho $NEW_PKG\fR /auto_install[1]/ai_instance[1]/software[1] $ \fBaimanifest add ${NEW_PKG}/software_data/name \e\fR \fBpkg:/system/utils\fR .fi .in -2 .sp .LP \fBExample 8 \fRDelete the "entire" Package from a Manifest Using Python .sp .LP This example looks for a package to install that has "entire" in its name, and deletes it from subprocess import Popen, PIPE. .sp .in +2 .nf AIMANIFEST = "/usr/bin/aimanifest" NODEPATH = "software/software_data[@action=install]/name" cmd = [ AIMANIFEST, "get", NODEPATH ] popen_ret = Popen(cmd, stdout=PIPE) popen_ret.wait() entire = None if popen_ret.returncode == 0: entire = [ pk.strip() for pk in popen_ret.stdout if "entire" in pk ] if len(entire) == 1: cmd = [ AIMANIFEST, "delete", NODEPATH + "='" + entire[0] + "'" ] popen_ret = Popen(cmd, stdout=PIPE) popen_ret.wait() if len(entire) != 1 or popen_ret.returncode != 0: print "delete of 'entire' package failed" .fi .in -2 .LP \fBExample 9 \fRUpdate a Common Attribute of All Disks With a Single "set" Command .sp .LP This example sets up four disks which are on a single controller, adding them all to the "datapool" zpool. It uses three "set" subcommands to update three attributes on all four disks. .sp .in +2 .nf NUM_C0_DISKS=4 for ((num = 0; num <= NUM_C0_DISKS; num++)) ; do aimanifest add disk/disk_name@name \ /pci@0,0/pci108e,534a@7/disk@${num},0 done aimanifest set disk/disk_name@name_type devpath aimanifest set disk@in_zpool datapool aimanifest set disk@whole_disk true .fi .in -2 .sp .LP This results in the following XML in the subtree: .sp .in +2 .nf ... ... .fi .in -2 .LP \fBExample 10 \fRAdd a Package By Adding a Manifest Fragment .sp .LP This example adds the package by loading a file that contains a partial AI manifest. In this case, the result is a separate, additional \fBsoftware\fR element of type IPS inserted after the original IPS \fBsoftware\fR element. This new \fBsoftware\fR element contains only a \fBsoftware_data\fR element; no \fBsource\fR element is specified. Packages named in \fBsoftware_data\fR elements within this new \fBsoftware\fR element are searched for from publishers defined in the preceding \fBsoftware\fR element. .sp .LP Create a file named \fBnewpkg.xml\fR with the following content: .sp .in +2 .nf pkg:/system/utils .fi .in -2 .sp .LP Even though you only want the \fBsoftware\fR section, you must include the \fBauto_install\fR and \fBai_instance\fR elements as well. If the loaded file specifies attributes for the \fBauto_install\fR or \fBai_instance\fR elements, then those attribute values replace existing values or are added. .sp .LP Use the following command to add this \fBsoftware\fR section to the \fBAIM_MANIFEST\fR manifest: .sp .in +2 .nf $ \fBaimanifest load -i newpkg.xml\fR .fi .in -2 .sp .LP \fBExample 11 \fRValidate a Manifest .sp .LP Validate the \fBAIM_MANIFEST\fR manifest. .sp .in +2 .nf $ \fBaimanifest validate\fR .fi .in -2 .sp .SH EXIT STATUS .sp .LP The following exit values are returned: .sp .ne 2 .mk .na \fB\fB0\fR\fR .ad .RS 13n .rt The command was processed successfully. .RE .sp .ne 2 .mk .na \fB\fB>0\fR\fR .ad .RS 13n .rt An error occurred. .RE .SH FILES .sp .ne 2 .mk .na \fB\fBAIM_MANIFEST\fR\fR .ad .sp .6 .RS 4n The value of this environment variable is the location of the AI manifest that is being built. .RE .sp .ne 2 .mk .na \fB\fBAIM_LOGFILE\fR\fR .ad .sp .6 .RS 4n The value of this environment variable is the location of the log file of \fBaimanifest\fR operations. .RE .SH ATTRIBUTES .sp .LP See \fBattributes\fR(5) for descriptions of the following attributes: .sp .sp .TS tab() box; cw(1.65i) |cw(3.85i) lw(1.65i) |lw(3.85i) . ATTRIBUTE TYPEATTRIBUTE VALUE _ AvailabilityT{ \fBsystem/install/auto-install/auto-install-common\fR T} _ Interface StabilityCommitted .TE .SH SEE ALSO .sp .LP \fBinstalladm\fR(1M) .sp .LP Part\ III, \fIInstalling Using an Install Server,\fR in \fIInstalling Oracle Solaris 11.3 Systems\fR