[Nix-dev] Is there a definite list of pre-reqs for nix for RPMs

[Milind Parikh]

Thanks for the detailed explanation ! It was very useful.

The question that still remains:

(a) I know that I cannot "just install a nix RPM" despite the claim that "it
should work on any RPM-based Linux distribution based on glibc 2.or later.".
So I need to know what is the "base requirement for deploying nix is" (and
more importantly, how will I know how this requirement will change with
time).

second is more of a comment...

(b) I know that the dependencies in the ELF binaries are actually referenced
in the binaries; instead of ld getting it from an env var. However from a
security audit standpoint (as it stands today), you get brownie points for
updating the detectable library (the metaphorical libc) rather than what the
binary is actually using. So, perversely, you could update the public
dependency (the one that the security audit would see) and yet leave the
binary using the older version of dependency [leaving the binary vulnerable]
and, of course, the vice-versa  [in which the security audit would sting you
for not updating the public dependency] even though your binary is
protected.... hope that this was not too confusing.... seems that one would
update both in current distros...

(c) Storage is cheap; unreliable systems are expensive. nix is the way to
make systems reliably consistent cheaply.


Regards
-- Milind

On Mon, Jul 20, 2009 at 8:31 PM, Tony White <tonywhite100 at googlemail.com>wrote:

> 2009/7/21 Milind Parikh <milindparikh at gmail.com>:
> > "Using nix-store --export and nix-store --import, so that you can
> > install nix on machines running centos (Or any other Linux distro that
> > runs more current upstream packages) First and then just distribute
> > the application(s)?
> > Is that what you mean by portable applications? Are you interested in
> > using nix to distribute binaries in a portable way?"
> >
> > In one word : yes
> >
> > I am interested in assuring someone that when postgres is dropped on a
> > server (linux), it just will work. Of course, postgres is a metaphor.
> >
> > Secondly, from security audit perspective, when libc has to be updated,
> all
> > packages will have the correct references to libc. Once again, package
> (as
> > is libc) is a metaphor; qa still has to be done; but there is simply no
> > better way of building. If it does not work (libc upgrade), there can be
> > nothing else to be done than to roll back or accept bugs.
> >
> > It seems, that the first step in this, is to ensure that nix will install
> > and operate on a given distro (kind of the bootstrapping process for the
> > problem space of nix). Hence the question.
> >
> >
> >
> >
> > On Mon, Jul 20, 2009 at 3:32 PM, Tony White <tonywhite100 at googlemail.com
> >
> > wrote:
> >>
> >> 2009/7/20 Milind Parikh <milindparikh at gmail.com>:
> >> > "RPM packages of Nix can be downloaded from http://nixos.org/. These
> >> > RPMs
> >> > should work for most fairly recent releases of SuSE and Red Hat Linux.
> >> > They
> >> > have been known to work work on SuSE Linux 8.1 and 9.0, and Red Hat
> 9.0.
> >> > In
> >> > fact, it should work on any RPM-based Linux distribution based on
> glibc
> >> > 2.3
> >> > or later."
> >> >
> >> >
> >> > Doesn't work on centos 5.3 until you upgrade llibstdc++ to the latest
> >> > version (that is not even available in yum repos).
> >> >
> >> > My question, though , is more general. The use case is "portable
> >> > applications" (though not under nixox).
> >> >
> >> >
> >> > Regards
> >> > -- Milind
> >> >
> >> >
> >> > _______________________________________________
> >> > nix-dev mailing list
> >> > nix-dev at cs.uu.nl
> >> > https://mail.cs.uu.nl/mailman/listinfo/nix-dev
> >> >
> >> >
> >>
> >> Hi Milind,
> >> Do you want to do something like this :
> >>
> >>
> http://hydra.nixos.org/build/47813/download/1/manual/#sec-sharing-packages
> >>
> >> Using nix-store --export and nix-store --import, so that you can
> >> install nix on machines running centos (Or any other Linux distro that
> >> runs more current upstream packages) First and then just distribute
> >> the application(s)?
> >> Is that what you mean by portable applications? Are you interested in
> >> using nix to distribute binaries in a portable way?
> >>
> >> Sorry if I misunderstand.
> >>
> >> Thanks,
> >> Tony
> >
> >
>
> Hi Milind,
> Your postgres would work but you would need to configure your own
> custom postgres settings (Maybe using the expression that builds the
> package or other method eg script or ssh) and importantly start or
> restart the upstart or sysvinit process to control the postgres daemon
> on the machine. But only because postgres is used generally as a
> daemon process and I guess needs to be configured to suit it's
> deployment task.
> You shouldn't generally with most software (Unless you want to make a
> special configuration) need to do anything exotic to any software that
> doesn't use a daemon.
>
> Being specific about which software that you want to deploy and
> finding out if the package already exists in the nixpkg collection
> will help you answer whether or not you can use nix easily to deploy
> software x y or z. Creating your own expressions for software that is
> not in nixpkgs will require you to learn a bit of nix expression
> language (Easy if you study existing expressions, read the manual and
> ask for help on the list or irc if you get stuck.)
> If the software you want is in the nixpkg collection, you can download
> the software package straight from a channel built by the nix build
> farm (Hydra,) Instead of building the software from source code using
> the expressions.
> Then you can distribute it using the nix-store --export or
> nix-copy-closure commands to the other machines that you want to
> deploy the software onto.
>
> nix-store --export will copy the software you want to distribute and
> all it's dependencies into a file that you can drop onto a machine.
> nix-copy-closure would maybe be even better for many machines over a
> network and has a similar result but over ssh.
>
> I'm pretty sure I understand it like this (And someone correct me if
> I'm wrong please) That the nix environment is separate from the centos
> environment. So for instance, a libc update in a nix store will not
> effect the centos libc because the dependencies are in the nix store
> and if libc was a dependency it would be copied across.
> So updates to libc in either the nix store or the centos rpm database
> do not effect one another.
>
> You'll need lots of disk space to run the two environments with lots
> of software installed and profiles but the profiles can be garbage
> collected and you will have a very powerful software environment that
> will be very difficult to break.
> If you drop an update and for any reason the new version is a
> regression, just roll back to the previous profile :
>
> http://hydra.nixos.org/build/47813/download/1/manual/#sec-profiles
>
> Hope some of that helps. :)
>
> Thanks,
> Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20090720/588029f3/attachment.html