Slashdot Mirror
Dynamic /bin support on FreeBSD
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."
Who the hell needs this!?
/etc.
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
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.
Healthcare article at Kuro5hin
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 my home-net's hostnames in the host file. This was still host.conf in -stable.
I believe other NIXes have had this for a long time, no?
So, my question is, why are /bin and /sbin traditionally static?
/bin would need to be dynamic, so there's a good chance that many would remain 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
Healthcare article at Kuro5hin
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.
It isn't a lie if you belive it.
The odd thing about FreeBSD is that dynamic libraries have rarely been a show-stopper for me.
There are two reasons for this:
The first point is self explanatory. As for their library mecahnisms: The last dozen or so times I have installed Linux, I have had to go on a treasure hunt to find exactly the right version of libc for a given application (Oracle, whatever). With FreeBSD, the old libraries can (and often are) installed and built with the system so you never have to hunt for them. Simply edit
FreeBSD libraries in make.conf also match the OS release so a 2.2 library is for a 2.2 kernel and program, etc. There is no guessing.
-sirket
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.)
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.
/lib libraries going bad.
/lib on a non-root mounted partition. No big deal there.
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
And you've got to remember not to put
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! :-)
Nothing in /rescue is dynamically linked:
/rescue/init
/rescue/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for NetBSD, statically linked, stripped
/rescue/init
/rescue/init*
/rescue.
$ file
$ ls -l
-r-xr-xr-x 127 root wheel 2564020 Mar 10 09:30
So we (NetBSD) impersonate 127 programs in