Date: Tue, 10 May 2016 18:30:53 +0000 From: Glen Barber <gjb@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Thomas Zander <riggs@freebsd.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, current@freebsd.org Subject: Re: HEADS-UP: installworld on r299292 through r299317 will replace master.passwd, passwd, and group files Message-ID: <20160510183053.GJ47527@FreeBSD.org> In-Reply-To: <3902262.K6dzkzNhik@ralph.baldwin.cx> References: <20160510055341.GA47527@FreeBSD.org> <1791715.DtjAh9y9tb@ralph.baldwin.cx> <20160510171228.GI47527@FreeBSD.org> <3902262.K6dzkzNhik@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--b0R8ugpUbPHtGZft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 10, 2016 at 10:22:04AM -0700, John Baldwin wrote: > On Tuesday, May 10, 2016 05:12:28 PM Glen Barber wrote: > > On Tue, May 10, 2016 at 10:04:47AM -0700, John Baldwin wrote: > > > On Tuesday, May 10, 2016 06:32:29 AM Glen Barber wrote: > > > > On Tue, May 10, 2016 at 08:25:22AM +0200, Thomas Zander wrote: > > > > > On 10 May 2016 at 08:18, O. Hartmann <ohartman@zedat.fu-berlin.de= > wrote: > > > > >=20 > > > > > > I haven't figured out so far how far this goes. Lucky for those= having > > > > > > recent /etc/ backups. A pity FreeBSD doens't backup this by def= ault. > > > > >=20 > > > > > After having shot myself in the foot some time ago, "zfs snapshot= " has > > > > > become a part of my standard upgrade procedures :-) > > > > >=20 > > > >=20 > > > > No argument that this is valuable, but we cannot rely on filesystem > > > > specific solutions. Similar topic came up a few days ago following > > > > lunch. It got me thinking of a better way to ensure this kind of t= hing > > > > does not require home-grown foot protection from cannons. > > > >=20 > > > > It should be fairly trivial to automatically backup /etc (and relat= ed) > > > > when 'distribution' is run, either intentionally or accidentally (o= r by > > > > commit mistakes, such as this). > > >=20 > > > Saving the output of 'etcupdate diff' nightly might not be a bad firs= t step. > > >=20 > >=20 > > This is also a good way to alleviate such things, however I am unsure > > how to handle cases where 'etcupdate' would inadvertently run into > > a conflict. This was my concern with implementing an "automatic" > > etcupdate run in the runtime package. >=20 > I mean as part of the nightly jobs we could add one that stores > 'etcupdate diff' in /var the same as we do with backups of the master.pas= swd, > group, and aliases files in /var/backups. You can then at least use that= to > reconstruct altered /etc files by applying the diffs. This isn't meant t= o be > an automated update run, but just saving a diff as part of the nightly jo= bs. >=20 To be clear, I do not disagree with the idea as a whole. However, I think we should considering making this part of the 'installworld' (or a dependent step of installworld) so we don't need to rely on periodic script execution. (Consider cases where one may shut down their laptop before going to sleep, and the job never runs). > As far as what to do in runtime packages, presumably there isn't a single > package with all of etc, but etc files can be split up (ppp.conf in the p= pp > package, etc.) and pkg needs to do its own 3-way merge of changes to conf > files when upgrading. As the state of things are now, /etc is not included in any package (config files exempted), but pkg(8) does have merge ability now. The problem with the initial implementation of "packaging /etc" was that it broke etcupdate(8) and presumably mergemaster(8), as the files were now part of an 'install'-style target, not 'distribute'-style target. But, I think you gave me an idea on how to handle this. (I'll test what I have in mind, but I'm not sure if it will continue to break the merge tools again as a side effect.) > (This would be nice for conf files for ports in > /usr/local/etc as well.) You still need to figure out how to handle > conflicts, but if pkg manages /etc files as config files and does a 3-way > merge of the old package and new package then that will serve to reimplem= ent > etcupdate as part of 'pkg upgrade'. Merge conflicts where human intervention is required is why I am hesitant to add an implicit 'etcupdate' invocation as a post-install script, as it breaks automated, non-interactive upgrades. > Having a 'pkg confdiff' or some such to > output diffs made to conf files would be the equivalent of 'etcupdate dif= f' > in that case (and would be nice as it would apply to conf files in ports = as > well). >=20 Agreed. But, to be honest, I'd like to use etcupdate for this if it comes down to it. We use it in the cluster, and have never run into an issue (until I introduced the change mentioned above, which removed things like /etc/auto_master (part of the autofs package). Glen --b0R8ugpUbPHtGZft Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXMijXAAoJEAMUWKVHj+KTGskP/ietv9tgGTUYr1zwAe4b2EMl OSB5FI3U6wQp/cI14O0atiFMpwwJOtYks+9HNySK2CnUwHr9iz5smFefS846RTcp lMjUWph31C5LYjwU5R7bvNT9oYUwYjvs5FB4tF15ISHoVwCCQ/8CSw3JQ9AHE79n y78UXZbD1znTMUPfa2VL7gd/jO+pOiqUl5O91yfr+S8quK07BHc7am8eRPw7oWKc O35OIzCf+Edn6tIDRNHBif1/vkgjeklooKI9s5boNS7Jnp+KUTjZUNeDrD8MpsiO VzU3O+phWP2juTI8rY+qMhPdbKWION9bF4DERy/BBosYJY++NiX8qbM5gm8uwiJQ dUee1NUC1YYfBGmrs8fTPpQY2tMRvOxQkCvy+jvF3GFKuXFrcU1ZVbnJUNHJP76B xtLsh2HWpRX9UCCEEjo+2lcJx4lpU9yYlT8TLUS5kgqtSoVdcpHvsxutQLYFBy41 iFXvRhls0WqbaVt8XOmatW5mdexXl6uG1kE6+8ITpMQSz5URYnVKcAUujEzAC1hs 7cnlql8KtKwOct+EwbOFMH6LMWP50sJVu1/qHfNpzAT7NYfGVYikhDFgdVYa6C1y a8q8hfi6MroMtQVvW5C4fzcgNHe5PBN2Wuqis6V6YTfTTUmGmqheZtcopUWa/FBC Q1pJ7dlPRf0lUiFUFhOl =dFMH -----END PGP SIGNATURE----- --b0R8ugpUbPHtGZft--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160510183053.GJ47527>