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]
Announcement: Debian cluster tools.
Dear Debian developers, The tools multi-apt-get-* and multi-dpkg-* can be seen as extensions of the corresponding Debian tools to this kind of cluster arquitecture. It has enabled a small management team to maintain large sets of terminals here in our Institute and other nearby institutions. Cheers, -- Forwarded message -- Dear Debian users, This is a general announcement of the availability of a couple of Debian packages that I have produced and made publicly available in the server http://sft.if.usp.br/debian-cluster/ They are called cluster-tools-client and cluster-tools-server and contain tools for dealing with clusters of remotely-booted compute nodes or X11 terminals, which is the most interesting case. The terminals do not have to be thin clients, they may be full-featured workstations as well. They may be in a public terminal room or in rooms distributed around a floor. The core ideas and code contained in these tools are fairly well developed and have been in use in half a dozen production clusters for a few years. However, this particular version of the programs is only a few weeks old, and I consider it to be in beta. There is a fair amount of documentation, which is all very new. Most of the documentation is available online at http://cluster.if.usp.br/ People involved with setting up, using, maintaining and managing sets of identical or at least similar machines, to work as either compute nodes in a parallel processing cluster, or as X11-capable terminals, may find use for the programs and ideas contained in these packages. The documentation contains general explanations of each aspect of the cluster architecture. The packages were developed and are currently used in Woody, but they are installable in Sarge as well. These packages are for the i386 architecture only, but since the tools are implemented as shell scripts, they can be in fact used in any architecture. All the sources are available and it is a simple matter to make packages for other architectures, so long as one has access to appropriate machines. You can install and update these packages if you include in your /etc/apt/sources-list file the line deb http://sft.if.usp.br/debian-cluster stable main For anyone wishing to mirror the site, an rsync module is available. This is being sent to the Debian lists debian-user and debian-beowulf. Please feel free to forward it to any other lists that may be appropriate. 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]
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.
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.
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.
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.
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.
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]
