Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

Dynamic /bin support on FreeBSD 54

Posted by michael 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."
This discussion has been archived. No new comments can be posted.

Dynamic /bin support on FreeBSD More

Dynamic /bin support on FreeBSD

Comments Filter:

  • Why? (Score:5, Insightful)

    by aridhol ( 112307 ) <ka_lac@hotmail.com> on Thursday May 08, 2003 @01:57PM (#5912302) Homepage Journal
    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?

    • Re:Why? (Score:5, Informative)

      by Neil ( 7455 ) on Friday May 09, 2003 @10:46AM (#5919179) Homepage

      NSS (name service switch) provides "on the fly" reconfigurable name services - it is the mechanism that allows (for example) a Solaris or Linux machine to look up password entries in /etc/passwd, the NIS, LDAP, or whatever, depending on the contents of the "passwd:" line of /etc/nsswitch.conf.

      NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.

      A system where some of the binaries obey preferences the admin expresses through /etc/nsswitch.conf but, say, /bin/ls doesn't is unlikely to be popular! :-)

      • NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.

        This is, of course, not a sane justification. For example the resolver library quite happily obeys host.conf to control the same kind of decision about host name lookup dispite being statically linked into things. The highly sophistic

        • This is, of course, not a sane justification. For example not all resolver libraries bundled by default on the system, and applications certainly can't allow for all possible future resolver libraries. The purpose of NSS isn't just name resolution configuration, its to extend name resolution infinitely with new resolvers. Those resolvers become dynamic libraries which would have to be load, gasp, dynamically.

          If my /bin stuff is statically linked, and I install a new resolver, then what? No amount of config
          • The purpose of NSS isn't just name resolution configuration, its to extend name resolution infinitely with new resolvers.

            How many times in the past 10 years have you desperately needed to have /bin/ls look up passwords in some bizzare new way?

            If my /bin stuff is statically linked, and I install a new resolver, then what? No amount of configuration file reading is going to solve this one smart guy. I one: either have to recompile everything in /bin,[...]

            I build world maybe 4 or 5 times a year. That's i

            • Well I'm glad your requirements permit that, so don't bother turning on the ability to dynamically link /bin. However not everyone's requirements are the same as yours so it's nice to have the ability. Also, Last time I checked, /bin didn't only contain 'ls'. Smart guy.
              • Also, Last time I checked, /bin didn't only contain 'ls'.

                So, how many times in the last 10 years have you needed to have /bin/cat look up passwords in a different way:-)

  • Why (Score:1, Insightful)

    by Anonymous Coward
    Who the hell needs this!?

    • Re:Why (Score:5, Informative)

      by pmz ( 462998 ) on Thursday May 08, 2003 @02:36PM (#5912750) Homepage
      Who the hell needs this!?

      Some of the comments at the link in the article would suggest new or improved LDAP support. That's pretty significant. NSS stands for Name Service Switch, which allows alternative datasources for many of the databases traditionally stored in /etc.

      Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database. Minus DNS, these datasources can also provide the users database, the RBAC databases, the automounter configuration, bootparams, to name a few. To say it is useful is an understatement.

      • Re:Why (Score:4, Interesting)

        by Piquan ( 49943 ) on Thursday May 08, 2003 @02:51PM (#5912933)

        That's good for who needs this. As for why, the NSS code works by dynamically loading the necessary backends. That's presumably why a dynamic /bin and /sbin are needed.

        So, my question is, why are /bin and /sbin traditionally static? Gordon's patch pretty much just sets them to dynamic linkage, and puts some libs and rtld in /lib. I'd think that if having /bin and /sbin dynamically linked was kosher, tho, that they would be. So I'm a little worried about this patch.

        • Re:Why (Score:4, Informative)

          by pmz ( 462998 ) on Thursday May 08, 2003 @03:03PM (#5913083) Homepage
          So, my question is, why are /bin and /sbin traditionally static?

          Safety. When trying to repair a broken system, the dynamic linker and libraries become one less thing to worry about when the essential tools are staticly linked. I can't imagine that all the tools in /bin would need to be dynamic, so there's a good chance that many would remain static.

        • Re:Why (Score:4, Interesting)

          by aridhol ( 112307 ) <ka_lac@hotmail.com> on Thursday May 08, 2003 @03:05PM (#5913093) Homepage Journal
          /bin and /sbin need to be usable when only the root has been mounted. That means that they can't dynamically link to anything that's not in the root. That includes /usr/lib, which is where most dynamic linking takes place.

          I don't know why they needed to be completely static, as /lib still exists, so they should be linkable with libraries in there.

          It's probably just a safeguard against accidentally linking to a library in /usr/lib, just to have them fail when they're most needed.

          • Re:Why (Score:4, Informative)

            by parc ( 25467 ) on Friday May 09, 2003 @10:21AM (#5918982)
            There is no /lib in current FreeBSD systems. You have to create one to go along with this patch, and several dlls will be placed in it.

            The only thing this realy gets you (other than NSS) is a smaller memory footprint at a (theoretical) cost in speed, as well as a little unsafeness in the case of one of your /lib libraries going bad.

            And you've got to remember not to put /lib on a non-root mounted partition. No big deal there.

        • Re:Why (Score:5, Informative)

          by JDizzy ( 85499 ) on Thursday May 08, 2003 @03:18PM (#5913228) Homepage Journal
          Static because of the paranoia we have about libraries becoming corrupted. Consider this nightmare situation: Your computer panics, and in so it somehow gets a bit of filesystem corruption. You softboot, and discover that the FS corruption occurred in your libc and now all you dynamically linked executable that almost all of which link to libc are utterly useless. If fsck were dynamically linked it would be unable to examine/fix the file systems. That is why the /bin, and /sbin are all statically built, because these nightmares have happened before to some of use on other UNIX systems. WE do not dare to make that mistake on the most stable OS on earth! Also, what is somebody decided to put his libraries on /usr (mounted on its own filesystem), and have dynamically linked init on the root filesystem? The answer is the kernel wouldn't' be able to boot the system into single, or multi-user modes. There are many reasons to have static /bin and /sbin. On the other hand there are also a few reasons to not build them statically. Space is one major issue. The root filesystem would lessen in size dramatically if libc, and others, were not replicated into each executable. It would also open the door to more small version of FreeBSD that fit on floppies, and stuff. The only issue with dynamically linked /bin and /sbin is the need to fall back upon staticly built version of the same stuff in case your libs get corrupted. I think we might copy NetBSD and make a /rescue folder with crunched executables. Crunching is akin to compiling all your /bin and /sbin into one singulare binary file, and depending on how you invoke the binary, renders a different executable. Sorta like if I called crunch.bin as "fsck" it would bring the fsck code to the surface, or if the same crunch.bin were called as "ls" it would be ls. Inside the crunch.bin is dynamically linked , and archived executables. Hopefully that one file would not be damaged in fs corruption.

          • Re:Why (Score:5, Interesting)

            by renehollan ( 138013 ) <{ten.eriwraelc} {ta} {nallohr}> on Thursday May 08, 2003 @04:01PM (#5913687) Homepage Journal
            Hopefully that one file would not be damaged in fs corruption.

            Holy light bulb, Batman! (well, JDizzy, any way, to give proper credit). You've just given me an idea!!

            Given that some executables are more important than others in reparing broken filesystems, this situation particularly exacerbated with crunched binaries, why not add error correcting codes to them, and use inteleaving techniques to mitigate single block errors? Yes, they would grow, but not likely to the limit of multiple complete copies.

            Also, for sensitive dynamically linked libraries, perhaps the directory structure could be modified to have a common LD_LIBRARY_PATH for some system directories. Heck, never mind a mod: just make the loader sensitive to .ldpath symlinks in the directory of the executible.

            • Re:Why (Score:3, Insightful)

              by JDizzy ( 85499 )
              It would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!
              • t would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!

                Yes, at some point, SOMETHING has to work O.K. in order for the system to boot. But, that something should be small enough and the rest reliable and redundant enough to permit the critical piece to either live in ROM, or floppy.

                Thought, bootable live CD distros are handy.

                Still, the one time you most desperately need to repair a sick system is also going to be the time you don't have your Swiss-

                • Re:Why (Score:3, Interesting)

                  by JDizzy ( 85499 )
                  Right!

                  I'm all for a really small /rescue partition with crunched init, fsck, mount, sh, and a few other essential tools to recover a broken system. The kernel could be altered in such a way that if it couldn't mount the root file system, it could mount the /rescue FS, and the fsck could happen. This would be a FreeBSD (shoot me) "safe mode" of sorts.

                  If things were so broken that you couldn't fix them with the various built-in ways, a "rescue disk" (aka bootable cdrom, floppy) would have to be used to moun

            • Re:Why (Score:3, Insightful)

              by aphor ( 99965 )

              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)

            • 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.

              • Re:Why (Score:2, Insightful)

                by yanestra ( 526590 ) *

                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 lo

            • Given that some executables are more important than others in reparing broken filesystems, this situation particularly exacerbated with crunched binaries, why not add error correcting codes to them, and use inteleaving techniques to mitigate single block errors? Yes, they would grow, but not likely to the limit of multiple complete copies.

              Bit failures are very rare when having filesystem problems. ECCs only help with (single or multiple) bit failures. They don't help if the whole block is destroyed (whi

          • Pssh. I'd just boot with linux init=/sbin/sash if my libs got corrupted.

          • Re:Why (Score:1, Informative)

            by Anonymous Coward
            Nothing in /rescue is dynamically linked:

            $ file /rescue/init

            /rescue/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for NetBSD, statically linked, stripped

            $ ls -l /rescue/init

            -r-xr-xr-x 127 root wheel 2564020 Mar 10 09:30 /rescue/init*

            So we (NetBSD) impersonate 127 programs in /rescue.

          • That's why, when this dynamic linking funnyness is going through, I want static versions of /bin and /sbin utils in /stand.
        • As for why, the NSS code works by dynamically loading the necessary backends. That's presumably why a dynamic /bin and /sbin are needed.
          You could statically link all the libraries except libdl, if you really want static /bin and /sbin.

      • Re:Why (Score:2, Flamebait)

        by KeyserDK ( 301544 )
        Linux has had this for ages?

        • Re:Why (Score:1)

          by pmz ( 462998 )
          Linux has had this for ages?

          I don't know much about FreeBSD and what it's current NSS capabilities are. This could be one of those things where Linux is stronger in some things but FreeBSD stronger in others. FreeBSD has a very good reputation, so I wouldn't expect the current limitations are show-stoppers.
          • True, i've only used nss to play around with winbind
            in a win2k domain (samba3).

            Pretty odd seing windows usernames with 'ls -l' =)
      • Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database.
        And on a SVR4 system (like, for example Solaris):
        $ ls -l /bin
        lrwxrwxrwx 1 root sys 8 Jan 4 2002 /bin -> /usr/bin
        So no problem with dynamicly linked /bin then :-)
      • Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database.

        I didn't know that. MacOS X 10.2 uses a similar mechanism to look up system information, like hostnames, printers, users, groups, mountpoints. The information can reside in BSD-like /etc/ files, LDAP, NIS or SLP databases, or obtained via Rendezvous or SMB. The system finds the information it needs in the selected items. See the utility "Directory Access" for more (albeit minimal) info.

  • NSS = nsswitch (Score:1, Informative)

    by Anonymous Coward
    I was wondering what it meant so I looked it up (http://www.freebsd.org/releases/5.1R/todo.html):

    "NSSwitch support -- Jacques Vidrine (nectar@) --
    Support for pluggable directory services using NSS, including adaptations of current directory services (local databases, NIS), and support for new services (LDAP, Active Directory, etc). This change has been committed, and requires broader testing."

    One thing I had noticed that in -current I had to use nsswitch.conf to have it use dns rather than looking up m

  • Debate over dynamic /bin (Score:3, Informative)

    by evilcyber ( 672159 ) <cyber@ono-sendai.com> on Friday May 09, 2003 @09:48AM (#5918679)
    As evidenced by the messages already posted, the Dynamic/Static debate is probably going to rage on here. To see how this will likely all play out, take a look at the NetBSD mailing list archives regarding the Pro's and Con's. You'll also see some of the solutions that came up to the various issues. NetBSD has already gone through this flame war when they commited a dynamic root to their tree. (Noted buried in one of the threads.)

Slashdot Top Deals

"I am, therefore I am." -- Akira

Close