Chapter 1.6 : The Repository in details

Installing and configuring the repository is as simple as dedicating some server space in your favorite system, and creating the following folders.

Eventually the install procedure should include a repository creation script, it kind of does (you should at the start install Tlaloc in a specific SSH user's account so as to dedicate it's SSH functionality to Tlaloc, as a matter of preference for a local intranet network perhaps.)

If you're using Amazon's S3 storage facilities (or any other that allows easy access through regular file transfer protocoles), then simply create the following hierarchy, it will get populated as you work along the integration.

Hierarchical structure of the Repository;

  • defaults/

    The defaults for all nodes, usually consists of a couple of very generalised config files, but most importantly, the SSH public keys and Known_Hosts files to distribute (if your repository consists of an SSH-based system)

  • modules/

    Module-specific default configuration files and such. Some module recipes such as Nginx/Apache come with their default configs which goes here.

  • nodes/[hostname]

    This is the customized, per-node, configurations. (see push_to_repository.sh which populates its subfolders using [hostname] to identify each node)

  • OpenBSD/

    This is where we usually put the OpenBSD sources, respecting the official distribution hierarchy (ie; 5.4/i386/, 5.4/packages/i386, etc...).
    This is an important folder in the Repository, this is where you should put your OpenBSD sources and packages for each supported version and platform you wish to maintain, if you're into compiling your own kernel or packages, this is very useful. Note that this folder doesn't contain OS-specific configuration files as per say, but rather their network installation ISOs.

  • Ubuntu/ [Centos/] [Redhat/] [etc..]

    • Each kernel should have it's source partition, as the respective kernel can recognize. It's also possible to extend this to Windows, although we haven't had much time for testing this yet.

  • [recipes/]

    A recipe folder, if you're into including/requiring sub-recipes from your main node recipes.

  • [sites/]

    Just a personal preference, I usually have this folder has a symbolic link to my website development main root from which all websites are rolled-out, this way, nodes can pickup the sites they need to serve from the big melting pot on re-initialisation without me having to push a new rollout.

Using the Repository

Through the use of the File->Source() method, you will automatically access the repository in the following order:

  • nodes/`hostname`/ *
  • [modules/module_name/]
  • defaults/

File->Source will return the first found file, therefore, the Node specific, Module-specific or finally the default.

* note: the nodes/`hostname`/ repository can be quickly populated with the push_to_repository.sh script, simply execute it once after setting up your fresh server, and you got a day-0 image of your configurations at hand.

Populating the Repository, using push_to_repository.sh

Once your repository is setup, if you were to have already-running systems (who doesn't?), you can go through each node and "push" their main configurations to the Repository using the push_to_repository.sh shell script.

I personally use it like a backup, or image-init procedure, currently tuned to the OpenBSD model, it will backup pretty much everything under /etc/, /etc/ssh/, /var/www/conf/, and a bit more.

Feel free to customize this script to your likings; add your standard webroot, things like that.

Warning ! I do not suggest using this methodology to make backups, as it will invariably overwrite the Node's specific config files with anything that could have tainted them. (virus, trojans, exploits, misconfigs, etc...)

Use it when you're sure your node hasn't been tampered with, or when zapping machines, its a great way to keep a reference to the pre-zap configs, and then rebuild one file at a time

Recipes/

The initial repository partition for the recipe library. You can extend this currently without fear of breaking things.