[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy 3.7.0 - /usr/lib/cgi-{bin|lib}



hi,

On Wed, May 03, 2006 at 03:02:49PM +0200, Alexis Sukrieh wrote:
>   W: bugzilla: file-in-usr-lib-cgi-bin usr/lib/cgi-bin/bugzilla/
>   N:
>   N:   Packages shipping web server CGI files should install them in
>   N:   /usr/lib/cgi-lib, not in /usr/lib/cgi-bin. This is done to avoid
>   N:   conflicts with the cgi-bin script alias, which is reserved for the
>   N:   local use of webmasters. Web servers should include /cgi-lib/ as a
>   N:   standard ScriptAlias pointing to that directory.

this is a surprising change.  guess that's what i get for not being
subscribed to -policy :)

first, i don't really see what the merit is of moving files from
/usr/lib/cgi-bin to /usr/lib/cgi-lib.  

second, AFAIK, /usr/lib is still the domain of dpkg/debian and not the
"local use of webmasters", so why should we have to move the files?
it seems to me that the policy *at least* should instead say:

- if it is really for the local admin's use, web servers should have
  /cgi-bin point at /usr/local/lib/cgi-bin or somesuch
- /cgi-lib points at /usr/lib/cgi-bin

but i'm still grappling to understand the rationale behind why this
is a desirable thing.  if the desire is to provide a way for the
local admin and packages to be able to share a script aliased directory,
i would argue this is entirely the wrong way about it.  i'd be happy to
elaborate further.

> I think that we should document somewhere how to handle this
> migration. Just changing the path /usr/lib/cgi-bin to /usr/lib/cgi-lib
> in our debian/rules isn't enough, we have at least to warn the user
> that he has to make sure that his webserver provides a Script Aliasing
> feature from cgi-lib/ to cgi-bin/.

i would argue that /usr/lib/cgi-foo is an outdated approach anyway, and
that most applications ought to be scriptaliasing /package/cgi-bin 
or /cgi-bin/package to somewhere under /usr/lib/package (this would in
fact be another use for the non-existant libexec dir...).  but that's
just my $0.02.

in any case, this will also require updating of configuration files and
for some systems a lot of grep+sed will need to be done if the internal
systems reference something with cgi-bin in the url.  it'll also break
a lot of bookmarks, though that should really be the least of our
concerns.

a note to the debian-policy folks: you may or may not be aware that
we've done a significant amount of work regarding drafting a comprehensive
and sensible policy for web servers and web applications.  i don' think
it's quite ready for submission (i think the unspoken assumption is that
we'd submit it for etch+1, and after webapps-common was introduced into
the archive), but your feedback on what we've come up with so far would
be very much appreciated:

	http://webapps-common.alioth.debian.org/draft/html/

for any of you who are going to be at debconf, we're hosting
a BoF session on all this too.

	sean

-- 

Attachment: signature.asc
Description: Digital signature


Reply to: