|
⇤ ← Revision 1 as of 2013-01-05 06:27:37
Size: 286
Comment: basic stub
|
Size: 1722
Comment: I thought I documented this, try and get some kind of start now
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| We are using [[http://debathena.mit.edu/config-packages/|config-package-dev]] to manage the configuration of shared services. | We are using [[http://debathena.mit.edu/config-packages/|config-package-dev]] to manage the configuration of shared services. |
| Line 3: | Line 3: |
| == Services Changed By Unpackaged == | == Rationale == Using config-package-dev has several advantages for HCoop: * They can be used to [[AutomatedSystemInstall|automate installation]] * Our changes to config are kept in an executable format * Basic Debian packaging is straightforward to pick up * Distribution of configuration occurs through the same channel as our general software updates * Everyone is forced to formalize their changes rather than leaving a trail of undocumented changes A system like Puppet might make sense in the future. == Current Config Packages == We are managing our configuration packages in git, at `/afs/hcoop.net/user/h/hc/hcoop/.hcoop-git/debian`, or you can view the [[http://git.hcoop.net/?a=project_list&pf=hcoop%2Fdebian&s=-config|list of configuration packages]] using gitweb. == Creating a Config Package == See [[DebianPackaging#Creating_a_Configuration_Package]] for the low-level details of creating a config package and our general packaging workflow with git-buildpackage. The [[http://debathena.mit.edu/config-packages/|Debathena documentation]] describes the new primitives. Primarily, config packages will consist of files installed with `dh_install`, a few diversions, and some transformations. Use what makes sense: `dh_installcron` et al are your friends. The [[http://git.hcoop.net/?p=hcoop/debian/hcoop-apache2-config.git;a=summary|hcoop-apache2-config]] package is a good example. == Services Changed But Unpackaged == |
We are using config-package-dev to manage the configuration of shared services.
1. Rationale
Using config-package-dev has several advantages for HCoop:
They can be used to automate installation
- Our changes to config are kept in an executable format
- Basic Debian packaging is straightforward to pick up
- Distribution of configuration occurs through the same channel as our general software updates
- Everyone is forced to formalize their changes rather than leaving a trail of undocumented changes
A system like Puppet might make sense in the future.
2. Current Config Packages
We are managing our configuration packages in git, at /afs/hcoop.net/user/h/hc/hcoop/.hcoop-git/debian, or you can view the list of configuration packages using gitweb.
3. Creating a Config Package
See DebianPackaging#Creating_a_Configuration_Package for the low-level details of creating a config package and our general packaging workflow with git-buildpackage.
The Debathena documentation describes the new primitives. Primarily, config packages will consist of files installed with dh_install, a few diversions, and some transformations. Use what makes sense: dh_installcron et al are your friends. The hcoop-apache2-config package is a good example.
4. Services Changed But Unpackaged
- php5 config (changed a few variables, disabled some suhosin stuff at least).