Date: Tue, 12 Oct 1999 00:00:13 -0600 From: "Ryan Thompson [FreeBSD]" <freebsd@sasknow.com> To: Brian Reichert <reichert@numachi.com> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: Chroot and ~/bin, ~/etc. Better way? Message-ID: <3802CE6D.2A166543@sasknow.com> References: <Pine.BSF.4.10.9910111606070.30594-100000@bsdie.rwsystems.net> <38029482.9077F9E9@sasknow.com> <19991011234206.A24645@numachi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a LONG message. :-) Brian Reichert wrote: > > On Mon, Oct 11, 1999 at 07:53:06PM -0600, Ryan Thompson [FreeBSD] wrote: > > I consired hard links, as well (and, after reading the other messages in > > this thread, it appears others have, too :-) The problem, though, still > > remains that you can't hard link a directory (users' etc directories on > > my system contain about a dozen files). That makes for a lot of work > > when adding users or updating files. (even for a script! :-) > > How so? You could easily cram in all sorts of weird stuff into, > say, /home/skel, and a script as simple as: > > # cd /home/skel ; find -d . -print | \ > cpio -p --make-directories --link --quiet ~/new_user > > would seem to handle the creation of a directory full of hard links. > > Use a private pw.conf(5) to cause create of local copies of file > you want them to be able to touch, and away you go... > > > And, > > maintenance is still messy. > > Maintenance of what? Certainly, if you change /home/skel after > you created ~/new_user, you'd have to re-sync, but so what? Re-run > the cpio thang... > > > AND, ln won't create hard links across file systems... LET ALONE NETWORK > > CONNECTIONS :-) So, that pretty much cinches it for me, as home > > directories can exist on multiple systems, here. > > Hence, my original condition that said skel tree be placed on the > same drive at the home directories. For less specialized applications, I'm sure your solution would work just fine. Using cpio is a good idea... But: 1) Some sort of automated script would still be needed to sync ALL users with the skel 2) If the structure of /home/skel changes (files are added or removed), yes, you do need to rerun cpio. Not just once... but for ALL users. Meaning, you STILL need some sort of script to iterate through the password db entries and fix home directories. Am I right? 3) Hard links (even when they work) can be a bit messy. Suppose I have a shell user who would like to use differing version of sh (for whatever reason). ~/bin/sh is hard linked to /home/skel/bin/sh. In order to drop in a new sh, I first have to unlink (ala rm) ~/bin/sh before placing the new file in. Not difficult, by any means. But, suppose I forget. Now ALL users are using a different version of sh. OOPS! Perhaps there are better examples to illustrate this... But I don't want to get too far off topic :-) 4) For my system (and others, I'm certain), it would be impossible for /home/skel to reside on the same filesystem as the users' home directories, as my users' home directories do NOT all reside on the same filesystem themselves. I'm not going to go into the WHY behind it, as my system is not really unique in that respect... The outcome, though, boils down to the fact that, for my system, and others, hard links just aren't going to work. This all brings another question to mind. I DID create a nice little script to maintain multiple copies of needed files based on a default skeleton (see prior message in thread)... And, for me, it works great. However, it's still not a perfect solution. Multiple users mean multiple copies of these files. In some cases, multiple copies are NECESSARY, if, for some users, changes to the defaults are in order. However would something like the following work? (This is where my device mounting knowledge gets a little shaky.. I obviously haven't tested this :-)... - Create two small filesystems (one for bin, one for etc) - When chroot'ed user logs on, do something like the following as the user: mount -r /dev/bindevice /bin mount -r /dev/etcdevice /etc Of course, all users would need to have a small /dev/ directory with a node for each of those devices... This, to me, seems like a similar solution to Brian's, with the following benefits: 1) /bin and /etc directories need not be resynched as they are changed 2) Ability to use the same skeleton for users across filesystems is gained 3) Different skeletons for different groups Drawbacks (not certain about all of these): 1) Speed/memory requirements for mounting additional devices repeatedly? 2) Slower logins on busy systems if mounts need to be done? 3) Specialized bin and etc directories become more difficult. One can not simply destroy a link and drop in changed files. The filesystems would only be mounted when a user logs on... So, unless many simultaneous users were on the same system (hundreds), performance shouldn't be seriously hampered, I don't think... Mind you, I've never tried to mount and unmount hundreds of small filesystems at random. :-) But, every different idea has it's own advantages :-) What would be REALLY nice is if mount -o union worked a bit differently. The way it works now (for the benefit of those who aren't familiar with the option), mounting a filesystem as a union will look for files on the mounted filesystem FIRST before looking in the existing directory. New files, in addition, will be created on the mounted filesystem, instead of the existing directory. I would LIKE to be able to do the following: - Create a skeleton filesystem like the following / .cshrc ...etc /bin ls csh sh ...etc /etc pwd.db group motd ...etc And have users automatically mount it (via login shell script) like: mount -o union /dev/userrootdevice / BUT, have the EXISTING user directory take precedence over the mounted filesystem. Namely, if a new motd is created in the user's directory, the MOUNTED version of motd should be ignored. And, have new files created in the existing user directory. (so they can freely add their own files in public_html, add a pinerc... whatever users normally do in their home directories :-). THAT, imho, would be an elegant solution indeed.... But (remember, I am not a mount guru :-) I would think this would require some modifications to the kernel to possibly add an entirely different option to mount (so the old union option isn't broken) to support the filesystem as mentioned. Thoughts on this? Am I nuts? Would it require a few hours of coding? Or would it take months? Would it create any problems? Security holes? ---- What I have currently done, as I'm sure you've heard me say, is create a neat little perl script to step through home directories in the password database and sync individual directories if they need syncing. The script, with a bit of work, could be made into quite a simple answer... BUT, multiple copies of the files are still scattered, occupying space (not much, mind you... ~250k for each user... But it would still burn up half a gig for 2000 users). The script runs quickly, and ensures that files stay current. Basically, it works well for me... May work well for others... Will probably not work for some. If there's a way to implement my mount -o union idea, I'd be all for it. Currently, though, I'm hard pressed to think of a better solution. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3802CE6D.2A166543>