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."
The linked writeup:
The message itself:
Not much more to add, is there? Except that this is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.
What I'm listening to now on Pandora...
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.
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
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.
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
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.
I can't say that I don't give a fuck. I've just run out of fuck to give.
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.
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.
You could've hired me.
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.
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
This is significant in that /bin utilities are JUST A TEMPORARY HACK, and that NSSWITCH will provide modular resolver support for important stuff like gethostbyname(3) among other things. /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):
3: if you use dlopen(3) you can choose to use the ldconfig(8) hints or you can build a special secure1: the dynamic
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
--- Nothing clever here: move along now...
Right!
/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.
I'm all for a really small
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 mount a pseudo root to in turn fsck the real root FS.
It isn't a lie if you belive it.
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
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:
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?)