Re: Invoking ‘init’ from an init.d script (Wheezy)
On Tue, Jun 16, 2015 at 12:49:36PM +, Thorsten Glaser wrote: Ansgar Burchardt ansgar at debian.org writes: Please be aware that --force-yes makes apt ignore invalid signatures for Ouch. Oh, how disingenuous these apt developers are! I wonder, what got you: The friendly, very peaceful and gentle option name --force-yes (who doesn't like to be forced to a yes?), the promise of ponies and rainbows in the manpage (destroy your system … harmful … should not be used) or are you just running any arbitrary command you run across on the internet without checking what they do first? In either case: Ouch… I hope it really hurts… *indistinguishable curses* There is a HUGE difference between being forced to use such an option because you either don't know the alternative or there isn't one and just using random options you don't understand and acting like it is the fault of someone else then you are hurt by it… What is the equivalent of --force-yes with*out* --allow-unauthenticated, then? This scenario (scheduled non-interactive upgrades) is common… If only documentation would exists… I think it would read like this: -y, --yes, --assume-yes Automatic yes to prompts; assume yes as answer to all prompts and run non-interactively. If an undesirable situation, such as changing a held package, trying to install a unauthenticated package or removing an essential package occurs then apt-get will abort. Configuration Item: APT::Get::Assume-Yes. You already know --allow-unauthenticated, there is also --ignore-hold. The other two (downgrade and essential removal) currently lumped together in --force-yes do not have a dedicated option ATM. If anyone wants to writing a patch for this feel free to – and achieve everlasting glory by fixing an apt bug (lots of opportunity, very few takers)! Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Invoking ‘init’ from an init.d script (Wheezy)
Ansgar Burchardt ansgar at debian.org writes: Please be aware that --force-yes makes apt ignore invalid signatures for Ouch. What is the equivalent of --force-yes with*out* --allow-unauthenticated, then? This scenario (scheduled non-interactive upgrades) is common… Thanks, //mirabilos
Re: Invoking ‘init’ from an init.d script (Wheezy)
]] David Kalnischkies It is on my TODO list to drop the --force-yes flag and replace it with specialised --allow-* flags 'just' to force users to acknowledge what it is they are saying yes to. Somehow most people are way more willing to add --allow-everything than --allow-prostate-exam … That would be great. Currently, I'm not aware of any way to say «downgrade this package and any necessary dependencies and don't ask» short of --force-yes (or listing all the necessary packages to be downgraded with their versions). If there is a way, I'd love to be told about it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m27fr8yqgn@rahvafeir.err.no
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Mon, Jun 08, 2015 at 12:09:37PM +0200, Alexander Thomas wrote: On Mon, Jun 8, 2015 at 11:49 AM, Ansgar Burchardt ans...@debian.org wrote: On 06/08/2015 10:29 AM, Alexander Thomas wrote: We falsely assumed that setting DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none, and using the -y and --force-yes options, would never invoke terminal-related code. Please be aware that --force-yes makes apt ignore invalid signatures for repositories, cf. https://bugs.debian.org/787174. It is a really unsafe option that should probably not be used in any automated way, though I have seen people do so in several places. I know, but this is a closed system and nothing is pulled in from external repositories during this automated update. The stuff that is included in the local patch repository is thoroughly tested before release. Still, enforcing proper signing and getting rid of that --force-yes is on our TODO list. Use --allow-unauthenticated in this case. Or better yet, mark the local source as [trusted=yes] in sources.list to avoid this prompt without opening the floodgates entirely. --force-yes e.g. also disables the 'Do as I say' prompt before destroying your system^W^W^Wremoving (pseudo) essential packages. It is on my TODO list to drop the --force-yes flag and replace it with specialised --allow-* flags 'just' to force users to acknowledge what it is they are saying yes to. Somehow most people are way more willing to add --allow-everything than --allow-prostate-exam … Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Wed, Jun 10, 2015 at 2:14 PM, David Kalnischkies da...@kalnischkies.de wrote: On Mon, Jun 08, 2015 at 12:09:37PM +0200, Alexander Thomas wrote: I know, but this is a closed system and nothing is pulled in from external repositories during this automated update. The stuff that is included in the local patch repository is thoroughly tested before release. Still, enforcing proper signing and getting rid of that --force-yes is on our TODO list. Use --allow-unauthenticated in this case. Or better yet, mark the local source as [trusted=yes] in sources.list to avoid this prompt without opening the floodgates entirely. --force-yes e.g. also disables the 'Do as I say' prompt before destroying your system^W^W^Wremoving (pseudo) essential packages. It is on my TODO list to drop the --force-yes flag and replace it with specialised --allow-* flags 'just' to force users to acknowledge what it is they are saying yes to. Somehow most people are way more willing to add --allow-everything than --allow-prostate-exam … I think the second highest-rated answer here is one of the reasons for the popularity of --force-yes: http://superuser.com/questions/164553/automatically-answer-yes-when-using-apt-get-install Anyone with sufficient reputation to make comments, may want to add a remark about --allow-unauthenticated in an attempt to stop people from shooting at the unsigned mosquito with a bazooka. Regards, Alexander -- 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/cakr4ymwl4pmbpfn9+udvat8wr51bkyv94iuhmgfcwk2wsk8...@mail.gmail.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Wed, 10 Jun 2015 15:47:50 +0200 Alexander Thomas alexander.thomas+d...@esaturnus.com wrote: [...] --force-yes e.g. also disables the 'Do as I say' prompt before destroying your system^W^W^Wremoving (pseudo) essential packages. It is on my TODO list to drop the --force-yes flag and replace it with specialised --allow-* flags 'just' to force users to acknowledge what it is they are saying yes to. Somehow most people are way more willing to add --allow-everything than --allow-prostate-exam … I think the second highest-rated answer here is one of the reasons for the popularity of --force-yes: http://superuser.com/questions/164553/automatically-answer-yes-when-using-apt-get-install Anyone with sufficient reputation to make comments, may want to add a remark about --allow-unauthenticated in an attempt to stop people from shooting at the unsigned mosquito with a bazooka. Just did that, thanks for the suggestion. -- 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/20150610171654.415d93524164530cbd378...@domain007.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Fri, Jun 5, 2015 at 7:39 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 5 Jun 2015 16:25:21 +0200 Alexander Thomas alexander.thomas+d...@esaturnus.com wrote: [...] That would be an option, but it might still cause the same problem of apt-get hanging as we currently experience when doing the update before runlevel S. We looked deeper into this and found out that apt-get always hangs while installing a package before the first runlevel switch. An strace reveals an endless loop of SIGCONT and ioctl calls. Running other commands that use ioctl also results in a hang, so the controlling terminal seems to lack certain capabilities at this stage. We have found a workaround: we spawn a new terminal with agetty and run the update script in there, this allows to perform the apt-get dist-upgrade in runlevel S and avoid the init 1 hack. I would try running apt-get with /dev/null somelogfile 21 redirections: that should ensure it sees no terminal at all on its stdin and that should avoid code paths dealing with TTY-related ioctls altogether. (Well, excluding the isatty(3) call which supposedly uses fstat(2) and checks to see the device's major number is that of a TTY). The /dev/null avoids the hang indeed. I haven't looked at the code but it makes sense that when apt-get starts configuring the packages, it will probe the terminal or prepare it for user interaction. We falsely assumed that setting DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none, and using the -y and --force-yes options, would never invoke terminal-related code. Thanks! -- Alexander Thomas -- 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/cakr4ymxoqq0a-rvztymts3c371tgxocvx+yra96ovyy6y-d...@mail.gmail.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Mon, Jun 8, 2015 at 11:49 AM, Ansgar Burchardt ans...@debian.org wrote: Hi, On 06/08/2015 10:29 AM, Alexander Thomas wrote: We falsely assumed that setting DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none, and using the -y and --force-yes options, would never invoke terminal-related code. Please be aware that --force-yes makes apt ignore invalid signatures for repositories, cf. https://bugs.debian.org/787174. It is a really unsafe option that should probably not be used in any automated way, though I have seen people do so in several places. I know, but this is a closed system and nothing is pulled in from external repositories during this automated update. The stuff that is included in the local patch repository is thoroughly tested before release. Still, enforcing proper signing and getting rid of that --force-yes is on our TODO list. Regards, -- Alexander Thomas -- 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/CAKr4yMwunBRBYctToqw=ce9iebypixujvpbsehftp-6denb...@mail.gmail.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
Hi, On 06/08/2015 10:29 AM, Alexander Thomas wrote: We falsely assumed that setting DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none, and using the -y and --force-yes options, would never invoke terminal-related code. Please be aware that --force-yes makes apt ignore invalid signatures for repositories, cf. https://bugs.debian.org/787174. It is a really unsafe option that should probably not be used in any automated way, though I have seen people do so in several places. Regards, Ansgar -- 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/55756519.3080...@debian.org
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Wed, Jun 3, 2015 at 6:09 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 3 Jun 2015 17:26:21 +0200 Alexander Thomas alexander.thomas+d...@esaturnus.com wrote: [...] The long story: We have a setup with multiple servers (running Wheezy). When booting, the servers check whether updates are available on a master server. If available, they are pulled in through a dist-upgrade. This check/update needs to happen before any of the normal services are started, to avoid the need of taking down everything and then starting it back up after the update. [...] Wouldn't it be simpler to implement this check and update using initramfs hooks? You could bind-mount /dev, /sys and /proc to the root filesystem, chroot there and run there a script which would check for updates, apply them, if any, and exit. After that the system would just resume booting. That would be an option, but it might still cause the same problem of apt-get hanging as we currently experience when doing the update before runlevel S. We looked deeper into this and found out that apt-get always hangs while installing a package before the first runlevel switch. An strace reveals an endless loop of SIGCONT and ioctl calls. Running other commands that use ioctl also results in a hang, so the controlling terminal seems to lack certain capabilities at this stage. We have found a workaround: we spawn a new terminal with agetty and run the update script in there, this allows to perform the apt-get dist-upgrade in runlevel S and avoid the init 1 hack. -- Alexander -- 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/cakr4ymwhfxxd2sxrbwgpnu6hlsubllcygo9ofv0z7rz5g7n...@mail.gmail.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Fri, 5 Jun 2015 16:25:21 +0200 Alexander Thomas alexander.thomas+d...@esaturnus.com wrote: [...] That would be an option, but it might still cause the same problem of apt-get hanging as we currently experience when doing the update before runlevel S. We looked deeper into this and found out that apt-get always hangs while installing a package before the first runlevel switch. An strace reveals an endless loop of SIGCONT and ioctl calls. Running other commands that use ioctl also results in a hang, so the controlling terminal seems to lack certain capabilities at this stage. We have found a workaround: we spawn a new terminal with agetty and run the update script in there, this allows to perform the apt-get dist-upgrade in runlevel S and avoid the init 1 hack. I would try running apt-get with /dev/null somelogfile 21 redirections: that should ensure it sees no terminal at all on its stdin and that should avoid code paths dealing with TTY-related ioctls altogether. (Well, excluding the isatty(3) call which supposedly uses fstat(2) and checks to see the device's major number is that of a TTY). -- 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/20150605203938.fd1322f3bbf2bc4426c6f...@domain007.com
Re: Invoking ‘init’ from an init.d script (Wheezy)
On Wed, 3 Jun 2015 17:26:21 +0200 Alexander Thomas alexander.thomas+d...@esaturnus.com wrote: [...] The long story: We have a setup with multiple servers (running Wheezy). When booting, the servers check whether updates are available on a master server. If available, they are pulled in through a dist-upgrade. This check/update needs to happen before any of the normal services are started, to avoid the need of taking down everything and then starting it back up after the update. [...] Wouldn't it be simpler to implement this check and update using initramfs hooks? You could bind-mount /dev, /sys and /proc to the root filesystem, chroot there and run there a script which would check for updates, apply them, if any, and exit. After that the system would just resume booting. -- 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/20150603190921.9c5c265a63b6a12ef039a...@domain007.com
Invoking ‘init’ from an init.d script (Wheezy)
The short question: Is it acceptable to boot a server into runlevel 1, and then invoke init 2 from an /etc/rc1.d script to interrupt the execution of any further scripts in that runlevel and continue in RL2? The long story: We have a setup with multiple servers (running Wheezy). When booting, the servers check whether updates are available on a master server. If available, they are pulled in through a dist-upgrade. This check/update needs to happen before any of the normal services are started, to avoid the need of taking down everything and then starting it back up after the update. The most sane thing to do would be to perform this check/update as the very first init script in runlevel 2. This however seems impossible to guarantee, aside from the unmaintainable practice of adding every possible service to the Required-Start field of this script. There is a way to make a script run last (Required-Start: $all), but as you may have guessed, X-Start-Before: $all does not work. The next most sane thing to do would be to run the script at the end of runlevel S. When we do this however, the dist-upgrade will often hang indefinitely after the unpacking stage. Any attempt to perform the upgrade while we're still in level S, results in the same hang. Therefore to both avoid this hang and guarantee that the update is performed before any runlevel 2 service, we boot the servers into runlevel 1 and check the update there. The init script is configured as X-Start-Before: killprocs, because we do not want anything to be killed at boot. /etc/rc1.d therefore looks like this: S01bootlogs S01motd S01magic-update-script S02killprocs S03single To allow runlevel 1 to be used normally, the script does nothing if this is not the first runlevel after boot. Otherwise it does its thing, and when done invokes init 2 to replace the entire shell and therefore (in theory) prevent S02killprocs and S03single from being executed. This works fine in most cases. On one particular server however, we noticed that killprocs was sometimes (in about 20% of all boots) still being executed even though the 'runlevel' command already reports the current level to be 2. We managed to work around this by adding an extra check to the killprocs script that skips it if the runlevel is not 1. However, we realize that what we're doing might not be perfectly sane and wonder whether it might have other risks. We could avoid this 'init-inside-an-initscript' hack if someone had a foolproof way of guaranteeing that the init script is always executed as the very first in runlevel 2. -- Alexander Thomas -- 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/CAKr4yMxo8VQiy7w8JRZf3Uh-snEygCxxsJsv8o=yq-ygi_w...@mail.gmail.com
