Re: adduser Pre-Depends for qemu-system-common
I'm not an admin but I'm interested in ADDUSER breakage, if any. Could you side-band me (reply to sender please) why adduser may have any (new) dependancy problems with adduser ? Obviously hacks that break adduser imply breakage to other softwares in or not in debian, which supposedly against policy (as if they follow that anymore). There are so many hacks and additions to basic standards from dvd (series of image: now gone wild with hw incompatibility and changes) to user permissions bits (and what format) to just adding a user: it's crazy anything old OR new even works :) Why can't they build on things instead of break them - like they more or less used to do ? For example I have a nice install time script that imports old password and group to be new password and group (it makes all changes needed, ie to filesystem too) so that new distribution has no problems in it's expectations while installing. adduser is employed somewhere within for obvious reasons. Thank you, John Hendrickson Ian Jackson wrote: Wookey writes (Re: adduser Pre-Depends for qemu-system-common): I don't know if there is a better way in this particular case but I do know that adding users in preinsts does cause problems. Preinsts that do anything important (which is not dealing with upgrades from previous packages) cause issues for cross-arch rootfs generation, where the system has to be booted before preinsts can be run. [...] Making sure that the user/group is _also_ created in the postinst if it's not already been done would make everything work nicely from my POV. Avoiding doing such things in preinsts at all is good if possible. . Perhaps a discussion of this issue would be welcome in the policy manual ? Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5156113d.4050...@cox.net
Re: adduser Pre-Depends for qemu-system-common
Wookey writes (Re: adduser Pre-Depends for qemu-system-common): I don't know if there is a better way in this particular case but I do know that adding users in preinsts does cause problems. Preinsts that do anything important (which is not dealing with upgrades from previous packages) cause issues for cross-arch rootfs generation, where the system has to be booted before preinsts can be run. [...] Making sure that the user/group is _also_ created in the postinst if it's not already been done would make everything work nicely from my POV. Avoiding doing such things in preinsts at all is good if possible. . Perhaps a discussion of this issue would be welcome in the policy manual ? Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20820.16905.925025.770...@chiark.greenend.org.uk
Re: adduser Pre-Depends for qemu-system-common
Quoting Wookey (woo...@wookware.org): +++ Serge Hallyn [2013-03-14 14:58 -0500]: Hi, To fix this the kvm group should be created during preinst before the udev rules file is unpacked. This requires adding adduser to the Pre-Depends. vorlon warned me that any new pre-depends should be discussed here first, so I'm emailing to ask - is this ok? Is there a better way? I don't know if there is a better way in this particular case but I do know that adding users in preinsts does cause problems. Preinsts that do anything important (which is not dealing with upgrades from previous packages) cause issues for cross-arch rootfs generation, where the system has to be booted before preinsts can be run. Mysql, for example, creates its user in the preinst and this breaks if you create a foreign-arch rootfs with multistrap containing mysql. I find it hard to imagine why this necessary, but I assume someone had a good reason. Making sure that the user/group is _also_ created in the postinst if it's not already been done would make everything work nicely from my POV. Avoiding doing such things in preinsts at all is good if possible. . Thanks, I'll make sure to keep it there as well. It's also been pointed out to me that actually qemu-kvm, which is being replaced by qemu, already had adduser in Pre-Depends. So actually this isn't a new case, and perhaps this thread was unnecessary :) (But then I wouldn't have thought about this case) thanks, -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130315132754.GA3782@sergelap
adduser Pre-Depends for qemu-system-common
Hi, qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). To fix this the kvm group should be created during preinst before the udev rules file is unpacked. This requires adding adduser to the Pre-Depends. vorlon warned me that any new pre-depends should be discussed here first, so I'm emailing to ask - is this ok? Is there a better way? thanks, -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130314195824.GA21222@sergelap
Re: adduser Pre-Depends for qemu-system-common
On Thu, Mar 14, 2013 at 02:58:24PM -0500, Serge Hallyn wrote: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). To fix this the kvm group should be created during preinst before the udev rules file is unpacked. This requires adding adduser to the Pre-Depends. vorlon warned me that any new pre-depends should be discussed here first, so I'm emailing to ask - is this ok? Is there a better way? FWIW, my own analysis is that this looks fine; qemu-system-common is nothing approaching a core package, and adduser is already one of the most common Pre-Dependencies in the archive (32 packages in unstable; the only more common pre-deps seem to be multiarch-support, and dpkg). So I think this is a clear cut legitimate use of a Pre-Depends, but of course this should still get other eyeballs on it in case I've missed something. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: adduser Pre-Depends for qemu-system-common
Hi, Serge Hallyn serge.hal...@ubuntu.com writes: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). Couldn't postint tell udev explicitly to reload rules after the kvm group was added? The init script has a reload action which calls udevadm control --reload-rules which might do the right thing. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9q5vg2n@deep-thought.43-1.org
Re: adduser Pre-Depends for qemu-system-common
On 14.03.2013 22:15, Ansgar Burchardt wrote: Hi, Serge Hallyn serge.hal...@ubuntu.com writes: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). Couldn't postint tell udev explicitly to reload rules after the kvm group was added? The init script has a reload action which calls udevadm control --reload-rules which might do the right thing. I'd probably just do an explicit chown/chmod /dev/kvm (given the device exists) in postinst. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: adduser Pre-Depends for qemu-system-common
* Serge Hallyn serge.hal...@ubuntu.com, 2013-03-14, 14:58: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). To fix this the kvm group should be created during preinst before the udev rules file is unpacked. This requires adding adduser to the Pre-Depends. vorlon warned me that any new pre-depends should be discussed here first, so I'm emailing to ask - is this ok? Is there a better way? IIRC, src:sane-backends uses setfacl(1) instead of changing the group. Not sure if that counts as better. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130314212823.ga4...@jwilk.net
Re: adduser Pre-Depends for qemu-system-common
+++ Serge Hallyn [2013-03-14 14:58 -0500]: Hi, To fix this the kvm group should be created during preinst before the udev rules file is unpacked. This requires adding adduser to the Pre-Depends. vorlon warned me that any new pre-depends should be discussed here first, so I'm emailing to ask - is this ok? Is there a better way? I don't know if there is a better way in this particular case but I do know that adding users in preinsts does cause problems. Preinsts that do anything important (which is not dealing with upgrades from previous packages) cause issues for cross-arch rootfs generation, where the system has to be booted before preinsts can be run. Mysql, for example, creates its user in the preinst and this breaks if you create a foreign-arch rootfs with multistrap containing mysql. I find it hard to imagine why this necessary, but I assume someone had a good reason. Making sure that the user/group is _also_ created in the postinst if it's not already been done would make everything work nicely from my POV. Avoiding doing such things in preinsts at all is good if possible. . Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130314214317.gf20...@stoneboat.aleph1.co.uk
Re: adduser Pre-Depends for qemu-system-common
Quoting Michael Biebl (bi...@debian.org): On 14.03.2013 22:15, Ansgar Burchardt wrote: Hi, Serge Hallyn serge.hal...@ubuntu.com writes: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). Couldn't postint tell udev explicitly to reload rules after the kvm group was added? The init script has a reload action which calls udevadm control --reload-rules which might do the right thing. I'd probably just do an explicit chown/chmod /dev/kvm (given the device exists) in postinst. That is not sufficient. If something else does udevadm trigger, udev will re-label /dev/kvm with the old group perms. -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130314213030.GA6605@sergelap
Re: adduser Pre-Depends for qemu-system-common
On 14.03.2013 22:30, Serge Hallyn wrote: Quoting Michael Biebl (bi...@debian.org): On 14.03.2013 22:15, Ansgar Burchardt wrote: Hi, Serge Hallyn serge.hal...@ubuntu.com writes: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). Couldn't postint tell udev explicitly to reload rules after the kvm group was added? The init script has a reload action which calls udevadm control --reload-rules which might do the right thing. I'd probably just do an explicit chown/chmod /dev/kvm (given the device exists) in postinst. That is not sufficient. If something else does udevadm trigger, udev will re-label /dev/kvm with the old group perms. Nothing should run udevadm trigger, at least not without being specific to a subsystem. If a package is doing that, it's buggy. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: adduser Pre-Depends for qemu-system-common
* Ansgar Burchardt: Couldn't postint tell udev explicitly to reload rules after the kvm group was added? udev does not support this: http://lists.fedoraproject.org/pipermail/devel/2013-January/177046.html (The discussion extends into February 2013.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hakdy4y0@mid.deneb.enyo.de
Re: adduser Pre-Depends for qemu-system-common
On Thu, Mar 14, 2013 at 10:59:42PM +0100, Michael Biebl wrote: On 14.03.2013 22:30, Serge Hallyn wrote: Quoting Michael Biebl (bi...@debian.org): On 14.03.2013 22:15, Ansgar Burchardt wrote: Hi, Serge Hallyn serge.hal...@ubuntu.com writes: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). Couldn't postint tell udev explicitly to reload rules after the kvm group was added? The init script has a reload action which calls udevadm control --reload-rules which might do the right thing. I'd probably just do an explicit chown/chmod /dev/kvm (given the device exists) in postinst. That is not sufficient. If something else does udevadm trigger, udev will re-label /dev/kvm with the old group perms. Nothing should run udevadm trigger, at least not without being specific to a subsystem. If a package is doing that, it's buggy. The relevant subsystem for kvm is misc, which could be triggered by any number of arbitrary packages. A solution that happens to work /unless/ some other package gets installed that uses the same kernel subsystem isn't very robust. I think it's important to ensure that, by the time the package is in state 'installed', the udev db is in a consistent state. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: adduser Pre-Depends for qemu-system-common
On Thu, Mar 14, 2013 at 10:28:23PM +0100, Jakub Wilk wrote: * Serge Hallyn serge.hal...@ubuntu.com, 2013-03-14, 14:58: qemu-system-common installs a udev rules file which sets /dev/kvm group to 'kvm'. Its postinst then adds a kvm group. However udev reads the new rules file as soon as it sees it, sees that group kvm doesn't exist, and ignores that part of the rule (until reboot, udev restart, or the rule is re-added, of course). To fix this the kvm group should be created during preinst before the udev rules file is unpacked. This requires adding adduser to the Pre-Depends. vorlon warned me that any new pre-depends should be discussed here first, so I'm emailing to ask - is this ok? Is there a better way? IIRC, src:sane-backends uses setfacl(1) instead of changing the group. Not sure if that counts as better. setfacl or chgrp, it still needs to be handled in the udev rules; so preferably, those udev rules would be the *only* place the device perms need to be handled, and that means making sure the rules are valid at unpack time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
