From owner-freebsd-pkg@freebsd.org Fri Jun 16 11:10:44 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 15483BFDBA7 for ; Fri, 16 Jun 2017 11:10:44 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 CB8F77AEB4 for ; Fri, 16 Jun 2017 11:10:43 +0000 (UTC) (envelope-from egypcio@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id b6so22359986oia.1 for ; Fri, 16 Jun 2017 04:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=LmW0pfT8x5++0i71WCCYLzuB7Y5o5HP/vMxIYWkPWIU=; b=GIzmGXEwhFSPq58S5Nk3TSMhfCuyT9g4vFVxS8bLWUh0zaV1XELKqAqm16iCFIh12E kkoRvqT7QnuwXX8yT/Hs4iLt9+IwVdSKH+pVd+g1vqPFvDIAq+5pwBypkmb3Ba1ifSV7 guV8HUUrDKcgfAmL95l8roBoDaae8LN79E7SEoMvoSKSvAOOH6V0wQ2nzfzLdraELg2A ugSuoaywObgPd0BMYVs7/9p/7u1+djlXFiVcXD0o61wPiIYQLduTDFeJPhY4EFr6HuYI LgKGe4iKLWN2l5hUeF1Z4ZZ9MPFoN6g0CPyS6n9e4sOu1OMxUbFNG3xeybNKGYYH48kd aCDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=LmW0pfT8x5++0i71WCCYLzuB7Y5o5HP/vMxIYWkPWIU=; b=EY32ecrZqp+0mzfTqqZ94cqwUTGRjyTmWR3oh2gn34u4EmDofL6OydPR1ws7LVuYdu X0GhyPOorxOLjDsbUMRR02p9BczwTs76sIWXGyZ9gKRGOKOQVleRWbbYMz/CWKP3pyH1 +/JE/wcA986VTuZ1C9WH4tLSMRhBqdfNK/ufNh5TBTrgL4N+VYkTw9mNYxiCID5xscMf njOeKkKVj9+WP+D0qD9Eg+qX6dG8t7H7DuWpjzeuYEMiisnQ2JKka9o134RvUDZNdIhL qklAR7QLxX5yXThPjCmqJtEtg87po3JrbIiAiNT6EqeGu65mZZcXalMjJ4M12/YcROVs UY5g== X-Gm-Message-State: AKS2vOy++DXHrV3ZIiiq+nSe0cDXS3edoNHBmwV6CcPp2oNHc7oEHSS6 ZuT93CYNTGSMHBgyH4aGEGZmSPXFyQ== X-Received: by 10.202.75.7 with SMTP id y7mr5238648oia.151.1497611443020; Fri, 16 Jun 2017 04:10:43 -0700 (PDT) MIME-Version: 1.0 Sender: egypcio@gmail.com Received: by 10.182.134.42 with HTTP; Fri, 16 Jun 2017 04:10:42 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Vin=C3=ADcius_Zavam?= Date: Fri, 16 Jun 2017 13:10:42 +0200 X-Google-Sender-Auth: vjLvxS8eQJfSRFNP79_jMlAWx30 Message-ID: Subject: Re: pkg rollback To: Luca Pizzamiglio Cc: Arto Pekkanen , freebsd-pkg@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 16 Jun 2017 11:10:44 -0000 2017-06-08 11:42 GMT+02:00, 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 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 >> --=20 Vin=C3=ADcius Zavam keybase.io/egypcio/key.asc