Hi Angus:
Thanks for a detailed reply on my problems.
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.
>its an admirable security feature on a web hosting server.
>to see what the user sees, do "chroot /home/virtual/domain.com" as
root. when you exit that shell, you'll return to "normal".
*** I will try and see.
>(chroots have other uses too. eg: the debian package "pbuilder" helps
you setup chroot environments so you can compile packages for "stable"
on an otherwise "unstable" system (or vice-versa))
*** I have to read up on this chroot stuff.
>hard links will work, however, but they only work between files on the
same device - which is unlikely to be the case in many chroot-setup
cases.
>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 ??
> Now what I would like to know is this, if I manually
> kill all the contents of Perl for the domain.com, like
> this (from root)
>
> rm -Rf /home/virtual/domain.com/usr/lib/perl5
>
> and then do this (still as root)
>
> 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.
> The only issue with this is as I install new CPAN modules
> as root they will not be seen at the user accounts.
>
> Then I probably need an additional step when CPAN install is
> complete. Have a script that somewhow will copy all these new
> modules to the Perl repositories of all the user accounts
> on this server.
>
> Any ideas on how I can do this ?
>
> Or is there a way to have user accounts perl repositories
> be somehow automatically linked to the main /usr/bin/perl ?
>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) ?
I hate to ask this, how do I create such a tasks from what you said above in
the commands ?
>personally, i'd just install new copies of the perl modules into each
chroot. scripting something using CPAN.pm would probably be reasonably
straight-forward and very useful.
("perl -MCPAN -e shell" is a very easy way to install CPAN modules)
*** I'm only concerned about keeping the control panel template directory, and
root perl5 as up to date as possible. But if I have a cron script, then why
not let it look at existing virtual sites as well, and then do this update
automatically when necessary. I don't want to do a manual CPAN install for
every single virtual site.
I can do it for the main root perl repository (which is what I have been
doing). But a cron script should do the job for all other repositories.
Louis.
--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
