atstake atstake wrote:
Not directly OpenBSD related but I thought I'd ask. I'd like to use
a revision control system to manage files on 25-30
servers but I'm not sure whether I'd use a centralized repository or
have a separate revision control system on each box. It would also be
good
to know how much leverage can a revision control system can give
over a "make-backup-before-change" policy in the long run and also
what files and directories should I add to it. Anything else anyone
would like to add from experience would be much appreciated.
Amazing question; I was just now working on a similar one to submit to
the list.
First, this site got me thinking, http://www.infrastructures.org/.
Second, I have not done this, but I am in the research and getting ready
to test phase. I'm sure experienced admins can provide greater insight
to this matter.
I would use a dedicated, highly secure and always backed-up box to
store/manage a central repository (CVS/SVN). This repos will hold all
the necessary bytes (binaries, config files, ports, etc.) to "re-image"
any machine from scratch. Each node on the network would then "pull"
everything it needs from the central repos using method X. That's the
part I'm trying to figure out. I want the whole automation system to be
simple and would like to use only default tools.
I was thinking about using sup(1) to pull changes/deletions from the
central box. My question would be, "does anybody use sup(1) for this
kind of situation?" It seems lightweight, yet has hooks built-in to run
config scripts after updating a collection. Another question about sup
regards security concerns, what are they?
To the OP, I would keep everything centralized and in a repository. Then
dedicate a test machine, or two, that you will use to deploy your
updates and test the integrity of your automation system. If all goes
well with the test, push the tested updates over to the production
repos. That particular production system should automatically pull the
updates on the next scheduled system update via cron or some custom
polling system. If the updates crap out the production server, you can
then revert your changes in the repos, the server will pick up the
revert, and everything will be back to the original, hopefully. The only
tricky part, for me to grasp, is how to execute a set of actions
before/after updating/adding/deleting a system file if needed?
I am working on an automation system that will commence from OS
installation. For instance, all the questions asked during OS
installation can be placed in a config file on the central repos. To
initiate an installation, run bsd.rd via CD or PXEBOOT. When asked
whether to run install, upgrade or shell, run shell. Then ftp your
system build script to the bare system and run it. The script will then
run the installation for you and build you a base system, filling in the
blanks. It will then "customize" the system by pulling individual
updates meant only for that server. Command line interaction:
# ftp central-repos:/buildsys
# buildsys <image-name>
Because the ramdisk kernel has a limited number file retrieval commands,
you will need interface with your central server using ftp. This will
only be required until you get your base system installed. Then you can
use whatever you like, such as rsync, rdist, sup, cvs, scp, etc. So
initially, your buildsys script will need to ftp things like disklabels
and instructions on how to run newfs. The sets to install should be
predefined ssomehow; read from a config file or placed in a directory.
For an example of the latter, your buildsys script could do something
like this:
ftp -o - central-repos:/images/<image-name>/OS/*.tgz | tar xpzf - -C /mnt
Note: you will build your new system under /mnt. The ftp command will
retrieve sets like base40.tgz, etc40.tgz, man40.tgz, etc.
Back to the OP's question of what should be kept in the repository?
Everything! Individual configs under /etc, your binaries, libraries, and
ports. In fact, I would install ports to an updated working copy of the
repos (pkg_add -L <wd>). Sometimes a port install requires user
interaction and some tweaking. This way you can install once and deploy
to many network nodes automatically. As far as the base OS, I would
probably commit the compressed tarballs (base40.tgz, etc) to the repos.
If you're following release, I don't see a reason to mess with
individual OS files.
Side Note: what I suggested above should probably not be used for large
amounts of business data, such as DBs or a filesystem of images for a
website. I would isolate this data on a partition of its own and dump(8)
that to a dedicated backup machine. You can then use restore(8), after a
system re-image, to get the machine to 100% recovery.
Just thinking and typing. Hopefully someone that has experience can fill
in the blanks, comment, or criticize.
-pachl
