6432
Comment: installed puppetlabs-mysql module
|
8466
move admin puppet envs to /srv
|
Deletions are marked like this. | Additions are marked like this. |
Line 10: | Line 10: |
* Installed https://apt.puppetlabs.com/puppet5-release-stretch.deb manually | * Installed https://apt.puppetlabs.com/puppet6-release-stretch.deb manually |
Line 55: | Line 55: |
* puppetlabs-tagmail * puppetlabs-mailalias_core * smash-jitsimeet * [[https://github.com/voxpupuli/puppet-prosody.git|puppet-prosody]] (for smash-jitsimeet) * puppet-nginx (for smash-jitsimeet) |
|
Line 67: | Line 72: |
* In retrospect this was probably bad and we might want to instead create our own defined type to wrap firewall_multi | |
Line 73: | Line 79: |
* Any root crontabs should have `environment => 'MAILTO=log+SERVICE@hcoop.net'` (where `SERVICE` is the service the cron is related to). This ensures that mail won't go to the wrong address if another job sets `MAILTO` earlier in the crontab. === Deploying Changes === A bare git repo of the `hcoop` puppet module is stored in /afs/hcoop.net/user/h/hc/hcoop/private/hcoop-puppet-module.git. Only the `hcoop` user and members of afs `system:administrators` have access currently. A cron runs every few minutes to pull changes and will send an email to all admins if any changes were made. Each admin has their own personal environment. To deploy, push to the default origin of `/afs/hcoop.net/user/h/hc/hcoop/private/hcoop-puppet-module.git`, and wait for the cron to run (if changes need to be applied sooner, changes can be pulled into the production environment manually). |
|
Line 76: | Line 91: |
Each admin will have a [[https://puppet.com/docs/puppet/5.5/environments_about.html|puppet environment]] where changes should be made and tested with `puppet agent --test --noop --environment $user`. | Each admin will have a [[https://puppet.com/docs/puppet/5.5/environments_about.html|puppet environment]] where changes should be made and tested with `puppet agent --test --noop --environment $user`. Before testing with your environment, even using `--noop`, make sure you have pulled in changes from the central repo. Even `--noop` tests cause puppetdb rules to be created/deleted, and there is no separate environment support in puppetdb so running with a stale environment could trigger unexpected side effects (lasting until the agent automatically runs again and overwrites any spurious facts with the correct ones from production). |
Line 78: | Line 93: |
''incomplete.'' | Setting up: |
Line 80: | Line 95: |
`mkdir -p /etc/puppetlabs/code/environments/clinton_admin/{modules,manifests}` | We store personal environments in `/srv/puppet/environments` so that etckeeper does not persistently alert (causing it to be ignored) if an admin has uncommitted work in their git repo. {{{ mkdir -p /srv/puppet/environments/USER_admin/{modules,manifests} ln -s /srv/puppet/environments/USER_admin/ /etc/puppetlabs/code/environments/USER_admin }}} In `/etc/puppetlabs/code/environments/USER_admin/`: |
Line 90: | Line 112: |
cd $user/modules && git clone /etc/puppetlabs/code/environments/production/modules/hcoop | cd modules && git clone /afs/hcoop.net/user/h/hc/hcoop/private/hcoop-puppet-module.git |
Line 92: | Line 114: |
chown $user: -R /etc/puppetlabs/code/environments/$user | chown USER_admin: -R /etc/puppetlabs/code/environments/USER_admin |
Line 94: | Line 116: |
To checkout, you will need to have afs tokens for a member of `system:administrators`. |
|
Line 98: | Line 122: |
* main git repo is still in production env |
Contents
1. Puppet
As of 2018, HCoop is using Puppet to manage system configuration.
1.1. puppetserver
Hosted on ServerGibran
Installed https://apt.puppetlabs.com/puppet6-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 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
- server
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
- camptocamp-systemd
- puppetlabs-apache
- puppet-logrotate
- puppetlabs-stunnel
- puppetlabs-mysql
- puppetlabs-tagmail
- puppetlabs-mailalias_core
- smash-jitsimeet
puppet-prosody (for smash-jitsimeet)
- puppet-nginx (for smash-jitsimeet)
1.2.1. Specially Installed Module
These are not in puppet forge, but seemed useful enough to deal with manually.
puppet-posix_acl from https://github.com/voxpupuli/puppet-posix_acl
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
- In retrospect this was probably bad and we might want to instead create our own defined type to wrap firewall_multi
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)
Any root crontabs should have environment => 'MAILTO=log+SERVICE@hcoop.net' (where SERVICE is the service the cron is related to). This ensures that mail won't go to the wrong address if another job sets MAILTO earlier in the crontab.
1.4. Deploying Changes
A bare git repo of the hcoop puppet module is stored in /afs/hcoop.net/user/h/hc/hcoop/private/hcoop-puppet-module.git. Only the hcoop user and members of afs system:administrators have access currently.
A cron runs every few minutes to pull changes and will send an email to all admins if any changes were made.
Each admin has their own personal environment. To deploy, push to the default origin of /afs/hcoop.net/user/h/hc/hcoop/private/hcoop-puppet-module.git, and wait for the cron to run (if changes need to be applied sooner, changes can be pulled into the production environment manually).
1.5. Personal Environments
Each admin will have a puppet environment where changes should be made and tested with puppet agent --test --noop --environment $user. Before testing with your environment, even using --noop, make sure you have pulled in changes from the central repo. Even --noop tests cause puppetdb rules to be created/deleted, and there is no separate environment support in puppetdb so running with a stale environment could trigger unexpected side effects (lasting until the agent automatically runs again and overwrites any spurious facts with the correct ones from production).
Setting up:
We store personal environments in /srv/puppet/environments so that etckeeper does not persistently alert (causing it to be ignored) if an admin has uncommitted work in their git repo.
mkdir -p /srv/puppet/environments/USER_admin/{modules,manifests} ln -s /srv/puppet/environments/USER_admin/ /etc/puppetlabs/code/environments/USER_admin
In /etc/puppetlabs/code/environments/USER_admin/:
set up environment.conf
modulepath = ./modules:$basemodulepath:../production/modules manifest = ../production/manifests
check out modules/hcoop:
cd modules && git clone /afs/hcoop.net/user/h/hc/hcoop/private/hcoop-puppet-module.git cd hcoop && git submodule init chown USER_admin: -R /etc/puppetlabs/code/environments/USER_admin
To checkout, you will need to have afs tokens for a member of system:administrators.
problems:
- no tracking of site.pp or top level hiera files
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
- Distributing configuration with apt was time consuming
- Packages must be released, built, uploaded, and installed which could take upward of an hour, compared to Puppet that runs an agent and fetches new updates within minutes
The benefit of automated system installs was realized.
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).