From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Self-contained Guix tarball Date: Tue, 21 Apr 2015 10:11:29 +0200 Message-ID: <87zj61q4su.fsf@gnu.org> References: <20150410084651.GA23353@thebird.nl> <873848p5kd.fsf@gnu.org> <20150410131420.GB24509@thebird.nl> <87a8ydt8k8.fsf_-_@gnu.org> <871tjlxen6.fsf@gnu.org> <20150416053355.GD21015@thebird.nl> <87k2x9b061.fsf@gnu.org> <87h9sci6n7.fsf@taylan.uni.cx> <87pp6ywmny.fsf@inria.fr> <20150421070357.GB15795@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkTHM-0003d2-8b for guix-devel@gnu.org; Tue, 21 Apr 2015 04:11:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkTHI-0004jX-92 for guix-devel@gnu.org; Tue, 21 Apr 2015 04:11:36 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkTHI-0004jT-6E for guix-devel@gnu.org; Tue, 21 Apr 2015 04:11:32 -0400 In-Reply-To: <20150421070357.GB15795@thebird.nl> (Pjotr Prins's message of "Tue, 21 Apr 2015 09:03:57 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins Cc: guix-devel@gnu.org Pjotr Prins skribis: > When you administrate a large amount of servers things can go wrong > due to system failures, failed backup recoveries, hacking attempts and > adminstrators trying to be clever ;). Murphy's law dictates that the > store and the sqlitedb meta information will go out of sync. For > production setups it is necessary to be able to recover from backups, > but as an intermediate recovery step it would be really nice if Guix > could recover its meta information from an existing store - assuming > only the DB is corrupt (google for sqlite corrupted databases). It is > especially nice when your backups are out of sync too. The important thing is that currently, the DB is authoritative. So it cannot be corrupt (that would be equivalent to having lost /gnu/store altogether), and thus it cannot be repaired. What *can* be repaired is the store: for instance, if a store item is tampered with. The daemon has code to do it, but the Guix client tools do not expose it yet. > guix archive looks good, but for speedy deployment it can happen an=20 > adminstrator would have a simple use case of: > > - Copying 2 stores to 1 machine > - Rebuild database > > to do it quick and dirty. Since all software packages are isolated > this would make a really good use case even if (with some trouble) you > could use guix archive for that. I prefer quick and dirty. > > I am not pushing for this functionality directly, but I would > certainly like to have it when I need it :) I don=E2=80=99t think it could work the way you envision it. What kind of deployment do you have in mind? For whole system deployment, one can obviously use =E2=80=98guix system=E2=80=99. >> I suspect this would make GC inefficient (lots of disk seeks to >> determine references/referrers compared to queries of the SQLite >> database.) > > Yes, Nix switched to using sqlitedb because of the GC. I think it=E2=80=99s been there =E2=80=9Cforever=E2=80=9D (at least since I= started contributing in 2008.) > It is also useful to search current versions of installed packages > quickly. Even so, I think it should be viewed as an index. The state > of the machine is what is *sitting* in the store. That would be the > correct design. > > Meta information can go out of sync. Therefore we should not assume > they are in sync. Again, the store can go =E2=80=9Cout of sync,=E2=80=9D but the DB itself is authoritative currently. And it=E2=80=99s important that it be this way. One example is that build processes can write their outputs to the store; if the build process fails, there are still those files in the store, but the DB won=E2=80=99t h= ave recorded them as valid, so they can be swept on the next GC. >> Another (opposite :-)) option is to make /gnu/store a read-only bind >> mount on GuixSD. Commit 3392ce5 does that. This will prevent >> accidental modifications of the store. > > That is a good solution for end-users. Not for administrators. So > adminstrators will circumvent it. Well, administrators won=E2=80=99t be able to circumvent it accidentally, at least. I understand this framework really constrains what sysadmins can do, and in particular prevents them from doing =E2=80=9Cquick-and-dirty hacks.=E2= =80=9D I think we should strive to find the UIs that allow for quick hacks while not compromising the store=E2=80=99s integrity. WDYT? Thanks, Ludo=E2=80=99.