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

31–40 of 57 posts

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

#32

Post by stevekemp »

That's a really cute looking tool. I ran it without installing via:

    uv tool run enroll  single-shot --harvest ./harvest --out ./ansible
It generated almost a thousand roles, and at quick glance it identified many changes which I expected and some that I didn't.

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

#33

Post by _mig5 »

stevekemp wrote: post #32

That's a really cute looking tool. I ran it without installing via: uv tool run enroll single-shot --harvest ./harvest --out ./ansible It generated almost a thousand roles, and at quick glance it identified many changes which I expected and some that I didn't.

Yup - it can be pretty overwhelming, it depends on what it detected on your system! The state.json will usually explain why it 'harvested' something (perhaps it was because it found a running systemd service, perhaps it was due to detecting a package having been manually installed, etc)

There is the --exclude option which might help (also keep in mind you can define an enroll.ini file to manage the flags so it's less cumbersome). Otherwise, you can always prune the roles from the ansible dir/playbook.

I'm going to continue to work on easy options to skip stuff. In particular I do think many of the 'lib' packages could be omitted if they are just dependencies of other packages already detected as part of the harvest. (Need to basically build a dependency graph)

Thanks for trying it out!

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

#34

Post by usrme »

An incredible undertaking! How much testing have you done with regards to harvesting a manual configuration into Ansible, creating a new machine and then applying that to see whether the machine is a functional representation of the old machine?

The reason I'm asking is because I'm interested in how much confidence could be lent to this tool with regards to more old and obscure machines that have been running for years.

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

#35

Post by mlrtime »

_mig5 wrote: post #33
stevekemp wrote: post #32

That's a really cute looking tool. I ran it without installing via: uv tool run enroll single-shot --harvest ./harvest --out ./ansible It generated almost a thousand roles, and at quick glance it identified many changes which I expected and some that I didn't.

Yup - it can be pretty overwhelming, it depends on what it detected on your system! The state.json will usually explain why it 'harvested' something (perhaps it was because it found a running systemd service, perhaps it was due to detecting a package having been manually installed, etc) There is the --exclude option which might help (also keep in mind you can define an enroll.ini file to manage the flags so it's less…

Can you create a baseline system to create the ignores?

What I mean is in some large companies you are given a host that already has lots of config changes, possibly by ansible. Then your team has to configure on top of those changes, maybe ansible again. I'd like to run on the baseline system given to create a baseline, then on a production host to see how it drifted.

Sorry if this is in the docs, cool tool!

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

#36

Post by c0balt »

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.

The other comment already answers part of it, there is no real need for it for a NixOS system as you usually either can consult the store on the machine (and recursively build a graph of a all transitive dependencies of a generation), have a system that stores the config along with the generation (option `system.copySystemConfiguration` or a flake-based system will store the config in the store itself).

A system that has neither a store nor the config (container image) not easily reconstructable as you miss too much metadata.

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

#37

Post by westurner »

_mig5 wrote: post #24
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 in…

Thanks for your reply. As well; otoh:

Does it already indirectly diff the output of `systemd-analyze security`?

Would there be value to it knowing the precedence order of systemd config files? (`man systemd.unit`)

How to transform the generated playbooks to - instead of ansible builtins - use a role from ansible-galaxy to create users for example?

How to generate tests or stub tests (or a HEALTHCHECK command/script, or k8s Liveness/Readiness/Startup probes, and/or a Nagios or a Prometheus monitoring config,) given ansible inventory and/or just enroll?

Ansible Molecule used to default to pytest-testinfra for the verify step but the docs now mention an ansible-native way that works with normal inventory that can presumably still run testinfra tests as a verify step. https://docs.ansible.com/projects/molecule/configuration/?h=...

MacOS: honebrew_tap_module, homebrew_module, homebrew_cask_module, osx_defaults_module

Conda (Win/Mac/Lin, AMD64, ARM64, PPC64, RISC-V 64 (*), WASM)

CycloneDX/cyclonedx-python generates SBOMs from venv, conda, pip requirements.txt, pipenv, poetry, pdm, uv: https://github.com/CycloneDX/cyclonedx-python

Container config: /var, $DOCKER_HOST, Podman, Docker, $KUBECONFIG defaults to ~/.kube/config (kube config view), Podman rootless containers

Re: vm live migration, memory forensics, and diff'ing whole servers:

Live migration and replication solutions already have tested bit-level ~diffing that would also be useful to compare total machine state between 2 or more instances. At >2 nodes, what's anomalous? And how and why do the costs of convergence-based configuration management differ from golden image -based configuration management?

E.g. vmdiff diffs VMs. The README says it only diffs RAM on Windows. E.g. AVML and linpmem and volatility3 work with Linux.

/? volatility avml inurl:awesome https://www.google.com/search?q=volatiloty+avml+inurl%3Aawes...

Post reply on HN