Difference between revisions of "BXadmin:Cfengine"
(Created page with 'Cfengine 2 Reference: http://www.cfengine.org/manuals/cf2-Reference.html') |
|||
| Line 1: | Line 1: | ||
| + | = 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. | ||
| + | |||
| + | = 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''. | ||
| + | |||
| + | Classes/groups are in ''inputs/cf.classes''. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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 | ||
| + | |||
| + | = References = | ||
Cfengine 2 Reference: http://www.cfengine.org/manuals/cf2-Reference.html | Cfengine 2 Reference: http://www.cfengine.org/manuals/cf2-Reference.html | ||
Revision as of 14:34, 9 October 2010
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.
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.
Classes/groups are in inputs/cf.classes.
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.
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.
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.
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
References
Cfengine 2 Reference: http://www.cfengine.org/manuals/cf2-Reference.html
