Firstly, a ringing endorsement for Ansible here. I've used Puppet before,
and while that's useful for large fleets of machines which need to be
policed on their configuration, it's not so great for ad-hoc machines.
My worry is the second part of your email where you mix several items into
one block:
* Config files (managed with Ansible) under revision control (um, perhaps
manage the Config files with Ansible, and your ansible scripts with Git)
and convenient auto backup (Or, use etckeeper, and have a cronjob which
does a git push to a central repo store?)
* All superuser actions fully logged (um, auditd is your friend here, so
you'd then need a central syslogd to push those logs to it) and replayable
(yehr, that's not going to happen... - the way to enforce this is to
completely prevent all logins to the box, and manage it entirely with some
automation tooling - like Ansible - but your ops teams [*] will HATE this)
* Nobody gets direct sudo access, but I can give out admin access (yep,
ansible can change user groups and /etc/sudoers files)
Regarding that second item, my employer used
https://www.ssh.com/academy/iam/pam in the past which basically you put in
front of your managed device, and it's the only box with SSH keys to access
it, but it's got a service that records all the TTY while you're logged
into the box. That said, it's a commercial service, and means you've got
another device to manage too.
Regarding learning Ansible, it's pretty straightforward. I've done a few
podcasts about it (shameless plug for the podcast I'm a regular co-host on
-
https://www.adminadminpodcast.co.uk/ep63/ and one where I just joined
them to talk about Ansible -
https://lhspodcast.info/2019/10/lhs-episode-307-ansible-deep-dive/) but
you'll also find lots of videos on Youtube, Udemy and A Cloud Guru about
Ansible.
If this really is a one-off event, then disable password login from your
host, and have it calling out every 30 minutes (to a github repo for
playbook changes using ansible-pull) to enable it again. Your build process
should be:
1. Install OS (any Linux distro will do, but I'd suggest one of the
commercially supportable ones, like RHEL, Ubuntu, etc)
2. Set a LONG password for the root user. Sign in as root.
3. Remove your user account.
4. Install git and python3-pip then `pip install ansible`.
5. git clone
https://some.git.service/yourOrgAccount/OfficeHubMachinePlaybook to
somewhere sensible (changing URL, natch)
6. ansible-playbook /opt/OfficeHubMachinePlaybook/setup.yml
To create your OfficeHubMachinePlaybook, I'd suggest using Vagrant to
rapidly provision and destroy a VM with the configuration on it. That way,
if you want to see what the current state of your deployed host is, you can
just issue `vagrant up` and then it'll be operating like your deployed node.
If you don't mind having a little bit of SSH access into the host - you
could setup and run Ansible Tower (a commercial product from RedHat and
requires a RHEL device to run Tower on) or AWX (the open source upstream
project), as this will record your Ansible activities, including all the
logs from your playbook. It will also schedule regular deployment
activities (e.g. every day, run the security-updates playbook, or every
week, run the full-upgrade playbook, or every time the git repo is updated,
run the provision playbook)... but again, this is another machine you have
to feed and water and manage and maintain. This gives you a friendly web
interface, and as your ops [*] get more capable, they can be trusted to run
more activities on this node, and it keeps all your "secrets".
[*] Obviously, if you don't have an ops team, then ... ignore this part :)
--
Jon "The Nice Guy" Spriggs
@jontheniceguy everywhere...
https://jon.sprig.gs
On Sun, 21 Nov 2021 at 09:18, Ross Younger via users <
users@???> wrote:
> I always meant to get my head around Ansible (or Chef, or Puppet) for my
> VPS based on recommendations on this very list. Sadly I have not yet got
> round to it, and I suddenly find I have a need for something of this ilk
> at work.
>
> My use case is a single Linux instance, on-prem. (No fleet, no cloud, no
> VMs or containers planned.) It's to provide internal services for an
> office network: DHCP, DDNS, maybe NAS, maybe print accounting, maybe
> firewall/router/IDS, maybe apt cache or other proxies.
>
> I think what I want is infrastructure-as-code:
>
> * Config files (/etc) under revision control with convenient automated
> backup
> * All superuser actions are fully logged and replayable (fire drill:
> complete reimage from scratch)
> * Nobody gets direct sudo access, but I can give out admin access via
> the config management tool.
>
> I've had root shells for about 25 years now but I'm new to thinking
> deeply about IaC. I would be grateful for feedback:
>
> - is what I think I want reasonable and achievable? (what are the gotchas?)
> - am I on the right track by looking at Ansible/Chef/Puppet and do any
> of them particularly suit my use case? Are the paid-for versions worth
> paying for?
> - is there a useful noobs guide?
>
> Thanks
>
> Ross
>
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
>
