Home / server / Questions / 281810
Accepted
VonC
Asked: 2011-06-19 11:48:24 +0800 CST

How to install packages on Linux or Solaris on non-default paths?

  • 772

By "default path", I mean "/usr/local", or other paths managed by root ("system paths").

I have to install many application packages (by that, I mean: svn, httpd, git, perl, python, ...) on a few Linux (RedHat) or Solaris (10, in local zones) servers.

But:

  • those servers manage many different applications (sometimes using different versions of svn or perl or ...)
  • I am not administrator on those servers (no sudo root for me)

I tried using, for instance on Solaris, pkgadd -R to try an install pre-compiled packages in a custom path (namely within the homedir of a specific user, rather than in the normal default path of /usr/local/...), but said pre-compiled packages all comes with references to other resources in /usr/...:

A ldd /path/to/local/installed/packages will show many dependencies to system paths:

ldd /home/myuser/usr/local/git
  libz.so => /usr/local/lib/libz.so
  libiconv.so.2 => /usr/local/lib/libiconv.so.2
  libsocket.so.1 => /usr/local/libsocket.so.1
  ...

That will not do, because:

  • In Solaris, I have no way to write anything on /usr which is only writable from the global zone, not from a local zone.
  • In Solaris or Linux, I am not root anyway, so I cannot write anything in system path.
  • I don't manage the upgrades on those servers, so if any library changes, it can potentially breaks many of my installed services.

What would you recommend to do in order to install in an isolated way different "services" on a same (Linux or Solaris) server, each one potentially requiring their own version of (perl, python, ...)?

I propose a solution below, but if you have other alternatives, I am interested.

linux installation solaris package-management

3 Answers

  1. Best Answer

    The only solution I have found so far:

    • compatible with installing (as non-root) multiple applications,
    • allowing each application to have with their own set of dependencies (with potential different versions used from one set of dependencies to another)

    is:

    recompile everything

    (and by everything, I mean even gcc itself if needed, since the /usr/swf/bin/gcc installed by default on our Solaris servers is even older than the pre-requisite gcc 3.4.6)

    All the versions used in this global recompilation are comming from sunfreeware, which will details all the necessary dependencies, and will provide a link to the sources for each packages.
    That works both on Linux and Solaris.

    Each package source is downloaded, compiled, and installed in $HOME/usr/local (i.e. not in a system path).
    The key is to have a .bashrc (for instance) which will change the $PATH in order to not have any /usr/bin or /usr/local/bin in it, but only $HOME/usr/local/bin.

    I found over time several advantages:

    • The libraries in /usr can change, that will have 0 impact on the several services currently running (because they all have been compiled on their own set of dependencies installed in $HOME/usr/local)
    • The non-root user who runs a compiled application is pretty much root in his own environment, and that user can launch/kill/update/recompile any element within $HOME/usr/local
    • It is easy to make a new directory in the $HOME and compile again all dependencies for testing an upgrade of a given application. You can end up with several versions of a same package, and test/switch from one version to another.
    • You control the compilation options, and it is very easy to compile an Apache Httpd with all modules activated in it if you want (as opposed to a pre-compiled package where you take what you get).

    The main disadvantages are:

    • Any full compilation can takes time (up to 1 hour on Linux, 3 to 4 hours on Solaris).
      But you don't always need to recompile everything.
    • The compilation options are different for every packages, and can be quite complex to set properly
    • The environment variables (LDFLAGS, CFLAGS, CPPFLAGS, LD_LIBRARY_PATH) can be tricky to setup with the right values
    • If you don't have a script able to extract for you the right dependencies and to launch the compilations, that means: manual process, which is a drag.
      (I am in the process of making that script, and will publish it on GitHub)
    • 4

  2. There's an option to set up a chroot environment for every service and installing those packages under that. It certainly involes some bloat in that you are required to basically replicate many libraries into chroot environment. But it does isolate your services from everyone else's and vice versa and gives you full (root-like) control over the enviroment.

    This still requires root access to set up and to access the chroot environment.

    Subsequent access can be managed using e.g. SSH:

    http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229

    • 2

  3. On Solaris, you can define RPATH using the $ORIGIN magic word. For example, if you have the following layout, you can define RPATH as '$ORIGIN/../lib' in the RPATH of your binaries, passing the -R flag to the linker.

    /usr/local/bin/foo
/usr/local/lib/libfoo.so.1

    However, it won't work if the layout is specified by the user. For example, the user could set bindir to /usr/local/bin/sparcv9 and libdir to /usr/local/lib/sparcv9. In this case the setting should be $ORIGIN/../../lib/sparcv9.

    Traditionally, all binaries compiled for Solaris use hardcoded RPATH, which makes them non-relocatable.

    One other thing to look at might be crle, which allows to configure the dynamic linker.

    • 0