Slashdot Mirror

← Back to Stories (view on slashdot.org)

Dynamic /bin support on FreeBSD

Posted by michael on from the ymmv dept.

Dan writes "Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system. He cautions that the patch is preliminary and should probably be installed on a test machine."

5 of 54 comments (clear)

  1. Why? by aridhol · · Score: 5, Insightful

    Why do they need to change the established way things work (statically linked in /bin, dynamically linked in /usr/bin) to add a new system? Why not either adapt NSS or install it in /usr?

    --
    I can't say that I don't give a fuck. I've just run out of fuck to give.
  2. Why by Anonymous Coward · · Score: 1, Insightful

    Who the hell needs this!?

    1. Re:Why by JDizzy · · Score: 2, Insightful

      It would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!

      --
      It isn't a lie if you belive it.
    2. Re:Why by aphor · · Score: 2, Insightful

      This is significant in that
      1: the dynamic /bin utilities are JUST A TEMPORARY HACK, and that NSSWITCH will provide modular resolver support for important stuff like gethostbyname(3) among other things.
      In case you haven't noticed, we need a way (LDAP?) to resolve IPSec host certificates by hostname/IP, and DNS isn't doing the job... IMHO.. other people have other reasons for wanting this.
      2: dynamic linked /bin doesn't mean that everything is dynamic linked! You can static link everything, and dlopen(3) modules as you like.. falling back to a safe static function call if the .so is corrupted/gone. From FreeBSD-STABLE dlopen(3):

      ELF executables need to be linked using the -export-dynamic option to
      ld(1) for symbols defined in the executable to become visible to dlsym().
      3: if you use dlopen(3) you can choose to use the ldconfig(8) hints or you can build a special secure .so and open it directly, bypassing the hints.

      --
      --- Nothing clever here: move along now...
    3. Re:Why by yanestra · · Score: 2, Insightful
      Sure. The executables are small enough you could probably store them in a directory on each of your slices and each of your partitions in the slices. I like the idea, and I've taken advantage of it before when I couldn't mount / but I could convince the kernel to mount /usr as / in single user.

      The problem is sitting in front of the terminal. It's absolutely no technical problem to have a partition somewhere containing all the data you need to get you system back to life if something very integral gets lost.
      The problems are:
      • deciding what is "all" you need,
      • deciding where to put it so it doesn't get damaged,
      • documenting the place so the person who needs it to fix a problem finds it,
      • keeping it sync'ed so it can be used,
      • but not too much sync'ed, so it doesn't copy your mistakes while administrating the system.

      In my opinion, imitating the laisser-faire of the Linux folks doesn't help in doing everyday's administration job.
      In my experience, the biggest problem with FreeBSD machines always has been finding some adequate tools to fix it when the system crashes after >2 years uptime- (Or do you have your FreeBSD 2.2 disk handy?)