Re: systemd now appears to be only possible init system in testing
Quoting Russ Allbery (r...@debian.org): > Cameron Norman writes: > > > Oh this is easy. The init script calls s-s-d and does not check the return > > code (so always exits 0). I am just going to use set -e in the init > > script, only a couple tweaks are needed. > > Please don't use set -e in init scripts. See Policy 9.3.2: > > Be careful of using set -e in init.d scripts. Writing correct init.d > scripts requires accepting various error exit statuses when daemons > are already running or already stopped without aborting the init.d > script, and common init.d function libraries are not safe to call with > set -e in effect. For init.d scripts, it's often easier to not use > set -e and instead check the result of each command separately. > > Not mentioned there is another problem, namely that LSB mandates > particular exit codes for particular conditions in init scripts, and set > -e will not produce the correct exit codes. No worries, I've gone a different route - borrowing heavily (and appreciatively) from the libvirt init scripts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725233710.GS31507@ubuntumail
Re: systemd now appears to be only possible init system in testing
Quoting Michael Biebl (bi...@debian.org): > Hi Serge! > > Am 25.07.2014 23:35, schrieb Serge Hallyn: > > Quoting Michael Biebl (bi...@debian.org): > >> Am 25.07.2014 19:23, schrieb Steve Langasek: > >>> systemd-shim 6-4 has now been uploaded to unstable with a dependency on > >>> cgmanager, implementing the new post-v205 interfaces. > >> > >> I just installed systemd-shim 6-4 and cgmanager 0.28-1. > >> Unfortunately the cgmanager package seems to be not quite ready yet. > >> > >> The init script fails with > >> > >> # service cgmanager start > >> [] Starting cgroup management daemon: cgmanagercgmanager: Failed > >> mounting memory onto /run/cgmanager/fs/memory: No such file or directory > >> cgmanager: Failed mounting cgroups > >> cgmanager: Failed to set up cgroup mounts > >> . ok > > > > That was an upstream bug, should be fixed in 0.28-2. The default of > > having memory show up in /proc/cgroups but not be mountable was being > > mishandled. > > Ah perfect. Seems this just hasn't hit the archive yet when I installed > cgmanager. > > Steve, could you please bump the depends on cgmanager in systemd-shim > accordingly to ensure a working cgmanager is installed? > > > There was also mention of having a systemd unit linked to /dev/null to > > not run cgmanager in systemd. I assume that's what systemd itself would > > actually prefer and I'm fine with it, but for the sake of supporting > > nested containers it would be nicer if we could have it actually run > > (for now). > > If cgmanager and systemd don't step on each others toes and there is > value running cgmanager besides systemd, it might make sense to also run > it under systemd. > > My only concern would be, that most users probably don't need nested > containers and if cgmanager is pulled in as a depends on systemd-shim, > they'd have a useless daemon running. > > What about shipping a native .service file for cgmanager, but not enable > it by default, i.e. the admin would have to run > systemctl enable cgmanager.service > if want's to run cgmanager under systemd. > > That means, under sysvinit the service would be running by default and > under systemd it would have to be enabled explicitly. > > Would that work for you? Sure - I don't know offhand how this would be done, but I'll look into it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725221022.GO31507@ubuntumail
Re: systemd now appears to be only possible init system in testing
Quoting Michael Biebl (bi...@debian.org): > > Am 25.07.2014 23:35, schrieb Serge Hallyn: > > Quoting Michael Biebl (bi...@debian.org): > >> > >> The init script fails with > >> > >> # service cgmanager start > >> [] Starting cgroup management daemon: cgmanagercgmanager: Failed > >> mounting memory onto /run/cgmanager/fs/memory: No such file or directory > >> cgmanager: Failed mounting cgroups > >> cgmanager: Failed to set up cgroup mounts > >> . ok > > > > > >> on a default jessie kernel. > >> > >> Interestingly, the return code of the init script was 0. > > Could you please also look into this. > > The init script shouldn't have an exit code of 0 if the daemon failed to > start. > > Thanks! D'oh, yup, that's a real bug in the (upstream) sysvinit job. Thanks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725220636.GN31507@ubuntumail
Re: systemd now appears to be only possible init system in testing
Quoting Michael Biebl (bi...@debian.org): > Am 25.07.2014 19:23, schrieb Steve Langasek: > > systemd-shim 6-4 has now been uploaded to unstable with a dependency on > > cgmanager, implementing the new post-v205 interfaces. > > I just installed systemd-shim 6-4 and cgmanager 0.28-1. > Unfortunately the cgmanager package seems to be not quite ready yet. > > The init script fails with > > # service cgmanager start > [] Starting cgroup management daemon: cgmanagercgmanager: Failed > mounting memory onto /run/cgmanager/fs/memory: No such file or directory > cgmanager: Failed mounting cgroups > cgmanager: Failed to set up cgroup mounts > . ok That was an upstream bug, should be fixed in 0.28-2. The default of having memory show up in /proc/cgroups but not be mountable was being mishandled. There was also mention of having a systemd unit linked to /dev/null to not run cgmanager in systemd. I assume that's what systemd itself would actually prefer and I'm fine with it, but for the sake of supporting nested containers it would be nicer if we could have it actually run (for now). > on a default jessie kernel. > > Interestingly, the return code of the init script was 0. > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725213503.GL31507@ubuntumail
Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)
Quoting Marco d'Itri (m...@linux.it): > On Jul 09, Alessio Treglia wrote: > > > I think that it would be valuable for our users to keep the > > non-default init system working on Jessie for those who do neither > > intend nor need to switch to systemd. > I suggest less thinking and more coding then, because an updated > systemd-shim still has not magically appeared. I'm working on a systemd-shim update to do the cgroup setup on login. However if someone with a better understanding of all the slices and scopes and sessions has an interest please let me know and don't let me hold you back! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709172957.GT1132@ubuntumail
Re: [Pkg-shadow-devel] Help wanted: test new shadow source package (login, passwd, uidmap, etc.)
Quoting Steve Langasek (vor...@debian.org): > On Fri, May 02, 2014 at 04:38:15AM +0000, Serge Hallyn wrote: > > Quoting Christian PERRIER (bubu...@debian.org): > > > Quoting Christian PERRIER (bubu...@debian.org): > > > > Hello fellow developers, > > > > > > > > I would like to request your help in testing the new version of the > > > > shadow package (that provides login, passwd and such other important > > > > or base packages). > > > > I haven't got much feedbackwhich is indeed what I was more or less > > > expecting. ;-) > > > > So, well, let's jump into the mud (I love to do that when > > > running.not sure I love to do that in my FLOSS activities) and > > > I'll soon upload shadow to unstable Be prepared. > > > so first glitch I found is that /etc/subuid was not created for me. > > login.postinst only creates that on new installs. In Ubuntu it > > does so anytime it does not exist - I assume you made that change > > on purpose? usermod -v refuses to run if the file does not exist, > > so users will need to be told to create those files themselves. > > The right answer is probably to create the file on new installs and on > upgrades from versions earlier than the first version introducing this. Yeah I was thinking that last night - i guess this is pretty easy to do, and some people will not want to have those files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502133823.GC1760@ubuntumail
Re: [Pkg-shadow-devel] Help wanted: test new shadow source package (login, passwd, uidmap, etc.)
Quoting Christian PERRIER (bubu...@debian.org): > Quoting Serge Hallyn (serge.hal...@ubuntu.com): > > Quoting Christian PERRIER (bubu...@debian.org): > > > Quoting Christian PERRIER (bubu...@debian.org): > > > > Hello fellow developers, > > > > > > > > I would like to request your help in testing the new version of the > > > > shadow package (that provides login, passwd and such other important > > > > or base packages). > > > > > > I haven't got much feedbackwhich is indeed what I was more or less > > > expecting. ;-) > > > > > > So, well, let's jump into the mud (I love to do that when > > > running.not sure I love to do that in my FLOSS activities) and > > > I'll soon upload shadow to unstable Be prepared. > > > > Hi, > > > > so first glitch I found is that /etc/subuid was not created for me. > > login.postinst only creates that on new installs. In Ubuntu it > > does so anytime it does not exist - I assume you made that change > > on purpose? usermod -v refuses to run if the file does not exist, > > so users will need to be told to create those files themselves. > > What makes you think this? > > In login.postinst, we have: > > # Create subuid/subgid if missing > if [ ! -e /etc/subuid ]; then > touch /etc/subuid > chown root:root /etc/subuid > chmod 644 /etc/subuid > fi > > > (strangely indented, admitedlybut unless I'm missing something Oh, yo'ure right. The indenting threw me off. And the reason they weren't created was that I was blindly expecting the uidmap package to depend on both passwd and login >= 1:4.2-1, so while i had upgraded passwd to experimental's version i hadn't upgraded login's. Sorry, my bad. So all seemed to be working fine! > obvious, it is unconditionnally run) > > That code probably somes unchanged from the patches that have been > proposed, indeed. > > And, well, on my system, /etc/subuid and /etc/subgid were indeed > created when I manually installed the new login package. > > ___ > Pkg-shadow-devel mailing list > pkg-shadow-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502133733.GB1760@ubuntumail
Re: Help wanted: test new shadow source package (login, passwd, uidmap, etc.)
Quoting Christian PERRIER (bubu...@debian.org): > Quoting Christian PERRIER (bubu...@debian.org): > > Hello fellow developers, > > > > I would like to request your help in testing the new version of the > > shadow package (that provides login, passwd and such other important > > or base packages). > > I haven't got much feedbackwhich is indeed what I was more or less > expecting. ;-) > > So, well, let's jump into the mud (I love to do that when > running.not sure I love to do that in my FLOSS activities) and > I'll soon upload shadow to unstable Be prepared. Hi, so first glitch I found is that /etc/subuid was not created for me. login.postinst only creates that on new installs. In Ubuntu it does so anytime it does not exist - I assume you made that change on purpose? usermod -v refuses to run if the file does not exist, so users will need to be told to create those files themselves. >From there I was able to start an unprivileged lxc container, so the basics seemed to be correct. Thanks! -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502043815.GA1500@ubuntumail
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
Quoting Cameron Norman (camerontnor...@gmail.com): > El Wed, 26 de Mar 2014 a las 9:03 PM, gustavo panizzo > escribió: > >On 03/26/2014 11:49 PM, Cameron Norman wrote: > >I wonder if dbus activation > >> could be used to accomplish this. Of course, then one would not > >>be able > >> to put (in the case of Upstart) the socket bridge, dbus bridge, > >>dbus, or > >> anything those services need to boot into a cgroup, but one can > >>still > >> put stuff like Apache, lightdm/gdm/kdm/sddm, nginx, et al into > >>a cgroup. > >> Another option is to push the kernel maintainers to allow delegating > >> parts of the cgroups tree to other processes, so that the init > >>system > >> could say "you get a sub-hierarchy, you get a sub-hierarchy" > >>without the > >> complication of multiple separate hierarchies. How do you > >>suggest this > >> integration with cgroups be done? > >> > >i just want to put services inside cgroups, no socket activation, no > >dbus, no dbus activation. > > > > Haha. The problem there is that cgmanager uses dbus! So you need It doesn't use the system or session bus, though, just listens over its own unix socket. Dbus does not need to be started first. -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140327142638.GC7658@sergelap
Re: Call to fork
Quoting John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de): > On 02/11/2014 04:18 PM, Serge Hallyn wrote: > > FWIW, disagree - I rarely set up a machine (little laptop or server or > > container) where I don't need to do one thing or another custom at boot. > > Throttle back cpus to prevent overheating, register dynamic dns, > > whatever. > > All of that is possible or even easier with systemd. I don't see your > point. I was arguing against the idea that users might not care what init system they are on. -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/20140215000958.GG30960@sergelap
Re: Call to fork
Quoting Paul Tagliamonte (paul...@debian.org): > On Tue, Feb 11, 2014 at 03:39:49PM +0100, Florian Lohoff wrote: > > I am telling you that by all the technical discussions which of > > the systems is superior over the other you forget about your users. > > Our users shouldn't care what init system we use. It's an > implementation -- and purely technical -- detail of the OS. FWIW, disagree - I rarely set up a machine (little laptop or server or container) where I don't need to do one thing or another custom at boot. Throttle back cpus to prevent overheating, register dynamic dns, whatever. -- 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/20140211151848.GB5025@sergelap
Re: systemd effectively mandatory now due to GNOME
Quoting Brian May (br...@microcomaustralia.com.au): > On 24 October 2013 11:09, Adam Borowski wrote: > > > * it breaks other users of cgroups. I have not tested this personally > > (mostly because of the above point), but if I understand it right, it takes > > over the whole cgroups system, requiring anything that runs on the same > > kernel instance to beg it via dbus to perform required actions. > > > > I have heard this said before, would like to have some official > confirmation if this is actually the case or not. cgroups are currently > hierarchical, I would have thought this would mean, at least in theory, > different programs could be responsible for different parts of > the hierarchy. It currently can't prevent you from just mounting the cgroupfs and working with it. One of the justifications presented at plumbers for wanting to do this was that changes to a subtree you control can affect other tasks. But it was agreed that that was actually only for realtime (?) cgroup and that it is a bug which must be fixed. In any case, google has released lmctfy (https://github.com/google/lmctfy/) as an alternative cgroup manager which is actually quite nice, and which does support delegation. Based on that I intend to implement a nestable manager. By nestable I mean that it will create a unix socket over which requests can be made. So I can create a container and bind-mount that unix socket into the container. Then a container copy of the same cgroup manager, finding it can't mount cgroups but the device socket exists, makes requests over that socket. If it is in cgroup /c1, and requests creation of socket c2, the host's manager will create /c1/c2. Since we have a unix socket we can check the caller's credentials, it's access(2) rights to the cgroups it wants to manage as well as the tasks it is wanting to move. (And if a container is created inside that container, it can bind-mount the same socket, start another manager, and nesting should just work) I've played enough to verify that all the pieces we need are there. I just haven't had the time to write it, and I need to decide whether/how to base on / integrate with lmctfy. [ And if anyone else wants to write this, please be my guest :) I just want nesting as described above ] -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/20131024172511.GA21543@ac100
Re: lxc / vserver / openvz (was: systemd flamage)
Quoting Adam Borowski (kilob...@angband.pl): > On Thu, Oct 24, 2013 at 03:40:04PM +0200, Marco d'Itri wrote: > > On Oct 24, Dmitrijs Ledkovs wrote: > > > > > What do you mean by "holding hostile root." ? > > http://blog.bofh.it/debian/id_413 > > > > The missing parts (UID virtualization IIRC) are upstream now, and should > > be ready for jessie. > > If I read Ubuntu documentation correctly, you also need a large complex > apparmor policy to block sensitive /proc and /sys files from being messed > with by guest systems. vserver does this internally based on its system > of capability bits. It also censors misc syscalls; I can't seem to find > this part being done by lxc. > > > Until then if you do not trust containers then the best choice is to > > use openvz with Parallel's 2.6.32 kernel. > > As Ben Hutchings just told us, openvz has been merged upstream in 3.12. The openvz and container communities worked together on the kernel features. vzctl has been updated to use the kernel features that were upstream-acceptable. So 'openvz has been merged upstream' is technically false, as it implies that the patches as they stood were merged. But openvz developers played a huge part in what made it upstream. -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/20131024165316.GB2226@ac100
Re: systemd effectively mandatory now due to GNOME
Quoting Adam Borowski (kilob...@angband.pl): > On Thu, Oct 24, 2013 at 09:11:30AM +0100, Jonathan Dowland wrote: > > On Thu, Oct 24, 2013 at 02:09:46AM +0200, Adam Borowski wrote: > > > And I for one heavily use vservers > > > > It's a professional shame of mine that we are still trying to get rid of > > some old vserver instances at $WORK. > > lxc is still nowhere close to vserver (or openvz) functionality. It lacks > even basics like "vserver enter" (you can't access a container more than > once other than via ssh or similar), lxc-attach does that and fully works with recent kernels. > not to speak about holding hostile > root. 3.12 has full user namespace support which gets us about as far as we'll ever get. -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/20131024164251.GA2226@ac100
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
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 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
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: socket-based activation has unmaintainable security?
Quoting Andrey Rahmatullin (w...@wrar.name): > On Wed, Feb 06, 2013 at 12:30:28PM -0600, Serge Hallyn wrote: > > > > Do we finally have mechanisms to start processes without root but with > > > > elevated capabilities? > > > We also need fallback for non Capability-capable supported kernels > > > (wow that's an awkward sentence) > > Not to mention non-xattr-backed filesystems. > xattrs is only one of possible mechanisms but as we don't have it either, > its shortcomings are probably not worth mentioning. For posix capabilities attached to files xattrs are currently the only means. That's what I assumed this was referring to. -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/20130206212009.GA18337@sergelap
Re: socket-based activation has unmaintainable security?
Quoting Jonathan Dowland (j...@debian.org): > On 6 Feb 2013, at 17:37, Andrey Rahmatullin wrote: > > > Do we finally have mechanisms to start processes without root but with > > elevated capabilities? > > We also need fallback for non Capability-capable supported kernels > (wow that's an awkward sentence) Not to mention non-xattr-backed filesystems. Every time I've been in a discussion like this, that ends up being the reason not to pursue it. -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/20130206183028.GB19018@sergelap
