hxmd-format files to setup a local site configuration for your hosts. This sometimes looks harder than it is. so just jump in a build one. You can always revise it later.
hxmd, instancing an
xapplymachine, wrapped in
xclates above and below, to collate output works. But it doesn't do much for you until you build a local configuration.
The local configuration consists of some
meta data files which describe your host populations (you can have as many
of these as you need) and a zero configuration file to set the
default attribute macros for
transport options. You may even need to build multiple default attribute
macro files, but that is rare.
There is a remote configuration too, which we'll get to below.
hxmdwhat default attribute macros to set when
msrcuses it to visit hosts. I'm sure you've already read the
hxmdHTML document and the
msrcHTML document, so we don't have to review all that material. In this context you need to remember which of the attribute macros are used by the application as hooks, and which are used by the structure itself.
These three attributes are almost always used by
any "Msrc.hxmd" files to hook back to the make recipe file, so
avoid setting them:
HOST macro and the other four
distrib used (
would not be global preferences. So don't set those here.
That leaves the attributes that describe how to get the
and who to become there (
what to source to get a clean environment
which transport programs to use
Of those you needn't set any. The structure should work if
you can ssh over to each host with
rdist is installed in the default
search path on both ends.
I usually do change
RDIST_PATH to suppress
rdist's chatty nature. One could add the
-q option to
or include shell markup to redirect the
stream to the bit-bucket.
The other tune I include, in the default
hxmd file for
ENTRY_DEFS that is backwards compatible
with the old master source system: the old system always sourced
a shell file named "/usr/local/lib/distrib/local.defs". You could
spell the filename anyway local policy requires in the new system,
and even put the file in a different place for different groups of
Here is an example
msrc.cf from my site policy:
which looks a lot like the default one shipped in this directory, but forces the local.defs path.
# $Id: msrc.cf,v ... # Hxmd configuration (designed for the -Z option) which sets all the (ksb) # macro definitions that msrc needs to set to locally significant values. ENTRY_DEFS=`/usr/local/lib/distrib/local.defs' RDIST_PATH=`rdist >/dev/null'
msrc"how", "who", "what" and "which" we need to tell
hxmdwhere (a list of hosts) and why (other attributes about those hosts).
I break my hosts into realms. For example the "dmz" realm holds the hosts that run our Internet face. The "sac" realm holds the workstations and test hosts for the system administration group. One large file with all your hosts in it is also a workable solution.
hxmd reads as many configuration files
as you like (under
-C) you can build one
file per host, if you feel that's a good solution to your local
issues. I'm pretty sure that doesn't scale to thousands of hosts.
Pick a name (like
mysite.cf) build the file
here. I used
sac.cf, and it starts out
# $Id: ... %HOST w01.sac.fedex.com w02.sac.fedex.com adm0.sac.fedex.com...
Add the file name to the
SOURCE macro, and in
After that, when you run
install this directory the new "mysite.cf" file should
become available via
-C without a full pathname. We'll add a shell
script (called "dmz.sh" in
msrc's source directory)
later so we don't have to type that option over and over.
Keep that list of hosts up-to-date. Put an revision control spell over it (subversion, RCS, SCCS, CVS, or what ever you like) and keep track of the current revision. Break it up later into realms, only if you need to.
Now you must prime the pump for
ssh. If you
don't give it a chance to record the host keys for each host
ssh is going to go interactive on you at the
worst time to ask if the host key matches for each of your hosts.
To prevent this make sure you have an active
loaded with your keys, then run a command like:
$ hxmd -dM -xP1 -C mysite.cf 'ssh -oBatchmode=yes -n HOST date'
hxmdto verify the file is syntactically correct, the trace the launch of an
sshto each host sequentially to run
Remove the "-oBatchmode=yes" option to verify host keys then
fix any errors you see in that output: misspelled hosts, mismatched
host keys, incorrect dates, and the like.
-P1 can be made wider, but
the secure shell client sometimes steps on
known_hosts file with large
numbers of parallel updates.
Now you must add some additional facts about each host.
For the base tools to work you must add "HOSTTYPE" and
"HOSTOS" to the file. If all your hosts are the same, you may
add them as
lines before the host list:
# $Id:... HOSTTYPE="value" HOSTOS="value" %HOST host1 host2...
When they are a mixed set, you should use the column-style for each host.
# $Id:... %HOST HOSTTYPE HOSTOS host1 type1 os1 host2 type2 os2
I use the columns for attributes like a serial number: all hosts have one and they are all different. I use the "set it an forget it" style for attributes that are common to a large section of the file, or to all hosts in the file.
If you use the set-it-here style you might need to "unset it" after the end of the hosts that have that attribute, this can be hard to remember, so write a sanity checker if you need one.
We might break the list of hosts up on a few criteria: the mechanism to gain access, the political span of administrative control, or the level of support (viz. test, development, beta, production), or the class of server (web, application, database, dns, or cache server). That partitioning is largely up to your local site policy.
batch command can trigger a shell
action to start the process to update a list of hosts. My
kicker batch-file injector, the
may include scripts to run
efmd) on a
list of hosts. Any task management service (even a web CGI)
could start the ball rolling.
keyfield (usually the "HOST" attribute macro).
Then the Hardware guys can keep "hardware.cf" up to date with 3 columns:
The Software guys can merge that file in with "
# $Id: hardware.cf,v ... %HOST SNUMBER LOCATION host1.example.com 5271010 E101:97:1 host2.example.com 1964215 E101:97:2 ...
hardware.cf" when they need to use the location or serial number to select a host or report on a host's status.
If you are limited to some spead-sheet format, just import it through a converter. We use plain text files to avoid any specific tool limits.
The file class.m4 always (in my implementations) contains
CLASSOF which converts a given
HOST into the name of the parent class.
It should hide any local macros behind the local political domain.
The one in this directory uses the domain "CLASS", but is actually not
the one I use in my group.
The shorthand macro
CLASS expands to
which is what you want most of the time. Sometimes you need to
find the class of a host you found by a macro like
in which case use
CLASSOF on the name.
You should edit that file so it turns your local hostnames into
classes, if you are going to use that (for
rule-base) later on.
auto.cfis generated by some detailed
auto.cf.host. This includes macros which describe some of the macro values needed to push or pull updates to the local host.
These should include at least some of the lines below. Other additions to this file would be local site policy.
date when file created"
A comment that lets an admin know when the update was built, the time
on the file tell when it was installed. It may have been packaged in
an RPM or
tar archive for quite some time.
absolute path to local.defs"
path to rdistd on this host"
login accont name"
path to rdist on msrc host"
There may be useful for local self-updates.
RDIST_PATH is a comment because there is
no proof that the source host has the same location as the client (which may
have different everything from each other) for
If this line is in the file then the update was a pull, rather than a push.
Only if this line is present should the next three lines be included.
tcmpmux name for msrcmux"
msrc pull service CNAME"
mmsrcfor target host
All the information required to connect to the pull service to ask for another update: the RFC1078 service name, the host to connect to, and the configuration file which contains our definition.
muxcat MSRCMUX_MPS MSRCMUX local/bin/flock MSRCMUX_CFG > /tmp/$TFILE.tar
In recent releases of
hxmd's library we include
the name of the the configuration file that first defined
this host. That may not be enough to know where all the attributes came from,
but it might help trace duplicate
hosts. The requires
hostdb revision 1.87, which
HXMD_FROM for us.
If we know the class the master machine thought we were, we record it for
hostlint. The where may be the string
"class.m4" or same value as
MY_CONFIG, which is
always an absolute path. Or it may not be defined when
MY_CLASS is not defined, and no
CLASSOF macro is defined.
SERVICE macro is defined we record the
I always use
localhost, but other site policy
calls for the hostname. If you don't specify one you may update the
host three times. If you specify a common name for the host you might
match none of the lines.
None of these sets
HASSRC because we really
do not know if this host should have a full platform source.
sshis not up to snuff you might need to specify a path to another for some group of hosts, or build a script that adds command-line options to the vanilla
sshto diddle options. You might also want to apply the high performance network patches to
msrc_baseRPM, or start with the
If you are interested in pull updates to your hosts,
HTML document or
$Id: site.html,v 1.27 2014/04/13 21:34:07 ksb Exp $ by ksb.