Live data from Hacker News

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

enroll.sh

51–57 of 57 posts

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

#51
post #50
post #48

Earlier quoted context omitted.

Ah, this is not a problem for me on my remote hosts. I'm guessing this comes down to a sudoers policy on certain distros (redhat-like ones perhaps). I'm about to make a new release and I'll set `get_pty=True` for the paramiko calls that use sudo. I'm not 100% sure if it will fix it for all use cases, but hopefully it will.

It's just plain Ubuntu actually! I would provide a fix, since getting a PTY is not enough. I can't open a PR because it's not possible with the way you hosted it.

Dang! Seems strange.. I guess you are not using password-less sudo? (I'm interested to understand how Ansible itself works for you then too in such a setup, you have it prompting for a password when it invokes sudo?)

Yeah, I haven't been confident enough with Forgejo's federation capabilities yet to open up PRs/login etc. Maybe soon. Trying to avoid using Github and the other big providers if I can help it :) but I recognise it's a hindrance..

I'll happily take a patch and credit you, if you can be bothered, but I understand if not. Feel free to email mig@mig5.net

*EDIT* reading up on it, sounds like I need to use sudo -S and accept stdin..

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

#52
Thanks for all the love HN!

I had a lot of good feedback directly from the comments here, and have made a new release that contains some bug fixes, as well as an improvement to support remote harvesting when the user requires a password for sudo. Thanks to 'slhck' here for the help, advice and patch for that.

There have also been some questions about 'what does enroll harvest actually capture in its state'. I've updated the docs here to clarify the process:

https://enroll.sh/docs.html#harvest

And for the data/API nerds, I've also published a JSON Schema of the state.json file here:

https://enroll.sh/schema.html

Thanks again!

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

#53
post #29

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!)…

Also, enroll.sh could be VERY useful for vibe-coding. git tracking will only capture application-level (unless you are fully dockerizing the app), however, for example if you are done vibe-coding your app, point enroll.sh at the VM or whatever you are using (this is assuming you are vibe-coding to a Linux system/VM/instance with ssh available), and you can then capture both application and system level needs, and have an Ansible playbook that you can deploy anywhere at the end of it. Eg, I told the folks on exe.dev that enroll.sh would be very useful for a service like exe.dev.

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

#54
post #29

Earlier quoted context omitted.

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!)…

Also, enroll.sh could be VERY useful for vibe-coding. git tracking will only capture application-level (unless you are fully dockerizing the app), however, for example if you are done vibe-coding your app, point enroll.sh at the VM or whatever you are using (this is assuming you are vibe-coding to a Linux system/VM/instance with ssh available), and you can then capture both application and system level needs, and hav…

Cool tool, didn't know it existed! :) Thanks for passing on the word. 'Capture app and system stuff and deploy anywhere' is totally the goal :)

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

#55
post #49
post #43

A question I didn't see answered on the Web site or in the comments... How does it determine what is "state"? Packages are easy, you just get a list of those with the package manager. I guess systemd lists services. But what about everything else? Is it just walking the whole file system and checking every file it finds to see if a package owns it? What about files and symlinks created by postinst scripts? Does it ha…

Thanks for the comment and questions! Very wise. Let me break it down as to what harvest does: 1) Detects the OS and its package backend (e.g dpkg vs rpm etc) 2) Detects what packages are installed 3) For each package, it tries to detect files in /etc/ that have been modified from the default that get shipped with the package . It does't walk the whole filesystem, it looks straight in /etc for stuff here. 4) It detec…

I captured most of the above in the docs now:

https://enroll.sh/docs.html#harvest

I've also published a JSONSchema of the state.json file here to help people understand its structure: https://enroll.sh/schema.html

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

#57
Hi everyone! I'm pleased to report I'm releasing Enroll 0.4.0 today. It has some cool new features:

--ignore-package-versions for 'enroll diff' ,so you don't get alerted to just standard software updates of existing packages

--exclude-path for 'enroll diff', in case you need to ignore noisy drift but can't ignore the path from the harvest itself

'enroll manifest' will now add 'tags' in the playbook so you can use --tags with ansible to selectively apply specific roles from the playbook instead of everything.

And get ready for the big one....

--enforce for 'enroll diff'! Here's a video of it https://asciinema.org/a/766934

If a diff exists and `ansible-playbook` is available, Enroll will: 1) generate a manifest from the *old* harvest into a temporary directory

2) run `ansible-playbook -i localhost, -c local /playbook.yml` (often with `--tags role_` to limit how much has to run in the play)

3) record in the diff report that the old harvest was enforced

Enforcement is intentionally “safe”:

- reinstalls packages that were removed (`state: present`), but does *not* attempt downgrades/pinning

- restores users, files (contents + permissions/ownership), and service enable/start state

If `ansible-playbook` is not on `PATH`, Enroll returns an error and does not enforce.

Basically, 'enroll diff [...] --enforce' is akin to Puppet agents checking in with Puppetmaster and re-applying the declared state.

The new release also has some other smaller features also in place, such as 'enroll validate' which will check that a harvest is not corrupted or containing any orphaned artifacts.

Enjoy! And thanks for all the fish^Wlove.

Post reply on HN