[tech] Config management: etckeeper vs dedicated repos

Nick Bannon nick at ucc.gu.uwa.edu.au
Wed Dec 27 12:35:14 AWST 2023


There's been a a few starts on trying to mechanise our deployments,
turning on a new machine or service often involves touching:

- DNS/IP allocation
  - https://gitlab.ucc.asn.au/ucc-systems/ucc-domains
- DHCP (thanks, [MPT] murasoi:/etc 2023-11-29)
  - https://gitlab.ucc.asn.au/ucc-configuration/ucc-dhcp
- firewalls
  - https://gitlab.ucc.asn.au/ucc-configuration/ucc-fw
- switches/routers
  - murasoi:/etc/cron.hourly/11rancid
- passwords/uccpass/push.sh
- Proxmox? more?

It's good to get those changes into a git repo somewhere but
recent centralisation&visibility improvements have been fighting
the "automatic" etckeeper mechanism.

A lot of us have become used to hacking at live config, at least for
testing. We can kind of get away with that when etckeeper/rancid captures
each change with a daily autocommit - although it's a lot nicer when
there's a meaningful specific log message. Especially if multiple files
are touched at once.

However if the "source of truth" is being synced/push/pulled into a
shared or centrally visible repo, like our authroot or DNS/DHCP/firewall,
I think we need to make sure all the changes really are being promptly
and meaningfully committed.

What's the least we can get away with? Running through a list of repos
and mailing us here if there's an outstanding `git status`/`git diff` ?

The list of repos probably has a lot of overlap of what needs to be in:
/etc/gitconfig
https://gitlab.ucc.asn.au/ucc-systems/ucc-ansible-soe/-/blob/master/roles/ucc_tweaks/tasks/main.yml#L17

Nick.

-- 
   Nick Bannon   | "I made this letter longer than usual because
nick-sig at rcpt.to | I lack the time to make it shorter." - Pascal


More information about the tech mailing list