On Thu, 01 Mar 2007, Nikita V. Youshchenko wrote: > Sorry Marco, but it is not valid to close a bug report that describes an > existing issue only because you don't like the solution suggested by the > submitter.
Agreed, actually. But this is bigger than udev, it probably belongs in "general", and not just one or two packages. > Udev startup script does operate in restricted environment, where not all > system services are already up and running. And it should be written as > such. So far so good. Udev really will have to somehow know when it is being run at coldplug and very early userspace setup, and use a subset of the scripts. > For ages, there was an agreement related to non-local auth services, that > everything that is referenced before network service is up, should be > resolvable by local data. 'Resolvable' here means that the result (being > it positive or negative) should be available locally, without attempts to > request data from not-yet-available service. So far so good. This is basic. > And in the current situation, udev is *the* package that, by installing > it's default configuration files, injects references to > non-resolvable-locally users and groups into early stage of boot. Wrong. Your expectations to what is allowed to be non-resolvable-locally are not in sync with what Debian currently supports. Note: I am not telling you your expectations are unreasonable, but that they are more than what we can properly support right now. And this is NOT just a bug in udev. With async userspace, and more imporantly, async userspace boot, we need to have things properly setup much earlier because we don't (currently) really know when yhey will be needed. Udev is just one of the things that are part of it. Dependency-based booting is another one. The bottom line is that, until we define *exactly* what early userspace can and cannot do, so that we can implement async userspace a lot more sanely, any system which cannot work standalone until network is up and running is going to break. And udev cannot really be expected to do much more than what it already does unless we define the early userspace. > So a *fix* for this issue could be only inside udev package. No. In fact, a proper fix needs to be Debian-wide, a number of packages may need to be changed to do it right. Udev is probably one of them, but not the only one. > - if base-passwd will be used as workaround location, this will create a > situation when changes to default udev configuration files, introducing > references to new groups or removing references to old ones, will cause > need of base-files update - which is increased complexity and will cause > out-of-sync situations; This will be fixed when we know what early userspace can and cannot do, and thus udev will know to which groups it must restrict itself. And probably some way to defer rules from running while in early userspace could be implemented, as well. Note that we may end up defining that early userspace must restrict itself to *static* system users and groups. That likely will require an increase in the number of static system users and groups. > - workaround at libnss-* level is complex (see all that logic with files > noting boot process etc), needed in any libnss-* that references network, Whatever we do, there is no magic here. Important system resources (users and groups) that are needed at early userspace must *NOT* depend on anything that is not provided by the initrd (or the kernel itself plus the root partition), and that's it. You can *override* them later, so that, e.g., you can add a lot more stuff to group "sound" when network comes up. libnss-* modules that need something more than what the kernel/initrd/intramfs/whatever provides must not be active until the resources they need are available. This is probably a big bad bug on most of the libnss-* modules and their packaging, or maybe we should be swapping /etc/nsswitch.conf around during boot. > and generally misplaced - because, unlike udev init script, nss is not a > system designed for restricted environment, and it is not it's job to It has to be designed to work on restricted environments, because it is running as soon as anything linked to libc needs it. That doesn't mean we are using it correctly. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
