Giacomo Mulas wrote: > 1) Which filesystems ought to be bind-mounted in the chroot? /home, /tmp, > /var/tmp are quite obvious, but what about /var/mail? Configuration files > in /etc? I see no need to bind mount /var/mail or /etc and reasons against doing so. Are you really needing users to run in the chroot? I just use it to manage the software installed there. From outside the chroot you can run the 32-bit binaries. Only a small number of them, such as openoffice, actually require the chroot. Try this: /emul/ia32-linux/bin/ls Should run fine. (If not check /etc/ld.so.conf and make sure your paths include the /emul/ia32-linux directories.) Which means you can set PATH to include the 32-bit chroot and just run them normally. PATH=$PATH:/emul/ia32-linux/usr/bin:/emul/ia32-linux/bin > 2) (related to 1) In many cases, a system user and/or group is created > upon installation of a package. These will obviously happen to be > different between the chroot and the pure64 system. Should /etc/passwd, > /etc/group etc. be shared between the pure64 and ia32 systems? Packages that add users are generally system packages such as postfix or apache. Do you have a specific example in mind? But bind mounting password, group and shadow could be useful to make sure all users have logins in the chroot in the case that you have an application that requires the chroot, like openoffice. > Any problems to be expected in this case? Or should I compare the > uids/gids in the chroot to the ones in the pure64 system and get > them to agree by hand, using something like find to locate and > change file ownerships accordingly? Personal preference, but that is more likely what I would do for the specific cases that needed it. > 3) I suppose (hope?) I am not the first to do something like this. People > who went through it already (and survived): hints, suggestions? Confusion and education are the two biggest problems. Most people do not understand chroots. It confuses them. Bob
Attachment:
signature.asc
Description: Digital signature