welcome: please sign in

Diff for "ConfigurationManagement"

Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2013-01-05 06:27:37
Size: 286
Editor: ClintonEbadi
Comment: basic stub
Revision 6 as of 2018-04-22 02:12:42
Size: 5148
Editor: ClintonEbadi
Comment: start date for config packages
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. <<TableOfContents>>
Line 3: Line 3:
== Services Changed By Unpackaged == == Puppet ==

As of 2018, HCoop is using Puppet to manage system configuration.

=== puppetserver ===

 * Hosted on ServerGibran
 * Installed https://apt.puppetlabs.com/puppet5-release-stretch.deb manually
 * Packages: puppetserver, puppet-agent

Puppet git structure (different repos for each): /etc/puppetlabs/puppet, /etc/puppetlabs/code/environments/production (excludes modules), /etc/puppetlabs/code/environments/production/modules/hcoop, /etc/puppetlabs/code/environments/production/modules/hcoop_private. Subject to change.

Git repos structure and tracking of installed modules will be revisited once we need to set up multiple environments. For now, `/etc/puppetlabs/code/environments/production/modules/hcoop` is where all of our code aside from node definitions lives. `/etc/puppetlabs/code/environments/production/modules/hcoop_private` is for private data (krb5 host keys, ssl keys, etc.) that needs to be managed by Puppet. Ideally we would use something like [[https://www.eyrie.org/~eagle/software/wallet/|wallet]] for this instead. hcoop_private contains only virtual references to files tagged appropriately so they can be realized on individual servers.

Puppet module structure:

 * hcoop
   * server
     * $server (e.g. gibran)
   * service
     * openafs-client

==== puppetdb ====

install guide is weird

{{{
 puppet resource package puppetdb ensure=latest
 puppet resource package puppetdb-termini ensure=latest
 puppet module install puppetlabs-puppetdb
}}}

=== Installed Modules ===

Please Update when installing a new module on the puppetserver.

 * puppetlabs-firewall
 * puppetlabs-puppetdb
 * alexharvey-firewall_multi (says incompatible, but works... enough).
 * stm-resolv_conf
 * ccin2p3-mit_krb5
 * stm-debconf
 * saz-sudo
 * herculesteam-augeasproviders_pam
 * herculesteam-augeasproviders_core
 * saz-timezone
 * dalen-dnsquery

=== Style Guidelines ===

Ideas for keeping consistency among admins. Work in progress.

 * Use firewall_multi for all rules unless it really is ipv4 or ipv6 only, provider is set in defaults and will keep ipv4 and ipv6 firewall in sync
 * Should pass puppet-lint (enforce using git hook) / respect https://puppet.com/docs/puppet/5.5/style_guide.html
 * Inheritance is discouraged? Avoiding it for now
 * Files controlled by puppet have comment "This file is managed by Puppet. DO NOT EDIT." somewhere near the top
 * Some structure to firewall rule numbers
  * Under 100 for core system things that need to go near the beginning
  * Over 900 for core system things that need to go near the end (e.g. jumping to fwtool output chains)




== Config Packages ==

From 2013 until 2018 we were using [[http://debathena.mit.edu/config-packages/|config-package-dev]] to manage the configuration of shared services. They proved to be cumbersome to maintain and were abandoned for Puppet.

The following is for historical reference only.

=== 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

==== Post-Mortem ====

However, we failed to realize many of these benefits in the end:

 * Basic Debian packaging was not quite as straightforward to pick up or remember as it seemed initially
   * An extra entry barrier for new admins by using a config management system not widely used by others
 * Packages were cumbersome to update, and resulted in a trail of underdocumented and unpackaged changes
 * Packages were cumbersome to port between Debian releases

The benefit of automated system installs was realized, but the value of distributing config changes through apt was minimal for us.

=== 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 ===

1. Puppet

As of 2018, HCoop is using Puppet to manage system configuration.

1.1. puppetserver

Puppet git structure (different repos for each): /etc/puppetlabs/puppet, /etc/puppetlabs/code/environments/production (excludes modules), /etc/puppetlabs/code/environments/production/modules/hcoop, /etc/puppetlabs/code/environments/production/modules/hcoop_private. Subject to change.

Git repos structure and tracking of installed modules will be revisited once we need to set up multiple environments. For now, /etc/puppetlabs/code/environments/production/modules/hcoop is where all of our code aside from node definitions lives. /etc/puppetlabs/code/environments/production/modules/hcoop_private is for private data (krb5 host keys, ssl keys, etc.) that needs to be managed by Puppet. Ideally we would use something like wallet for this instead. hcoop_private contains only virtual references to files tagged appropriately so they can be realized on individual servers.

Puppet module structure:

  • hcoop
    • server
      • $server (e.g. gibran)
    • service
      • openafs-client

1.1.1. puppetdb

install guide is weird

 puppet resource package puppetdb ensure=latest
 puppet resource package puppetdb-termini ensure=latest
 puppet module install puppetlabs-puppetdb

1.2. Installed Modules

Please Update when installing a new module on the puppetserver.

  • puppetlabs-firewall
  • puppetlabs-puppetdb
  • alexharvey-firewall_multi (says incompatible, but works... enough).
  • stm-resolv_conf
  • ccin2p3-mit_krb5
  • stm-debconf
  • saz-sudo
  • herculesteam-augeasproviders_pam
  • herculesteam-augeasproviders_core
  • saz-timezone
  • dalen-dnsquery

1.3. Style Guidelines

Ideas for keeping consistency among admins. Work in progress.

  • Use firewall_multi for all rules unless it really is ipv4 or ipv6 only, provider is set in defaults and will keep ipv4 and ipv6 firewall in sync
  • Should pass puppet-lint (enforce using git hook) / respect https://puppet.com/docs/puppet/5.5/style_guide.html

  • Inheritance is discouraged? Avoiding it for now
  • Files controlled by puppet have comment "This file is managed by Puppet. DO NOT EDIT." somewhere near the top
  • Some structure to firewall rule numbers
    • Under 100 for core system things that need to go near the beginning
    • Over 900 for core system things that need to go near the end (e.g. jumping to fwtool output chains)

2. Config Packages

From 2013 until 2018 we were using config-package-dev to manage the configuration of shared services. They proved to be cumbersome to maintain and were abandoned for Puppet.

The following is for historical reference only.

2.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

2.1.1. Post-Mortem

However, we failed to realize many of these benefits in the end:

  • Basic Debian packaging was not quite as straightforward to pick up or remember as it seemed initially
    • An extra entry barrier for new admins by using a config management system not widely used by others
  • Packages were cumbersome to update, and resulted in a trail of underdocumented and unpackaged changes
  • Packages were cumbersome to port between Debian releases

The benefit of automated system installs was realized, but the value of distributing config changes through apt was minimal for us.

2.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.

2.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.

2.4. Services Changed But Unpackaged

  • php5 config (changed a few variables, disabled some suhosin stuff at least).


CategorySystemAdministration

ConfigurationManagement (last edited 2023-10-13 13:57:26 by ClintonEbadi)