On Sat, Jul 12, 2014 at 12:45 PM, Yasha Karant <[email protected]> wrote: > On 07/12/2014 05:27 AM, Tom H wrote: >> >> On Thu, Jul 10, 2014 at 8:39 AM, Lamar Owen <[email protected]> wrote: >>> >>> On 07/09/2014 08:48 PM, Nico Kadel-Garcia wrote: >>>> >>>> The other dirty trick would be to use something like 'mock' to build a >>>> chroot cage, and put your tools inside the chroot cage. ... >>> >>> I have to wonder if the 'Software Collections' framework could work for >>> glibc. Otherwise your solution should work ok, even though it is more >>> than >>> a bit of a kluge. >> >> Or use lxc on EL6 or lxc or systemd-nspawn on EL7. > > From: > > http://en.wikipedia.org/wiki/Lxc > > LXC is similar to other OS-level virtualization technologies on Linux such > as OpenVZ <http://en.wikipedia.org/wiki/OpenVZ> and Linux-VServer > <http://en.wikipedia.org/wiki/Linux-VServer>, as well as those on other > operating systems such as FreeBSD jails > <http://en.wikipedia.org/wiki/FreeBSD_jail>, AIX > <http://en.wikipedia.org/wiki/AIX> Workload Partitions > <http://en.wikipedia.org/wiki/Workload_Partitions> and Solaris Containers > <http://en.wikipedia.org/wiki/Solaris_Containers>. In contrast to OpenVZ, > LXC works in the vanilla Linux kernel > <http://en.wikipedia.org/wiki/Vanilla_Linux_kernel> requiring no additional > patches to be applied to the kernel sources. Version 1 of the LXC, which was > released on 20 February 2014, is a long-term supported version and intended > to be supported for five years.^[6] > <http://en.wikipedia.org/wiki/Lxc#cite_note-6> > > End quote. > > The above -- if it works and does not require "excessive" system resources > would be the solution we need, as it has something akin to real > polymorphism. Does it have something akin to inheritance, using all of the
Yasha, your concept of such polymorphism seems to be personal, unique, and not supported by anyone else's models of how to make software work that I've ever seen. I urge you to set it aside for a while, it's not about Scientific Linux and confuses things when you keep bringing it up. > base (native) environment except as needed to avoid inconsistencies? Can > one load, say, the appropriate glibc within a LXC container without loading > what is tantamount to a full OS environment? glibc is one of the most basic components of an operating system, so that seems exceedingly unlikely. Almost *very other binary* uses it, so to simply apply it via RPM and not potentially corrupt the operating system, you pretty much *have* to have a complete, isolated container, VM, chroot cage, etc. There are components that are designed to be installed in parallel with multiple versions available, like sendmail or postfix or other MTA's, and like Java. But that still requires some kind of binary specific wrapper to select that particular version when you need something other than the standard. It's not free. Part of the point of various containers is to *isolate* them from the rest of the operating system. I've already pointed out to you a fairly safe hack to get this one tool running, of unpacking the different glibc RPM into a diferent directory and setting wrapper scripts to use that in a LD_LIBRARY_PATH. You've got half a dozen chroot cage and virtualization technologies to select from and test with. > Any comments from actual users of LXC or any competitors/alternatives > thereto?\ > I am in the field today, and in a time constrained situation, and thus no > time to hunt -- are any of these available via RPMs in a production release > with some sort of built-in configuration tool(s)? > > Yasha Karant If you're time constrained, why didn't you try the wrapper script approach? You could be up and running without burning time setting up complex, untested technologies. It's a hack, but it's an old, *stable* hack.
