On Sat, Jul 12, 2014 at 12:45 PM, Yasha Karant <[log in to unmask]> wrote:
> On 07/12/2014 05:27 AM, Tom H wrote:
>>
>> On Thu, Jul 10, 2014 at 8:39 AM, Lamar Owen <[log in to unmask]> 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.
|
