Re: differences in busybox configurations, part1 (longish)
Hello Ferenc, 2011/2/15 Ferenc Wagner wf...@niif.hu: Otavio Salvador ota...@ossystems.com.br writes: On Mon, Feb 14, 2011 at 22:06, Michael Tokarev m...@tls.msk.ru wrote: FEATURE_SHADOWPASSWDS support for getspent() and friends. Current: deb n static y udeb n Proposed action: enable for deb Discussion: It is quite unexpected that busybox can't use shadow passwords. On the other hand, there's just a few applets which actually deals with passwords, and most of them are disabled for deb build. I'd say to enable it on deb since it can be an important applet for embedded people to rely on. I have the gut feeling that static busybox was mostly used for testing cross-built system images under Qemu user-mode emulation. I can't serve with references now, but a web search would surely give you relevant hits. That's why the current static config is so much different from the other two: all three serve rather different purposes (deb: initramfs and rescue, udeb: d-i, static: full system testing). However, maybe the emulation use case isn't present anymore, since qemu-user gained the -L option... I hope embedded people can report on the current practices. Once upon a time there was an attempt to have a cross built Debian derivative based around busybox instead coreutils et al, it was named Crush and Neil Williams did an amazing work through some packages to be able to cross build them. Crush development has been postponed until multiarch is ready but some of the bits for the proof of concept can be found at emdebian svn [0]. Currently I cannot tell if that is an important option or not for cross-built systems derived from Debian. Best regards, [0] http://www.emdebian.org/trac/browser/current/target/busybox-crush/trunk Best regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=yrtnwa1ek4sadeaqljhxyarpdqbh5vaben...@mail.gmail.com
Re: differences in busybox configurations, part1 (longish)
On Wed, 16 Feb 2011 20:55:13 + Otavio Salvador ota...@ossystems.com.br wrote: On Wed, Feb 16, 2011 at 20:44, Hector Oron hector.o...@gmail.com wrote: ... Crush development has been postponed until multiarch is ready but some of the bits for the proof of concept can be found at emdebian svn [0]. ... What should we do? Just sync static with deb and later work on that? Seems like a more logical way for now at least. Each embedded installation may benefit from a slightly tweaked busybox from the busybox upstream default. All embedded installations of busybox are likely to benefit from a busybox built against a configuration completely unlike anything useful in standard Debian. For Emdebian Crush, I stuck to a busybox config which was fairly close to the standard default busybox configuration and nothing like the Debian config. I don't think there is a way of providing a single configuration of busybox which is both ideal for d-i and friendly to embedded systems. I cannot recommend any embedded system should use any version of busybox built by Debian for d-i without *also* installing and using coreutils, login, passwd, shadow, perl and all the rest. i.e. busybox from Debian is only suitable for what Debian normally does with busybox - which explicitly does *not* include handling passwords, shadow or otherwise. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpasXOgQEtp9.pgp Description: PGP signature
Re: differences in busybox configurations, part1 (longish)
On Wed, Feb 16, 2011 at 20:44, Hector Oron hector.o...@gmail.com wrote: ... Crush development has been postponed until multiarch is ready but some of the bits for the proof of concept can be found at emdebian svn [0]. ... What should we do? Just sync static with deb and later work on that? Seems like a more logical way for now at least. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=ta=Fg2HOQVrPehbOUhcZSmD1afR_xx2bYRzL=@mail.gmail.com
Re: differences in busybox configurations, part1 (longish)
On Wed, Feb 16, 2011 at 21:06, Neil Williams codeh...@debian.org wrote: ... I cannot recommend any embedded system should use any version of busybox built by Debian for d-i without *also* installing and using coreutils, login, passwd, shadow, perl and all the rest. i.e. busybox from Debian is only suitable for what Debian normally does with busybox - which explicitly does *not* include handling passwords, shadow or otherwise. Please take a look on this thread: http://lists.debian.org/debian-boot/2011/02/msg00471.html Basically we're going to revamp busybox and busybox-static configuration (d-i one is not going to be changed too much) and then we wish to try to be more friendly to this kind of use-cases. Doing the proposed changes I guess we fit this gab. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimidko_9QT9qtd-ypsvjYaKV3aC2Z5n=fv2w...@mail.gmail.com
Re: differences in busybox configurations, part1 (longish)
On Wed, 16 Feb 2011 21:15:57 + Otavio Salvador ota...@ossystems.com.br wrote: On Wed, Feb 16, 2011 at 21:06, Neil Williams codeh...@debian.org wrote: ... I cannot recommend any embedded system should use any version of busybox built by Debian for d-i without *also* installing and using coreutils, login, passwd, shadow, perl and all the rest. i.e. busybox from Debian is only suitable for what Debian normally does with busybox - which explicitly does *not* include handling passwords, shadow or otherwise. Please take a look on this thread: http://lists.debian.org/debian-boot/2011/02/msg00471.html Basically we're going to revamp busybox and busybox-static configuration (d-i one is not going to be changed too much) and then we wish to try to be more friendly to this kind of use-cases. As I'm sure you're aware, busybox is not one package, it's 50 or more - and that's just counting the common variations in source configuration, not counting the variations of C library used. Doing the proposed changes I guess we fit this gab. Only in the static model, which explains why the binary is so large. Emdebian Crush shipped with a binary of ~700kb but that was a much older version. Embedded users who want a static version are probably going to want a static version linked against uClibc and with no coreutils, login, passwd etc. installed and all symlinks enabled. I don't see how Debian can even test such a configuration, let alone recommend it for widespread usage. I think the best option is for d-i to simply keep up with busybox releases. (Current stable is 1.18.3, Debian has 1.17.1, even with bubulle's update since Squeeze.) That is, itself, a signficant challenge for a busy and overworked team like d-i and has proved to be an unreachable target before - especially once a release process starts up and the rest of d-i needs so much testing. Busybox needs to freeze early, that's entirely understandable. The standard build won't be (ever) able to install the symlinks which actually make busybox useful for embedded devices. (It can be hard to run something on device to create the symlinks when the device cannot boot because the symlinks don't exist.) The only real solution would be a fourth build with the symlinks enabled but which conflicts with dpkg, coreutils, login, passwd and numerous other utilities. I tried to make this fourth build available just for a single architecture via cross-building - it is a lot of work. This doesn't even start to handle the more common instance where the device needs a customised busybox configuration in the first place. It's a bigger problem than kernels because users who want busybox want busybox because there isn't room on the system for anything else and every 10kb less in /bin/busybox makes it worth reconfiguring and rebuilding it. Trying to be friendly is a good thing - adding work for the d-i team which still means that busybox needs to be reconfigured and rebuilt for actual embedded devices anyway isn't being friendly - either to the rest of the d-i team or the embedded users. Most important: what's the usage for the static build? Umm, exactly - not much IMHO. In the opinion of the dpkg maintainers, around the time of the Lenny freeze, a system which replaces coreutils, dpkg and passwd is not Debian any more. In the opinion of many embedded developers, a system with a full size busybox *and* coreutils, dpkg and the rest is simply wasting precious space. I don't want to be overly negative over this, I'm just trying to ensure that a commendable desire to be friendly does not actually result in wasting time within the d-i team and then turn out to not be useful to embedded users. IMHO, the best thing d-i can do is to ensure that Debian stays as close to the current busybox stable release as possible. Updating to current upstream stable as soon as possible after the release is done and ensuring it is again updated before the next freeze takes hold. That's a minimum of only two updates per release cycle, but updates which go directly to latest upstream stable. It will necessarily slip during all release freezes but that one commitment may well be enough. Rebuilding from a Debian source package with adjusted configuration is a lot more friendly than using wget on busybox.net. Keep the deb and udeb configuration exactly as d-i requires - maybe even drop the static version if d-i doesn't use it. Just keep the package up to date and it will make embedded use a lot simpler than trying to mangle together some incomplete, broken configuration which isn't directly usable. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgprrywdQGAKp.pgp Description: PGP signature
differences in busybox configurations, part1 (longish)
Part one of the discussion series. Config options which are enabled in udeb and static builds but not enabled in regular build. I assume two things: 1) regular build should include at least all options (with very few exceptions, see below) as udeb and static builds does. 2) generally, we want to ship all available utilities in regular build, and probably the same (maybe minus few exceptions which makes the binary extra-large) for static. This is just a beginning of the list of differences. If the assumptions above are correct, and the changes below look sane, and we agree with something. ;) Just for the record, non-static allyesconfig for i386 produces the following: textdata bss dec hex filename 40344917908988 414227 65213 busybox-1.17.1-9 133195429019180 1344035 148223 busybox-1.18.3-allyesconfig-shared I'm not sure we really need such a monster, so actual good question I'm still unsure about is: what's the intended usage for this tool? The config I use here does not include everything but only the most important utils, especially the ones which can't be easily substituted with shell code fragments. Most important: what's the usage for the static build? DPKG and DPKG_DEB (dpkg applet) Current: deb n static y udeb n Proposed action: enable for deb, keep disabled for udeb Discussion: small dpkg can be useful, especially in a static build indeed (for repair purposes when nothing else can be run). Just keeping two configs in sync for regular build. For udeb it isn't needed, -- can be enabled but we've size constraints. See next option. AR (ar applet) Current: deb n static y udeb y Proposed action: drop from static and udeb Discussion: I'm not sure why it's used for udeb. May be obsolete dpkg applet. Since .deb file is an ar archive, only one of these tools can be built. I prefer to keep dpkg since it is more debian-friendly. FEATURE_NON_POSIX_CP With this option, cp file symlink will delete symlink and create a regular file. This does not conform to POSIX, but prevents a symlink attack. Similarly, cp file device will not send file's data to the device. Current: deb y static n udeb n Proposed action: disable for deb. This is a good one. From one side we're trying to be POSIX-compatible, from another the standard behavour is a somewhat unsafe, and from 3rd side, this busybox feature appears to be unexpected. Anyway, current cp from coreutils behaves as if this feature is turned off, so let's match coreutils here. --- autentification, login utils --- FEATURE_SHADOWPASSWDS support for getspent() and friends. Current: deb n static y udeb n Proposed action: enable for deb Discussion: It is quite unexpected that busybox can't use shadow passwords. On the other hand, there's just a few applets which actually deals with passwords, and most of them are disabled for deb build. ADDUSER, DELUSER, ADDGROUP, DELGROUP Current: deb n static y udeb n Proposed action: remove from static. Discussion: can be trivially done using some editor or sed magic or just 'echo'. PASSWD Current: deb n static y udeb n Proposed action: enable for deb Discussion: probably needs to be setuid to work well, but good for root-only. Can be used from within an initrd to (re)set system password (alternative is to use editor to set it to empty string). CHPASSWD or CRYPTPW (not really a difference, but suggested to be enabled in context of passwd utility, currently disabled) FEATURE_PASSWD_WEAK_CHECK Current: deb n static y udeb n Proposed action: drop for static Discussion: most likely irrelevant option, since the checks it performs are very basic. GETTY, LOGIN, NOLOGIN, SU, SULOGIN, VLOCK Current: deb n static y udeb n Proposed action: disable static Discussion: I'm not actually sure why all this is enabled for static build, it makes very little sense unless we really need full system in a single executable. --- init --- INIT (init applet) Current: deb n static y udeb y Proposed action: enable for deb Discussion: small init is actually useful at times, I use it on our diskless workstations (which runs Debian). FEATURE_INIT_SYSLOG this lets init to perform syslog logging. Current: static n udeb y Proposed action: set to n for deb after enabling init (by default it is enabled upstream). RFC. FEATURE_INITRD Legacy support for running init under the old-style initrd. Allows the name linuxrc to act as init, and it doesn't assume init is PID 1. Current: static y udeb n Proposed action: enable for deb Discussion: Is it actually needed? The feature itself is still supported by current kernel, so it's probably a good idea to support it. The code size is very small. PIVOT_ROOT and FREERAMDISK goes together and near INITRD, since most usage is around initrd. Note that pivot_root is used nowadays for lxc Current: deb n static y udeb y Proposed action: enable for deb Discussion: tools for initrd (legacy but may be useful) HALT Current: deb n static n
Re: differences in busybox configurations, part1 (longish)
On Tue, Feb 15, 2011 at 01:06:46AM +0300, Michael Tokarev wrote: Part one of the discussion series. Config options which are enabled in udeb and static builds but not enabled in regular build. I don't disagree with anything you've mentioned. If all of the changes you recommend were integrated, I wouldn't have a problem. - Matt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214225306.gd2...@hezmatt.org
Re: differences in busybox configurations, part1 (longish)
First I'd like to thank you for doing that but I'd also want to make clear that we need to be conservative on udeb flavour since the installer heavily depends on it. More bellow... On Mon, Feb 14, 2011 at 22:06, Michael Tokarev m...@tls.msk.ru wrote: ... Just for the record, non-static allyesconfig for i386 produces the following: text data bss dec hex filename 403449 1790 8988 414227 65213 busybox-1.17.1-9 1331954 2901 9180 1344035 148223 busybox-1.18.3-allyesconfig-shared I'm not sure we really need such a monster, so actual good question I'm still unsure about is: what's the We surely not! intended usage for this tool? The config I use here does not include everything but only the most important utils, especially the ones which can't be easily substituted with shell code fragments. Personally I agree that all-yes is a no-go. We ought to use some common-sense when thinking about enabling or not something. Most important: what's the usage for the static build? DPKG and DPKG_DEB (dpkg applet) Current: deb n static y udeb n Proposed action: enable for deb, keep disabled for udeb Discussion: small dpkg can be useful, especially in a static build indeed (for repair purposes when nothing else can be run). Just keeping two configs in sync for regular build. For udeb it isn't needed, -- can be enabled but we've size constraints. See next option. Personally I think it shouldn't be enable in any flavour since a deb package can be extracted with ar and tar. So easily done in case of need. AR (ar applet) Current: deb n static y udeb y Proposed action: drop from static and udeb Discussion: I'm not sure why it's used for udeb. May be obsolete dpkg applet. Since .deb file is an ar archive, only one of these tools can be built. I prefer to keep dpkg since it is more debian-friendly. deb=y It is used on d-i since udpkg rely on it to work. FEATURE_NON_POSIX_CP With this option, cp file symlink will delete symlink and create a regular file. This does not conform to POSIX, but prevents a symlink attack. Similarly, cp file device will not send file's data to the device. Current: deb y static n udeb n Proposed action: disable for deb. ... Agreed. --- autentification, login utils --- FEATURE_SHADOWPASSWDS support for getspent() and friends. Current: deb n static y udeb n Proposed action: enable for deb Discussion: It is quite unexpected that busybox can't use shadow passwords. On the other hand, there's just a few applets which actually deals with passwords, and most of them are disabled for deb build. I'd say to enable it on deb since it can be an important applet for embedded people to rely on. ADDUSER, DELUSER, ADDGROUP, DELGROUP Current: deb n static y udeb n Proposed action: remove from static. Discussion: can be trivially done using some editor or sed magic or just 'echo'. Agreed. At least for now it can be dropped. PASSWD Current: deb n static y udeb n Proposed action: enable for deb Discussion: probably needs to be setuid to work well, but good for root-only. Can be used from within an initrd to (re)set system password (alternative is to use editor to set it to empty string). Fully agree. CHPASSWD or CRYPTPW (not really a difference, but suggested to be enabled in context of passwd utility, currently disabled) IMO this shouldn't be enabled. FEATURE_PASSWD_WEAK_CHECK Current: deb n static y udeb n Proposed action: drop for static Discussion: most likely irrelevant option, since the checks it performs are very basic. Agreed. GETTY, LOGIN, NOLOGIN, SU, SULOGIN, VLOCK Current: deb n static y udeb n Proposed action: disable static Discussion: I'm not actually sure why all this is enabled for static build, it makes very little sense unless we really need full system in a single executable. This can hurt embedded people. I am adding Hector so he can comment on it. INIT (init applet) Current: deb n static y udeb y Proposed action: enable for deb Discussion: small init is actually useful at times, I use it on our diskless workstations (which runs Debian). Agreed. FEATURE_INIT_SYSLOG this lets init to perform syslog logging. Current: static n udeb y Proposed action: set to n for deb after enabling init (by default it is enabled upstream). RFC. We have a busybox-syslog that depends on it, no? For udeb please let it as is. FEATURE_INITRD Legacy support for running init under the old-style initrd. Allows the name linuxrc to act as init, and it doesn't assume init is PID 1. Current: static y udeb n Proposed action: enable for deb Discussion: Is it actually needed? The feature itself is still supported by current kernel, so it's probably a good idea to support it. The code size is very small. IMO it could be disabled. It is difficult to think someone is using a such old way of booting for wheezy based systems. PIVOT_ROOT and FREERAMDISK
Re: differences in busybox configurations, part1 (longish)
Otavio Salvador ota...@ossystems.com.br writes: On Mon, Feb 14, 2011 at 22:06, Michael Tokarev m...@tls.msk.ru wrote: FEATURE_SHADOWPASSWDS support for getspent() and friends. Current: deb n static y udeb n Proposed action: enable for deb Discussion: It is quite unexpected that busybox can't use shadow passwords. On the other hand, there's just a few applets which actually deals with passwords, and most of them are disabled for deb build. I'd say to enable it on deb since it can be an important applet for embedded people to rely on. I have the gut feeling that static busybox was mostly used for testing cross-built system images under Qemu user-mode emulation. I can't serve with references now, but a web search would surely give you relevant hits. That's why the current static config is so much different from the other two: all three serve rather different purposes (deb: initramfs and rescue, udeb: d-i, static: full system testing). However, maybe the emulation use case isn't present anymore, since qemu-user gained the -L option... I hope embedded people can report on the current practices. NC_SERVER, NC_EXTRA (netcat options) Current: deb n static n udeb y Proposed action: enable for deb and static Discussion: actually useful for rescue system Agreed. I am not sure it ought to be enabled on udeb. Comments? I often find it easier to keep the server end on the machine being installed to avoid reconfiguration of the firewall on production machines (which block incoming connections to all unused ports). -- Cheers, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vxidsja@tac.ki.iif.hu
Re: differences in busybox configurations, part1 (longish)
Quoting Michael Tokarev (m...@tls.msk.ru): Part one of the discussion series. Config options which are enabled in udeb and static builds but not enabled in regular build. I won't comment myself (as said already, this is out of my field of expertise), but I'd suggest to also wait for Joey Hess input. Joey is our history memory in D-I and, for anything that deals with what we need in D-I (so for the udeb), his advice is more or less mandatory... Input by Bastian Blank would be great as well, though Bastian uses to be quite scarce when he comments things (but he nearly always has a point..;:-)) signature.asc Description: Digital signature
