Library dependencies in Arusha

Some interesting problems cropped up when I tried to omit the C
compiler from a host running a web server.

Why did I want to do that?  CERT and many others recommend that server
hosts machines offer only essential services.  For example,
http://www.cert.org/security-improvement/practices/p068.html
recommends, "No compilers, editors, interpreters, shells, scripts, or
other programming tools should be available on a server providing
specific services or applications (as contrasted with a server being
used for internal development)."

Using <hosts-supported> I limited the distribution of gcc and
gcc-wrapper.  As soon as Python was installed on my new web server,
netra5, ark stopped running there.  I slowly discovered that the
ark-installed Python would not run:

   netra5% python
   ld.so.1: python: fatal: libstdc++.so.5: open failed:
       No such file or directory
   Killed

I found libstdc++ among the gcc libraries on the gold server.

Problem 1:  Arusha constraints do not capture the requirement that
Python deployment needs libraries installed by gcc.

Seeing no quick way to partition gcc into a libraries package and an
"everything else" package, I decided to install gcc on netra5. The ark
installation of gcc-3.2.2 went smoothly, but Python would still not
run.

Did I forget to set the runtime library path?  No:

   netra5% ldd -s /usr/local/bin/python
   ...
   find library=libstdc++.so.5; required by /usr/local/bin/python
    search path=/our/.-ark-deploy/zlib--1.1.4/lib:
        /our/.-ark-deploy/expat--1.95.5/lib:
        /our/.-ark-deploy/openssl--0.9.6g/lib:
        /our/.-ark-deploy/readline--4.3/lib:
        /our/.-ark-deploy/python--2.2.2/lib:
        /our/.-ark-deploy/gcc--3.2/lib
        (RPATH from file /usr/local/bin/python)
    trying path=/our/.-ark-deploy/zlib--1.1.4/lib/libstdc++.so.5
    trying path=/our/.-ark-deploy/expat--1.95.5/lib/libstdc++.so.5
    trying path=/our/.-ark-deploy/openssl--0.9.6g/lib/libstdc++.so.5
    trying path=/our/.-ark-deploy/readline--4.3/lib/libstdc++.so.5
    trying path=/our/.-ark-deploy/python--2.2.2/lib/libstdc++.so.5
    trying path=/our/.-ark-deploy/gcc--3.2/lib/libstdc++.so.5
    search path=/usr/lib  (default)
    trying path=/usr/lib/libstdc++.so.5
        libstdc++.so.5 =>        (file not found)
    ...

Ah ha, a clue!  I had installed gcc--3.2.2, the current version, but
Python was compiled last year with the now-deprecated gcc--3.2.  My
gold server and other older servers have both versions of gcc, but the
new netra5 had only gcc--3.2.2.  The quick workaround was to recompile
and redeploy Python with the now-current gcc--3.2.2.  Python ran on all
hosts.

Problem 2:  Since Sidai policy tightly controls the library load path
at compile and run times, the configuration files should capture the
critical dependency on specific versions of packages.

For example, ldd showed that Python depends on libraries installed by:
    zlib--1.1.4
    expat--1.95.5
    openssl--0.9.6g
    readline--4.3
    python--2.2.2
    gcc--3.2

If any of those packages were updated (as when zlib was changed to fix
a security problem), Python should be recompiled.  Many packages
probably should be recompiled, too.

Problem 3:  We need to know which version of gcc compiled each package,
but gcc-wrapper hides that information.  The definition of CC in
team/host/ALL.xml refers to /our/bin/gcc, which uses gcc-wrapper to run
a selected or default version of gcc:

    <CC><string>@team:ark-dirs:OUR@/bin/gcc</string></CC>

Problem 4:  Although Sidai configuration files carefully control the
path of each command, the arkcmd script looks for Python on the shell's
search path.

The arkcmd script does not honor the configuration choices defined in
team/host/ALL.xml:

    <PYTHON><string>@team:ark-dirs:LOCAL@/bin/python</string></PYTHON>
    <PYTHON-BOOT>@team:ark-dirs:ARK_BOOT@/bin/python</PYTHON-BOOT>

--

Joel Shprentz
National Imagery and Mapping Agency
Mailstop N-17
Washington Navy Yard, Building 213
1200 First Street, SE
Washington, DC 20303-0001

202-685-3534




-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.