BXadmin:Cfengine
Contents
Repo layout and usage
Central git repository is at /afs/bx.psu.edu/service/cfengine/bxcfe.git
There is a top-level Makefile, with the following targets (others as well, but these are the only ones you need to worry about):
- prod: does a git pull, syntax check, and releases the volume with afs-control, so you don't have to be admin
- check: Does a syntax check by doing a cfagent -pqv against the working directory. Pass cfargs="-Dfoo" to define additional classes.
To make a change:
- If you don't already have a clone of bxcfe.git, git clone /afs/bx.psu.edu/service/cfengine/bxcfe.git
- Make your changes
- Run make check cfargs="-Dfoo" to test your changes
- git add <files you have changed> followed by git commit, or git commit <files you have changed>
- git push. If this fails due to non fast-forward changes, git pull first, then git push
- make prod
TODO: add a "test suite" for iterating through multiple class definitions.
- bxcfe.git/
- Makefile
- inputs/
- cfagent.conf.in (see version target in Makefile)
- cf.site
- cf.applications
- cf.classes
- cf.profiles
- cf.app_*
- cf.profile_*
- update.conf
- masterfiles/
- misc/
- apps/
- foo/
Conventions
The first pass performed by cfagent uses inputs/update.conf. This file should NEVER be changed without extensively testing. If this file breaks, you will have to manually fix the clients that have broken as a result!
Site-specific settings are in inputs/cf.site.
cf.classes
Classes/groups are in inputs/cf.classes. After a particular change is defined through cfengine, applying that change to clients should involve simply editing inputs/cf.classes.
There are also host groups, named whatever you like. Host groups could then be included in profiles. Profiles and host groups should be included in role_foo and app_foo definitions.
cf.applications
Applications definitions are in inputs/cf.applications, which include the appropriate inputs/cf.app_foo if the app_foo class is defined. Applications could be things like ntp, kerberos, pam, apache, etc.
Roles are defined within each app, named role_foo_client, for example.
In general, there should be at least one role defined for a particular app. Every role for an app should then be used to define the app_foo class. For example:
role_ntp_server = ( river simon jayne ) role_ntp_client = ( any -role_ntp_server ) app_ntp = ( role_ntp_server role_ntp_client )
cf.profiles
Profiles are included in inputs/cf.profiles, which include the appropriate inputs/cf.profile_foo if the profile_foo class is defined. Profiles could be things like workstations, persephone_cnode, etc.
References
- Cfengine 2 Reference: http://www.cfengine.org/manuals/cf2-Reference.html
- Cfengine tips, pointers, and sample configs: http://sial.org/howto/cfengine/
- http://cfwiki.org/cfwiki/index.php/Main_Page
- Git cheat sheet: https://git.wiki.kernel.org/index.php/GitCheatSheet
- Git Reference: http://gitref.org/
- Everyday Git in 20 commands: http://www.kernel.org/pub/software/scm/git/docs/everyday.html