bundle schema for bcfg2 Narayan Desai, Argonne National Laboratory Abstract implementation of a Package entry. The full specification will be generated by a plugin such as Packages. Abstract implementation of a Path entry. The entry will either be handled by Cfg, TGenshi, or another Generator plugin; or handled by Rules, in which case the full specification of this entry will be included in Rules. Abstract implementation of a Service entry. The full specification will be included in Rules. Abstract implementation of an Action entry. The full specification will be included in Rules. Abstract description of a POSIXUser entry. Abstract description of a POSIXGroup entry. PostInstall entries are deprecated in favor of Action entries. Actions can do everything PostInstall entries can do and more. Abstract SELinux boolean entry. Abstract SELinux port entry. Abstract SELinux file context ("fcontext") entry. Abstract SELinux node entry. Abstract SELinux login entry. Abstract SELinux user entry. Abstract SELinux interface entry. Abstract SELinux permissive domain entry. Abstract SELinux module entry. Fully bound description of a software package to be managed. Fully bound description of a filesystem path to be handled by the POSIX driver. Fully bound description of a system service to be managed. Fully bound description of a command to be run. Fully bound description of an SELinux boolean entry. Fully bound description of an SELinux port entry. Fully bound description of an SELinux file context entry. Fully bound description of an SELinux node entry. Fully bound description of an SELinux login entry. Fully bound description of an SELinux user entry. Fully bound description of an SELinux interface entry. Fully bound description of an SELinux permissive domain entry. Fully bound description of an SELinux module entry. Fully bound description of a POSIXUser entry. Fully bound description of a POSIXGroup entry. Elements within Group tags only apply to clients that are members of that group (or vice-versa; see #element_negate below) Elements within Client tags only apply to the named client (or vice-versa; see #element_negate below) Nesting Bundle tags is allowed in order to support XInclude within Bundles. A **BundlerGroupType** is a tag used to provide logic. Child entries of a BundlerGroupType tag only apply to machines that match the condition specified -- either membership in a group, or a matching client name. :xml:attribute:`BundlerGroupType:negate` can be set to negate the sense of the match. The group name Negate the sense of this group or client; i.e., entries within this tag are only used on clients that are not members of the group, or that have hostnames that do not match. Freeform description of the bundle. The name of the bundle. This must match the bundle filename, minus the extension. Bundle schema version. URL of master version (for common repo) Master version control revision. A bundle describes a group of inter-dependent configuration entries, such as the combination of packages, configuration files, and service activations that comprise typical Unix daemons. Bundles are used to add groups of configuration entries to the inventory of client configurations, as opposed to describing particular versions of those entries. For example, a bundle could say that the configuration file ``/etc/passwd`` should be included in a configuration, but will not describe the particular version of ``/etc/passwd`` that a given client will receive.