Sidai team: the `*-config' packages

An example might be: setting up /etc/inetd.conf (for every host of every platform type at your site).

The first section works through a single example. Then we have an ``index'' of all the files/things that you can set with these packages. Finally, descriptions of the details of individual packages.

Example: syslog-config

1. Log to the same files in the same directories on every host, no matter the platform, so that you always know where to look for syslog files.

   We happen to log to /var/log/mail.log (mail-related logging) and /var/log/messages (everything else).

2. Besides logging to local files, also log to a central syslogging host. This helps to give a site-at-a-time view of your syslog activity.

   (Note: central logging is no substitute for local-logging-to-files; the former is quite useless once networking goes pear-shaped...)

OK, to make this work, Sidai provides two things:

• syslog-config/syslog.conf.tmpl: an ARK template file from which to make each host's real /etc/syslog.conf file.

• package/syslog-config.xml: a proto-package that includes the smarts to drive said process.

So, a site that wants to do things the Sidai Way need only specify the following (this is team glasli1's package/syslog-config.xml):

<package name="syslog-config" xml-version="1">
<status>revealed</status>
<prototypes>
  <prototype team="sidai" name="syslog-config"/>
  <prototype team="."     name="ALL"/>
</prototypes>

<src-linkfarm>
  <param name="PKG_TEAM">sidai</param>
</src-linkfarm>

<compile>
  <param name="CENTRAL_SYSLOG_HOSTNAME">slimy</param>
  <!-- where our syslog.conf says that things are to be put: -->
  <param name="SYSLOG_DIR">/var/log</param>
</compile>

<reveal>
  <!-- where our syslog.conf says that things are to be put: -->
  <param name="SYSLOG_DIR">/var/log</param>
  <param name="SYSLOG_FILES">messages mail.log</param>
</reveal>
</package>

• The <src-linkfarm> method essentially says, ``Use sidai's syslog.conf.tmpl, not our own.'' You could, of course, roll/use your own.

• The other <param> settings are the obvious: what is the central-logging host, what directory are we stashing syslog files in, and what are those files.

• That's not a lot of typing for a fully-specified multi-platform central-logging service!

• Even if you really don't like the Sidai syslogging ``solution'', it pretty much shows you how to set up an Arusha-ish variation of your own.

Index of files/stuff managed by *-config

General comments

Our approach is: (a) the basic thing on offer is how we Sidai people do that particular thing, e.g. what we put in /etc/shells; plus (b) a small number of options that you can use. For example, we might include a ``don't use TCP wrappers'' option for /etc/inetd.conf... (even if it is a lousy idea).

If you violently disagree with the Sidai approach, you should be able to use this stuff to invent your own ARK packages to do what you want.

You should also bear in mind that the Sidai Way is to separate a package from its configuration. Take the `sudo' program for example: We would expect you to have a `sudo' package (say, sudo--1.6.5p2), and its job is to install the binaries and man pages. This task should be very, very standard across ARK sites.

We then expect you to have a separate sudo-config package, which is your site-specific configuration. In sudo's case, that's just some way of setting up your 'sudoers' file.

The general *-config pattern

1. Your team supplies a foo-config.xml package, which (importantly) has Sidai's foo-config as a prototype. Obviously: this is also where site-specific parameters are set.

2. Sidai's foo-config.xml proto-package supplies the ``smarts'' for the job. Usually, the <compile> method does the interesting part...

3. Sidai has a foo-config directory that includes a number of ARK template (*.tmpl) files, which are (surprise!) templates for the actual files that you want to produce.

   You can use the Sidai templates (by setting a <param> in your site package file...), or you can roll your own.

4. A fair number of the Sidai templates let you specify per-package or per-host (or per-user, or per-vendor, or...) fragments to go in the file in question. For example, a package that wants something in /etc/inetd.conf can have a <inetd-conf-fragment> (or <inetd-conf-fragment>) field, which will be picked up by Sidai's net-services-config/inetd.conf.tmpl template.

The apache-config package

The automount-maps package

The Sidai solution comes from its automount-maps proto-package; the real package (also called automount-maps) distributed by the `verilab2' (ditto `glasli1') team is a live working example.

Creating the maps: Automount maps can come from *.tmpl files (see automount-maps/*.tmpl from `glasli1', for example) or can be generated from `dchunks' info, or both.

'Glasli1' does both. Maps for `users' (we have that instead of `home') and `local' come from .tmpl files; maps for `d' and `workspace' are generated from dchunks' info.

The Sidai `configure' method (by default) groks the dchunks stuff, to produce a 'super-tmpl' file, automount-maps.tmpl.

The ensuing `compile' method produces per-host automount maps, either from the generated automount-maps.tmpl file, or from the hand-written *.tmpl files.

Something you might have reason to do (but we don't): If you don't use dchunks but do have ARK `user' objects (i.e. <team>/user/*.xml), you could arrange to generate your `home' automount map from, say, <home-disk> fields. All you would do is have a auto_home.tmpl file that looked something like (NB: untested, illustrative only):

<%
ret['destname'] = 'etc/auto_home'
%>
# `fixed' entries for 'root' etc would probably go here...
<%
# generate /home entries for normal users:
import ark.user

options = '-rw,intr,noquota,nosuid'

for user in ark.user.ArkUsersMgr().unpackSpecs(['ALL']):
    home_disk = user.home_disk(ARK_HOST_CTXT=thishost)
    print '%s %s %s' % (user.idString,options,home_disk)
%>

Distributing the maps -- NIS: (We may be talking nonsense here...) Instead of <hosts-supported> being ALL, you'd set it to something like (e.g.) sparc-solaris7-nis-server, and then still do a diffing deploy to get the bits there.

Other packages (nis-server-config? nis-client-config?) would then be tickled (ypmake on the server, for instance) to make the right thing appear on all clients.

Re-building the maps after changes: When we make changes to the maps, we run

sidai/package-utils/ark-invasive automount-maps

(If anyone wants to do something with automount maps that is slightly different from what we've described, please get in touch.)

The etc-exports package

The findutils-config package

1. You use updatedb to build a database of filenames (probably in an overnight cron job).
2. You then use locate to query that database; something like locate \*/flibble will list every file named `flibble' anywhere on your system, in just a few seconds.

Setting up all of this is the job of Sidai's findutils-config package.

In the standard ARK ``site-at-a-time'' way, we want locate to report for all of the filespace across the site.

What about system partitions, e.g. /usr? If we do locate grep, do we want to see /usr/bin/grep listed just once, or once per system partition (i.e. per host)?

We assume the former (``just once''). However, we also provide a script locate-all which really will list them all (assumed to be mostly for sysadmin use).

So: when you run locate on a host, you get (the databases for) one set of system stuff [that of the host you're on] and all of the NFS-available stuff.

Our implementation relies on the Sidai `dchunks' stuff. You specify proto-dchunks that characterize the ``systems'' partitions and the ``NFS'' partitions.

The databases should be built as an ordinary user (probably nobody), so that filenames that other people don't want disclosed will not be put in the databases. If you run it as `root', there will be no secrets.

The flexlm-config package

The Sidai flexlm-config package is basically about setting up a combined license file (i.e. all the licenses you have from different vendors). It does little more than copy it into place.

Don't store your license file in a public CVS repository, or distribute it. Do as `glasli1' does, and have it under a glasli1-private team.

Finally, you will also need ``vendor daemons'', which do the vendor-specific magic associated with particular licenses. Your ARK packages that manage those vendor tools should do something about the vendor daemons, too. Your flexlm-config package should therefore have <constraint>s on those vendor packages...

The host-trust-config package

The Sidai Way herein is:

/etc/hosts.equiv:

Trust the other hosts within the site, and no others. You can specify a <param> to add a few extra trusted hosts, if you wish.

.rhosts for root:

Don't.

.amandahosts:

Every host needs one line, something like slimy sysbkups. (You specify those details, of course.) The backups host (in our case, slimy) needs to have a <host> root for every host that might phone in needing a restore done...

The hpux-rc.d-config package

This Sidai package gives you a way to set some of these parameters in a site-at-a-time way. The most common reason to do this tweaking is to turn stuff off.

Note: there are some /etc/rc.config.d files that are the province of other packages, notably: (a) those that set per-host networking things -- net-config.

This package probably does not do what you want, yet! It's pretty easy to check out painlessly, however. Give it a status of built, then run ark package compile on it. You can now diff what it generated for your HP-UX host(s), and see how close you are to what you want.

If you've tweaked it up to be what you want, then change the status (to revealed, presumably), and carry on. It is well worth keeping a copy for posterity of the diffs between what-HP-provided-initially and what-you-changed-it-to.

ToDo: more.

The net-config package

/etc/defaultrouter
/etc/hostname.hme0 # or le0, or ...
/etc/hosts
/etc/netmasks
/etc/networks
/etc/nodename
/etc/nsswitch.conf
/etc/protocols
/etc/resolv.conf
/etc/rpc
/etc/services

/etc/nsswitch.conf: files for everything. We'd be happy to support other common, sane choices...

/etc/hosts: Records all your local hosts in there, and perhaps a few others that you specify. (NB: nsswitch.conf says hosts: files dns)

The templates for /etc/rpc and /etc/services let your ARK packages supply `fragments' to add, notably <rpc-numbers-database-fragment>s and <etc-services-fragment>s.

The net-services-config package

Those services can be classified as static (started at boot time, with an init.d script) or dynamic (started by `inetd' or `xinetd').

Currently, this package only does the `(x)inetd' side, namely setting up /etc/inetd.conf (or /etc/xinetd.conf).

The Sidai net-services-config/inetd.conf.tmpl template picks up per-package and per-host <inetd-conf-fragments (or <xinetd-conf-fragments).

The openssh-config package

The root-acct-config package

The sendmail-config package

You must supply a clients.mc Sendmail m4-ish input thingy, and a comparable thing for your mail hub, if you have one.

For both clients and hub, you can also supply a list of ARK template (*.tmpl) files to be splatted accordingly. Examples might be: aliases files, default-domains, genericstable, and so on.

The shells-config package

The sudo-config package

We advise keeping the original for your sudoers.tmpl in some ``more secure'' place. Don't include it in the bits on your public CVS repository or which you give out to your ARK friends.

The sys-cron-config package

1. Who is allowed to run `cron' and `at'; to this end, it creates /etc/cron.allow and /etc/at.allow files.

2. The crontabs for ``systems'' accounts, most notably `root'. (Other relevant ``not-a-person'' accounts might be `mailman', `vobadm', `twiki', ...)

On the crontabs front, individual ARK things (typically: packages or hosts) can specify a <sys-crontab-fragments> table. At the moment, an entry for any key other than root will cause a Python exception, but that could change :-)

Note: we have one or two ARK packages which exist only to supply a <sys-crontab-fragments> table. An example is glasli1's time-config package; its main is to provide:

<sys-crontab-fragments>
<constraint><host-spec>sidai:sparc-solaris</host-spec></constraint>
<table><entry name="root"><string><![CDATA[
2,22,42 * * * * /usr/sbin/ntpdate -s timehost
]]></string></entry></table>
</sys-crontab-fragments>

The syslog-config package

The tcp-wrappers-config package

We advise keeping the original for your hosts.{allow,deny}.tmpl files in some ``more secure'' place. Don't include it in the bits on your public CVS repository or which you give out to your ARK friends.

The time-config package

We advise keeping the original for your ntp.keys.tmpl file in some ``more secure'' place. Don't include it in the bits on your public CVS repository or which you give out to your ARK friends.