From owner-freebsd-pkg@freebsd.org Thu Jun 8 09:42:50 2017 Return-Path: Delivered-To: freebsd-pkg@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69C0EBFAC12 for ; Thu, 8 Jun 2017 09:42:50 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E9087B503 for ; Thu, 8 Jun 2017 09:42:50 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id s3so16255272oia.0 for ; Thu, 08 Jun 2017 02:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dj9Cvjz81huzECczUxr1/UL5RhIw+4L7vaT8kK6ihZs=; b=WOfNc7o+tAvQFQ6Ppcjojvu+aMV2gycObThWM71C3K5j+L6wDUHRQvRl3tk61hFsUY xIUxxf6Wahm+9GMg+NKSSejZv48i7A3FqNr802CNv2Wmja6MsLlVSW3tTo1aIt3Jj5/a C9Ik2Ili2N+mjVxm8d97BJ83OYxC5sEeLIqkBiEVoF5YbykQdlovOuFtBd44hUkXr41u KYm82rHeJLDrmoR9bFeaxJaGxrJjKa7sY9qVR8VAtNZVlDkeuMN9geeT/a5K8MIxRrMQ PDhROBvL2x/UEZ0f4vq+IVM4o5IEzp/G2yLjfJE7yjEi7gh1acP+v/uRObbDuh2unyhf Nh2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dj9Cvjz81huzECczUxr1/UL5RhIw+4L7vaT8kK6ihZs=; b=Bcm6fOY9EcS47mQveDsniOegoyCBu9/PyZRPp1r7Tr3Z0oJjd4drmn6hHFZR6zOi+g Hz9mMPVxyDbAGoy8j0MWNAm8Murs9PUUgJZE7rIL12TOzW/TyyPQZva1jDkKVd23xZy+ +7ClHzmdxopuodG/CkFTAIqUmkNZJ8g1Dkm9mupT/6npLSwPXOVypEmBBQfD0zZniiLv S+BC4Pko7sfvXAGbrj0HxwSMmVCRc+0XRbVKN8UIz1IE/cLGrJkujbb/r+h5v20qkxjo 1gmmd0dfmej0TXj/DPa8Wdbq6rIO3CV/ZWrTCVPyze3v09dGqH9WTkRbh11gTUOBn1+A viqQ== X-Gm-Message-State: AODbwcA9J/3tGXP3JXcYI4BAxq2jxuVe3YlT07lrEGFd0B4kc8wqlJ2a 996peynPkpdAu/+GW7z2M9Z5NyVSdZhT X-Received: by 10.202.168.85 with SMTP id r82mr5469527oie.91.1496914969535; Thu, 08 Jun 2017 02:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.47.103 with HTTP; Thu, 8 Jun 2017 02:42:29 -0700 (PDT) In-Reply-To: References: From: Luca Pizzamiglio Date: Thu, 8 Jun 2017 11:42:29 +0200 Message-ID: Subject: Re: pkg rollback To: Arto Pekkanen Cc: freebsd-pkg@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 09:42:50 -0000 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 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@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-pkg >> To unsubscribe, send any mail to "freebsd-pkg-unsubscribe@freebsd.org" >> > > -- > Arto Pekkanen >