pkg rollback

[Vinícius Zavam]

2017-06-08 11:42 GMT+02:00, Luca Pizzamiglio <luca.pizzamiglio at gmail.com>:
> yes zfs snapshot/rollback could be usable, if /usr/local is on zfs.
> If /usr/local is on ufs, zfs snapshot is not an option :)
>
> Several older systems here were installed with root based on ufs and
> /usr/local is not on the zfs tank :( Reinstall all of them is,
> currently not an option.
>
> IMHO pkg snapshot/rollback would work on ufs and only for packages,
> but I see zfs as a valuable option, if applicable.
>
> Best regards,
> Luca
>
> On Thu, Jun 8, 2017 at 2:53 AM, Arto Pekkanen <isoa at kapsi.fi> wrote:
>> Why does not ZFS snapshot and rollback work for this scenario?
>>
>> On 7.6.2017 16:40, Luca Pizzamiglio wrote:
>>> Hi all,
>>>
>>> I'm trying to figure out how an automatic process to upgrade packages
>>> on production machines can look like.
>>>
>>> A kind of:
>>> # pkg upgrade
>>> # restart services
>>> # if everything not OK
>>> #   rollback
>>> #   restart services
>>>
>>> I'm considering a package repository that is not guaranteeing 100%
>>> stability, like `latest`.
>>> Even intercepting events needing manual intervention (i.e. reported by
>>> UPDATING), a blind pkg upgrade can break the web application running
>>> on top.
>>> So, I was thinking if it's possible to perform some kind of rollback.
>>>
>>> to proof if it's possible, I wrote a shell scripts with two features
>>> (it helped me a lot to understand how pkg works):
>>> # backup
>>> ## backup the repo sqlite database
>>> ## run `pkg update` and determine all actions would be performed by
>>> `pkg upgrade` (a kind of `pkg upgrade` simulation)
>>> ## backup all packages from the cache that would be replaced by `pkg
>>> upgrade`
>>> ## download all new packages to determine potentially conflicts
>>> ## backup all packages from the cache that would be replaced by `pkg
>>> upgrade` (after determined conflicts)
>>> ## restore the repo sqlite database
>>> # rollback
>>> ## restore the repo sqlite database
>>> ## install all previously backup'ed packages

here, when you say "backup packages" you mean that you're gonna use
'pkg create' to save your current installed packages, or just save the
whole /var/cache/pkg? if you are not using 'pkg create', try to
associate some of your services to some packages and run a check after
restarting it; if it fails, reinstall the created package using the
old|stable version.

>>> Another approach, less complex, but I guess even valid, could be:
>>> # backup (or snapshot)
>>> ## backup of the repo sqlite database
>>> ## take a snapshot of all installed packages
>>> # rollback (a previously stored snapshot)
>>> ## restore the repo sqlite database
>>> ## reinstall all previously backup'ed packages
>>>
>>> Adding two features [snapshot and rollback] to pkg(8), the automated
>>> upgrade process would become:
>>> # pkg snapshot
>>> # pkg upgrade
>>> # restart services
>>> # if everything not OK
>>> #   rollback
>>> #   restart services
>>>
>>> What do you think?
>>> What am I missing?
>>> Ideas, suggestions and feedback are welcome, so, please, feel free to
>>> reply.
>>>
>>> Best regards,
>>> Luca
>>>
>>> PS: I'd use `pkg snapshot`, because `pkg backup` already exist and it
>>> has another meaning.
>>> PS2: In some case, `zfs snapshot` could work as well, but it's not
>>> always possible

you can also count on
https://www.freebsd.org/doc/en/books/handbook/snapshots.html or
depending on your current scenario, it might also be possible to use
dump+restore. no?

>>> PS3: if feebacks are positive, I'd like to implement those features
>>>
>>
>> --
>> Arto Pekkanen
>>


-- 
Vinícius Zavam
keybase.io/egypcio/key.asc