Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

enroll.sh

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

#21

Post by _mig5 »

neilv wrote: post #19

This is a great idea. I have done this manually, and it was a lot of work. Even with a tool, people will still have to understand the output, enough that they can spot situations like "this part doesn't make sense at all", "that bit isn't static", "holy crud, there's an unsecured secret", "this part suggests a dependency on this other server we didn't know was involved, and which the tool doesn't investigate".

I agree! It's always a 'best effort' tool. There's going to be corner cases where something that might end up in the 'logrotate' role could arguably be better placed in a more specific app's role.

It does an okay job at this sort of thing, but definitely human eyes are needed :)

Re: Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

#23

Post by westurner »

Could it also detect changed package files; if there are per-package-file checksums like with `debsums` and `rpm -V`?

Does it check extended filesystem labels with e.g. getfacl for SELinux support?

I've also done this more than a few times and not written a tool.

At least once I've scripted better then regex to convert a configuration file to a Jinja2 templated configuration file (from the current package's default commented config file with the latest options). And then the need is to diff: non-executable and executable guidelines, the package default config (on each platform), and our config.

Sometimes it's better not to re-specify a default config param and value, but only if the defaults are sane on every platform. Cipher lists for example.

P2V (physical to virtual) workflows don't result in auditable system policy like this.

Most of the OS and Userspace packages backed up in full system images (as with typical P2V workflows) are exploitably out of date in weeks or months.

To do immutable upgrades with rollback, Rpm-ostree distros install the RPM packages atop the latest signed immutable rootfs image, and then layer /etc on top (and mounts in /var which hosts flatpaks and /var/home). It keeps a list of packages to reinstall and it does a smart merge of /etc. Unfortunately etckeeper (which auto-git-commits /etc before and after package upgrades) doesn't yet work with rpm-ostree distros.

Ansible does not yet work with rpm-ostree distros. IIRC the primary challenge is that ansible wants to run each `dnf install` individually and that takes forever with rpm-ostree. It is or is not the same to install one long list of packages or to install multiple groups of packages in the same sequence. It should be equivalent if the package install and post-install scripts are idempotent, but is not equivalent if e.g. `useradd` is called multiply without an explicit UID in package scripts which run as root too.

I wrote a PR to get structured output (JSON) from `dnf history`, but it was for dnf4.

From https://news.ycombinator.com/item?id=43617363 :

> upgrading the layered firefox RPM without a reboot requires -A/--apply-live (which runs twice) and upgrading the firefox flatpak doesn't require a reboot, but SELinux policies don't apply to flatpaks which run unconfined FWIU.

Does it log a list of running processes and their contexts; with `ps -Z`?

There are also VM-level diff'ing utilities for forensic-level differencing.

Re: Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

#24

Post by _mig5 »

westurner wrote: post #23

Could it also detect changed package files; if there are per-package-file checksums like with `debsums` and `rpm -V`? Does it check extended filesystem labels with e.g. getfacl for SELinux support? I've also done this more than a few times and not written a tool. At least once I've scripted better then regex to convert a configuration file to a Jinja2 templated configuration file (from the current package's default c…

Hi westurner!

> Could it also detect changed package files; if there are per-package-file checksums like with debsums and `rpm -V`?

Yes, that's exactly what it does. See https://git.mig5.net/mig5/enroll/src/branch/main/enroll/plat... and https://git.mig5.net/mig5/enroll/src/branch/main/enroll/rpm....

It also tries to ignore packages that came with the distro automatically, e.g focusing on stuff that was explicitly installed (based on 'apt-mark showmanual' for Debian, and 'dnf -q repoquery --userinstalled' (and related commands, like dnf -q history userinstalled) for RH-like)

> Does it check extended filesystem labels with e.g. getfacl for SELinux support?

Not yet, but that's interesting, I'll look into it.

> At least once I've scripted better then regex to convert a configuration file to a Jinja2 templated configuration file (from the current package's default commented config file with the latest options).

Yep, that was the inspiration for my companion tool https://git.mig5.net/mig5/jinjaturtle (which enroll will automatically try and use if it finds it on the $PATH - if it can't find it, it will just use 'copy' mode for Ansible tasks, and the original files).

Note that running the `enroll manifest` command against multiple separate 'harvests' (e.g harvested from separate machines) but storing it in the same common manifest location, will 'merge' the Ansible manifests. Thereby 'growing' the Ansible manifest as needed. But each host 'feature flips' on/off which files/templates should be deployed on it, based on what was 'harvested' from that host.

> Does it log a list of running processes and their contexts; with `ps -Z`?

It doesn't use ps, but it examines systemctl to get a list of running services and also timers. Have a look at https://git.mig5.net/mig5/enroll/src/branch/main/enroll/syst...

Thanks for the other ideas! I'll look into them.

Re: Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

#26

Post by ptman »

novoreorx wrote: post #16

I wonder if Nix has similar tools, as it is famous for declarative system management, which is quite suitable for server provisioning.

It's hard with nix to end up with a system without first having a config for that system

Re: Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

#29

Post by _mig5 »

indigodaddy wrote: post #25

Does the playbook generation have support for some totally custom/one-off application? (Eg, not just system/well-known stuff). If so, that would be insane!

It does! There are several sort of 'catch-alls' in place:

1) stuff in /etc that doesn't belong to any obvious package, ends up in an 'etc_custom' role

2) stuff in /usr/local ends up in a 'usr_local_custom' role

3) Anything you include with --include will end up in a special 'extra_paths' role.

Here's a demo (which is good, helped me spot a small bug, the role is included twice in the playbook :) I'll get that fixed!) https://asciinema.org/a/765385

Thanks for your interest!

Re: Show HN: Enroll, a tool to reverse-engineer servers into Ansible config mgmt

#30

Post by indigodaddy »

_mig5 wrote: post #29
indigodaddy wrote: post #25

Does the playbook generation have support for some totally custom/one-off application? (Eg, not just system/well-known stuff). If so, that would be insane!

It does! There are several sort of 'catch-alls' in place: 1) stuff in /etc that doesn't belong to any obvious package, ends up in an 'etc_custom' role 2) stuff in /usr/local ends up in a 'usr_local_custom' role 3) Anything you include with --include will end up in a special 'extra_paths' role. Here's a demo (which is good, helped me spot a small bug, the role is included twice in the playbook :) I'll get that fixed!)…

Nuts, I'm going to have to try this out. Pretty sure nothing like this exists, at least not for Ansible (?). This would certainly help converting chef cookbooks (we have a ton of custom applications along with system stuff of course) to Ansible (I guess it's not really converting in this scenario, just scanning the host(s), super neat!). We are still using chef, and use Ansible for one-off jobs/playbooks/remediations etc, but would like to pivot to Ansible for config mgmt of everything for deployments at some point. This definitely looks useful in that effort.
Post reply on HN