[EMAIL PROTECTED] wrote:
> The largest problem I encountered when setting up Cherokee was
> interpreting the meaning of the Chroot option. When the chroot
> happens and how the variables are treated/handled in accordance with
> the chroot are the primay questions. Just the first would have
> saved me from stracing the program a fair amount.
>
> Exacerbating this is that a google search for cherkoee and chroot
> turns up this email:
> http://alobbs.com/pipermail/cherokee/2005-May/000722.html which
> suggests quite explicitly that the DocumentRoot should be redundant
> with the Chroot path, which i would not have expect and in fact is
> not correct (according to my experiences).
>
> I could possibly write a lousy (uncertain to be correct) first take
> on the chroot behavior based on my experiences and source readings.
> If this is useful, should I just edit the html, or is there a more
> upstream documentation form?
It would be useful to know how your case is, what Cherokee needs to
implement or change, what are the functionality you are missing,
etc.
The Chroot option will jail the server under that path, so after the
start up it will need all the paths to be relative to path point.
For example, lets imagine this configuration *without* Chroot:
========
DocumentRoot /var/www
Directory /icons {
Handler file
DocumentRoot /var/www/images/icons/
}
========
For a Chroot environment, it should be written as follows:
========
DocumentRoot /var/www
Chroot /var
Directory /icons {
Handler file
DocumentRoot /www/images/icons/
}
========
> ----
>
> Secondarily, I enabled the UserDir feature for my users, and had some
> trouble figuring out how this would work inside a chroot. thttpd simply
> transforms /~foo into /users/foo if /users/foo exists, which seems safe
> and sane.
Okay, so what you suggest is to add a check to ensure the user home
directory exists, isn't it? (It makes quite sense for me)
> cherokee tries to support apache style homedir access (which I think
> is a bad idea, but that is a design choice), and so does getpwent
> etc. Adding a fakey etc/password to the chroot works, but it is
> quite difficult to figure this out for the following reasons.
>
> 1) Access to the path http://host/~username returns an error, seemingly
> in all cases. http://host/~username/ works. Should I file a bug?
Oops! Yeah, it is a bug. Would you mind to file it?
> 2) If UserDir is disabled, a path such as http://host/~username/dir will
> be silently transformed into an access to the path '/dir'. Surely the
> string should be passed along unchanged if it is not handled?
Damn it, it is another one..
Josh, thanks for your feedback! :-)
--
Greetings, alo.
http://www.alobbs.com
_______________________________________________
Cherokee mailing list
Cherokee@lists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
