Re: [Nix-dev] Packaging software that mutates itself
Hi, On 06/05/16 00:02, Nikita Karetnikov wrote: > Has anyone packaged something like this? What's a proper way to solve this > without compromising the integrity of a system (think of potential security > issues or just proper operation)? There is no way to solve this. Packages with ad hoc auto-updaters are fundamentally incompatible with system package managers (except if they play nice with the package manager, but they never do). They're especially incompatible with declarative configuration management - e.g., if I deploy a system with version X of some package, I don't want it to suddenly morph into version Y on my production system. The best thing to do is to disable the auto-update functionality if possible. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Packaging software that mutates itself
Alexei, looks like steam does exactly that trick, just per user basis rather than on the system level. It keeps itself in ~/.local/share/steam I think, and applications are kept there as well and installed there but this are steam internals (nothing to do with nixos packaging). 2016-05-06 1:14 GMT+01:00 Alexei Robyn : > I suggest you look into the way Steam is packaged, as it also self-updates > (and updates other applications under its control). > > > On Fri, May 6, 2016, at 09:13 AM, Tomasz Czyż wrote: > > IMHO, this is pretty simple. > You pack "first/original" version into immutable store /nix/store. You add > tiny wrapper around it, which checks if /var/lib/ exists, if not, > create directory and copy binary there and run it there. If file already > exists in /var/lib, execute it directly. Application can update itself > there. > > 2016-05-05 23:07 GMT+01:00 Nikita Karetnikov : > > On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: > > The server is controlled by other people. > > I'd like to add that I'm assuming that these people are not malicious. In > this > case, I'm more worried about a misconfigured package that might break my > system > in some way. > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > > -- > Tomasz Czyż > *___* > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Packaging software that mutates itself
I suggest you look into the way Steam is packaged, as it also self- updates (and updates other applications under its control). On Fri, May 6, 2016, at 09:13 AM, Tomasz Czyż wrote: > IMHO, this is pretty simple. > You pack "first/original" version into immutable store /nix/store. You > add tiny wrapper around it, which checks if /var/lib/ exists, if > not, create directory and copy binary there and run it there. If file > already exists in /var/lib, execute it directly. Application can > update itself there. > > 2016-05-05 23:07 GMT+01:00 Nikita Karetnikov : >> On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: >> > The server is controlled by other people. >> >> I'd like to add that I'm assuming that these people are not >> malicious. In this >> case, I'm more worried about a misconfigured package that might >> break my system >> in some way. >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > -- > Tomasz Czyż > _ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Packaging software that mutates itself
IMHO, this is pretty simple. You pack "first/original" version into immutable store /nix/store. You add tiny wrapper around it, which checks if /var/lib/ exists, if not, create directory and copy binary there and run it there. If file already exists in /var/lib, execute it directly. Application can update itself there. 2016-05-05 23:07 GMT+01:00 Nikita Karetnikov : > On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: > > The server is controlled by other people. > > I'd like to add that I'm assuming that these people are not malicious. In > this > case, I'm more worried about a misconfigured package that might break my > system > in some way. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Packaging software that mutates itself
On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: > The server is controlled by other people. I'd like to add that I'm assuming that these people are not malicious. In this case, I'm more worried about a misconfigured package that might break my system in some way. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Packaging software that mutates itself
I've talked a bit about this on IRC earlier today, but I think the issue deserves an in-depth discussion. It's more of a general policy question, a clash of an imperative world and a pure functional one. I'm trying to package a Java program, a client, which can be (among other things) updated by the server. At first, I put everything into the store, but then the client received an update command from the server and attempted to create a directory in the store (probably based on the program location), which failed. The program is proprietary, so I tried to find a way to change this behavior in the docs, but there doesn't seem to be any way to do it. And it wouldn't solve the issue anyway. The server is controlled by other people. Even if I find a way to solve this for this particular version, e.g., by putting some files into a mutable directory (more on this below), the new client version, which will be installed by the server, might contain other unexpected features, which might prevent the client from operating properly. Has anyone packaged something like this? What's a proper way to solve this without compromising the integrity of a system (think of potential security issues or just proper operation)? NixOS supports containers, but I haven't used them yet, can it be the answer? What would be an expected mutable location for something like this? There's, for instance, /var/lib as described in http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION, but I can't even use it since that requires sudo, which is a no go for a build script. I need to copy the files into a mutable directory at build time (I'm using the builder.sh way as described in the Nixpkgs manual). ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
