pkg rollback

[Luca Pizzamiglio]

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
>>
>> 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
>> PS3: if feebacks are positive, I'd like to implement those features
>> _______________________________________________
>> freebsd-pkg at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-pkg
>> To unsubscribe, send any mail to "freebsd-pkg-unsubscribe at freebsd.org"
>>
>
> --
> Arto Pekkanen
>