Re: documenting on how not starting a daemon upon installation
On Tue, 2020-03-10 at 18:48 +0100, Simon Richter wrote: > Hi, > > On Tue, Mar 10, 2020 at 03:50:42PM +, jnq...@gmail.com wrote: > > > - the 'move start-stop-daemon' trick is the old-old solution, kept > > around because some packages failed to get on board with the > > policy- > > rc.d solution, and could be removed from things like > > debootstrap/live- > > build if and only if at some point in the future there was > > certainty > > that there were no such packages left. > > It is a bad hack, but it catches a few instances where people have > been > following very old packaging guides. Such packages likely don't exist > anymore in Debian, but the Debian tools are often used outside it, > especially in companies building embedded systems. > > Removing this hack would not affect Debian, but it might break some > users' > setups, so it's left in. > > > - the policy-rc.d solition is the old solution, kept around > > because > > systemd use is not quite 100%, though I'd expect and home that all > > packages are compatible by now, though systemd has a compatibility > > mechanism relating to policy-rc.d to work with users of that. > > Please disregard the statistics on systemd usage -- there is no > accurate > way to track installations because the vast majority of machines > don't > report back to Debian, and with containers, the question of what > counts as > a Debian installation is rather muddy anyway. > > The policy-rc.d interface is not an official interface according to > Debian > Policy, but it is used by invoke-rc.d, which is listed in Policy as > the > appropriate way to invoke an init script from a maintainer script, so > "support" is widespread. > > With systemd, a lot of these issues do not exist in the first place, > as no > systemd is running inside the chroot, so there is no mechanism to > start > services through systemd during debootstrap. > > Historically, the requirement to start daemons after installation is > older > than debootstrap and the idea of installing packages into a chroot. > Before > the current debian-installer, the installation system extracted a tar > file > into the target file system, made the system bootable and > installation then > proceeded from there. Maintainer scripts were seldom run inside a > chroot, > and those few that were had special checks. > > > From a debootstrap/live-build perspective, policy-rc.d is the only > mechanism that really matters, because it is respected by those > packages > that use a mechanism to start a daemon that actually works during > debootstrap time. > > > - 'systemctl mask' is the modern systemd solution. the best > > solution > > for users if they have systemd. probably pointless though for > > debootstrap/live-build use if they're having to keep policy-rc.d > > support and even start-stop-daemon support around anyway after all > > these years. > > "systemctl mask" does something else though: it disables a specific > service > across reboots by hiding it from systemd, while policy-rc.d asks to > be > consulted for every action. After installation, when the policy > script is > removed, its effect is gone, but masked services remain disabled. > > The equivalent of "systemctl mask" in the init.d world would be > "update-rc.d package defaults-disabled", as described in Debian > Policy > section 9.3.3.1. > > The systemd compatibility layer for policy-rc.d is not used for > bootstrapping, but to remain compatible with setups that use this > mechanism > at runtime to integrate with some site-wide configuration framework. > >Simon > interesting. thankyou. :)
Re: documenting on how not starting a daemon upon installation
On Tue, 2020-03-10 at 16:23 +0100, Marco d'Itri wrote: > On Mar 10, jnq...@gmail.com wrote: > > > If the policy-rc.d solution is the modern/best/whatever solution, > > the > No. policy-rc.d is the old solution which was implemented because > there > was no better way to implement this with init scripts. > It worked by mandating that maintainer scripts must start and stop > daemons only by using invoke-rc.d. > > The modern and simple solution is "systemctl mask", as long as you > do > not need to care about the 0.6% of systems which do not use systemd. > If you are doing this for your own systems then you obviously know > if > you can rely on systemd or not. > > > fact that live-build/debootstrap also includes the 'moving start- > > stop- > > daemon' trick is either indeed a left over from before systemd (I > > do > > not know the history of it), or is left to ensure compatibility > > without > > systemd? > It is needed because some buggy maintainer scripts do/did not use > invoke-rc.d, so better be safe than sorry. okay, thankyou. so as I understand it: - the 'move start-stop-daemon' trick is the old-old solution, kept around because some packages failed to get on board with the policy- rc.d solution, and could be removed from things like debootstrap/live- build if and only if at some point in the future there was certainty that there were no such packages left. - the policy-rc.d solition is the old solution, kept around because systemd use is not quite 100%, though I'd expect and home that all packages are compatible by now, though systemd has a compatibility mechanism relating to policy-rc.d to work with users of that. - 'systemctl mask' is the modern systemd solution. the best solution for users if they have systemd. probably pointless though for debootstrap/live-build use if they're having to keep policy-rc.d support and even start-stop-daemon support around anyway after all these years.
Re: documenting on how not starting a daemon upon installation
On Tue, 2020-03-10 at 19:39 +0500, Andrey Rahmatullin wrote: > On Tue, Mar 10, 2020 at 02:33:50PM +, jnq...@gmail.com wrote: > > If the policy-rc.d solution is the modern/best/whatever solution, > > the > > fact that live-build/debootstrap also includes the 'moving start- > > stop- > > daemon' trick is either indeed a left over from before systemd (I > > do > > not know the history of it), or is left to ensure compatibility > > without > > systemd?, because of course for a long time systemd has been > > considered > > a choice, and perhaps still is (not that I want to start another > > systemd vs alternatives discussion). > policy-rc.d is much older than systemd. oh okay, forgive my ignorance of that matter if that is so and policy-rc-d is applicable to both systemd and non- systemd situations, then perhaps live-build and debootstrap should consider dropping the 'move start-stop-daemon' solution as redundant? the original author of live-build left the project so can't be asked why it existed (git hostory did not help much when I previously looked) and I am ignorant as to whether it serves any other purpose than being an older (?) secondary solution for the same thing... I could discuss it with the current maintainers; if anyone has any useful info to support it being unnecessary that could be helpful in any such proposal of removal (I'm currently doing a lot of live-build contributing)...
Re: documenting on how not starting a daemon upon installation
On Tue, 2020-03-10 at 08:47 -0400, Marvin Renich wrote: > I think the OP's question was not about creating a package with a > daemon > that is disabled by default, but about preventing an existing > package, > that would otherwise start its daemon, from starting it. That was my understanding also. > As for the other poster who seems to be advocating an approach which > combines policy-rc.d and diverting or replacing files in /bin and > /usr/bin, I believe that is neither necessary nor appropriate in the > general case. For the specific cases of debootstrap and live-build, > there might very well be other reasons for diverting system binaries > (or > it could be left over from before the implementation of policy-rc.d), > but let's not cargo-cult this into inappropriate situations. If you mean me, I was not so much advocating the use of the dpkg-divert or policy-rc.d solutions used by live-build/deboostrap, but merely informing the OP what solutions are in use by these Debian project tools, wrt. to the mess of hacks found in the provided link. If the policy-rc.d solution is the modern/best/whatever solution, the fact that live-build/debootstrap also includes the 'moving start-stop- daemon' trick is either indeed a left over from before systemd (I do not know the history of it), or is left to ensure compatibility without systemd?, because of course for a long time systemd has been considered a choice, and perhaps still is (not that I want to start another systemd vs alternatives discussion).
Re: not starting a daemon upon installation
On Sun, 2020-03-08 at 11:44 -0400, Marvin Renich wrote: > * jnq...@gmail.com [200308 10:58]: > > On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote: > > > The problem is that installing the package will automatically > > > start > > > the > > > daemon cluster in a "default" configuration. > > > > > > [1] > > > https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services# > > > > i can't comment on what might be considered an "official" solution. > > > > how live-build achieves this is essentially the same as happens to > > be > > discussed in the linked page for Debian's debootstrap package (the > > tool > > for building the base filesystem). > > > > that is to use dpkg-divert to temporarily replace the /sbin/start- > > stop- > > daemon binary with something that essentially just exits with > > success > > (i.e. 0). This could be an empty shell script (or one that prints a > > warning about the diversion being in place as in the linked > > discussion) > > or a symlink to /bin/true. > > > > enabling diversion: > > ``` > > dpkg-divert --add --rename /sbin/start-stop-daemon > > ln -fs /bin/true /sbin/start-stop-daemon > > ``` > > > > removing diversion: > > ``` > > rm -f /sbin/start-stop-daemon > > dpkg-divert --remove --rename /sbin/start-stop-daemon > > ``` > > I'm surprised that live-build does this and that debootstrap does as > well. Note that the link above, farther down the page, gives what I > thought was the "correct" answer, which is to create a script, > /usr/sbin/policy-rc.d, which simply invokes exit 101. This is also > the > method described in the Debian wiki page for chroot [2]. > > live-build and debootstrap may have been doing this since before the > policy-rc.d API was defined, and they may also have more strict needs > than is defined by policy-rc.d (e.g. handling misbehaving packages). > > However, for the OP's original purpose described in this thread, I > believe the policy-rc.d approach is the correct solution, and > dpkg-divert should be avoided. > > [2] https://wiki.debian.org/chroot > > ...Marvin as corrected in an earlier addition to this discussion I amended my description of live-build's approach to include that it does both the start-stop-daemon approach _and_ the policy-rc.d approach (which I'd overlooked). debootstrap does both also, but avoiding without using dpkg-divert itself for the move of start-stop-daemon (it just moves the file).
Re: not starting a daemon upon installation
On Sun, 2020-03-08 at 18:50 +0100, Marc Haber wrote: > debootstrap's files don't contain the string "divert". They do, > however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d. I should issue a small correction to my earlier statement of live-build using a dpkg-divert of start-stop-daemon as its _single_ solution; working on the live-build codebase right now I bumped into its chroot_sysv-rc module and thus got a reminder that it does in fact also implement the policy-rc-d solution. so both debootstrap and livebuild both implement a form of both of these.
Re: not starting a daemon upon installation
On Sun, 2020-03-08 at 18:50 +0100, Marc Haber wrote: > On Sun, 08 Mar 2020 14:58:01 +, jnq...@gmail.com wrote: > > how live-build achieves this is essentially the same as happens to > > be > > discussed in the linked page for Debian's debootstrap package (the > > tool > > for building the base filesystem). > > > > that is to use dpkg-divert to temporarily replace the /sbin/start- > > stop- > > daemon binary with something that essentially just exits with > > success > > (i.e. 0). > > debootstrap's files don't contain the string "divert". They do, > however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d. I had not looked at debootstrap's approach until just now. their's is indeed partially to use the policy-rc.d solution as you say, but also to do similar to the dpkg-divert solution only without actually using dpkg-divert, they just move the original file. extracting from debootstrap's scripts/debian-common: ``` echo \ "#!/bin/sh exit 101" > "$TARGET/usr/sbin/policy-rc.d" chmod 755 "$TARGET/usr/sbin/policy-rc.d" mv "$TARGET/sbin/start-stop-daemon" "$TARGET/sbin/start-stop- daemon.REAL" echo \ "#!/bin/sh echo echo \"Warning: Fake start-stop-daemon called, doing nothing\"" > "$TARGET/sbin/start-stop-daemon" chmod 755 "$TARGET/sbin/start-stop-daemon" ``` I also found the following entry in debootstrap's changelog which is interesting wrt. this discussion, from v1.0.52 (May 2013): ``` * scripts/sid, scripts/gutsy: Add a policy-rc.d, matching that in debian-installer-utils. This is the primary way to disable daemon startup. ```
Re: not starting a daemon upon installation
On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote: > The problem is that installing the package will automatically start > the > daemon cluster in a "default" configuration. > > That's a problem for me because etcd differentiates between starting > the > cluster for the first time and starting it subsequentially. The first > time is special as it generates some internal state. > > So I would like to control whether etcd - or for the matter any > service > - is started upon package installation. > > I imagine that this would be quite a standard requirement for > devops/configuration tools aka "please do not run and configure the > service for me because I want to do it precisely **this way**" (which > is > kinda the point of configration automation). > > When I duckduckgo "dpkg do not start service on install" first hit is > [1] which contains /absurdly involved/ suggestions to achieve "not > starting a daemon upon installation". > > It /seems/ that the "official" way to achieve "not starting a daemon > upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d` > with a script that exits with 101. > > This to me seems again like a awkward, byzantine and brittle way to > achieve that goal. Also, the only canonical documentation of policy- > rc.d > seems to be > /usr/share/doc/init-system-helpers/README.policy-rc.d.gz, which is > quite > cryptic, contains no examples and contains "rc.d" in its name in a > world > where systemd is the default, which makes me doubt whether all > packages > using systemd will respect policy-rc.d... > > So I'm wondering: > > * is this really the official (twisted ?8-o) way to solve the problem > of > not starting a daemon automatically upon installation? > * why was such an involved method chosen, instead of say setting an > environment variable DPKG_DONT_START_DAEMON or such? > > [1] > https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services# i can't comment on what might be considered an "official" solution. fyi, preventing start/stop of _all_ services on package installation is a requirement of Debian's live-build, which if you're not familiar with it is a tool to build a Debian live-cd. Building a live environment is typically done in a chroot and it involves installing many packages which should not impact the host in terms of starting/stopping services. how live-build achieves this is essentially the same as happens to be discussed in the linked page for Debian's debootstrap package (the tool for building the base filesystem). that is to use dpkg-divert to temporarily replace the /sbin/start-stop- daemon binary with something that essentially just exits with success (i.e. 0). This could be an empty shell script (or one that prints a warning about the diversion being in place as in the linked discussion) or a symlink to /bin/true. enabling diversion: ``` dpkg-divert --add --rename /sbin/start-stop-daemon ln -fs /bin/true /sbin/start-stop-daemon ``` removing diversion: ``` rm -f /sbin/start-stop-daemon dpkg-divert --remove --rename /sbin/start-stop-daemon ``` someone else has already offered an alternate solution applicable to individual packages. if the problem you are experiencing with this particular package you reference is common, then perhaps a bug should be filed or discussion take place regarding changing it such that it not try to start its service upon installation.
Re: How to undo a merged-user installation?
On Tue, 2020-02-18 at 17:35 +, jnq...@gmail.com wrote: > On Tue, 2020-02-18 at 17:58 +0100, Svante Signell wrote: > > Hello, > > > > I recently installed Debian/bullseye/sid in a VM from a snapshot. > > After running > > that image I realized the I got a merged-user installation. > > > > As for now I have: > > bin -> usr/bin > > lib -> usr/lib > > lib32 -> usr/lib32 > > lib64 -> usr/lib64 > > libx32 -> usr/libx32 > > sbin -> usr/sbin > > > > Is there some way to achieve a non-merged-user system from the > > current > > situation? > > > > The Debian Installer does not seem to have an option for a non- > > merged-user > > installation. Is that true? > > > > Thank you for your time! > > As I understand it (I somehow only became aware of it days ago) a > move > to merged usr has been a move planned for Debian since ~2014 and all > more recent installers implement it by default. I would not expect > any > available switch in the installer to avoid it (why add complexity to > support the older layout that surely no-one needs?). > > I have to ask, why are you determined to spend effort reversing the > change? > > While merging is of course trivial, un-merging is most certainly not. > The easiest methods that occur to me would be to either: > a) if you have access to an older version of the installer, do a > fresh > install with that (then of course upgrade). > b) make sure the usrmerge package is not installed; manually switch > the symlinks back to actual directories; then ask apt/aptitude to do > a > reinstall of every package on your system. > > Of course I cannot give you any guarantee that the above procedure > will > actually be successful. Proceed at your own risk. :) edit: what on earth am I thinking, solution B isn't going to be sufficient unless DPKG is brilliant enough to remove things from the old locations; you're ineviatably going to end up still with the merged copies of things floating about in the merged-to directories... to solve that, you cannot exactly just delete the directories before asking apt to reinstall because then you'll likely have broken apt. perhaps after an all-package reinstall you can then purge all files from the merged-to directories that exist in the now unmerged directories (then do a second round of all-packages reinstall, or find a means of checking for packages with missing files to reinstall, to be safe). as I say, non-trivial and proceed at your own risk...
Re: How to undo a merged-user installation?
On Tue, 2020-02-18 at 17:58 +0100, Svante Signell wrote: > Hello, > > I recently installed Debian/bullseye/sid in a VM from a snapshot. > After running > that image I realized the I got a merged-user installation. > > As for now I have: > bin -> usr/bin > lib -> usr/lib > lib32 -> usr/lib32 > lib64 -> usr/lib64 > libx32 -> usr/libx32 > sbin -> usr/sbin > > Is there some way to achieve a non-merged-user system from the > current > situation? > > The Debian Installer does not seem to have an option for a non- > merged-user > installation. Is that true? > > Thank you for your time! As I understand it (I somehow only became aware of it days ago) a move to merged usr has been a move planned for Debian since ~2014 and all more recent installers implement it by default. I would not expect any available switch in the installer to avoid it (why add complexity to support the older layout that surely no-one needs?). I have to ask, why are you determined to spend effort reversing the change? While merging is of course trivial, un-merging is most certainly not. The easiest methods that occur to me would be to either: a) if you have access to an older version of the installer, do a fresh install with that (then of course upgrade). b) make sure the usrmerge package is not installed; manually switch the symlinks back to actual directories; then ask apt/aptitude to do a reinstall of every package on your system. Of course I cannot give you any guarantee that the above procedure will actually be successful. Proceed at your own risk. :)
Re: Who gets an email when with bugreports
I think that Ideally the BTS should offer per-bug subscription functionality, like bugzilla. Submitter and maintainer would be added to the list automatically upon submission of the bug report; contributors to the bug report could also be added automatically upon submission of their message. Anyone (possibly baring submitter and maintainer) could add or remove themselves to the bug's subscription list via control. Any messages received at the bug address would be sent automatically to everyone on the subscription list. On 19/01/2015 00:06, Don Armstrong wrote: On Sun, 18 Jan 2015, Tomas Pospisek wrote: I guess, changing semantics of bugnumber[-something]@b.d.o yet again will not be considered. Actually, I think that the way we handle nnn-* is pretty much wrong, but it's wrong for mainly historical and manpower reasons. I'm going to put together a bit more firm of a proposal in the next few weeks, but I think that basically everything but nnn-done@ and nnn-submitter@ should be no different from mailing nnn@, and until I allow submitters to opt out of e-mail, mailing nnn-submitter@ should be no different from e-mailing nnn@ either. I don't know what to do about contributors to a bug being e-mailed as well, but maybe even they should also be e-mailed by default... but I've been making the perfect the enemy of the good for too long here, I think. -- 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/54bc4d45.5090...@gmail.com
Re: debian-efi mailing list
Direct link: https://lists.debian.org/debian-efi/ Joined! On 17/01/2015 09:57, Steve McIntyre wrote: In article 20141216233320.gg14...@einval.com I wrote: On Thu, Dec 11, 2014 at 07:00:34PM +, Steve McIntyre wrote: Hi folks, I'm thinking it might be useful to set up a specific debian-efi mailing list to help as a central space for discussion about (U)EFI issues and support in Debian. There's been quite a lot of development in this area recently, and (as Leif just mentioned on -devel) there are a number of packages that might benefit from wider discussion and (maybe?) group maintenance. We could also help out with targeted support for users with EFI-related problems. So, pursuant to the HOWTO [1], I'm asking here who else might be interested in using such a list. Please follow up here and we'll see how far we get. [1] https://www.debian.org/MailingLists/HOWTO_start_list OK, I think we have enough to get started. I've opened #773327 to ask for the new list - please follow up there too? And the listmaster-du-jour just created it for us this morning - thanks Alex! /me goes to sign up. -- 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/54baa6ca.2030...@gmail.com
