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
ah.
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.
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".
(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))
> The contents of "/home/virtual/domain.com/usr/bin/perl"
> are not symbolic links to the main /usr/bin/perl .
> This will not work anyway as user accounts cannot
> and should not see anything below it. Right ??
correct. symlinks are also affected, since they go off the user-space
view of the filesystem.
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.
> 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.
you'll need to worry about any dependencies (perl and non-perl) too,
of course.
> 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).
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)
--
- Gus
--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
