Re: Idea: about package installation under chroot.
G'day, just saw the discussion about chroot stuff and avoiding starting daemons/ mounting proc etc. The lessdisks package has a lessdisks-chroot command that does all this for you. I believe it diverts start-stop-daemon so that it fakes starting/stopping the daemons. -- Donovan Baarda [EMAIL PROTECTED] Obsidian Consulting Group -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Hello On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote: Dear Debian developers, I would like to consult the developer community on the following issue. Here is the story: Debian packages including daemons may be a problem for people installing them via chroot, due to the fact that the packages will typically try to stop and restart the daemons. In fact, this can interact destructively with the system of the server, accidentally killing this or that process. It may also cause the Debian package tools to crash. Installation via chroot can be very useful for embedded systems, and also for diskless machines that boot remotely from a server and mount the root via NFS. If a package is being installed via chroot running in the server it does not really make any sense to try to stop or start daemons. Although most packages do in fact survive this process, in the sense that the installation completes despite some errors when stopping and starting daemons, some do cause the package tools to exit in error, leaving behind a broken package. One example that is particularly troublesome is rwhod. Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 So here are my questions: is there any way in which including a line like this in the init.d/ scripts can be adopted as a standard procedure in the future, for all Debian packages containing daemons? Are there, perhaps, undesirable side effects to this? Yes there are. First of all people can mount entire or all of proc into a chroot. The second problem is with vservers (www.linux-vserver.org) and the util-vserver tools. Using this project you can mask parts (at least with latest development branch as I have understood it) of /proc, so this can have really bad side effects. Is there some other, better solution to this problem? Hopefully yes. Solving this problem would certainly help people using chroot to install packages and so help to extend the range of applicability and usefulness of Debian. Cheers, I suggest you actually use the vserver project (or the util-vserver and kernel-patch-vserver packages) in order to have full virtualization of your chroot if that is what you want. Regards, // Ola Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Well, just reporting that this whole instructive interchange resulted in my using in the remote-boot nodes of our clusters the policy-rc.d script #!/bin/bash test -x /sbin/runlevel || exit 101 if [ `/sbin/runlevel` == unknown ] ; then exit 101 fi exit 0 It solved the problem with rwhod in Sarge, but not in Woody, because the package's scripts do not use invoke-rc.d in that case. The runlevel gets undefined inside the chroot shell because I mask the /var/run directory, mounting an empty directory over it. This mount is playing the role of a flag file in order to momentarily prevent the daemons from starting. The use of this policy-rc.d script is made necessary by the fact that the program invoke-rc.d seems to default to allowing the scripts to start and stop daemons when the runlevel is undefined. I find this a bit odd, seems to me that it would be more natural for it to default the other way. In case anyone in interested in the clusters of diskless X11 terminals in which this issue came up, I am posting in the following message a copy of an announcement I sent to the debian-user list a few days ago pointing to the web pages about the cluster tool packages. Thank you all for your help!Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Wouter Verhelst [EMAIL PROTECTED] writes: Additionally, other kernels (such as the FreeBSD kernel) that do have a /proc do not have it functionally overloaded like the Linux one. That's an excellent point. While it's likely that a /proc filesystem will be written for the Hurd, it's very unlikely that it will include more than self and PIDs. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Adeodato Sim wrote: # test -r /proc/1/root || echo Inside a chroot What if an postinst script at some point drops privs to a non-root user and grsec is preventing it from reading any process' info other than its own user's? Also, as pointed out earlier this wouldn't work on HURD. signature.asc Description: OpenPGP digital signature
Re: Idea: about package installation under chroot.
Op do, 24-03-2005 te 20:01 +0100, schreef Daniel Baumann: Josselin Mouette wrote: I don't know whether we have ports without /proc, the Hurd has no /proc. Additionally, other kernels (such as the FreeBSD kernel) that do have a /proc do not have it functionally overloaded like the Linux one. e.g., FreeBSD's /proc only contains process directories; it does not contain sysctl stuff, or other things like /proc/mounts. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Idea: about package installation under chroot.
Dear Debian developers, I would like to consult the developer community on the following issue. Here is the story: Debian packages including daemons may be a problem for people installing them via chroot, due to the fact that the packages will typically try to stop and restart the daemons. In fact, this can interact destructively with the system of the server, accidentally killing this or that process. It may also cause the Debian package tools to crash. Installation via chroot can be very useful for embedded systems, and also for diskless machines that boot remotely from a server and mount the root via NFS. If a package is being installed via chroot running in the server it does not really make any sense to try to stop or start daemons. Although most packages do in fact survive this process, in the sense that the installation completes despite some errors when stopping and starting daemons, some do cause the package tools to exit in error, leaving behind a broken package. One example that is particularly troublesome is rwhod. Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 So here are my questions: is there any way in which including a line like this in the init.d/ scripts can be adopted as a standard procedure in the future, for all Debian packages containing daemons? Are there, perhaps, undesirable side effects to this? Is there some other, better solution to this problem? Solving this problem would certainly help people using chroot to install packages and so help to extend the range of applicability and usefulness of Debian. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Le jeudi 24 mars 2005 14:54 -0300, Jorge L. deLyra a crit : Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 I definitely like that idea. I don't know whether we have ports without /proc, but such a check for a chroot would be really nice anyway. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Idea: about package installation under chroot.
Hello! On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote: Here is the story: Debian packages including daemons may be a problem for people installing them via chroot, due to the fact that the packages will typically try to stop and restart the daemons. In fact, this can interact destructively with the system of the server, accidentally killing this or that process. It may also cause the Debian package tools to crash. [...] Is there some other, better solution to this problem? echo -e '#!/bin/sh\n\nexit 101' /chroot/usr/sbin/policy-rc.d \ chmod a+x /chroot/usr/sbin/policy-rc.d as mentioned by Steve Langasek in http://lists.debian.org/debian-devel/2005/01/msg01316.html. HTH, Flo signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
Scripsit Jorge L. deLyra [EMAIL PROTECTED] Although most packages do in fact survive this process, in the sense that the installation completes despite some errors when stopping and starting daemons, some do cause the package tools to exit in error, leaving behind a broken package. One example that is particularly troublesome is rwhod. ... Is there some other, better solution to this problem? Write a policy-rc.d script for the chroot that denies starting either the particular demon or all demons in general. zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz -- Henning Makholm What has it got in its pocketses? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Write a policy-rc.d script for the chroot that denies starting either the particular demon or all demons in general. zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start in its postinstall script to start that daemon. I was not talking about booting a system, but about using a chroot shell to install packages in the filesystem structure of a remotely-booted machine. In this situation one does not want to prevent the machine from starting daemons when it boots, just to prevent package installations or upgrades from stoping or starting daemons, when they are done in the disk server, by means of a chroot shell. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Josselin Mouette wrote: I don't know whether we have ports without /proc, the Hurd has no /proc. Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, 24 Mar 2005, Jorge L. deLyra wrote: Write a policy-rc.d script for the chroot that denies starting either the particular demon or all demons in general. zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start in its postinstall script to start that daemon. It won't, but thankfully there are fewer and fewer packages that don't follow the recommendation of Policy 9.3.3.2.[1] If you find such a package, please file a wishlist bug against it requesting that the follow the recommendation of Policy not to call the init scripts directly. Don Armstrong 1: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote: Installation via chroot can be very useful for embedded systems, and also for diskless machines that boot remotely from a server and mount the root via NFS. If a package is being installed via chroot running in the server it does not really make any sense to try to stop or start daemons. [...] Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. FWIW, the Debian-amd64 HOWTO suggests mounting /proc in your i386 chroot too. (Though I don't know what the benefits are.) See: https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274246 I think this is a good problem to solve though. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. There is nothing wrong with mounting /proc in a chroot; you should not assume that chroots all lack /proc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start Well if they do they won't work on file-rc system , so are already broken ... Alban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
There is nothing wrong with mounting /proc in a chroot; you should not assume that chroots all lack /proc. Yes, I know, and I'm not. But it would be nice if one could prevent the packages from starting the daemons by simply choosing not to mount /proc in the chroot. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, Mar 24, 2005 at 07:42:01PM +0100, Josselin Mouette wrote: Le jeudi 24 mars 2005 ?? 14:54 -0300, Jorge L. deLyra a ??crit : Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 I definitely like that idea. I don't know whether we have ports without /proc, but such a check for a chroot would be really nice anyway. Probably I don't understand the assumption /proc is not mounted in chroot. All my chroots have /proc. There are just too many programs that depends of /proc. I even witnessed a FTBFS of a C++ program that depended of the chroot not having /proc mounted. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: There is nothing wrong with mounting /proc in a chroot; you should not assume that chroots all lack /proc. Yes, I know, and I'm not. But it would be nice if one could prevent the packages from starting the daemons by simply choosing not to mount /proc in the chroot. But you might need /proc. If you are going to tell people to prevent packages from starting daemons, do this in the filesystem, then why not just have an /etc/startdaemons file? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start Well if they do they won't work on file-rc system , so are already broken ... Then there are many such broken packages. I just counted about 40 both in the sarge system closest at hand and in a woody server. The list includes many important packages, see lists below. Looks like this policy has not been followed very much... Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] woody: acct adjtimex anacron and apache at autofs bind console-common cron dqs gom gpm ircd isapnptools junkbuster kbd libc6 linuxlogo lprng makedev mrouted netkit-inetd nfs-common nfs-kernel-server nis ntop ntp-simple ntpdate portmap ppp procps quota rwhod setserial spamassassin ssh sudo sysstat upsd xfs xpilot-server xtell sarge: anacron and apache apache-common at autofs binfmt-support console-common console-tools cron dhcp3-server exim4-base exim4-daemon-light gom hpoj isapnptools libdevmapper1 lprng makedev nbd-client nbd-server netkit-inetd nfs-common nfs-kernel-server nis ntp-server ntpdate nut portmap procps queue quota rsync rwhod setserial ssh sudo wu-ftpd xprt-common xtell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Is there some other, better solution to this problem? echo -e '#!/bin/sh\n\nexit 101' /chroot/usr/sbin/policy-rc.d \ chmod a+x /chroot/usr/sbin/policy-rc.d as mentioned by Steve Langasek in http://lists.debian.org/debian-devel/2005/01/msg01316.html. OK, I got to this point: if all packages used invoke-rc.d then I could solve my problem with installing packages under chroot by installing a policy-rc.d script that returned 101 if the runlevel is unknown. All I have to do is to mask /var/run, which I already do. Two questions: 1) The command runlevel returns unknown and exits in error, will this error status do something bad to invoke-rc.d? 2) What does invoke-rc.d do if the runlevel is unknown? Maybe I would not have to do anything after all, if the policy was followed. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, 24 Mar 2005, Jorge L. deLyra wrote: nfs-kernel-server This uses invoke-rc.d: invoke-rc.d nfs-kernel-server $act ntp-server invoke-rc.d ntp-server start || exit 0 ntpdate as does this: invoke-rc.d ntpdate start || exit 0 Pray tell, how was this list generated? The three examples that I picked at random all use invoke-rc.d. [Two of which because they use debhelper to do the invoking.] Don Armstrong -- A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'... -- Joshua D. Wachs - Natural Intelligence, Inc. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
On Thu, Mar 24, 2005 at 08:58:22PM -0300, Jorge L. deLyra wrote: I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start Well if they do they won't work on file-rc system , so are already broken ... Then there are many such broken packages. I just counted about 40 both in the sarge system closest at hand and in a woody server. The list includes many important packages, see lists below. Looks like this policy has not been followed very much... sarge: anacron and apache apache-common at autofs binfmt-support console-common console-tools cron dhcp3-server exim4-base exim4-daemon-light gom hpoj isapnptools libdevmapper1 lprng makedev nbd-client nbd-server netkit-inetd nfs-common nfs-kernel-server nis ntp-server ntpdate nut portmap procps queue quota rsync rwhod setserial ssh sudo wu-ftpd xprt-common xtell At least some of these packages call /etc/init.d/package start *only* if invoke-rc.d cannot be found. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
But you might need /proc. Well, I am starting to see that this might not be a good way to solve the problem but, still, if you need it, just mount it, and be aware that some daemons may come up and down on the server if you install or upgrade some package in these circumstances. If you do not need it, don't mount it and then do not worry about daemons... If you are going to tell people to prevent packages from starting daemons, do this in the filesystem, then why not just have an /etc/startdaemons file? Well, I suppose you could create this file briefly while doing the install or upgrade, and then delete it. You do not want it there permanently since the remote-boot machine is not to be prevented from starting daemons. Will using this file really work in this way? Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: But you might need /proc. Well, I am starting to see that this might not be a good way to solve the problem but, still, if you need it, just mount it, and be aware that some daemons may come up and down on the server if you install or upgrade some package in these circumstances. If you do not need it, don't mount it and then do not worry about daemons... If you are going to tell people to prevent packages from starting daemons, do this in the filesystem, then why not just have an /etc/startdaemons file? Well, I suppose you could create this file briefly while doing the install or upgrade, and then delete it. You do not want it there permanently since the remote-boot machine is not to be prevented from starting daemons. Will using this file really work in this way? I think you miss my point. Rather than keying restart daemons to /proc (who would ever guess that?!), I'm saying create something *new*, that means this is a chroot, don't restart demons. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Pray tell, how was this list generated? The three examples that I picked at random all use invoke-rc.d. [Two of which because they use debhelper to do the invoking.] Oh, I see. Looks like I did a poor job here. I just searched for instances of /etc/init.d/something being executed. So, I take it all back... |:-) Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
At least some of these packages call /etc/init.d/package start *only* if invoke-rc.d cannot be found. Ah! This is another way how I miscounted them, since I just seached for instances of /etc/init.d/package being executed... Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
I think you miss my point. Rather than keying restart daemons to /proc (who would ever guess that?!), I'm saying create something *new*, that means this is a chroot, don't restart demons. OK, I read you. Your message gave me the impression that something like it was already in place. That meaning doesn't have to be this is a chroot, but just don't start daemons, for whatever reasons there may be for that in any particular case. It would be nice if we could touch a flag file and prevent packages from starting daemons... Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Scripsit Jorge L. deLyra [EMAIL PROTECTED] zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start in its postinstall script to start that daemon. As far as I'm aware it's a bug if a package has that in its postinst rather than invoke-rc.d daemon start even though it is not yet mandatory policy. It is, however, strongly recommended (§9.3.3.2). -- Henning Makholm Y'know, I don't want to seem like one of those hackneyed Jews that you see in heartwarming movies. But at times like this, all I can say is 'Oy, gevalt!'
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: OK, I read you. Your message gave me the impression that something like it was already in place. That meaning doesn't have to be this is a chroot, but just don't start daemons, for whatever reasons there may be for that in any particular case. It would be nice if we could touch a flag file and prevent packages from starting daemons... Yes, that's basically what I'm suggesting. I'm glad you located this bug; it's a problem will worth fixing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
* Jorge L. deLyra [Thu, 24 Mar 2005 14:54:40 -0300]: test -e /proc/mounts || exit 0 Others have already pointed out that a policy-rc.d script is the way to do what you want. Still, I thought I'd share a way of testing if you're inside a chroot even if /proc is mounted. IIRC, it was LaMont Jones who mentioned this some weeks ago on IRC: # test -r /proc/1/root || echo Inside a chroot Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Mecano - Aire The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Florian Ernst wrote: echo -e '#!/bin/sh\n\nexit 101' /chroot/usr/sbin/policy-rc.d \ chmod a+x /chroot/usr/sbin/policy-rc.d as mentioned by Steve Langasek in http://lists.debian.org/debian-devel/2005/01/msg01316.html. Would someone like to package this? (No, I'm not really kidding.) -- see shy jo signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
Jorge == Jorge L deLyra [EMAIL PROTECTED] writes: Jorge /etc/init.d/daemon start Jorge in its postinstall script to start that daemon. I was not Jorge talking about booting a system, but about using a chroot Jorge shell to install packages in the filesystem structure of a Jorge remotely-booted machine. If a package directly uses /etc/init.d/daemon in its scripts, file a bug report. It should use invoke-rc.d instead. man invoke-rc.d It should work for chroots, and does work for pbuilder. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
