Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems BSD IT Technology

Dynamic Root Support For FreeBSD Now Available 112

Posted by Hemos from the coming-at-you dept.
Dan writes "FreeBSD's Gordon Tetlow has committed his enhancements to enable users to build /bin and /sbin dynamically linked on FreeBSD. His reason to do this is two-fold. One is to give better support for PAM and NSS in the base system. The second is to save some disk space. Currently (on his x86 box), /bin and /sbin are 32 MB. With a dynamically linked root (and some pruning of some binaries), the /bin, /lib, and /sbin come out to 6.1 MB. This should be great for people with 2.x and 3.x era root partitions that are only about 50 MB. Gordon says that there will be a performance hit associated with this. He did a quick measurement at boot and his boot time (from invocation of /etc/rc to the login prompt) went from 12 seconds with a static root to 15 seconds with a dynamic root."
This discussion has been archived. No new comments can be posted.

Dynamic Root Support For FreeBSD Now Available More

Dynamic Root Support For FreeBSD Now Available

Comments Filter:

  • bad bad bad (Score:5, Insightful)

    by Tirel ( 692085 ) on Monday August 18, 2003 @11:01AM (#6723008)
    not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,

    there are less and less reasons to use seperate partitions for root directories, and this is *NOT GOOD*

    • Re:bad bad bad (Score:5, Insightful)

      by Fweeky ( 41046 ) on Monday August 18, 2003 @11:15AM (#6723146) Homepage
      Er, why? /bin, /sbin and /lib should all be on the same partition, and if you're really screwed, that's what /rescue is for.

    • Re:bad bad bad (Score:5, Informative)

      by Nizzt ( 45461 ) * on Monday August 18, 2003 @11:16AM (#6723163) Homepage Journal
      Thats why the librarys are in /lib not /usr/lib

    • Re:bad bad bad (Score:5, Informative)

      by cperciva ( 102828 ) on Monday August 18, 2003 @11:23AM (#6723225) Homepage
      it will also make it impossible to recover a server if you accidentally delete /usr

      No. The libraries used by stuff in /bin and /sbin are being moved into /lib, so everything which is being changed from static to dynamic will still work even if /usr is gone.

      Also note that /rescue is still static (and crunched).

      • Re:bad bad bad (Score:3, Informative)

        by jkujawa ( 56195 )
        The point of static binaries in /bin and /sbin is not only being able to mount /usr of a file server, but also being able to recover if you kill ld.so.

        • Re:bad bad bad (Score:1, Informative)

          by Anonymous Coward
          Why would you kill ld.so? You might as well argue that statically linked binaries aren't suitable either, because you can accidentally kill the actual executables themselves.

        • My understanding... (Score:4, Interesting)

          by devphil ( 51341 ) on Monday August 18, 2003 @01:06PM (#6724428) Homepage


          ...was that, in earlier *nixes, sbin programs were always statically linked, to avoid problems with requiring /usr, or accidentally damaging the dynamic loader, or still functioning while restoring dynamic libs from tape, etc, etc.

          Not necessarily FreeBSD, but just some flavor of Unix. The versions of Digital Unix (under different names) which I teethed on were designed like this.

          It's always annoyed me that Linux's [/usr]/sbin was dynamically linked.

    • Re:bad bad bad (Score:2, Informative)

      by Anonymous Coward

      not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,

      Only if you do something stupid, like put critical system libs into /usr. The binaries in /bin and /sbin shouldn't rely on anything in /usr, only libraries in /lib.

    • Re:bad bad bad (Score:5, Insightful)

      by ctr2sprt ( 574731 ) on Monday August 18, 2003 @01:10PM (#6724471)
      It's not good as a default, but it's good as an option. So while I hope FreeBSD installs still come with a static bin+sbin, it's nice to have the option, on a make world, to change the behavior if I decide I need to. It's added flexibility without any added complexity. What more could you want?

    • Re:bad bad bad (Score:3, Funny)

      by Arandir ( 19206 )
      Screw /usr. I still want to know how to recover the server after I accidentally deleted / last week...

      • Re:bad bad bad (Score:3, Informative)

        by R.Caley ( 126968 )
        Screw /usr. I still want to know how to recover the server after I accidentally deleted / last week...

        Stick in the fixit cdrom.

        You do keep a copy of /etc somewhere don't you?

    • Re:bad bad bad (Score:5, Informative)

      by shlong ( 121504 ) on Monday August 18, 2003 @03:08PM (#6725732) Homepage
      " not only will this affect performance, but it will also make it impossible to recover a server if you accidentally delete /usr,"

      What wasn't mentioned in the write-up is that /rescue contains statically-link versions of the tools that one would need to recover from problems. It might not be able to recover a deleted filesystem, but if you're trouncing careless around like that then there are plenty of other ways to shoot your feet off too.

  • good and bad here (Score:5, Informative)

    by josepha48 ( 13953 ) on Monday August 18, 2003 @12:33PM (#6723955) Journal
    This is good in the case of people who want to run a system off a cdrom or floppy or flash memory. On a cdrom you don't need to worry about deleteing /usr cause it should be burned into the cdrom. Also any partitions that you need end up in ram / memory disks. /dev is a good example of a ram disk. By having a smaller /bin and /sbin one can suddenly have nice small routers / gateways using freebsd, instead of Linux.

    I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other. Just look at the realpath vulnerability that they all were affected by.

    • It's good that they are trying to save disk space, but why don't they just rewrite them so they don't use libc? Linux assembly.org [linuxassembly.org] is working on such a project, though it doesn't have to be in assembly. I've done some work using direct syscalls in Linux with C (look at /usr/include/asm--start with unistd.h). I haven't looked at FreeBSD in this way yet, but I think it can be done. At the very least, simple utilities like cp and ln could be written this way. Save disk space and be staticly linked--good all th

      • Because there's a lot of logic in, say, PAM or NSS, which are needed often in /bin and /sbin. You could write that into each program, but then you'd have to update them all each time you found a bug or needed to add a feature. You could share a .o file between them, and then it's the same thing as statically linking them in the first place.

        • Yeah, but ln and cp do not need PAM or NSS or libc, so why use them?

          You could share a .o file between them, and then it's the same thing as statically linking them in the first place.

          Indeed, but then you are not statically linking in the entire libc system, which is the problem. I'm not against linking a bunch of .o files together, I just don't see the point in cramming tonnes of libc functions into a binary which doesn't need them and ends up more bloated as a result.

          • Indeed, but then you are not statically linking in the entire libc system, which is the problem.

            When you statically link, you only link in what you need. It doesn't suck in all of libc.a, only the .o files that are necessary. (Remember that a .a is an archive of .o files.)

      • You should look at the uClibc project which is trying to make a smaller libc for small floppy based distros. Also busybox, can be used to make a smaller system. Progamming in assembly is not pretty.
      • It's good that they are trying to save disk space, but why don't they just rewrite them so they don't use libc?

        Because reinventing wheels is generally a Bad Thing?

        Better to work to make libc smaller, or restructure it so that small utilities only drag in what they absolutely need.

        • Why? Do programs such as cp, ln, and touch really need libc? Why make something the size of a small paperback book connected to four huge wheels when you can just carry it around in your pocket?

          Better to work to make libc smaller, or restructure it so that small utilities only drag in what they absolutely need.

          So you are saying rewrite libc? Is this not reinventing the wheel? Not that it is a bad idea, but how is it different?

          • Why? Do programs such as cp, ln, and touch really need libc?

            No program ever needs a library. You could always implement everything from the ground up. The point of having libraries is to share the code. Re-implementing parts of the standard library in each utility is, apart from the wasted effort, just a way of creating more places for bugs to live.

            So you are saying rewrite libc? Is this not reinventing the wheel?

            No, it's software development. You fix the one piece of code which does a job so that it

    • Re:good and bad here (Score:3, Informative)

      by vesamies ( 240247 )
      NetBSD is also using dynamic /bin, /sbin, not sure what OpenBSD is doing. This is not much of an ability since /usr/bin, /usr/sbin have always been dynamic, now everything is dynamic. Well, looks like everyone has all-dynamic system now, which is good.

    • Re:good and bad here (Score:3, Informative)

      by MobyTurbo ( 537363 )
      I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other.
      NetBSD has had dynamic root (with /rescue, etc.) in -current for months. :-)

    • Re:good and bad here (Score:3, Informative)

      by JDizzy ( 85499 )
      I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other.

      Silly didn't you know that FreeBSD is stealling this from NetBSD's dynamic world? Well they are. FreeBSD has also taken the idea of a /rescue incase one of the libs that is dynamicly linked by (say init) is damaged. This was also a NetBSD idea. I guess that leaves OpenBSD to make the changes, but they probably think dynamic bins is insecure or some shit because an a
    • I don't want OpenBSD to have it. What happens if you kill ld.so? You are *FUCKED*. At least now, when I kill it, I can at least use mv to copy back my good copy with static libs. Disk space is cheep, get over it, and make / a bit bigger.
      • Its not a requirement that you have it in FreeBSD AFAIK, its an option. Also if you are talking about flash cards / CDROM where you have about 650 Megs limit or older machines that cant handle a bigger disk then this will allow more stuff to be installed or a smaller install. There are people who use 128Meg flash cards to run BSD / Linux from as a firewall.

        Not sure how you'd kill ld.so, I'm guessing your talking about rm -rf ld.so. Yeah you'd be screwed, but there is such thing as a rescue CD or upgradi

    • NetBSD already moved to dynamic root and /rescue earlier this year.

  • Blink (Score:3, Interesting)

    by timotten ( 5411 ) on Thursday August 21, 2003 @03:09AM (#6752556) Homepage
    enable users to build /bin and /sbin dynamically linked on FreeBSD

    I am having difficulty parsing this, and neither the article nor the comments here help me. This is my best guess. Someone please correct me.

    SITUATION: For some executable program $P in /bin or /sbin; for some executable library $L in /lib; there exists some subroutine $p in $P and some object $l in $L such that $p uses $l.

    OLD BEHAVIOR: When building $P, static-linker resolves name "$l", yielding an address or the desired data.

    NEW BEHAVIOR: When executing $P, dynamic-linker resolves name "$l", yielding an address or the desired data.

    DETAILS OF CHANGE: The kernel enforced the old behavior by examining every request sent to the generic 'dynamic-link' facility and blocked any requests which involved programs which happened to be in /bin or /sbin. The new behavior is achieved by removing the arbitrary, stupid prohibition.

    ALTERNATIVE DETAILS OF CHANGE: The old behavior was enforced by the build scripts for $P and $L; we didn't want our super-important $P to be disturbed if something as lame as the dynamic linker crapped out on us. The new behavior is achieved by changing some compiler flags. We will all die when the dynamic linker craps out.

  • I fail to see the benefit of this.

    A 25% absolute performance penalty, at the relative "gain" of 82% of a small part of the filesystem. However, compared to even an incredibly small (by today's standards) 1GB partition, you talk about saving only 2.5% of the total disk space. On any reasonable drive, this would equal far less than 1% savings.

    Now, in an embedded environment, such a savings might make a noticeable difference. However, in an embedded environment, you wouldn't have every app ever considered
    • Well, I can try.

      In a typical FreeBSD installation you make the root partition (/) quite small, these days 128MB to 256MB. This is to make the chance that when something happens that could damage your hard disk, the chance of it damaging your root and leave your system unbootable is minimal.
      This makes the chance that you can get to single user mode and run fsck on the damaged partitions bigger.
      In FreeBSD 2.x and 3.x the default root was even smaller and this made upgrading to 4.x in the general make buildwo

Slashdot Top Deals

Some people claim that the UNIX learning curve is steep, but at least you only have to climb it once.

Close