Re: tlug: Re: static binaries (was: Re: tomsrtbt & glibc)

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Rex" == Rex Walters <rex@example.com> writes:

    Rex> Forgive me my hyperbole.  I meant overkill in the sense that
    Rex> for many of the executables in /sbin it simply doesn't matter
    Rex> whether or not they are statically linked.

Which ones?  If having /lib/libc.so disappear doesn't bother you with
respect to a given dynamically linked executable, then how is it
necessary?  Shouldn't it go to /usr/sbin?

    Rex> I wasn't referring to bloat (on disk or in memory).  FHS 2.0
    Rex> says /sbin is for executables only run by an admin and not
    Rex> normal users.  I can probably live without mkfs.msdos being
    Rex> statically linked.

A prime candidate for moving to /usr/sbin IMHO.

    Rex> I'm a little puzzled at Stephen pushing "only static binaries
    Rex> in /bin and /sbin" since it isn't in FHS 2.0 (nor, by
    Rex> extension, in the Debian Policy Manual).

I'm not pushing for it, I don't do it myself, after all.  I do think
of it as a slight extra safety factor.  As for the cites to FHS and
Debian Policy:  yes, I do advocate following standards strictly.  But
here, the manuals are more advice than requirement; it's _my_ system
after all.  It doesn't hurt other systems if mine is non-conforming.
So this is not a case of a bad standard is better than none, so I'm
willing to play the devil's advocate.

    Rex> I also agree, however, that there would seem to be need for
    Rex> more than just ln and sync being statically linked.  And I'm
    Rex> puzzled why the FHS doesn't include more -- I wondered if
    Rex> anyone knew the reason.

My *guess* is that people who think about it seriously, and advocate
dynamic executables, are thinking about things like security and other
bug fixes.  If it's dynamically linked, you need to rebuild and
install a library---and you know that's where the bug was.  If it's
static, you need to rebuild everything after rebuilding the library
(unless you know exactly what programs depend on the given function).

So there's controversy about the relative value of consistent bug and
security fixes vs the possibility of shooting yourself in the foot and
destroying libc.  FHS takes the conservative standpoint (which is also
convenient for distribution integrators) of not creating new
requirements by minimizing the statically linked executables.

ln and sync, if not static, would make updating libc on the fly rather 
dangerous, if not impossible.  So they're an exception to the above
conservative stance.

I think that probably FHS should add a priority list of things that
distribution integrators and individual sysadmins should consider
statically linking and/or moving to /{bin,sbin,lib} with rationales
pro and con.  Howard's MD/RAID example is a good example.

    Howard> Rex Walters wrote:

    >> I wasn't referring to bloat (on disk or in memory).  FHS 2.0
    >> says /sbin is for executables only run by an admin and not
    >> normal users.

    Howard> Then what's the difference between /sbin and /usr/sbin?
    Howard> (Honest question, I thought /sbin was only for recovering
    Howard> / booting when /usr couldn't be accessed.)

Besides recovery and booting, there are some other maintenance tasks
that you might want to do without mounting /usr, and there is always
the possibility that /usr lives on an NFS server or the like (CODA
might not have the problem) which goes south on you.  I could imagine
putting the X server and fonts in /bin and /lib respectively (NB:

bash-2.01$ ldd /usr/X11R6/bin/X
        /lib/nfslock.so.0 => /lib/nfslock.so.0 (0x4000d000)
        libc.so.6 => /lib/libc.so.6 (0x40013000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

so that at least I'd always have an X terminal available.  Imagine, I
wrote, I'm not nuts.  (Oh, heavens, I'm probably giving Chris ideas!  :-)

Note that FHS does say that what goes in /s?bin vs what goes in
/usr/s?bin is going to be system-dependent.  It depends on what _you_
need and want in such a situation.

And I disagree with some decisions about bin vs. sbin.  Eg, on Debian
traceroute is in /usr/sbin, not /usr/bin.  That doesn't stop users
from using it, and it is often useful for someone who is _not_ the
sysadmin to be able to use it.

    Howard> One that I have to deal with: mdrun / mdadd for software
    Howard> raid devices.  Until this discussion, I wasn't sure why it
    Howard> NEEDED to access /usr/lib before being able to start any
    Howard> mdX devices.  So, because it's not statically linked, I
    Howard> can't put /usr on a raid partition without extra work.
    Howard> (Last time, I just had 2 copies of the libraries, so that
    Howard> the one disappeared when it /usr got mounted.)  Now I know
    Howard> the right way to fix it: find the source and statically
    Howard> link it.

Probably you can also ldd and mv any relevant libraries from /usr/lib
to /lib.  No?  (See the X server example above.)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
----------------------------------------------------------------
Next Nomikai: 20 November, 19:30   Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: 12 December, 12:30 HSBC Securities Office
----------------------------------------------------------------
more info: http://tlug.linux.or.jp Sponsors: PHT, HSBC Securities