Re: Managing users and groups within multiple devel chroots.
On Thu, Sep 15, 2005 at 06:29:12AM -0500, Peter Samuelson wrote: [Ernestas V.] Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group to chrooted environments would help? Symlinks won't work. Think about what a chroot environment *is*. Hardlinks will only work if the programs that edit /etc/passwd and /etc/group overwrite them rather than copy / unlink. Bind mounts will work (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd) but apparently don't support locking all of a file's representations, so you would need to be careful not to run adduser in multiple chroots at once (like doing several dist-upgrades in parallel, or having users log in to different chroots and all try to change their passwords at once). Ooh ooh, an excuse to share my new toy... I was setting up a chroot a couple of weeks ago and wanted it to reflect my system configuration. So the first thing I tried were bind mounts for shareable directories - /home, /tmp, /etc, et cetera. There are a couple of problems with this for /etc. The biggest one, for me, was that the chroot was i386 and the base system was amd64. Which in itself works fine, except it points out one of those files which can't be shared in this way: ld.so.cache. And if you bind mount a different ld.so.cache on top of the bind mounted /chroot/etc, then you can no longer rename /etc/ld.so.cache - this has to do with the way the Linux VFS works, as I understand it. So I took FUSE, and the included demo which proxies one filesystem to another location. And I hacked it to support bringing specific files from other locations, based on name. It's not the most robust thing in the universe - FUSE is not good enough to share / this way, things just won't work right. By good enough I don't know whether the limitations are in FUSE or in the nature of what I was trying to do, though. And don't try this on /proc or /dev. But for /etc, it works well enough for 32-bit firefox and OpenOffice.org. I've got the feeling this could handle flock() locking correctly, but doesn't - does FUSE even implement that? Anyway it should be fine for /etc/.pwd.lock. Here's the code, hardcoded paths and all: http://return.false.org/~drow/fuse/shadow-etc.c -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
On Sun, Sep 18, 2005 at 11:52:09PM -0400, Daniel Jacobowitz wrote: Here's the code, hardcoded paths and all: http://return.false.org/~drow/fuse/shadow-etc.c Slightly better, but not much: http://return.false.org/~drow/fuse/ -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote: Is it possible to configure a set of chroots (woody, sarge, whatever) so that all of the chroot passwd/group DBs will stay in sync with each other and with the host DB automaticall, so that, for example, a useradd, usermod, or userdel, will automatically affect all of the DBs simultaneously and safely? I haven't investigated if adduser supports this properly (and I suspect it doesn't), but LDAP authentication across the whole lot would do the trick. For this to work right, in addition to everything else, I assume that Debian policy would also have to guarantee that no package will ever remove a user/group when purged, and no package will balk if the user/group it needs already exists. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group to chrooted environments would help? Rob Browning wrote: Is it possible to configure a set of chroots (woody, sarge, whatever) so that all of the chroot passwd/group DBs will stay in sync with each other and with the host DB automaticall, so that, for example, a useradd, usermod, or userdel, will automatically affect all of the DBs simultaneously and safely? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
[Ernestas V.] Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group to chrooted environments would help? Symlinks won't work. Think about what a chroot environment *is*. Hardlinks will only work if the programs that edit /etc/passwd and /etc/group overwrite them rather than copy / unlink. Bind mounts will work (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd) but apparently don't support locking all of a file's representations, so you would need to be careful not to run adduser in multiple chroots at once (like doing several dist-upgrades in parallel, or having users log in to different chroots and all try to change their passwords at once). signature.asc Description: Digital signature
Re: Managing users and groups within multiple devel chroots.
On Sep 15, Peter Samuelson [EMAIL PROTECTED] wrote: Bind mounts will work (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd) but apparently don't support locking all of a file's representations, What about bind-mounting the /etc/.pwd.lock lock file too? -- ciao, Marco signature.asc Description: Digital signature
Re: Managing users and groups within multiple devel chroots.
On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote: Is it possible to configure a set of chroots (woody, sarge, whatever) so that all of the chroot passwd/group DBs will stay in sync with each other and with the host DB automaticall, so that, for example, a useradd, usermod, or userdel, will automatically affect all of the DBs simultaneously and safely? From the adduser/addgroup manpage: If the file /usr/local/sbin/adduser.local exists, it will be executed after the user account has been set up in order to do any local setup. The arguments passed to adduser.local are: username uid gid home-directory, and the environment variables DEBUG and VERBOSE will be set according to the settings in the master program. You can use this to execute the same adduser/addgroup command in the chroot. While this doesn't guarantee that the different files are 100% in sync, I think it'll get close enough for practical usage. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
Ernestas V. [EMAIL PROTECTED] writes: Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group to chrooted environments would help? Thanks for the suggestion, but I suspect that locking wouldn't work correctly in such an arrangement. If you could tell the system to use a separate directory for the db files and bind mount that directory among all the chroots, then perhaps that would fix the locking problem (presuming the default setup uses fs locks). Thanks again -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
Richard Atterer [EMAIL PROTECTED] writes: From the adduser/addgroup manpage: If the file /usr/local/sbin/adduser.local exists, it will be executed after the user account has been set up in order to do any local setup. The arguments passed to adduser.local are: username uid gid home-directory, and the environment variables DEBUG and VERBOSE will be set according to the settings in the master program. You can use this to execute the same adduser/addgroup command in the chroot. While this doesn't guarantee that the different files are 100% in sync, I think it'll get close enough for practical usage. Ahh. I had forgotten about that, and you're right, it might be close enough, but if it's possible to arrange for unified handling, I'd really prefer that. The main problem is that I want a solution that handles all users and groups, and I want tools like adduser to continue to work correctly. So far I haven't been able to tell if the behavior of adduser and the related tools is configurable. I can see how to authenticate against other sources via lipam, but not how to re-route modifications. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Pollock [EMAIL PROTECTED] writes: On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote: Is it possible to configure a set of chroots (woody, sarge, whatever) so that all of the chroot passwd/group DBs will stay in sync with each other and with the host DB automaticall, so that, for example, a useradd, usermod, or userdel, will automatically affect all of the DBs simultaneously and safely? I haven't investigated if adduser supports this properly (and I suspect it doesn't), but LDAP authentication across the whole lot would do the trick. If you are using the chroot for e.g. building with sbuild/buildd, you don't really want the LDAP stuff in your minimal chroot. As an alternative suggestion to the original poster, have a look at the latest schroot: http://people.debian.org/~rleigh/schroot-0.1.6.tar.bz2 Note this is not an official release, it's a CVS snapshot, since I only added the necessary support over the last two days. Here's an example of it in action, in verbose mode to illustrate: $ schroot -c sarge -v run-parts: executing /etc/schroot/setup.d/00check AUTH_USER=rleigh AUTH_VERBOSITY=verbose CHROOT_TYPE=plain CHROOT_NAME=sarge CHROOT_DESCRIPTION=Debian sarge (stable) CHROOT_MOUNT_LOCATION=/srv/chroot/sarge CHROOT_MOUNT_DEVICE=(null) CHROOT_LOCATION=/srv/chroot/sarge run-parts: executing /etc/schroot/setup.d/10mount run-parts: executing /etc/schroot/setup.d/20network `/etc/resolv.conf' - `/srv/chroot/sarge/etc/resolv.conf' run-parts: executing /etc/schroot/setup.d/30passwd `/etc/passwd' - `/srv/chroot/sarge/etc/passwd' `/etc/shadow' - `/srv/chroot/sarge/etc/shadow' `/etc/group' - `/srv/chroot/sarge/etc/group' run-parts: executing /etc/schroot/setup.d/50chrootname Setting chroot name to sarge [sarge chroot] Running login shell: “/bin/bash” (sarge)[EMAIL PROTECTED]:~/projects/schroot/schroot$ id uid=1000(rleigh) gid=1000(rleigh) groups=20(dialout),24(cdrom),25(floppy),29(audio),40(src),44(video),46(plugdev),1000(rleigh),1001(sbuild) (sarge)[EMAIL PROTECTED]:~/projects/schroot/schroot$ logout run-parts: executing /etc/schroot/setup.d/50chrootname run-parts: executing /etc/schroot/setup.d/30passwd run-parts: executing /etc/schroot/setup.d/20network run-parts: executing /etc/schroot/setup.d/10mount run-parts: executing /etc/schroot/setup.d/00check $ Notice that the /etc/schroot/setup.d/30passwd was used to sync the passwd and related files by copying them into the chroot from the main system. While it's a simple copy in this case, you can easily customise the script to sync the other way on session shutdown, and make this as complex as you like if you want to take care of the locking issues properly. The scripts allow one to customise and configure the chroot quite easily, so it can (for example) mount block devices on demand, and (later tonight, once I write it) create, mount and destroy LVM snapshots on the fly. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDKcGKVcFcaSW/uEgRArw3AJ9pgH22e3HR9LG7AZvv4NRsBi2umgCg6IKV COrNTpFmtq1cLJFeQwCQVPM= =Xj9z -END PGP SIGNATURE-
Re: Managing users and groups within multiple devel chroots.
Roger Leigh [EMAIL PROTECTED] writes: Notice that the /etc/schroot/setup.d/30passwd was used to sync the passwd and related files by copying them into the chroot from the main system. While it's a simple copy in this case, you can easily customise the script to sync the other way on session shutdown, and make this as complex as you like if you want to take care of the locking issues properly. The scripts allow one to customise and configure the chroot quite easily, so it can (for example) mount block devices on demand, and (later tonight, once I write it) create, mount and destroy LVM snapshots on the fly. Hmm. That seems like a nice tool, but in this case, I want to keep the chroots around all the time with home bind mounted so that the chroots are available to everyone, and I don't want there to be any period of time after installing a package in one chroot (or on the host) where the users/groups don't match everywhere. In truth, if LDAP can be configured to work completely transparently for *all* users/groups, so that, for example, adduser automatically uses it when packages are installed, then that would be just fine, but I was under the perhaps mistaken impression that an LDAP approach wouldn't be that transparent. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Browning [EMAIL PROTECTED] writes: Roger Leigh [EMAIL PROTECTED] writes: Notice that the /etc/schroot/setup.d/30passwd was used to sync the passwd and related files by copying them into the chroot from the main system. While it's a simple copy in this case, you can easily customise the script to sync the other way on session shutdown, and make this as complex as you like if you want to take care of the locking issues properly. The scripts allow one to customise and configure the chroot quite easily, so it can (for example) mount block devices on demand, and (later tonight, once I write it) create, mount and destroy LVM snapshots on the fly. Hmm. That seems like a nice tool, but in this case, I want to keep the chroots around all the time with home bind mounted so that the chroots are available to everyone, and I don't want there to be any period of time after installing a package in one chroot (or on the host) where the users/groups don't match everywhere. I think bind mounts are probably appropriate in this case. That's what I was using until yesterday, but then I wanted to make the most use of my new toy ;-) You could use schroot with all the mounts set up if you wanted. That's how I use it, but I do get tired of the huge mount table. Unrelated, but I'm too excited to keep quiet! I now have LVM snapshotting working! $ ./schroot -c sid-snap -v run-parts: executing /etc/schroot/setup.d/00check AUTH_USER=rleigh AUTH_VERBOSITY=verbose CHROOT_TYPE=lvm-snapshot CHROOT_NAME=sid-snap CHROOT_DESCRIPTION=Debian sid snapshot CHROOT_MOUNT_LOCATION=/mnt CHROOT_MOUNT_DEVICE=/dev/hda_vg/sid_chroot CHROOT_DEVICE=/dev/hda_vg/sid_chroot CHROOT_MOUNT_OPTIONS=-o atime,sync,user_xattr CHROOT_LVM_SNAPSHOT_OPTIONS=--size 2G run-parts: executing /etc/schroot/setup.d/05lvm Logical volume sid_chroot-snapshot created run-parts: executing /etc/schroot/setup.d/10mount mount: you didn't specify a filesystem type for /dev/hda_vg/sid_chroot-snapshot I will try type ext3 /dev/mapper/hda_vg-sid_chroot--snapshot on /mnt type ext3 (rw,sync,user_xattr) proc on /mnt/proc type proc (rw) /dev/pts on /mnt/dev/pts type none (rw,bind) tmpfs on /mnt/dev/shm type tmpfs (rw) /home on /mnt/home type none (rw,bind) /tmp on /mnt/tmp type none (rw,bind) run-parts: executing /etc/schroot/setup.d/20network `/etc/resolv.conf' - `/mnt/etc/resolv.conf' run-parts: executing /etc/schroot/setup.d/30passwd `/etc/passwd' - `/mnt/etc/passwd' `/etc/shadow' - `/mnt/etc/shadow' `/etc/group' - `/mnt/etc/group' run-parts: executing /etc/schroot/setup.d/50chrootname Setting chroot name to sid-snap [sid-snap chroot] Running login shell: “/bin/bash” (sid)[EMAIL PROTECTED]:~/projects/schroot/schroot$ logout run-parts: executing /etc/schroot/setup.d/50chrootname run-parts: executing /etc/schroot/setup.d/30passwd run-parts: executing /etc/schroot/setup.d/20network run-parts: executing /etc/schroot/setup.d/10mount /tmp umounted /home umounted tmpfs umounted /dev/pts umounted proc umounted /dev/mapper/hda_vg-sid_chroot--snapshot umounted run-parts: executing /etc/schroot/setup.d/05lvm Logical volume sid_chroot-snapshot successfully removed run-parts: executing /etc/schroot/setup.d/00check $ Now the only remaining feature is disconnected session management, and it's basically complete. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDKeA4VcFcaSW/uEgRAlesAJ0ZcXY4X9oHcPZlraPVDjE4/8WRuACdHWur uFXPNny7PQdpwBqyy/k/qCA= =ZXU5 -END PGP SIGNATURE-
Managing users and groups within multiple devel chroots.
Is it possible to configure a set of chroots (woody, sarge, whatever) so that all of the chroot passwd/group DBs will stay in sync with each other and with the host DB automaticall, so that, for example, a useradd, usermod, or userdel, will automatically affect all of the DBs simultaneously and safely? For this to work right, in addition to everything else, I assume that Debian policy would also have to guarantee that no package will ever remove a user/group when purged, and no package will balk if the user/group it needs already exists. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
