louis, your mailer (USANET web-mailer (CM.1201.3.01A)) has a very confusing quoting style.
At Mon, 22 Apr 2002 11:40:10 +1000, Louis Selvon wrote: > Angus Lees <[EMAIL PROTECTED]> wrote: > At Thu, 18 Apr 2002 20:17:46 +1000, Louis Selvon wrote: > > When I create a domain called "domain.com" with username "username" > > from the control panel from root that directory is accesible at > > > > /home/virtual/domain.com/ (This is the base directory for the domain) > > > > At the user account level for that domain, it's home is > > > > /home/username (It cannot see /home/virtual/domain.com, only root > > can). > > > > Now root Perl repository is located at > > /usr/bin/perl > > > > The domain.com repository is located at > > /home/virtual/domain.com/usr/bin/perl > > >you have several "chrooted environments". read chroot(8) and chroot(2) > for the details, but basically its possible to change where you (and > your child processes) think / is. once you chroot into a subdirectory, > its very difficult (but not impossible) to get out again. > > *** I don't understand this chroot stuff, but you are most likely right. > > What I did discover is that the control panel that I was provided, has a > template directory. In that template directory there is an outdated version of > perl5 installed which was the one my newly created virtual sites were picking > up. > > I do not know how chroot works. So what I did was as per what I said below. I > removed the perl5 for the template (rm -Rf), and then copied the one from the > main /usr/bin/perl5 over. From what you said if sounds like chroot is a better > way to do this, instead of copy. chroot just moves where the kernel says "/" is for a particular process. you will need to copy any files into the chroot location if you want those files to appear there.. > >using hard links will also remove some of the security benefits of > chroot - it will allow the chrooted user to (potentially) modify the > (real) system files. > > *** Don't want that. With what I just did above, virtual sites user still > cannot modify the main perl stuff from root. Right ?? correct. they can only modify their copy of the files (those in /home/virtual/domain.com/). > > cp -r /usr/bin/perl /home/virtual/domain.com/usr/lib/perl5 > > > > Will this install Perl properly for the user account, or > > it just won't work ? > > >yes, should do. if you are going to have multiple copies anyway, you > might want to just do a fresh install into each chroot to be sure. > > *** What I did is said above. I copied over to the template directory for that > control panel, and now all newly virtual sites perl5 are in line with root. my concern was with modules that do something more clever in Makefile.PL - other than simply compiling or copying files. there are a few CPAN modules around that will try and autodetect (or prompt for) different configurations. these might fail if they are copied into what looks like a different filesystem (without whatever they had just checked for). i'd say about 95% of CPAN modules will work fine with a simply recursive copy, however. > >you could run a cron job which copied the perl trees around (using > rsync, cp -a, tar or cpio - choice is good). > > *** What is "cp -a" (a man on cp does not show any -a options) ? curious. assuming you have GNU cp, thats a bug in your manpage. "cp --help" should give enough information anyway. -a, --archive same as -dpR (-d, --no-dereference never follow symbolic links -p, --preserve preserve file attributes if possible -R, --recursive copy directories recursively) its basically the "make this as close as practical to that" option. > I hate to ask this, how do I create such a tasks from what you said above in > the commands ? choose one of the methods above. i'll choose rsync, since that should avoid lots of unnecessary copying. "rsync -a /source/directory /destination/directory" will duplicate /source/directory as /destination/directory. you may also want to add the "--delete" option if you want to delete files in /destination/directory that don't appear in /source/directory. so: assuming you have an /etc/cron.daily/ directory: (if you don't, tell us your distro) create the file /etc/cron.daily/copychroots, containing: <begin file> #! /bin/sh # # script to update perl in already installed chroots # USERS="domain.com otherdomain.net yadomain.org" # automatically update the template directory using what is installed # in the "real" system. # (you may not want to do this automatically) rsync -a /usr/lib/perl5 /template/directory/usr/lib/perl5 # copy the template directory into each user's chroot for user in $USERS; do rsync -a /template/directory/usr/lib/perl5 /home/virtual/$user/usr/lib/perl5 done <end file> and then make it executable (chmod +x /etc/cron.daily/copychroots). that will run this script daily (on default debian systems at ~6:30am), and hopefully it will do what we want. any output from the script (errors or otherwise) should be emailed to root, so make sure that goes to you (or someone) who will actually read it. you can test the script by running it manually like any other program (just type "/etc/cron.daily/copychroots") if you use any perl modules that link to shared libraries, you will need to copy the libraries in too, of course. (other directories can be copied by just duplicating the rsync lines (with new paths)) -- - Gus -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
