search

BastilleBSD / bastille

Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.
https://bastillebsd.org
BSD 3-Clause "New" or "Revised" License
783 stars 130 forks source link

New 'etcupdate' sub command #660

Open Rodrigo-NH opened 5 months ago

Rodrigo-NH commented 5 months ago

Hi. Started testing bastille recently and faced problems when upgrading 13.2-RELEASE 'test' jail to 14.0-RELEASE. The jail could start but wasn't able to 'bastille console' into the jail. This helped me solving this problem: https://forums.freebsd.org/threads/bastille-upgrading-jail-from-13-2-to-14-0-fails.91234/

I understand that this is not bastille fault, intrinsically. By the other hand it's concerning. It's non trivial having ./etc in sync considering different use cases, security changes, features or any other mix of situations like the issue I had.

The idea of 'etcupdate' command is to achieve a minimal level of sanity of ./etc folder, while being 'conservative' in regard to user modifications/additions made there. Includes a dry-run option and logs a semi-detailed log output. It's possible to see what it does checking the attached logfile produced by:

"bastille etcupdate -D testjail 13.2-RELEASE 14.0-RELEASE" from untouched 13.2-RELEASE jail upgraded to 14.0-RELEASE. The options of what FreeBSD versions to compare are explicit. That's, script will compare actual jail's ./etc files against the two any reference versions, distributed along 8 conditions executed serially.

I don't know if this type of approach would be considered bastille scope by project owners. It's something I had to do anyway (do something about) because I'm worried about actual conditions of my prod jails (accumulating updates since... can't even remember). I tried to test it as thoroughly as I could ATM and it looks OK. Tested with bastille with ZFS and without with same results.

Thanks! etcupdate.log

Rodrigo-NH commented 5 months ago

While this change is somewhat opinionated, to be opinionated is necessary for this feature.

That's how I see it too. Can be useful in many cases and doesn't hurt edge cases if it's run anyway (but not entirely sure on this). A generic option. I really appreciate suggestions in regard to English as it's not my native language. Thanks!

stafwag commented 3 weeks ago

This PR might be related to: https://github.com/BastilleBSD/bastille/issues/704

Any idea when this PR can be merged? It'd be nice to have this feature implemented/documented as it allows to upgrade thin jails without manual interventions.

scoobybejesus commented 2 weeks ago

Another issue came to mind while trying to test this. In short, this process would be better if it could detect the version of /etc that the jail has and account for it.

For example, I created a jail with 13.0-RELEASE. It currently runs on 13.2-RELEASE, but I haven't done any etcupdate procedures; I've only changed the fstab to point to the new 13.2-RELEASE base jail. When I first ran this etcupdate command on it, I told it to go from 13.2-RELEASE to 14.1-RELEASE, but I should really be telling it to go from 13.0-RELEASE to 14.1-RELEASE.

But that's actually not the major issue I'm finding. Looking at the diff's comparing 13.0 to the files it said are different in my jail, I didn't change most of the files. Unfortunately, this method of performing an etcupdate is a bit too crude to pick up on patch changes.

For example, I didn't make changes to $JAIL/root/etc/rc.d/gssd or $JAIL/root/etc/devd/iwmbtfw.conf or the enormous /root/etc/ssh/moduli files, but this diff shows that my jail has different files than 13.0 or 13.2, so it's leaving these changes undone. This is the case for many files.

If this etcupdate could detect that these files are from a jail created with, for example 13.0-RELEASEp0, then there would be no diff for $jail vs currentbasefile, and it would cleanly be able to copy the new file. Instead, I have a diff in C5 of 45 files that is over 2,000 lines long (mostly due to the moduli file).

It would be a hassle to interactively approve patch after patch 45 times, but I'm inclined to say interactively approving patches would be preferable to the current state where it simply skips all these files because it thinks I have modified them.

Rodrigo-NH commented 1 week ago

Yeah I agree that having to indicate the from version can be problematic. I was trying to think some approach to this fact by the time I wrote script. My conclusion was I'm not able to determine version automatically and reliably.

/etc/os-release is obsolete ( https://forums.freebsd.org/threads/determining-the-version-of-freebsd.31324/ ) /etc/motd is out of question for obvious reasons Other reference I can't remember right now, but also unreliable accross historical versions I thought about creating/mantaining a table referencing first line of /etc/ssh/moduli to correlate moduli versions/dates to specific freebsd versions but I'm not sure that would be reliable as well.

Or (rethoric question): If you inspect C4 condition, if most files are listed there this would be a good measure that you're comparing the right version? How reliable/unreliable is this manual comparison against trying to detect it automatically?

Ideas?

As for the interactive approach for me it sounds like a nice idea if added as user option (e.g. can opt for just doing it without asking)