11.4 Bundles

The Bundles menu is at least as important as the device menu. Objects that represent software items such as RPMs, patches, archives, and configuration files are located here.

11.4.1 Folders

The bundles menu is empty for a newly installed ZENworks Configuration Management server.

Figure 11-30 Bundle Folder after Installation

In general, two different kinds of software appear under this menu:

  • For every operating system and service pack level provided by vendors such as Novell or Red Hat, folders and bundle objects are automatically created here by the mirror process

    These objects are used by Novell Consulting to build an update methodology based on reliable frozen patch bundles, which are described later in Section 12.1, Frozen Patch Level.

  • Any kind of in-house software or in-house task object is located below this menu. These objects can be used to configure the target devices or to deploy software that was obtained by other means than mirroring distribution channels.

Folder Hierarchy

Even if some objects are created automatically, the folder structure underneath the Bundles menu must be predefined.

Because this part of the ZENworks Configuration Management system will hold a large number of entries, the folder structure must be well designed to allow for easy administration:

  • Deep folder hierarchies should be avoided. Novell Consulting recommends that you design a hierarchy with a maximum of five levels.

  • The first level of the folder hierarchy starts with Linux to distinguish between software bundles for products of other vendors such as Apple or Microsoft and software items for Linux products.

    Figure 11-31 Bundle Folder Level 1

  • The second level of the hierarchy is made up of the CUSTOM folder for customer-specific bundles and folders based on operating system versions or add-on product versions.

  • With the exception of CUSTOM, each of the previously mentioned Level 2 folders is subdivided into folders for the corresponding support packs at the third level.

  • Folders below Level 3 are automatically created by the mirror process.

Naming Standards for Bundle Folders with Mirror Content

In addition to the general naming rules formulated in Section 11.2.1, General Rules for Folder Names, the following additional definitions are required:

  • Names of folders on Level 2 are built from the product tag %PRODUCT% and the version tag %VERSION%. For example, SLES11.

  • Folders on Level 3 are named either after the corresponding service pack or the term “GA” if no service pack exists. For example, SP1 | SP2 | GA | ...

The following figure illustrates the folder structure for bundles at folder Level 2 with subfolders GA and SP1 at Level 3:

Figure 11-32 Bundle Folder Levels 2 and 3

Folders in the following figure are created automatically by the mirror process. Details about the configuration of mirror channels are explained Section 11.5.4, Creating a Subscription.

Figure 11-33 Bundle Folders Created by the Mirror Process - Level 4

In the following figure, you can see the bundles at the lowest level originally mirrored from Novell:

Figure 11-34 Bundles at Folder Level 5

The CUSTOM Folder

The CUSTOM folder serves as a container for all in-house software and special patches retrieved from Novell (PTF, FT, engineering builds). It contains several subcontainers for additional subdivision of bundles based on their operating system, patch level, and other criteria.

In addition to the general naming rules defined in Section 11.2.1, General Rules for Folder Names, the following rules apply to folders in the CUSTOM branch of the Bundles folder structure:

  • The top level folder is named CUSTOM

  • Folders below CUSTOM are named to symbolize the task the folder was created for

  • Folders prefixed with SLES11 contain software for SLES devices that is also applicable to OES 11 system

  • Folders prefixed with OES11 contain only software for OES 11 devices

The following figure shows the structure of the CUSTOM folder created during a recent project:

Figure 11-35 Bundle Folder CUSTOM

The purpose of the individual folders is as follows:

  • _ENGINEERING-BUILDS contains field test files (FTF) that are not available from update channels. These bundles are assigned to individual device objects or to device groups as needed. They must not be assigned automatically because they might be obsolete with the next patch level.

  • BUNDLE-GROUPS contains all bundle groups that are used for easier bundle assignment.

  • EDIR-BASECONFIG stores any bundles that configure eDirectory.

  • IMAN-BASECONFIG contains bundles that affect the configuration of iManager.

  • OES11-BASECONFIG contains bundles that are suitable for all OES 11 devices.

  • OES11-SERVICES contains bundles with configuration settings for OES 11 services such as NOV-FTP, LUM, and NSS.

  • SLES11-BASECONFIG contains bundles with configuration settings for SLES 10 or SLES 11 components, regardless of whether OES 11 is installed as an add-on product.

  • SLES11-NETWORK contains bundles that execute network-related configurations for SLES 11.

  • SLES11-STORAGE contains bundles located that configure properties of HBA hardware, volume managers, or multi-pathing for SLES 11.

  • VENDORS contains vendor-specific software such as hardware tools, virus scanners, backup software, and others from vendors such as IBM, HP, or Symantec. It has been introduced as a separate subfolder because possible vendor folders below the CUSTOM folder would destroy the ordering within the UI, because it is sorted alphabetically.

11.4.2 Bundles and Bundle Groups

In addition to subfolders, the most important objects in this folder are the bundles themselves, representing packages, configuration files, archives, and patches.

Several different types of bundle objects exist in the name space of ZENworks Configuration Management. They can be classified into the following categories:

  • Bundles created by a mirror process from external sources

    • Update bundles

    • Pool/Core bundles/dependency bundles

    • Online bundles

    • Bundles from external repositories

  • In-house bundles created via ZENworks Control Center or the zman command line utility

    • File bundles

    • RPM bundles

    • Empty bundles

An additional object type within the bundles menu is the bundle group.

Update Bundles

Vendors like Novell or Red Hat publish their patches via special update repositories. The contents of these repositories can be accessed by the device needing the updates directly or by a mirror server such as a ZENworks Configuration Management server that can download the updates so that devices on the corporate network have access to these updates locally.

The notion of an update bundle is used for a set of patches or packages that is targeted at a given OS level. Update bundles usually contain several RPMs or delta RPMs.

Updates bundles are also provided by the Novell update server nu.novell.com.

Figure 11-36 Bundle Types Provided by Novell

Pool Bundles

A pool bundle contains the same content as the installation medium of the corresponding product and service pack. It is primarily used for dependency resolution.

Core Bundle

This bundle type was introduced with SLES 11 SP2 as part of a recent change to the SUSE Linux Enterprise 11 Maintenance Model (see Section 11.1, Overview). It is simply a subset of the installation media that contains approximately 30 per cent of the original Pool channel, considered as the core of the new Service Pack. Core bundles are also used for dependency resolution. Packages that are not provided by a Core bundle are still provided by the earlier Pool bundle. This type of bundle is only used by SLES 11 but not by earlier SLES versions or by OES 11.

Online Bundles

An online bundle is a subtype of a pool bundle. It is used only when upgrading an operating system or an add-on product to the next release, such as upgrading from OES 2 SP2 to OES 2 SP3.

File Bundles

File bundles are typically used to distribute configuration files or archives from other vendors (McAfee virus scanner, HP Proliant Utilities, IBM Tivoli backup software, and so forth) if they are not provided as RPM format.

RPM Bundles

RPM bundles contain one or more RPM packages. The bundle can be made up of packages from the ZENworks Configuration Management repository, of external packages uploaded via the upload dialog box, or of a mixture from both sources.

Empty Bundles

At first glance, an empty bundle seems to make no sense. However, it is not really empty, but it has been created as a placeholder to be filled later with other bundle types. An empty bundle can play an important role when you need to group different bundles in a specific order. An empty bundle can serve as a container for other bundles. This lets you put different bundles in order for easier assignment, controlling the installation order, and applying properties such as filters to the whole set.

In addition, an empty bundle is often used for scripted deployments, where it serves as the carrier for a script that is executed at the target devices without distributing the script content to the devices.

The following figure illustrates different bundle types discussed earlier. OES11ALL_NOV-AUDIT-OFF and OES11GA_NOV-DEMO-EMPTYBDL are examples of empty bundles. The type of the remaining two bundles is displayed in the Category field.

Figure 11-37 Bundle Types

Bundle Groups

Bundle groups combine multiple bundles into one group object similar to empty bundles. By assigning bundle groups rather than individual bundles to devices, the number of required assignments can be reduced considerably. A further reduction in assignments can be achieved when bundle groups are assigned to device groups. Examples for bundle groups used by Novell Consulting are explained in the following figure. Their importance is explained in Section 11.4.4, Bundle Groups and Bundles Developed by Novell Consulting.

Figure 11-38 Bundle Groups Example

Naming Standards for Bundles and Bundle Groups

Naming Standards for Bundles

Novell Consulting has developed and applied the following naming standard for bundle objects located below the CUSTOM folder:

%PRODUCT%[%VERSION%[SP%SP-LEVEL%]]_%INITIATOR%-%PURPOSE%[-%TARGET%]

Name

Description

 
PRODUCT

SLES | OES | EDIR | IMAN | NCS | ...

This part of a name identifies the product for which a certain bundle is relevant. Objects with names that start with SLES must be assigned to pure SLES systems (such as SLES 10) as well as to the corresponding OES system (such as OES 2).

This part of the name is also used to identify if an object is only relevant for specific systems such as an eDirectory server (SLES or OES), a server with iManager installed (SLES or OES), or an NCS cluster.

 
VERSION

2 | 9 | 10 | 11 [only] | ALL

This part of the naming standard identifies for which version (SLES or OES) an object is applicable. If an object is only applicable for a certain support pack level, this is denoted by only. If it is not specific for a particular version, ALL is used instead.

 
SP-LEVEL

1 | 2 | 3 [only] | ALL

This becomes part of an object name only if an object is specific for a certain support pack level and later. If an object is only applicable for a specific support pack level, it is indicated by only.

If a bundle is not specific to a support pack, the SP level is replaced with ALL.

 
INITIATOR

NOV | CUST | ENG

Bundles that were initiated by Novell and that are not specific to a certain customer are identified by NOV. CUST indicates that an object is specific for the customer environment. ENG indicates an engineering build. Replace CUST with an identifier for the customer (maximum 4 characters).

 
PURPOSE

NAM | FTP | …

This part of the name very briefly indicates the purpose of the object or the component being configured.

 
TARGET

DUSCL01 | PRV | …

This is an optional part of the naming standard that is used only if an object is specific to certain systems such as the nodes of an NCS cluster or the systems in a specific location.

Naming Standards for Bundle Groups

Similar rules apply for bundle groups:

%PRODUCT%[%VERSION%[SP%SP-LEVEL%]]-%ENVIRONMENT%[-%Target%]-GRP

Name

Description

 
PRODUCT

SLES | OES

Equivalent to bundles

 
VERSION

2 | 9 | 10 | 11 [only] | ALL

Equivalent to bundles

 
SP-LEVEL

1 | 2 | 3 [only] | ALL

Equivalent to bundles

 
ENVIRONMENT

DEV - Development system

PROD - Production system

TEST - System from a technical proof of concept

 
TARGET

Equivalent to bundles

These naming standards are case-sensitive. The separators “_” and “-” also are a relevant part of the naming standard.

Some examples of how to use these naming standards to compose names for bundles or bundle groups are listed in the following table:

Name

Description

 
OE11GA_CUST-NAM-xyzcl01

The bundle configures NAM on the OES11GA nodes of cluster xyzcl01.

 
SLESALL_NOV-SUPPORT-CONFIG

The bundle contains the support-config packages from Novell for all SLES versions and service packs.

 
OES11GA_ENG_IFOLDER-SETTINGS

The bundle provides an FTF (field test file) obtained from engineering with specific settings for Novell iFolder.

 
IMAN_NOV-J2EE

The bundle contains configuration settings for iManager /etc/sysconfig/j2ee.

 
OES11GA-PROD-DUS01-GRP

A bundle group that deploys bundles to configure settings that are specific for cluster dusl01).

11.4.3 Creating a File Bundle

The main purpose of file bundles is to distribute simple files or archives. The creation of a file bundle starts in the appropriate subfolder below Bundles > Linux > CUSTOM. The following example shows the creation of a file bundle that configures a bond interface on SLES 11. The bundle is described in detail in SLES11ALL_CUST-BONDING.

Following the naming standard defined in Naming Standards for Bundles and Bundle Groups, the bundle is called SLES11ALL_CUST-BONDING for the following reasons:

  • SLES11ALL indicates that the bundle is intended for SLES 11 independent of the service pack version

  • _CUST indicates that the bundle is using some customer-specific information, such as the target IP address for link monitoring.

  • -BONDING indicates that the purpose of the bundle is to configure a bond device.

The bundle has been categorized as a network-related bundle and is therefore created below the Bundles > Linux > CUSTOM > SLES11-NETWORK folder as shown in the following figure:

Figure 11-39 Bundle Creation

The Linux Bundle entry is selected according to the default:

Figure 11-40 Bundle Creation - Select Bundle Type

Because the bundle distributes a script and a binary that are not part of any RPM, you need to select the Install File(s) bundle category:

Figure 11-41 Bundle Creation - Select Bundle Category

The bundle name is assigned in the next step. If the Icon box is left empty, a standard icon is displayed near the bundle name:

Figure 11-42 Bundle Creation - Define Details

Next opens the file upload dialog box, where one or more files can be uploaded into ZENworks Configuration Management:

Figure 11-43 Bundle Creation - Select Files

Novell File Upload Extension: The extension displayed in the Bundle Creation Step 4 allows you to upload multiple files and to upload files larger than 1 GB. However, you will have a problem when installing the extension on Mozilla Firefox if the SSL certificate of the hosting server is signed as “Certificate Authority unknown to the browser.” To resolve this, use the click here button and follow the instructions. In addition, the extension does not work on newer versions of Mozilla Firefox.

The next figure shows the configuration of the destination directory, the file permissions, and the file ownership:

Figure 11-44 Bundle Creation - Destination Directory, File Permissions, and File Ownership

The last step in the creation process sums up all the selections made to this point:

Figure 11-45 Bundle Creation - Summary

The bundle has been created and is almost ready for use:

Figure 11-46 Bundle Creation Success

Before the new bundle can be used, you will need to make a few modifications. Because an unintended redeployment of this bundle would almost certainly result in a service interruption, you need to ensure that it will only be deployed to devices that do not have a bond device already configured.

This can be done by adding a requirement to the bundle specifying that the configuration file for the bond0 device must not exist in /etc/sysconfig/network. If you ever want to reconfigure your bond0 device, ensure that you delete its configuration file before you reinstall the bundle.

Figure 11-47 Bundle Modification - System Requirements

By default, ZENworks Configuration Management does not have the uninstall task enabled. Novell Consulting recommends that you enable this feature under the Options link of the Uninstall action.

Figure 11-48 Bundle Modification - Enable Uninstall

Finally, you need to allow the config_bond.sh script contained in this bundle to be executed by the root user; otherwise, the bundle will never install.

To do this, you need to double-click the script in the Install action and go to the Advanced tab, then select Run as Root. This modification is required with every ZENworks Configuration Management bundle that contains a custom script.

We also recommend that you change the action name to something specific for your bundle, such as run_config-bond rather than the default Run Script action name

Figure 11-49 Bundle Modification - Run As root

Changes always create a sandbox version of a bundle. This version must be published to become available for all devices to which it is assigned.

Figure 11-50 Bundle Modification Completed

If the new bundle is assigned to a device in its current state it does not work because the last three modifications only exist in the sandbox of the bundle. To make these modifications available to devices, a new version of the bundle needs to be published.

Figure 11-51 Publish a New Bundle Version

When the bundle is published, the version number is incremented by one and the sandbox flag is removed.

Figure 11-52 New Bundle Version Published

11.4.4 Bundle Groups and Bundles Developed by Novell Consulting

Standard settings of the operating system and for some Novell services do not necessarily meet the special requirements of distributed, clustered SAN-based environments that dominate IT infrastructures today. Although tools are necessary to manage the configuration aspects that are typical for this kind of infrastructure, Novell Consulting has encountered many environments where no configuration management tools were available for SLES servers or OES servers. Therefore, Novell Consulting has instrumented ZENworks Configuration Management to deploy the various configuration items that are necessary to manage settings and services of OES servers.

In recent projects, similar configuration items have been identified for different customers. ZENworks Configuration Management bundles have been build by Novell Consulting to perform configuration tasks common to standard OES environments. These bundles and associated bundle groups are described in this section, along with identifying their appropriate parent folders.

The BUNDLE-GROUPS Folder

The purpose of this folder is to collect all customer-specific bundle groups in one place. These bundle groups in turn are assigned to device groups (see Section 11.3.2, Server Group Objects in the Device Menu). Typically there is a 1:1 relationship between a bundle group and a device group whereas the same bundle can be a member of multiple bundle groups. This approach has been chosen to reduce the number of mouse clicks required to assign a bundle to its target devices

Novell Consulting strongly recommends that you distinguish between bundle groups for production environments and bundle groups for test/development environments. Therefore, every environment needs its own bundle groups.

Most customers who are utilizing OES services are also using Novell Cluster Services. Novell Consulting recommends that you create separate bundle groups for every cluster.

For example, a cluster named duscl01 uses the OES11ALL-PROD-duscl01-GRP bundle group, which contains the following bundles:

  • OES11ALL_NOV-LVM-CONF

  • SLES11ALL_CUST-BINDINGS-duscl01

These bundles configure the Linux Volume Manager and name the multi-path devices.

NOTE:In the following sections, only examples for production environments are provided. The examples can be easily adapted for other environments.

Bundles in the _ENGINEERING-BUILDS Folder

Field test files provided by Novell Engineering for a certain customer are not part of official update channels and should be placed in this folder. These bundles are assigned to individual device objects or to device groups as needed.

According to the established naming standards in , a bundle located here must contain the string ENG in its name to identify its origin. For example, OES11SP1only_ENG-CIFSD-20120215, where the date string in the example above is part of the %PURPOSE% tag. Its intention is to inform the administrator about the exact date when the particular FTF was delivered and to allow a distinction between different engineering builds of the same module.

Bundles in the EDIR-BASECONFIG Folder

EDIR_NOV-ARC

Advanced Referral Costing (ARC) provides an improved server-to-server communication. ARC helps eDirectory servers avoid servers that are responding at a transport level, but are slow or unresponsive to eDirectory requests. This feature must be enabled by using DSTrace or NDSTrace. It is not enabled by default.

An empty EDIR_NOV-ARC file bundle without content but with the following post-installation script needs to be deployed to configure ARC at the target devices:

#!/bin/sh
my_cmd=/opt/novell/eDirectory/bin/ndstrace
$my_cmd -l >>/dev/null &
$my_cmd -c 'set ndstrace = !ARC1'
$my_cmd -u

The creation process for the EDIR_NOV-ARC file bundle is shown here because it is a task that must be configured many times. The first common steps when creating a new bundle are not displayed because they are the same for any bundle type and they have been shown already in Figure 11-41 through Figure 11-50.

After the bundle has been created, you need to define the post-installation script in the Additional Properties menu by clicking Actions > Install and activating the Add link. You must select Run Script from the drop-down list.

Figure 11-53 EDIR_NOV-ARC - Add Install Action

The following menu asks whether a script located on the managed device should be executed, a script from the workstation where the browser has been started should be uploaded, or an own script should be defined. To configure ARC, you need to define an own script (see Figure 11-54 and Figure 11-59).

You can select Edit and type the script, or you can or paste the script (Figure 11-55). This screen also allows you to change the Action Name to a descriptive name such as configure_ARC in the example:

Figure 11-54 EDIR_NOV-ARC - Define Script

Figure 11-55 EDIR_NOV-ARC - Define Script Content

Click OK to display the following figure. The bundle is ready for use; it becomes available after you click Apply.

Figure 11-56 EDIR_NOV-ARC - Action Created

Changes always create a sandbox version for a bundle. This version must be published to become available for all device groups:

Figure 11-57 EDIR_NOV-ARC - Sandbox

Finally, you need to click Finish.

Figure 11-58 EDIR_NOV-ARC - Publish as New Version

The bundle is now published and ready for assignment:

Figure 11-59 EDIR_NOV-ARC - Bundle Published

The bundle must be a member of all bundle groups that are assigned to OES or SLES device groups representing systems where eDirectory is installed.

Summary

  • Components: eDirectory, ARC

  • Tools: ndstrace

  • Environments: All eDirectory instances

  • Configuration Files/Paths: N/A

  • Documentation: Advanced Referral Costing in the Novell eDirectory 8.8 Administration Guide.

  • Technical Information Documents: N/A

EDIR_NOV-DSRMENU

NetWare administrators managing eDirectory have been very familiar with the DSREPAIR.NLM utility for many years. On OES Linux, the ndsrepair command line tool is used for the same eDirectory maintenance tasks, but its appearance and usage is quite different from DSREPAIR.NLM.

This file bundle contains a wrapper script from Novell called dsrmenu.sh, which provides a similar layout for ndsrepair as for DSREPAIR.NLM on NetWare.

The dsrmenu.sh file is distributed to the local /bin directory of the target device via the EDIR_NOV-DSRMENU file bundle.

The bundle must be a member of all bundle groups that are assigned to OES or SLES device groups representing systems where eDirectory is installed.

Summary

  • Components: eDirectory, dsrmenu.sh

  • Tools: ndsrepair, dsrmenu.sh

  • Environments: All eDirectory instances

  • Configuration Files/Paths: /bin/dsrmenu.sh

  • Documentation: DSRMENU

  • Technical Information Documents: N/A

Bundles in the IMAN-BASECONFIG Folder

This folder contains bundles that change the configuration of Novell iManager.

IMAN_NOV-J2EE

OES servers hosting services like iManager or NetStorage are currently using Tomcat 6 as an application server. The Java memory settings of Tomcat 6 are set to conservative values by default. Because sufficient memory is typically available on modern server hardware, a possible performance bottleneck can be avoided by increasing the Java memory settings for Tomcat 6.

An empty IMAN_NOV-J2EE file bundle must be created that contains no files, but modifies the /etc/sysconfig/j2ee configuration file to adopt the memory settings via a script.

This bundle must be a member of all bundle groups assigned to devices runnning iManager.

Summary

  • Components: iManager

  • Tools: iManager instances

  • Environments: All eDirectory instances

  • Configuration Files/Paths: /etc/sysconfig/j2ee

  • Documentation: N/A

  • Technical Information Documents: TID 7009773

Bundles in the SLES11-BASECONFIG Folder

This folder contains bundles created for devices running SLES 11 and its service packs. It also includes devices that have OES 11 configured as an add-on product.

SLES11ALL_NOV-FORCEDUMP-CONFIG

By default, a SLES 11 system is not configured to capture a memory dump (vmcore) after a system crash.

With kdump, several components can be configured, such as where to store a kernel memory dump, the name of the dump file, and how many dump files should be preserved.

The kexec-tools and kdump packages must be installed on target devices. You need sufficient space below /var to save up to five memory dumps.

A file bundle containing kdump configuration parameters has been created. The file is delivered to /etc/sysconfig/kdump on target devices. In addition, the /etc/sysconfig/bootloader file is modified by a post-installation script at the target devices to preset the DEFAULT_APPEND (/etc/sysconfig/bootloader) variable for configuring the crashkernel as described in TID 3374462.The post-installation script ensures that boot.kdump is enabled (/sbin/chkconfig) and the crash kernel parameters are inserted into the boot configuration file for grub (/boot/grub/menu.lst).

The bundle is a member of all bundle groups assigned to SLES or OES devices.

Summary

  • Components: kdump, grug, kexec

  • Tools: sysctl

  • Environments: Devices where kernel core files need to be taken from for debugging reasons

  • Configuration Files/Paths: /etc/sysconfig/kdump, /etc/sysconfig/ulimit

  • Documentation: N/A

  • Technical Information Documents: TID 3374462

SLES11ALL_NOV-APPCORE-CONFIG

This bundle configures systems for application dumps.

The ulimit package must be installed at the target device and sufficient space below /var is required.

An empty bundle that carries a post-installation script has been created. The post-installation script performs the following steps:

  • Creates the /var/cores directory that contains the dump files

  • Persistent configuration of the dump directory by inserting 

    kernel.core_pattern=/var/cores.%e.%p

    into

    /etc/sysctl.conf

  • Enables core dumps for setuid and setgid processes in /etc/sysctl.conf – kernel.suid_dumpable=2

  • Issuing the sysctl -p /etc/sysctl.conf command activates these new settings without rebooting.

  • Disables the limit for the maximum size of a core dump file by setting HARDCORELIMIT="unlimited" and SOFTCORELIMIT="0" in /etc/sysconfig/ulimit

The bundle is a member of all bundle groups assigned to SLES or OES devices.

Summary

  • Components: sysctl, ulimit

  • Tools: sysctl

  • Environments: All devices

  • Configuration Files/Paths: /etc/sysconfig/ulimit, /etc/sysctl.conf

  • Documentation: N/A

  • Technical Information Documents: TID 3054866

Bundles in the OES11-BASECONFIG Folder

This folder contains bundles that are applicable to OES 11 devices.

OES11ALL_NOV-AUDIT-OFF

This bundle stops and de-activates the audit daemon that is automatically activated when novell-afp is installed. It must be assigned to all systems running novell-afp.

A post-installation script that is configured in an empty file bundle stops the audit daemon and ensures that it is not started after reboot. It is implemented by calling chkconfig and stopping the daemon via its init script.

The bundle needs to be a member of all bundle groups assigned to devices where novell-afp is installed.

Summary

  • Components: novell-afp, auditd

  • Tools: chkconfig

  • Environments: NSS file server with AFP enabled

  • Configuration Files/Paths: /etc/init.d/auditd

  • Documentation: N/A

  • Technical Information Documents: TID 7006838 (in particular, take note of Problem 4).

OESALL_NOV-BASHRC

For easier administration of cluster nodes, some alias commands were defined by Novell Consulting. This file bundle distributes the appropriate configuration file. Currently, the file contains mostly cluster-related aliases, but any other useful aliases can be implemented through this file.

The OESALL_CUST_BASHRC file bundle distributes the bash.bashrc.local file to /etc at the target device. Within this file, aliases for console commands are defined. It is automatically read when starting a BASH shell (for example, at login). This file bundle is strongly recommended to be a member of all bundle groups assigned to NCS cluster nodes. It can be made a member of all bundle groups assigned to OES devices.

Summary

  • Components: Novell Cluster Services, bashrc

  • Tools: shell

  • Environments: Novell Cluster Services

  • Configuration Files/Paths: /etc/bash.bashrc.local

  • Documentation: Novell Cool Solutions

  • Technical Information Documents: N/A

OES11ALL_NOV-NCP-SETTINGS

Default NCP server settings are configured for a broad range of environments. However, they need to be optimized for customer environments by using this bundle.

An empty OES11ALL_NOV-NCP-SETTINGS file bundle must be created that configures NCP settings such as cache and watchdog parameters via a post-installation script by executing ncpcon.

For example:

  • MAXIMUM_CACHED_FILES_PER_VOLUME=NNNNNN

  • MAXIMUM_CACHED_SUBDIRECTORIES_PER_VOLUME=NNNNNN

Typically, you only need to modify these settings on OES 11 systems that provide very large file systems to a large number of users over NCP. Make this bundle a member of all bundle groups assigned to such devices.

Summary

  • Components: NCP

  • Tools: ncpcon

  • Environments: Novell Cluster Services

  • Configuration Files/Paths: /etc/opt/novell/ncpserv.conf

  • Documentation: N/A

  • Technical Information Documents: TID 7004848, TID 7004888.

Bundles in the OES11-SERVICES Folder

This folder contains bundles that provide configurations for OES 11 services such as Novell-FTP, LUM, and NSS.

OES11ALL_NOV-FTP-SYSLOG-xxx

The Novell-FTP service utilizes pure-ftpd to provide its functionality. The standard pure-ftpd writes its log files to the local file system. However, in clustered environments, it is desirable to have the log files on the cluster resource. A configuration change for syslog-ng is necessary in those environments to change the default logging behavior from local devices to the cluster resource.

Because the configuration of syslog-ng is related to the resource name, it is different on every cluster, so every cluster that needs this redirection of FTP logs needs its own bundle.

A configuration setting in syslog-ng.conf must be distributed via a file bundle to /etc/syslog-ng and the SuSEconfig command must be executed within a post-installation script of the file bundle.

NOTE:The SyslogFacility directive in the ftp.conf file for your cluster-enabled FTP instance must be set to the syslog facility configured in syslog-ng.conf. For example, local3.

In addition to the prefix defined in the bundle naming standards, an identifier of the appropriate cluster should be chosen as the suffix. For example, OES11ALL_NOV-FTP-SYSLOG-duscl01 is a bundle name consistent with the naming standard for a bundle that configures FTP logging for the duscl01 cluster.

The bundle should be a member of a bundle group with the purpose of cluster assignment, such as OES11ALL-PROD-duscl01-GRP.

Summary

  • Components: novell-ftp, pure-ftpd, syslog-ng

  • Tools: SuSEconfig

  • Environments: Novell Cluster Services with novell-ftp enabled

  • Configuration Files/Paths: /etc/syslog-ng

  • Documentation: N/A

  • Technical Information Documents: N/A

OESALL_NOV-PURE-FTPD-CONF

This bundle disables the start of the local instance of pure-ftpd on cluster nodes using novell-ftp. To avoid interference of local FTP instances with the configuration of FTP cluster resources, the local pure-ftpd instance is also configured to listen on the host IP address only. FTP for cluster resources is managed from the NCS load/unload scripts.

A script carried by an empty file bundle ensures that the bind directive in the /etc/pure-ftpd/pure-ftpd.conf global configuration file is changed to the host IP address only. In addition, the script deactivates the start of pure-ftpd during the boot process by executing checkconfig.

This bundle is an example for a bundle that is in multiple bundle groups because the configuration changes fit any cluster environment. The bundle must be a member of all bundle groups for clusters where novell-ftp services are running.

Summary

  • Components: novell-ftp, pure-ftpd

  • Tools: chkconfig

  • Environments: Novell Cluster Services with novell-ftp enabled

  • Configuration Files/Paths: /etc/pure-ftpd/pure-ftpd.conf

  • Documentation: N/A

  • Technical Information Documents: TID 7005792

OES11ALL-CUST-NAM-xxx

This bundle deploys settings for the namcd daemon to configure LUM for a specific device group.

Depending on the network infrastructure, it might be necessary to have different LDAP servers configured per system. Systems in different locations might need a separate bundle to properly configure LUM.

Important properties of namcd are changed by a post-installation script that is part of an empty file bundle and that restarts the daemon after the configuration change.

The usual naming rules are also applied here. The bundle also contains the customer name CUST because it is a customer-related change in the configuration file. In addition, identifiers for the location should be appended, such as OES11ALL-CUST-NAM-<Location1>.

The bundle is a member of a bundle group collecting all bundles that need to be assigned to all devices in a specific location, such as OES11-PROD-DUS-GRP.

Summary

  • Components: novell-lum

  • Tools: namconfig

  • Configuration Files/Paths: /etc/nam.conf

  • Documentation: N/A

  • Technical Information Documents: N/A

OESALL_NOV-NSS-SET-XATTR

This bundle sets attributes in nssstart.cfg that determine how creation time, modification time, and extended attributes are handled. It is necessary in environments where the backup software has no interface to novell-sms and therefore does not recognize extended attributes of the NSS implementation on Linux.

A post-installation script of the empty file bundle configures the correct entries in /etc/opt/novell/nss/nssstart.cfg. A reboot is necessary to activate these settings.

The bundle needs to be a member of all bundle groups assigned to OES devices that have their NSS file systems backed up with non-SMS-aware backup solutions.

Summary

  • Components: NSS, backup software

  • Tools: N/A

  • Environments: Novell File Services, Backup

  • Configuration Files/Paths: /etc/opt/novell/nss/nssstart.cfg

  • Documentation: N/A

  • Technical Information Documents: N/A

Bundles in the SLES11_NETWORK Folder

Bundles located in this folder are used to configure network-related properties such as bond devices and routing behavior.

SLES11ALL_CUST-BONDING

This bundle joins multiple network interfaces to a bond device by using an XML configuration file and a part of the AutoYaST framework ay_setup.ycp. The reliability of the bond members is monitored by the ARP ping technique. The bond members can be passed as parameters to the bundle.

The bundle checks for the existence of the /etc/sysconfig/network/ifcfg-bond0 configuration file, and executes only if this file does not exist. This protects against service interruption through unwanted reconfiguration of the network. If you need to reconfigure your bond device, ensure that you delete this configuration file first.

If the configuration file does not exist, the config_bond.sh script and the ay_setup.ycp tool are distributed to /usr/local/zac and executed afterwards.

Existing routes in addition to the default route are not considered when the network interfaces are reconfigured. Existing secondary IP addresses are lost.

The bundle name contains a customer part because it differs between particular environments regarding IP target address and bond members.

The bundle must be assigned to all cluster nodes and machines where a bond interface is configured. This means that membership in all bundle groups intended to configure cluster and high availability environments is required.

Summary

  • Components: Pacemaker, Network interfaces, routes

  • Tools: ay_setup.ycp

  • Environments: Novell Cluster Services, SLES HAE

  • Configuration Files/Paths: /etc/sysconfig/network/*

  • Documentation: N/A

  • Technical Information Documents: N/A

SLES11ALL_NOV-VNIC

In some situations it is beneficial if the IP address of a service is independent of the network attributes of the host devices (such as address ranges and net masks) so you can have maximum flexibility when those parameters change (for example, the IP address of the host device or the network mask).

This is required in a Business Continuity Cluster but can also be used in an ordinary cluster to assign IP addresses to services that are independent of the IP addresses of the cluster nodes (service mobility).

One of the means implemented by Novell Consulting to achieve this goal is to configure service IP addresses with 32-bit net masks (CIDR notation /32) bound to a virtual network interface (VNIC). If a service with this configuration migrates to a different location, only the route to the particular address changes. In addition, the service can be moved to any network segment if the route to the device hosting the service can be propagated.

Route propagation requires a dynamic routing protocol such as OSPF. Host servers and cluster nodes using this approach need to be configured as routers within a particular OSPF area.

The intention of this bundle is to implement the virtual network interface on the target machines. The virtual device name is VNIC.

The bundle contains several files to distribute to the target devices:

  • hwcfg-static-0 contains information about the dummy module and its options. It is distributed to /etc/sysconfig/hardware.

  • boot.local loads the dummy driver and ensures that the virtual device is named VNIC. It is distributed to /etc/init.d.

  • ifup-VNIC ensures that IP addresses bound to VNIC will persist a network restart. It is distributed to /etc/sysconfig/network/scripts.

  • ifcfg-VNIC configures the required network attributes (startmode, MTU, …) for the virtual device. It is distributed to /etc/sysconfig/network.

A post-installation script configures a link from /etc/sysconfig/network/scripts/ifup-VNIC to /etc/sysconfig/network/ifdown-VNIC.

A reboot is necessary to activate the virtual device.

The bundle must be assigned to all bundle groups configuring hosts of services that use virtual IP.

Summary

  • Components: Quagga, zebra, ospfd, VNIC

  • Tools: modprobe

  • Environments: Novell Cluster Services, SLES HAE

  • Configuration Files/Paths: /etc/sysconfig/network/*, /etc/init.d/boot.local

  • Documentation: N/A

  • Technical Information Documents: N/A

SLES11ALL_CUST-QUAGGA

The bundle configures OSPF routing via the zebra daemon. OSPF routing can be used for the automatic propagation of cluster resource IP addresses after a service using virtualIP has moved to a different node.

Template files for /etc/quagga/ospfd.conf and /etc/quagga/zebra.conf are distributed to the target devices. A post-installation script replaces server names and network addresses within the templates and starts and enables (chkconfig) the relevant zebra and ospfd daemons via their respective init scripts.

The bundle name contains a customer part because environments differ with respect to the OSPF ID, OSPF passwords, and other OSPF information.

The bundle must be a member of all bundle groups assigned to hosts that provide services using virtual IP.

Summary

  • Components: Quagga, zebra, ospfd, VNIC

  • Tools: chkconfig

  • Environments: Novell Cluster Services, SLES HAE

  • Configuration Files/Paths: /etc/sysconfig/network/*

  • Documentation: N/A

  • Technical Information Documents: N/A

Bundles in the SLES11-STORAGE Folder

Bundles located in this folder have the purpose to configure properties of HBA hardware, volume management, or multi-pathing.

SLES11ALL_NOV-LVM-CONF

LVM (Logical Volume Management), which is the standard logical volume management system on Linux, is used to manage local and shared devices and also configures clvm, which manages cluster-enabled POSIX file systems.

The lvm.conf file is distributed to target devices in the /etc/lvm path .

This bundle is required by all devices that use LVM to manage storage systems and must be a member of all bundle groups assigned to such devices.

Summary

  • Components: lvm, clvm, Novell Cluster Services, Pacemaker (pure SLES)

  • Tools: N/A

  • Environments: Novell Cluster Services, Pacemaker

  • Configuration Files/Paths: /etc/lvm.conf

  • Documentation: N/A

  • Technical Information Documents: N/A

SLES11ALL_CUST-MULTIPATH-CONF

A multipath configuration file has settings for different storage systems. They may come from the same vendor or different vendors. Settings like path access, location of the bindings file, policies, behavior on errors, and blacklisted devices must be configured for an optimal storage access. All of these settings are configured by /etc/multipath.conf on SLES 11. Novell Consulting typically uses a single multipath.conf file that holds the settings for all storage systems in an environment.

The multipath.conf file is distributed by this bundle and the multipath daemon is reconfigured by issuing the mulktipathd -k'reconfigure' command.

The bundle must be assigned to all OES 11 and SLES 11 machines with SAN attached storage, so it needs to go to all bundle groups that configure these device groups, such as OES11ALL-PROD-duscl01-GRP.

Summary

  • Components: HAE (Pacemaker), Novell Cluster Services, multipath

  • Tools: N/A

  • Environments: All systems with SAN attached storage devices

  • Configuration Files/Paths: /etc/multipath.conf

  • Documentation: N/A

  • Technical Information Documents: N/A

SLES11ALL_CUST-BINDINGS-xxx

A bindings file is specific for the nodes of a certain cluster or for a stand-alone server with SAN attached storage devices. It contains a table that assigns alias names to world-wide IDs presented by the MPIO module that retrieves them from the target storage system.

Bindings is a file that is distributed through a file bundle to the /etc/multipath directory.

By default the multi-path daemon places this file in /var/lib/multipath. However, if /var is in a separate partition and the partition has not finished mounting when the multipath daemon loads, the file will not be available for the daemon.

To avoid this kind of problem the bindings file must be stored in the root partition of the file system. Novell Consulting has chosen the /etc/multipath directory for this purpose.

The xxx in the heading must be replaced by an identifier that describes the environment of the target devices (that is, a cluster identifier). A name that is with the naming standard is OES11ALL_<CUST>-BINDINGS-duscl01.

This bundle must be a member of the bundle group assigned to the device group representing all nodes of the corresponding cluster, such as OES11ALL-PROD-duscl01-GRP in this example.

Summary

  • Components: Pacemaker, Novell Cluster Services, multipath

  • Tools: N/A

  • Environments: Novell Cluster Services, SLES HAE

  • Configuration Files/Paths: /etc/multipath/bindings

  • Documentation: N/A

  • Technical Information Documents: N/A