Roger Leigh <rle...@codelibre.net> writes: > On Sun, Jul 05, 2009 at 11:36:31PM +0200, Goswin von Brederlow wrote: >> Roger Leigh <rle...@codelibre.net> writes: >> >> > As I see it, there are two major hurdles: >> > >> > 1) Initial creation of the chroot. As above, I think a simple script >> > to integrate with the existing tools would work just fine here. >> >> Which must handle all possible user configurations for mail, sound, >> printing, .... > > I'm not sure I agree here. "All possible configurations" is a rather > impossible goal for any system. > > The creator of any package would need to decide what to support by > default. It can use the d-i tasks just like a normal installation > would, but the user will ultimately have the power to configure it > as they see fit.
That isn't what I ment. Or at least I think you misunderstood. If the user has configured his sound outside the chroot to for example use a network sound daemon and play on another host then inside the chroot the sound should do the same. Or when sound is used outside the chroot by e.g. kopete to beep when a new message comes in then sound should still work for a 32bit flash inside the chroot. And so on. There are a number of things that should be passed from the chroot to the real system and each has tons of different possibilities for the user to configure them. Makeing them work out of the box inside the chroot is shear impossible. And if the solution doesn't work out of the box but needs lengthly manual configuration and tinkering then that isn't a solution. > Although I use amd64, I have yet to want to install any 32bit > software, so I'm not entirely sure what the use case is for it. If > we're talking about specific programs such as proprietary binary- > only software and browser plugins etc., then we really only need > the specific software and its dependencies in there. I really don't > see the need for an entire functional desktop environment inside the > chroot, for example. Some further clarification is needed here. It doesn't need an entire functional desktop environment, it just should be entirely functioning. Having a 32bit browser and flash plugin in a chroot is of little use if you don't have sound while kopete is running outside the chroot. >> > 2) An easy way to run programs inside the chroot. This depends upon >> > exactly what you want to do. Wrapper scripts or shell aliases do >> > a good job for existing users; automatically generated desktop >> > menu files for specific applications would also work. >> >> Which then can't generaly send mail, play sound nicely (mix with the >> non-chroot sound), print documents, ... > > These tasks just require the necessary client libraries and/or > programs to talk to the server. In the case of the sound, the > device nodes are shared with the host system, as is SYSV and POSIX SHM. > For server AF_LOCAL sockets, we can bind mount the sockets in there > as well. Yes, you can. It just means do this, and that and that other thing. And then the user uninstalls sound system A and installs sound system B and suddenly the old bind mount is inefective since it mounts the wrong directory. >> And most unsovably: You can not start 64bit programs from inside the >> 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How >> many levels bind mounts do you want to do? > > Well, from a kernel POV, you can certainly use personality(2) to > switch the execdomain back to PER_LINUX from PER_LINUX32. > > You are correct that starting 64bit programs on the host from inside > the chroot is not possible. The isolation of the filesystem from the > host is, of course, the defining feature of a chroot environment. If > we are running specific programs inside only, is this a problem in > practice? How would you write a frontend so that it ensures any program the 32bit applications might want to start are available? Like cups for printing. You pretty quickly come to the conclusion that you need to install every binary in both 64bit and 32bit to be sure. > It's certainly possible to install schroot inside the chroot and then > chroot back into a virtual host system, but I do admit that's rather > gross! > >> > While I agree that chroots do appear more technical and fiddly to >> > set up, the reality is that we now have the means to set them up >> > in a reliable and automated fashion, and this will give the user >> > a more robust environment than a monolithic library package set >> > from a security POV, as well as giving them access to the /entire/ >> > archive rather than a restricted subset, making it rather more >> > useful. While multiarch should solve this problem, chroots offer >> > rather more functionality and reliability at the present time, >> > with a (rather small) hurdle to set up initially. >> >> Not in a way that is suitable for general desktop applications. >> >> And hey, here is this existing way of doing all this so that none of >> these problems arise: ia32-apt-get. It also is not monolithic, nor a >> security problem and also gives access to the full archive. Initially >> it was too much of it even. > > I'd rather see a working multiarch implementation in the long term. I > agree that the chroot setup is not as ideal as multiarch, but there are > quite a lot of people using schroot in practice for this purpose. We are only talking about NOW. There is no argument that multiatch is the long term solution. But with >5 years since it was started it reall is LONG term. > I would be interested to know exactly why it's not suitable for > general desktop applications, and exactly what use cases you are > planning for which lead to this being the case. As said above. There are too many configuration cases to handle setting up the chroot automatically and keeping it that way. Too many things need the users tinkering. Just ask yourself why we need multiarch instead of a chroot. All the same reasons apply here. The solution is just not as nice. > Regards, > Roger MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org