 |
» |
|
|
|
You can use Distributed Systems Administration Utilities (DSAU)
tools to send files and commands to designated systems in your cluster
or network. The DSAU tools provide the following: Configuration
synchronization
With configuration synchronization, you can have confidence
that systems in your cluster or network are maintained to a standard
you adopt. As you make changes on your configuration master, those
changes are propagated to all your client systems. With consolidated logging, you can examine a single log that
contains entries from all systems in your configuration, in order
of their time stamps, so you can find a specific entry easily. With command fanout, you can send the same command from one designated
system to all the systems in your defined configuration. This eliminates
visiting all systems in the configuration and many manual operations. Introduction
to Configuration Synchronization | |
Managing the configuration and configuration drift of a set
of distributed systems is a constant challenge for system administrators.
There are a variety of tools available to help manage various aspects
of multi-system configuration management. For example, for account
management, standard solutions include the Network Information System
(NIS) and Lightweight Directory Access Protocol (LDAP). For file
level synchronization, tools like rdist ( see the rdist(1) manpage) and rsync are available. HP’s System Insight Manager helps
to discover, monitor and manage groups of systems. A
new tool in this toolkit is Configuration Engine (cfengine). cfengine is a popular open source tool for configuration synchronization.
It allows policy-based or goal-based configuration management that
allows the administrator to define the management actions to be
applied to groups of systems so those systems reach a desired state. cfengine is a client/server based tool. A central configuration
master system or policy server hosts a configuration policy file
which defines the management actions to be performed on each managed
client. The configuration master also hosts the “golden
image” files, or reference copies of files that should
be distributed to the clients. The administrator can use cfengine
to perform tasks such as: Ensure that
client systems are using a correct set of configuration files by
copying over reference files or directories. Disable inappropriately configured
files on the client. Check file permissions, ownership,
and track checksum changes. Execute specified shell commands
on each client. Check for processes or signal
processes. Check for specific filesystem
mounts.
A
Configuration Synchronization Wizard (csync_wizard) is available to help the administrator quickly configure cfengine for managing a set of distributed systems or configuring
it as a highly available service in a Serviceguard cluster. The administrator starts by defining a central system or Serviceguard cluster
to act as the master configuration server or policy server. The Configuration
Synchronization Wizard (csync_wizard) is a user-friendly front-end to the initial configuration
process. This central system will house the master policy files
(for example, cfagent.conf) which define the desired configuration policies, and
also reference copies or master copies of files that should be distributed
to the managed clients. Each managed client copies down the master copies of the policy
files from the central configuration server and evaluates its current
state versus the desired state defined by the policy file. Any differences
cause configurations rules to run in order to resynchronize the
client. The administrator can initiate synchronization operations
on the managed clients in two ways, using either a push or a pull
operation. Using
the cfrun command (see the cfrun(1) manpage for more information)
from the master configuration server, the administrator can push
changes. cfrun reads the file cfrun.hosts to determine the list of managed clients. It then invokes
the cfagent command on each managed client to perform a synchronization
run. Thus, push operations are really requests to the managed clients
to perform an immediate pull. Pull operations are performed
using cron or cfengine’s own cron-like cfexecd daemon. Either technique invokes the cfagent command at fixed intervals in order to perform client-initiated
configuration synchronization. The administrator defines what interval
is appropriate for each group of managed clients. For example, every five
minutes, once an hour, or once a day. The administrator can also invoke
cfagent directly for on-demand synchronization runs.
cfengine
Daemons and Commandscfengine employs several daemons and commands to perform configuration
synchronization operations. The following list describes the primary cfengine components. cfagent -- the cfagent command is cfengine’s workhorse. It runs on each
managed client, and bootstraps itself using the file update.conf, which describes the set of files to transfer from the master
server to the local managed client. The files transferred include
the main policy file, cfagent.conf, and any related policy files. In the DSAU implementation, cfagent.conf imports the file cf.main which has examples of many cfengine features. After the configuration files are transferred, cfagent evaluates the configuration instructions in these files.
If the client system’s current configuration deviates from
the desired configuration, cfagent executes the defined actions to return the client to
the proper state. cfservd -- cfservd daemon has two roles:
cfservd runs on the master configuration server and is the clearinghouse
for file transfer requests from the managed clients. cfagent on the managed clients contacts the master server’s cfservd and requests copies of the master policy files, and copies of
any reference files that are needed as part of the defined configuration
synchronization operations. The master cfservd is responsible for authenticating remote clients using
a public/private key exchange mechanism and optionally encrypting
the files that are transferred to the managed clients. cfservd can optionally run on each managed client in order to process
cfrun requests. cfrun allows the administrator to push changes to
the managed clients instead of waiting for the clients to synchronize
using some client-defined time interval. The cfrun command must be initiated from the master configuration server.
It contacts each managed client listed in the cfrun.hosts files and connects to the managed client’s cfservd
asking it to invoke cfagent to perform the synchronization work. cfservd is configured using cfservd.conf and started using /sbin/init.d/cfservd.
cfexecd -- cfexecd is a scheduling and reporting tool. If the administrator
uses cron to perform synchronization runs at fixed intervals, cfexecd
is the command placed in to the crontab file in order to wrap the invocation of cfagent. It stores the output of the cfagent run in the outputs directory (see cfagent.conf for details) and optionally sends email. cfexecd has it’s own cron-like features based on cfengine’s time classes. The administrator can choose
to run cfexed in daemon mode and use it to invoke cfagent at defined
intervals instead of cron. The default is to invoke cfagent every
hour. When getting started with cfengine, it is simplest to start out using cron. cfrun -- the cfrun command contacts the managed clients asking each to perform
an immediate synchronization run. Specifically, it connects to the
optional cfservd on each managed client which in turn launches cfagent.
Figure 3-1 “cfengine Overview” illustrates
the relationship of the cfengine commands and daemons, and shows an example of the administrator
using cfrun. The dashed lines in the diagram indicate calling sequences
(for example, A calls B). Solid lines indicate that data is being
read from configuration files. The administrator is logged into the master configuration synchronization
server and makes a change to be propagated out to the managed clients,
using the cfrun command. cfrun checks the file cfrun.hosts for the list of managed clients.
Note that the master server can be a client of itself. In this diagram,
there are two clients, the master server and a remote client. cfrun contacts cfservd on each managed client, which in turn invokes cfagent. cfagent first checks the master server for an updated copy of update.conf file and transfers it to the client if needed. If a standalone system is the master server, by default the
master copy of update.conf is located in /var/opt/dsau/cfengine_master/inputs/. The master copies of other configuration files such
as cfagent.conf, cfservd.conf, and cfrun.hosts are also located here. If the master server is a Serviceguard
cluster, the master configuration files are located in the mount
point associated with the package. For example, if this mount point
is named csync, the path would be /csync/dsau/cfengine_master/inputs. When copying the configuration files to the local
system, cfagent places them in /var/opt/dsau/cfengine/inputs for both standalone systems and clusters. cfagent first evaluates the contents of update.conf in order to update any changed cfengine binaries (if any) and gets the latest version of the
policy files (cfagent.conf and related files. cfagent then evaluates cfagent.conf to determine the client is in the desired state. If
there are deltas, cfagent performs the defined actions to correct the clients configuration.
cfengine
Master Server Deployment ModelsThe cfengine master server can be a standalone HP-UX system servicing
groups of distributed clients. The clients can themselves be standalone
systems or members of a Serviceguard cluster. If you are already
using a Systems Insight Manager central management server, this
can be an ideal system to use as a cfengine master server. Master servers can also act as clients
and the configuration synchronization tasks can be performed on
these systems as well as the remote clients. If you are managing Serviceguard clusters, cfengine can be
deployed strictly for intra-cluster use to synchronize the members
of a single cluster. In this configuration, cfservd is configured as a package for high availability but
the only cfengine clients are the cluster members themselves. The
package’s DNS name/IP address is the name for the cfengine master server. In addition to providing configuration synchronization as
an intra-cluster service, another Serviceguard configuration has
the cluster providing the highly available configuration synchronization
service to groups of remote client systems. Those clients can be
standalone systems or Serviceguard clusters. The cluster providing
the cfengine service can be a client of itself and also take advantage
of cfengine’s configuration synchronization features. A
possible but somewhat unusual configuration is to have a fixed member
of Serviceguard cluster act as the master server but no package is
configured so cfservd will not be highly available. This configuration
is valid but not recommended. Configuring
cfengine | |
The following sections
provide detailed instructions for setting up a configuration synchronization
master server and its clients. The quickest way to get started is
to use the Configuration Synchronization Wizard (csync_wizard), described below. Completely manual configurations are also
described. Using the
Configuration Synchronization WizardThe csync_wizard (see csync_wizard(1)) automates the task of setting
a configuration synchronization master server and its managed clients.
It supports setting up a standalone system or a Serviceguard cluster
as the master server. The wizard configures all managed clients
to run a cfservd so that cfrun (see cfrun(8)) can be used on the master
server. See the appropriate sections below for details. Using
the Wizard to Configure a Standalone Synchronization ServerTo configure a synchronization server for a standalone
system, run the csync_wizard(1) on the standalone system
you wish to configure as the master synchronization server: # /opt/dsau/sbin/csync_wizard The wizard displays the following introductory screen: |
Querying the system <local hostname> for current status, one moment...
This Configuration Synchronization Wizard helps you set up the Configuration
Engine (cfengine) environment. Cfengine is a powerful tool for performing
policy-based management for groups of systems and cluster environments.
It is a client/server based utility. A standalone system or Serviceguard
cluster can be configured as the cfengine ‘master’. The master contains
the configuration description and configuration files that will be used by
all the clients. Clients copy the configuration description from the master
and apply it to themselves. The configuration description supports a rich set
of management actions such as copying configuration files from the master to
the client, performing edits to files, checking file ownerships, permissions,
and checksums, executing shell commands, checking for processes, etc.
For a detailed description of the cfengine management actions, please refer to
cfengine man page.
This wizard will help you set up this system as a cfengine master or to add or
remove a cfengine client, and to perform the required security setup.
Press ‘Return’ to continue...
|
|
Press return to continue and choose item 1 from the menu below
to configure a master server: Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Key management for cfengine users
(9) Exit
Enter choice: 1
The cfengine master server is being configured on:
<local hostname>
|
The wizard then asks if you would like to additionally configure
managed clients immediately after configuring the server. For this
example, answer no. Managed clients will be added later. You can optionally specify additional remote clients to manage at this time.
If you are running in an HA environment, you do not need to specify the
cluster members.
Would you like to manage clients? [N]: n |
The wizard proceeds to configure the system as a master server: ******* WARNING!!!! ********
To protect against possible corruption of sensitive configuration files,
control-c has been disabled for the remainder of this configuration.
Configuration of the cfengine master server is starting.
Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
Starting cfengine on the master and any pertinent client machines. This may
take a few minutes....
|
When the configuration is completed, the wizard displays the
following summary screens which direct the administrator to the
main policy file, /var/opt/dsau/cfengine_master/inputs/cf.main,
and the recorded answer file for this run of the wizard. |
The Configuration Synchronization Wizard has completed the configuration of cfengine:
- The master configuration description template is here:
</var/opt/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration synchronization
actions performed in cfengine. For example, synchronizing critical files such
as /etc/hosts, package scripts, etc.
All the actions in the template are disabled by default (commented out).
Uncomment the lines corresponding to the desired synchronization actions for
this configuration. See the cfengine reference documentation for a description
of additional cfengine features: /opt/dsau/doc/cfengine/
Press ‘Return’ to continue...
The cfengine environment has been created with Master Host: <local hostname>
and members:
|
Note that when configuring a master server but not adding
any managed clients during the server configuration, the members
(list of managed clients), will be empty as shown in the above example. A file recording the answers for this run of the Configuration Synchronization
Wizard is stored here...
/var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
This configuration can be reestablished by issuing the command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt |
Using the
Wizard to Configure a Serviceguard Cluster Synchronization ServerTo configure a synchronization server for a Serviceguard cluster,
there are two configuration choices: Create a Serviceguard
package for the configuration service to ensure high availability. Configure a single member
of the cluster as if it is a standalone system. The configuration
synchronization service will not be highly available, and this configuration
will also not work properly with the Serviceguard automation features
discussed in the section on Serviceguard Automation features and
is not recommended.
This section will focus on using the wizard to configure a
highly available configuration synchronization service. | | | |  | NOTE: Make sure that this cluster’s MAX_CONFIGURED_PACKAGES
value can accommodate the additional package. For more information
on this setting, please refer to the Managing Serviceguard manual
that is part of the Serviceguard documentation set. Also, before
starting the wizard, all the current cluster members should up and
running in the cluster. | | | | |
Start by running the Configuration Synchronization Wizard, csync_wizard(1): |
# /opt/dsau/sbin/csync_wizard
Querying the system <local hostname> for current status, one moment...
This Configuration Synchronization Wizard helps you set up the Configuration
Engine (cfengine) environment. Cfengine is a powerful tool for performing
policy-based management for groups of systems and cluster environments.
It is a client/server based utility. A standalone system or Serviceguard cluster
can be configured as the cfengine ‘master’. The master contains the configuration
description and configuration files that will be used by all the clients. Clients
copy the configuration description from the master and apply it to themselves.
The configuration description supports a rich set of management actions such as
copying configuration files from the master to the client, performing edits to
files, checking file ownerships, permissions, and checksums, executing shell
commands, checking for processes, etc.
For a detailed description of the cfengine management actions, please refer to
cfengine man page.
This wizard will help you set up this system as a cfengine master or to add or
remove a cfengine client, and to perform the required security setup.
Press ‘Return’ to continue...
|
|
Press return to continue and choose item 1 from the menu below
to configure a master server: Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Key management for cfengine users
(9) Exit
Enter choice: 1
|
After choosing 1 and pressing return, the wizard displays
the following text: This system is a member of a Serviceguard cluster. The cfengine configuration
will be defined as a package for high availability unless you answer no to the
below question. If you answer no, for the purposes of cfengine control, this
machine will be treated as a single machine without failover capability for
cfengine.
If you accept the default answer of ‘HA’ to the below question, cfengine will be
configured as a highly available Serviceguard package. This will ensure that your
cfengine master server is available as long as one of the cluster members that
can run the package is also available.
You will need a free IP address for this package and you need to configure
storage for the package before proceeding. For details on creating highly
available file systems, please refer to ‘Creating a Storage Infrastructure’
chapters of the Managing Serviceguard documentation.
Will this master server be Highly Available (HA) [Y]:
|
|
The wizard names the package name “csync” for
configuration synchronization. This specific package name is required.
The LVM storage configuration and network configuration for the
package must be set up before continuing or before running the wizard.
All the cluster members should also be up and available. For details,
refer to the Managing Serviceguard book,
under “Building an HA Cluster Configuration”, “Creating
a Storage Infrastructure with LVM.” | | | | | NOTE: The wizard only supports creating packages based on
LVM volume groups. When using CFS or VxVM, manual configuration
is required. See the section on manually configuring a Serviceguard
cluster for details on manually configuring the csync package. | | | | |
The wizard prompts for the following, all of which should
have already been configured: LVM volume
group name (for example, vgcsync) Logical volume in the volume
group (for example, /dev/vgcsync/lvol1) The mount point of the filesystem
(for example, /csync) The mount options of the
filesystem (for example, -o rw,largefiles).
The mount options are used verbatim in the Service package control
script’s FS_MOUNT_OPT[0] field. Note that the mount options
must agree with the filesystem you created on the logical volume.
For example, if the filesystem was created with largefiles support,
the largefiles mount option should be specified. The filesystem type (for
example, VxFS) The package IP address. This
should also be a registered DNS name so the configuration synchronization
is easy to configure on client systems. The package subnet. Use
netstat -i to determine the proper subnet.
Once the storage infrastructure is configured and the IP address obtained,
press return to access the default answer of ‘yes’ and
proceed with creating the package. The wizard now prompts for the
package information: Configuring the csync Serviceguard package for a highly available cfengine
master.
The cfengine master server is being configured as a HA Serviceguard Package on
this cluster.
Please provide the following information for the package:
Enter the Volume group? []: vgcsync
You need to enter a fully qualified Logical Volume, for example:
/dev/vgname/lvol1
Enter the fully qualified Logical Volume? []:
/dev/vgcsync/lvol1
Enter the Filesystem (Mount Point)? []: /csync
Enter the Mount Options? [-o rw,largefiles]:<return>
Enter the Filesystem Type? [vxfs]: <return>
Enter the IP address? []: 12.345.6.78
Enter the Subnet? []: 12.345.7.8 |
|
The wizard now asks if you would like to manage additional
remote clients, that is, systems outside the cluster. The wizard
automatically configures the current members of the cluster. This
is why all members must be up and accessible when running the wizard.
In the example shown below, the administrator chose ‘no’ so
only cluster members are configured as clients initially. Note that additional remote clients can easily be added later
using the wizard. It is not necessary to use the wizard to add new
clients when additional members are added to the cluster. Refer
to the section on Serviceguard Automation features for details. You can optionally specify additional remote clients to manage at this time. If
you are running in an HA environment, you do not need to specify the cluster
members.
Would you like to manage clients? [N]: <return>
|
The wizard now has all the data it needs to configure the
cluster and proceeds to do so: ******* WARNING!!!! ********
To protect against possible corruption of sensitive configuration files,
control-c has been disabled for the remainder of this configuration.
Configuring the ‘csync’ Serviceguard package.
Applying the ‘csync’ Serviceguard package configuration file, this will take a
moment.
Starting the ‘csync’ Serviceguard package, this will take a few moments...
The ‘csync’ Serviceguard package has been started on <local hostname>.
Configuration of the cfengine master server is starting.
Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
Starting cfengine on the master and any pertinent client machines.
This may take a few minutes....
|
|
When the configuration is done, the wizard displays the following summary
screens which direct the administrator to the main policy file, mount_point/cfengine_master/inputs/cf.main, and the recorded answer file for this run of the wizard.
Note that the policy file is located on the newly configured filesystem
associated with the package. In our example, the administrator chose
to mount the filesystem for the package as /csync.If
the administrator had previously configured cfengine, before overwriting any existing configuration files,
the wizard creates backups in the directory: /var/opt/dsau/cfengine/backups
|
The top level files in this directory are the most recent
backup files. Any configurations before that are saved in timestamped
subdirectories named v_timestamp. |
The Configuration Synchronization Wizard has completed the configuration of
cfengine:
- The master configuration description template is here:
</csync/dsau/cfengine_master/inputs/cf.main>
This default template has examples of typical configuration synchronization
actions performed in a cluster. For example, synchronizing critical files such as
/etc/hosts, package scripts, etc.
All the actions in the template are disabled by default (commented out).
Uncomment the lines corresponding to the desired synchronization actions for this
cluster. See the cfengine reference documentation for a description of additional
cfengine features: /opt/dsau/doc/cfengine/
Press ‘Return’ to continue...
The cfengine environment has been created with Master Host: <package hostname>
and members: <cluster member1>, <cluster member2>, ...
A file recording the answers for this run of the Configuration Synchronization
Wizard is stored here...
/var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
This configuration can be reestablished by issuing the command:
/opt/dsau/sbin/csync_wizard \
-f /var/opt/dsau/cfengine/tmpdir/csync_wizard_input.txt
|
|
Cluster
Configuration NotesThis section describes the details of a high availability
configuration of cfengine in a Serviceguard cluster. For more information on the
role of the various cfengine daemons and commands, refer to“cfengine
Daemons and Commands”. The Serviceguard package ensures that
cfengine’s cfservd daemon remains highly available. The cfengine configuration files update.conf and cfagent.conf define the master configuration synchronization server
to be the registered DNS name for the relocatable IP address of the
package. When managed clients run cfagent (see cfagent(8)), cfagent connects to cfservd on the package’s adoptive node. Thus the cluster
members themselves are all managed clients. The member hosting the
package additionally acts as the master server for the policy files. When booting the cluster, each member will start a client cfservd. This is the cfservd that responds to cfrun requests. When the package starts on a member, that cfservd now has access to the filesystem of the package and becomes
the master cfservd that serves the policy files to all managed clients.
This cfservd is monitored by the package. If cfservd fails, the package will attempt to restart on another
member. That member’s cfservd will then become the master cfservd. Note that halting the package does not stop the cfservd daemon on the adoptive member since the expectation is
that the daemon is present to respond to future cfrun requests. Also, unlike some other HA services, if the csync package is down or unavailable, remote clients are not adversely
impacted. The clients continue to run with their currently defined
configurations. The administrator would need to make sure the package
is up and running in order to distribute any new configuration instructions
to the managed clients. The wizard automates cfengine key distribution to all cluster members. For a detailed
description of key distribution steps performed, refer to “Security
Notes”. Serviceguard
Automation FeaturesThe Distributed Systems Administration Utilities require Serviceguard
11.17 or later. With Serviceguard 11.17 or later, when members are
added to or deleted from the cluster the configuration synchronization
tools will automatically take the appropriate configuration actions.
Specifically: When
adding a member to the cluster, the new member will be automatically
configured to participate in configuration synchronization. The
following configuration actions occur automatically on the added
member: etc/rc.config.d/cfservd is changed to set CSYNC_CONFIGURED to 1 The appropriate cfengine public/private keys are created for the new member and
placed in the members /var/opt/dsau/cfengine/ppkeys directory. The new keys for this member are also distributed
to the /var/opt/dsau/cfengine/ppkeys directories on the other cluster members. The new member’s
/var/opt/dsau/cfengine/inputs directory is populated. cfservd is started on the new member. The package files are copied
to /etc/cmcluster/csync/ on the new member. A cfagent synchronization run is performed on the master to populate
the master’s /var/opt/dsau/cfengine/inputs directory. A cfagent synchronization run is performed on the remote client.
When deleting a member from a cluster, the public
key of the deleted member is deleted from the /var/opt/dsau/cfengine/ppkeys directory clusterwide.
Note that the administrator can define cfengine groups or classes that enumerate all the members of a
particular Serviceguard cluster. These class definitions will not
be updated automatically and the administrator must manually update
the cfagent.conf and related files for cluster membership changes. Configuring
a Synchronization ClientYou can use the Configuration
Synchronization Wizard to add managed clients to an existing cfengine
configuration. Run the wizard on the master server, not the
client system. When a Serviceguard cluster is the master server,
run the wizard on the adoptive node for the csync package.
Note that adding a new cluster member in a High Availability setup
as a client is done automatically. For more information, see the “Serviceguard
Automation Features”. Also, in order to securely distribute cfengine keys, the client
must be configured for non-interactive ssh access
by the root account of the master server. The csshsetup tool (see csshsetup(1)) makes it easy to configure ssh access
to a remote system. That tool is used in the examples below. The wizard can currently only manage clients when the clients
are in the same DNS domain as the master server. For multi-domain configurations,
refer to “Manual
Configuration ” for instructions
on adding clients manually. Note that if adding a Serviceguard cluster as a managed client,
each cluster member must be added individually. Start by logging in as root on the master server and configure ssh access to
the remote system: # csshsetup <hostname of managed client> csshsetup first tests ssh access to the
remote system. If it is not configured, ssh prompts
for the managed client’s password. Run the Configuration Synchronization Wizard and choose option
2 to add a new client: Configuration Synchronization Wizard Menu
=========================================
(1) Set up a cfengine master server
(2) Add a client
(3) Remove a client
(4) Key management for cfengine users
(9) Exit
Enter choice: 2
|
When prompted, enter the name of the client to add: This option will configure additional clients to the cfengine domain.
Enter the name of the client to add: <new client>
|
The wizard then proceeds to configure the client and report
on its progress: Verifying the master has an entry in the /etc/hosts file on each client...
Keys are being created...
Keys have been created, now distributing....
The client <new client> has been added to the cfengine domain
|
The wizard configures each new client to run cfservd so it
can respond to cfrun requests and adds the client to master’s cfrun.hosts file. The following sections describe the steps required to manually
configure cfengine master configuration synchronization servers or managed clients.
Note that it typically easier to start by using the csync_wizard (see csync_wizard(1m)) and then modifying the
resulting configuration instead of starting from scratch. This is
especially true in a Serviceguard cluster where the wizard helps
set up the package and takes care of propagating the correct configuration
files to all members of the cluster. When performing manual configurations, it is possible to create configurations
that cannot subsequently be managed by the csync_wizard. For example, the wizard supports only single DNS domain
configurations. When manually configuring multi-domain configurations,
you cannot use the wizard to add and remove clients. | | | | | NOTE: You can use csshsetup to configure a trust relationship between the master
server and the managed clients. This will allow you to use command
fanout commands such as cexec and ccp (see cexec(1) and
ccp(1)).
Using these commands can simplify the configuration steps described
below when files need to be distributed to managed clients. | | | | |
Manually
Configuring a Standalone Synchronization ServerPerform the following one-time steps to configure a standalone
system as a cfengine master server: Start by creating the master copies
of the cfengine configuration files. These files are placed in a well
known directory and are distributed to each managed client. The
default directory is /var/opt/dsau/cfengine_master/inputs, referenced in the default templates. Start by creating
the directory: # mkdir -p /var/opt/dsau/cfengine_master/inputs Copy the default templates files to the following
directories: # cd /var/opt/dsau/cfengine_master/inputs
# cp /opt/dsau/share/cfengine/templates/cf.main.template cf.main
# cp /opt/dsau/share/cfengine/templates/update.conf.template update.conf
# cp /opt/dsau/share/cfengine/templates/cfagent.conf.template cfagent.conf
# cp /opt/dsau/share/cfengine/templates/cfrun.hosts.template cfrun.hosts
# cp /opt/dsau/share/cfengine/templates/cfservd.conf.template cfservd.conf
|
Next, edit update.conf. This file has a format similar to cfengine’s main configuration file cfagent.conf. It is used to transfer and update cfengine binaries and any updated configuration definitions files
(for example, cfagent.conf) to the managed clients. It is critical to keep this
file very simple and avoid errors. Errors in this file will require
manually copying a new version to each managed client. The file contains tokens in the form <%token nam%> that are replaced by the csync_wizard with the administrator’s answers to questions.
Replace the tokens as follows: Replace
<%HOST_NAMER%> with the unqualified hostname of the master server. Replace <%DOMAIN_NAMER%> with the master server’s domain name.
For example: host_name = ( “master-server-name” )
domain_name = ( “abc.xyz.com” ) |
Note that this update.conf template assumes that the master server and its clients
are all in a single DNS domain. If your master server will have
managed clients in multiple DNS domains, change update.conf as follows: Replace <%HOST_NAMER%> with the fully qualified hostname of the master
server.. Delete the <domain_name> variable. Replace the line “domain = ( “${domain_name}” )” with the following: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) )
|
This sets the domain variable appropriately on the client
side. Note that this technique assumes /etc/resolv.conf is properly configured on each managed client. These same domain edits must also be performed in cf.main and cfservd.conf as well. See the next steps. Use cfagent -p (or --parse-only) flag to verify the syntax of update.conf.
Distribute the master update.conf to each managed client. This step is described in “Configuring
a Synchronization Managed Client”. Create the master server’s security keys. cfengine uses a public/private key exchange to authenticate remote
clients. A public/private key pair is generated on the master server
and all managed clients. The public key for each managed client
is copied to the master server and from the master server to the
managed clients. It is important to exchange keys securely using
a tool like secure copy, (see scp(1)) or using tape or CD-ROM.
Start by generating the keys for the master server: # /opt/dsau/sbin/cfkey
# cd /var/opt/cfengine/ppkeys
This creates the files localhost.pub and localhost.priv. Copy the public key to root-master server IP address.pub. For example, assuming this system’s IP address
is 10.0.0.5, use this command: # cp localhost.pub root-10.0.0.5.pub
See “Configuring
a Synchronization Managed Client” for details
on copying the client keys to this master server. On the master server, configure
the cfservd daemon to start at system startup. Edit /etc/rc.config.d/cfservd and change the line CSYNC_CONFIGURED=0 to CSYNC_CONFIGURED=1. Optionally, if you want to be able to push changes
out to the managed clients using cfrun, replicate this change to all the managed clients. cfrun requires that the managed clients be listed in the file
cfrun.hosts. In the default configuration, this file is located
in /var/opt/dsau/cfengine_master/inputs. Edit it and add the hostnames of each managed client,
one per line. It is simplest to make sure that all the host names
are fully qualified. When using fully qualified hostnames, the “domain =” line is not required and can be deleted.
If using unqualified hostnames find the line
“
domain = <%DOMAIN_NAMER%>” and replace the token with the DNS domain
of the client systems. This restricts all the clients to be members
of that single domain. The file /var/opt/dsau/cfengine_master/inputs/cfagent.conf is the master policy file. The default cfagent.conf includes the default template cf.main which is a commented
template file with examples of common synchronization actions for
both standalone systems and Serviceguard clusters. cf.main contains the same <%HOST_NAMER%> and <%DOMAIN_NAMER%> tokens as those in update.conf. Perform the same edits described in Step 3 above. Note that this default cf.main file performs no management actions. All the action
lines are commented out. This is a starting point for creating a
custom set of cfengine policies and actions for your managed clients. The cfengine reference manual that documents the syntax and all the
management actions defined in this file is located in /opt/dsau/doc/cfengine. Other example cfengine configuration files which are included with the open
source cfengine distribution are located in /opt/dsau/share/cfengine/examples. The file /var/opt/dsau/cfengine_master/inputs/cfservd.conf controls which managed clients have access to the files
served by cfservd on the master. Perform the following edits to cfservd.conf. Delete the following line entirely: domain_name = ( “<%DOMAIN_NAMER%>” )
Change the line reading domain = ( “${domain_name}” )
to the following: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) )
The “admit:” stanza controls which remote clients
have access to files on the server. Change each “*.${domain_name}” to a space separated list of managed
client DNS domains. For example: /var/opt/dsau/cfengine_master/master_files *.abc.xyz.com *.cde.xyz.com This example allows all the hosts in the listed domains to
access files on the master server. You also can specify lists of
specific hosts, IP address ranges, etc. Please see the cfengine reference manual for additional information
On the master server, start cfservd: # /sbin/init.d/cfservd start This is repeated for each managed client. Test the configuration by performing the following
steps: On a managed client, use the command: # cfagent --no-lock --verbose --no-splay The verbose output will display the client checking for updated copies
of the master policy files, copying them down to /var/opt/cfengine/inputs if needed, and then executing the contents of cfagent.conf/cf.main. On the master server, test the cfrun command: # cfrun -- --inform The --inform syntax instructs the remote cfagent to use the --inform flag which will
produce messages for all changes cfengine performs on the system. For additional information, the --verbose can
also be helpful: # cfrun -v -- --verbose The -v instructs cfrun itself to be more verbose and the --verbose is
passed on to the remote cfagent.
For additional troubleshooting information, refer to “cfengine
Troubleshooting”.
Manually
Configuring a Serviceguard Cluster Synchronization ServerConfiguring cfengine for high availability in a Serviceguard cluster is similar
to configuring it for a standalone machine, which is described in
section “Using
the Wizard to Configure a Standalone Synchronization Server”. The
primary differences are the creation of the Serviceguard package
and the mechanism used to distribute cfengine’s security
keys. Follow all the steps described below. Initial Serviceguard
Package Preparation Start
by obtaining an IP address for the package. This address is typically
registered in DNS to simplify management of remote clients. If you
are using cfengine for intra-cluster use only, it is sufficient
to make sure the address is added to each member’s /etc/hosts file. Next, create the storage infrastructure required
for a new package. The instructions for doing this are documented
in the Managing Serviceguard book, under “Building
an HA Cluster Configuration”, “Creating a Storage Infrastructure.” For example.
if using an LVM storage infrastructure, that would include the following
steps: Create
the LVM volume group (VG) and logical volumes (LV) (for example,
/dev/vgcsync/lvol1). Exporting/importing the VG
cluster-wide. Setting up a filesystem on
the LV. Creating the the filesystem’s
mount point (for example, /csync) cluster-wide.
The default templates assume you are using LVM-based storage. To
use VxVM or other cluster-wide storage and filesystems, make the
appropriate changes to the package templates described below. Make sure the filesystem for the package is mounted
on the current member. For example, if using LVM do the following: # vgchange -a e /dev/vgcsync
# mount -o rw,largefiles /dev/vgcsync/lvol1 /csync
Initial Policy File Customization Create a subdirectory for the master
policy files and reference files. For example: # mkdir -p /csync/dsau/cfengine_master/master_files These example directories are those used by the csync_wizard. Copy the default templates into the master inputs
directory: # cd /csync/dsau/cfengine_master/inputs |
# cp /opt/dsau/share/cfengine/templates/cf.main.template cf.main |
# cp /opt/dsau/share/cfengine/templates/update.conf.template update.conf |
# cp /opt/dsau/share/cfengine/templates/cfagent.conf.template cfagent.conf |
# cp /opt/dsau/share/cfengine/templates/cfrun.hosts.template cfrun.hosts |
# cp /opt/dsau/share/cfengine/templates/cfservd.conf.template cfservd.conf
|
Edit update.conf. This file has a format similar to cfengine’s main configuration file cfagent.conf. It is used to transfer and update cfengine binaries
and any updated configuration definitions files (for example,
cfagent.conf) to the managed clients. It is critical to keep this
file very simple and avoid errors. Errors in this file will require
manually copying a new version to each managed client.
The
file contains tokens in the form <%token name%> which are replaced by the csync_wizard with the administrator’s answers to questions.
Replace the tokens as follows: Replace <%HOST_NAMER%> with
the unqualified hostname of the Serviceguard package. Replace <%DOMAIN_NAMER%> with
the package’s DNS domain name. For example: host_name = ( “package-hostname”)
domain_name = ( “abc.xyz.com”) |
Note that this update.conf template assumes that the master server and its clients
are all in a single DNS domain. If your master server will have
managed clients in multiple DNS domains, change update.conf as follows: Replace <%HOST_NAMER%> with
the fully qualified hostname of the Serviceguard package. Delete the “domain_name” variable. Replace the line domain = ( “${domain_name}” ) with the following: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) ) |
This sets the domain variable appropriately on the client-side.
These same domain edits must also be performed in cf.main and cfservd.conf as well. See below. Use cfagent’s -p (--parse-only) flag to verify the syntax of update.conf.
List Managed Clients in
cfrun.hosts cfrun requires that all managed clients be listed in the file cfrun.hosts. Since each cluster member is considered a client, make
sure each member is listed in /csync/dsau/cfengine_master/inputs/cfrun.hosts. Edit it and add the hostnames of each member, one per line.
It is simplest to make sure that all the host names are fully qualified. When
using fully qualified hostnames, the “domain = line” is not required and can be deleted. If
using unqualified hostnames, find the line “domain = <%DOMAIN_NAMER%>” and replace the token with the DNS domain
of the cluster members. This restricts all the clients to be members
of that single domain.
Edit the Master Policy File The file /var/opt/dsau/cfengine_master/inputs/cfagent.conf is the master policy file. The default cfagent.conf includes the default template cf.main which is a commented template file with examples of
common synchronization actions for both standalone systems and Serviceguard
clusters. Edit cf.main to replace the following tokens: cf.main contains the same <%HOST_NAMER%> and <%DOMAIN_NAMER%> tokens as update.conf. Perform the same edits described in item 3 in the previous
bulleted item, “Initial Policy File Customization.” Note that this default template performs no management actions.
All the action lines are commented out. It does contain many examples specific
to synchronizing files in a Serviceguard cluster. This is a starting
point for creating a custom set of cfengine policies and actions for your cluster and other managed
clients. The cfengine reference manual which documents the syntax and all the
possible management actions defined in this file is located in /opt/dsau/doc/cfengine/. Other example cfengine configuration files which are included
with the open source cfengine distribution are located in /opt/dsau/share/cfengine/examples. Edit the cfservd.conf File The file /var/opt/dsau/cfengine_master/inputs/cfservd.conf controls which managed clients have access to the files
served by cfservd on the master. Perform the following edits to cfservd.conf. Delete the following line entirely: domain_name = ( “<%DOMAIN_NAMER%>” ) Change the line reading domain = ( “${domain_name}” ) to the following: domain = ( ExecResult(/sbin/awk ‘/domain/ {print $2}’ /etc/resolv.conf) ) The “admit:” stanza controls which remote clients
have access to files on the server. Change each “*.${domain_name}” to a space separated list of managed
client DNS domains. For example: /var/opt/dsau/cfengine_master/master_files *.abc.xyz.com *.cde.xyz.com This example allows all the hosts in the listed domains to
access files on the master server. You also can specify lists of
specific hosts, IP address ranges, etc. Please see the cfengine reference manual for additional information.
Distribute the Master update.conf to Each Cluster Member Use the following commands: # cd /var/opt/dsau/cfengine/master_files/inputs # ccp update.conf /var/opt/dsau/cfengine/inputs/ cfengine itself will take care of distributing the remaining files cluster-wide
and to all managed clients.
Distribute the cfengine
Security Keys Since cfengine uses a public/private key exchange model to validate the
authenticity of managed clients, a key must be configured that is associated
with the relocatable IP address of the package. That address is
the one that remote clients see as the master server. Since any
cluster member can become the adoptive node, this key must be identical
across all cluster members. cfengine’s cfkey generates a public/private key pair
for the current system. cfkey creates the files localhost.priv and localhost.pub. cfengine expects keys to be named using the following convention: username-IP address.pub For example: root-10.0.0.3.pub The administrator copies the localhost.pub key to the correct
name based on the system’s IP address. For the case of
a cluster, the keys for the current member are used to generate
the keys cluster-wide using the following steps: Use cfkey to create the public and private key pair for this cluster
member: # mkdir -p /var/opt/dsau/cfengine/ppkeys
# cd /var/opt/dsau/cfengine/ppkeys
# /opt/dsau/sbin/cfkey |
This will create keys named localhost.priv and localhost.pub. The public key, localhost.pub is then copied to root-package IP address.pub. For example, # cp localhost.pub root-10.116.9.74.pub |
where 10.116.9.74 is the relocatable IP address of the csync package. This member’s localhost.pub is then used to create the member-specific keys for
each member: # cp localhost.pub root-<member1 IP address>.pub
# cp localhost.pub root-<member2 IP address>.pub
# cp localhost.pub root-<member3 IP address>.pub
...
# cp localhost.pub root-<memberN IP address>.pub |
Finally, all the keys are copied to each member. # ccp * /var/opt/dsau/cfengine/ppkeys |
Note: ccp, a command-fanout command, performs a cluster copy, copying
a command to all cluster members.
Configure and start cfservd Configure the
cfservd daemon to start at system startup. Edit /etc/rc.config.d/cfservd and change the line CSYNC_CONFIGURED=0 to CSYNC_CONFIGURED=1. Propagate this change cluster-wide: # ccp /etc/rc.config.d/cfservd /etc/rc.config.d/cfservd |
On the master server, start cfservd: # /sbin/init.d/cfservd start |
Repeat for the remaining cluster members. If you
have configured for cluster for use with the DSAU command fanout tools,
use the following command to start the daemons cluster-wide: # cexec /sbin/init.d/cfservd start
|
Create the csync Package To create the configuration synchronization package, modify
the default package template files as appropriate for your Serviceguard environment.
Note that it is required that the package be called csync.
Failure to do so will cause the Serviceguard automated operations
to fail. For more information, refer to the section “Serviceguard
Automation Features” . Start by making the changes described below. Create the package directory cluster-wide: # cexec mkdir /etc/cmcluster/csync |
Copy the template package ASCII file and package
control script to the /etc/cmcluster/cysnc directory on the current member: # cd /etc/cmcluster/csync
# cp /opt/dsau/share/serviceguard/templates/csync.conf.template csync.conf
# cp /dsau/share/serviceguard/templates/csync.script.template csync
# chmod +x csync |
Edit the csync.conf package
ASCII configuration file to replace the placeholder tokens with
the appropriate values. The tokens are in the form <%token name%>. Find the line “SUBNET <%SG_PKG_SUBNET%>” and replace the token with the subnet
for the csync package. Use netstat -i to help identify the subnet. Edit the package control script, and substitute
appropriate values for the placeholder tokens. Note: The default script template assumes you are using an LVM-based
storage configuration. If you are using VxVM and/or CFS, refer to
the Managing Serviceguard documentation
for more information on configuring packages using those technologies.
You will have to comment out the LVM parts of the template described
below and substitute the appropriate VxVM or CFS stanzas. Find the
the line “VG[0]=“<%SG_PKG_VOL_GRP%>”” and replace the token with the name of
the LVM volume group for the package. For example, VG[0]“vgcsync”. Find the line “LV[0]=“<%SG_PKG_LOG_VOL%>”” and replace the token with the full name
of the logical volume. For example, LV[0]=“/dev/vgcsync/lvol1”. Find the line “FS[0]=“<%SG_PKG_FS%>”” and replace the token with the name of
the filesystem mount point created for this package. For example, FS[0]=“/csync”. Note that this mount point should have been created on each cluster
member as part of the storage configuration described above. Find the line “FS_MOUNT_OPT[0]=“<%SG_PKG_MNT_OPT%>””and replace the token with the filesystem’s
mount options. For example, FS_MOUNT_OPT[0]=“-o rw,largefiles”. Find the line “FS_TYPE[0]=“<%SG_PKG_FS_TYPE%>””and replace the token with the filesystem
type. For example, FS_TYPE[0]=“vxfs”. Find the line “FS_UMOUNT_OPT[0]=“<%SG_PKG_FS_UMOUNT_OPT%>”” and replace the token with any filesystem
umount options. The token can be removed and this option left
blank if there are no special umount options. For example,
FS_UMOUNT_OPT[0]=“”. Find the line “FS_FSCK_OPT[0]=“<%SG_PKG_FS_FSCK_OPT%>”” and replace the token with any filesystem
specific fsck options. As above, the token can be deleted and this
option left blank. For example, FS_FSCK_OPT[0]=“”. Find the line “IP[0]=“<%SG_PKG_IP%>””and replace the token with the IP address
of the csync package. For example, IP[0]= 123.456.789.3. Find the line “SUBNET[0]=“<%SG_PKG_SUBNET%>””and replace the token with the subnet for
the package’s IP address. Use netstat -i to help determine the subnet. Fore example, SUBNET[0]= 123.456.789.0.
Distribute the package control script and package
ASCII configuration files cluster-wide: # ccp csync csync.conf /etc/cmcluster/csync/
Apply the package and start it: # cmapplyconf -P csync.conf
# cmmodpkg -e csync
|
Test the csync Package Configuration Test the configuration by performing a the following steps: On a managed client, use the
command: # cfagent --no-lock --verbose --no-splay The verbose output will display the client, checking for updated copies
of the master policy files, copying them down to /var/opt/cfengine/inputs if needed, and then executing the contents of cfagent.conf/cf.main. On the master server, test the cfrun command: # cfrun -- --inform --inform instructs the remote cfagent to use the --inform flag which will produce messages for all changes cfengine performs on the system. For additional information, the --verbose command can also be helpful: # cfrun -v -- --verbose The -v instructs cfrun itself to be more verbose and the --verbose is passed on to the remote cfagent. For additional troubleshooting information, please refer to “cfengine
Troubleshooting”.
Configuring
a Synchronization Managed ClientWhen manually configuring managed clients, the basic steps
are: Exchanging
security keys. This establishes the trust relationship between the
managed client and master server. Copying update.conf from the master server to the managed client. Setting a schedule for which
cfagent will perform synchronization operations.
To configure a Serviceguard cluster as a client of an existing cfengine master server, then each cluster member is treated as
if it were a standalone system and configured individually. If you
add new members to the cluster, each must be configured appropriately.If
you are adding a new member to a Serviceguard cluster and that cluster
is running the csync package, then the members of the cluster are automatically
configured as cfengine-managed clients. In this scenario, the csync package acts as the master server. New members will be
automatically configured as a managed clients and also able to handle
failover for the package. The package’s storage infrastructure
and filesystem should be configured before adding the member to
the cluster. To add a new managed client, start by configuring the
trust relationship between the client and the master server. The
two systems exchange security keys to authenticate each other. The
master server’s public key needs to be copied to the client
and the client’s public key is copied to the master server: As root, create the client’s
security key using cfkey: # mkdir -p /var/opt/cfengine/ppkeys
# cd /var/opt/cfengine/ppkeys
# /opt/dsau/sbin/cfkey
|
This creates the files localhost.pub and localhost.priv for
this client. Copy this client’s
key to the master server. The master server uses the following naming
convention for the client keys, <username>-<client_IP_address>.pub. Push the client’s public key to the master
server’s ppkeys directory using the following naming convention: # scp localhost.pub master_server:\
/var/opt/cfengine/ppkeys/root-client_IP_address.pub
|
Note that its important to use a utility like secure copy
(see scp(1)) when
transferring the key in order to protect its integrity. Finally, copy the master server’s key to
this managed client: # scp master_server:/var/opt/cfengine_master/ppkeys/localhost.pub \
root-master_IP_address.pub
|
Next, copy the master server update.conf to the
managed client: # mkdir -p /var/opt/dsau/cfengine/inputs |
# cd /var/opt/dsau/cfengine/master_files/inputs |
# cd /var/opt/dsau/cfengine/inputs |
# scp master_server:/var/opt/dsau/cfengine/inputs/update.conf ./update.conf |
To allow this client to accept cfrun requests, do the following: Edit
/etc/rc.config.d/cfservd and set the CSYNC_CONFIGURED variable to “1” -- this will start cfservd at system boot time. Start cfservd: # /sbin/init.d/cfservd start
Test the configuration with cfagent (see cfagent(8)): # cfagent --no-lock --verbose --no-splay
The verbose output will display the client checking for updated copies
of the master policy files, copying them down to /var/opt/cfengine/inputs if needed, and then executing the contents of cfagent.conf/cf.main.
For additional troubleshooting information, refer to the section “cfengine
Troubleshooting”. Choosing
a Synchronization Invocation MethodAs the administrator, you can push changes out to managed
clients by using the cfrun command (see cfrun(8)). cfrun contacts the cfservd daemon on each managed client and cfservd invokes cfagent does the actual synchronization work. You can also choose
to have cfagent run at intervals on the client. There are two approaches: Run cfagent from a cron job. When running cfagent from cron, invoke it using cfexecd -F. An example crontab entry is shown below: 0 * * * * /var/opt/dsau/cfengine/bin/cfexecd -F This crontab entry will cause cfagent to be run every hour. In this example, cfexecd (see cfexecd(8)) acts a wrapper for cfagent and collects any output and places it in /var/opt/dsau/cfengine/outputs. cfexecd can also cause mail to be sent to the administrator if
specified in the cfagent.conf file. For details, refer to the cfengine reference manual
in /opt/dsau/doc/cfengine. Note that the default cf.main has an example for automatically adding the above line
to the crontab file of each managed client. Run cfexecd in daemon mode. cfexecd has cron-like features based on cfengine’s time classes and can be used instead of cron to run cfagent. cfexecd defaults to running cfengine every hour. When first getting started with cfengine, it probably easiest to use cron for scheduling client side synchronization. For details
on using cfexecd in daemon-mode, refer to the cfengine tutorial located in /opt/dsau/doc/cfengine/.
cfengine has many security features that range from parameters
to control denial-of-service attacks to access control lists that
prevent managed clients from accessing reference file directories
on the server. For details on the cfengine security features, refer to the reference manual located
in /opt/dsau/doc/cfengine/. The security topics discussed below include: Key ExchangeAll the key exchange examples shown thus far have used scp to securely transfer master server public key to the
managed client and the managed client’s public key to the
master server. A scheme like this provides the highest level of
security but can be inconvenient in certain situations. Other key
distribution alternatives include the following: When connecting to a new client, cfrun has an interactive mode akin to ssh, where the administrator is prompted to accept the remote system’s
key. For example: cfrun(0): .......... [ Hailing remote-host.abc.xyz.com ] ..........
WARNING - You do not have a public key from host remote-host.abc.xyz.com =
12.345.678.90
Do you want to accept one on trust? (yes/no)
-> yes
cfrun:<master server name>: Trusting server identity and willing to accept key
from remote-host.abc.xyz.com=12.345.678.90
|
For large numbers of new
clients, this interactive mode can be inefficient. cfrun supports a -T option which tells cfengine to trust all new keys from the hosts listed in cfrun.hosts. cfservd.conf supports a TrustKeysFrom control clause. For example: control:
TrustKeysFrom = ( 128.39.89.76 ) # A trust host
TrustKeysFrom = ( 128.39.89.76/24 ) # A trusted subnet
|
The enumerated host or subnet addresses will be implicitly
trusted and their keys automatically accepted.
All of these key exchange alternatives should be used with
extreme caution and only in a secure environment where the LAN is
trusted and the remote hosts are trusted. Once a public key is accepted
it will not be updated unless it is deleted by hand from the master
server’s /var/opt/dsau/cfengine/ppkeys directory or manually replaced with a new key. Network Port Usagecfservd uses TCP port 5308 by default. You can instruct cfagent to connect to cfservd using a different port by specifying a port in the cfrun.hosts file. For example: host1.abc.xyz.com # Use standard port
host2.abc.xyz.com # Use standard port
host3.abc.xyz.com:4444 # Use port 4444
|
Also, cfengine will honor a cfengine tcp port defined in /etc/services. EncryptionIn general, file transfer traffic between the master server
and a managed client is not encrypted. For many system management
related configuration files this is acceptable. For certain files,
an encrypted file transfer is desirable. The copy action in cfagent.conf has an “encrypt = true̶ |
