On 05/10/2016 13:22, 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 <ohart...@zedat.fu-berlin.de> wrote:
>>>>>> 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 default.
>>>>> After having shot myself in the foot some time ago, "zfs snapshot" has
>>>>> become a part of my standard upgrade procedures :-)
>>>> 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 thing
>>>> does not require home-grown foot protection from cannons.
>>>> It should be fairly trivial to automatically backup /etc (and related)
>>>> when 'distribution' is run, either intentionally or accidentally (or by
>>>> commit mistakes, such as this).
>>> Saving the output of 'etcupdate diff' nightly might not be a bad first step.
>> 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.
> 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.passwd,
> 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 to be
> an automated update run, but just saving a diff as part of the nightly jobs.
That's what I do. The periodic "etcupdate diff" dumps, which I was
already taking despite boot environments helped me work through various
> 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 ppp
> package, etc.) and pkg needs to do its own 3-way merge of changes to conf
> files when upgrading. (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 reimplement
> etcupdate as part of 'pkg upgrade'. Having a 'pkg confdiff' or some such to
> output diffs made to conf files would be the equivalent of 'etcupdate diff'
> in that case (and would be nice as it would apply to conf files in ports as
Having "pkg confdiff" would be wonderful, for both base and ports.
- Nikolai Lifanov
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"