[Infrastructures] Recommended CVS heirarchy?

[Luke A. Kanies]

On Mon, 24 Feb 2003 wcooley@nakedape.cc wrote:

> I'm finally getting around to implementing a partial infrastructure for a
> site with two boxes and am setting up CVS.  Is there a recommended
> heirarchy?  The repository will be chiefly local configuration files (in
> /etc and other places) which are host-specific and scripts in /usr/local,
> which are more or less portable (or at least, won't harm anything by being
> on both), so I was thinking of:
>  o common/bin, common/man, common/sbin, etc
>  o hosts/host1/etc/foo, hosts/host2/etc/bar, etc
>
> Is there a recognized BCP I should follow instead?

Well, mine's just what works for me, but I have three basic directories in
CVS:

filesets/
code/
config/

The 'filesets' directory is where I keep the files that are to be
downloaded to the various systems.  These would be my oracle configs, my
motd files, my resolv.conf files, that kind of thing.  The 'filesets'
command in ISconf 3 then just pulls these down over rsync.

In the 'code' directory, I keep scripts; mainly locally developed perl
modules and a unified scripts directory to copy everywhere.  These are
separated largely for maintenance, not because they are treated
significantly differently.

In the 'config' directory, I currently only have my cfengine configs,
although I'd like to move my ISconf configs in there, too, so that the
ISconf code (which isn't updated very often) is treated separately from
the ISconf config info (which changes very often; my types file is beyond
450 versions now).

Once you get inside the 'filesets' directory, I have the following
currently:

applications     domain.com   fpd_sunos          prod.domain.com
common           fpd_common   hp-ux              sunos
CVS              fpd_fe       mgmt.domain.com    system-stubs
dev.domain.com   fpd_hp-ux    mtest.domain.com   workstation_dns

So, I have a fileset for every domain (which just contains the resolv.conf
file), a common fileset (which just contains the /root directory -- .ssh,
.profile, that kind of stuff), and then a fileset for every platform.  The
fpd_* filesets are for machines that are only partially managed by ISconf;
I still have to keep some things in sync here, but not as agressively as
the rest of the systems.

The applications subdirectory is where it gets funky:

buildhost  cvs      ignite   mysql-ng       oracle-server  sudo
clusters   dhcpd    loghost  oracle         rsyncd
CVS        genesis  mailhub  oracle-client  sshd

Basically, here I have everything else.  I have a fileset for oracle
clients and servers, a fileset with just the sudoers file (which is
probably actually the only fileset on every one of my systems, including
the ones ISconf didn't build), and a fileset for all of the different
management functions that require config files.

Also, my gold servers have things like filesets/pkg, filesets/perl5, etc.

This has worked pretty well for me.  My rsync.conf script is simplified,
because I can just make "filesets" available, and the 'filesets' conf file
lists, say, "filesets/applications/sshd" as the module (btw, there should
be a script in ISconf 3 to help maintain rsync files, but if you're just
starting this....  use cfengine as your transport, not rsync).

I also have two of every host, and it's all in a two-tiered structure. My
gold servers function as two types of file servers on the first tier:
They store the cvs repository, and they store all normal-file,
non-versioned filesets, like packages and all of the perl modules.  On the
second tier, I have rsync servers which perform CVS checkouts from the
gold servers, and serve those files over rsync to the rest of the systems.
These rsync servers are also my mail routers and log hosts, so they're not
idle (over 3.5 million syslog messages in MySQL!).

Of course, all of these operations are managed out of ISconf (the filesets
script natively supports CVS filesets now, too).  Each fileserver has a
master/slave setup, and the slaves refresh themselves periodically from
the master.

This means that for the vast majority of ISconf operations, it's only my
rsync servers that are contacted, and my gold servers (which I consider
more secure) are only contacted for the rare package installations and
things like that.

I've over-engineered my network here a bit; I've got two gold servers
running on Sun, two HP servers for package building and serving, two
application servers which will but don't currently function as backend
LDAP, DNS, NTP, and other servers, two NFS servers for bulk storage of src
and build repositories, and two rsync servers which also function as log
hosts, mail relays, and will be NTP and DNS resolvers.  For each of these
pairs, each half is in a different data center.

It's a bit overengineered for the size network we have, but it won't have
to change at all if we triple in size.

Is that a good enough answer?

Luke

-- 
Today I dialed a wrong number...The other person said, "Hello?" and
I said, "Hello, could I speak to Joey?"...
They said, "Uh...I don't think so...he's only 2 months old."
I said, "I'll wait."  -- Steven Wright