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 be handled by a Generator plugin, like Cfg or 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. 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. Nesting Bundle tags to specify dependencies to other 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. The name of the required bundle. Specify how to handle modifications in the required bundle. You can either ignore the modifications (this is the default) or you can inherit the modifications so that Services in the current Bundle are restarted if the required Bundle is modified. Freeform description of the bundle. If set to ``true``, indicates that the bundle is a collection of independent entries, and that service restarts and modified actions should not be performed. See :ref:`server-plugins-structures-bundler-magic` for more. **Deprecated.** The name of the bundle. If present, this must match the bundle filename, minus the extension. Specifying the name explicitly is deprecated. Bundle schema version. URL of master version (for common repo) Master version control revision. Override the global lax_decryption setting in ``bcfg2.conf``. 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.