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

Bug#32263: Splitting CGI-BIN

>  Brian> Once it becomes official policy, then I can get them to make the
>  Brian> necessary changes.  And once the webservers begin to change over,
>  Brian> then I can get the packages to change.
>         Perhaps things have changed in the last 3 years, and they
>  shall understand that post the /usr/doc issue policy has become more
>  conservative?

I'm afraid I don't understand what you mean here.

>  Brian> <webroot>/cgi-bin should default to "~www-data/cgi-bin".
>  Brian> However, existing implementations should not be automatically
>  Brian> changed so as not to break anything.  Once all packages follow
>  Brian> the new policy, then they can do semi-automatic changes to the
>  Brian> /cgi-bin setting.
>         I suppose you mean <webroot>/cgi-lib should default to
>  "~www-data/cgi-bin". I am with you so far. The only thing that has
>  changed so far is that the public interface may be changed to
>  <webroot>/cgi-lib, but nothing changes behind the scenes, and there
>  is no reduction in name space pollution.

No, I mean that <webroot>/cgi-lib should point to /usr/lib/cgi-bin
and <webroot>/cgi-bin should point to ~www-data/cgi-bin.  The latter is
what webmaster expect or, at the very least, they expect to be able to
control <webroot>/cgi-bin.

>  Brian> The reason no webserver must do a behind-the-scenes changes is
>  Brian> that the webmasters of some existing implementations will have
>  Brian> started inserting CGIs in the existing place and we should be
>  Brian> careful not to break that.
>         Quite so. Local cgi-scripts should _always_ be accessible
>  under <webroot>/cgi-lib.

I believe that <webroot>/cgi-bin should access local cgi-scripts since that
is the traditional method and the way most webmasters layout their site.
I'd like to use <webroot>/cgi-lib for access to the system cgi-scripts.

>  Brian> Once done, installed scripts will be available via both
>  Brian> "/cgi-bin/script" and "/cgi-lib/script".  The packages then
>  Brian> change all of their webspace references to be
>  Brian> "/cgi-lib/script".  However, both before they make that change
>  Brian> and after it is done, there is no interruption of service.
>         Yes. But the scripts still live in ~www-data/cgi-bin, right?
>  If not, I missed when you are going to have packages move the scripts
>  out.

All system scripts would live under /usr/lib/cgi-bin and be accessed via
<webroot>/cgi-lib.  To make for a smooth transition, any existing alias
of <webroot>/cgi-bin would remain untouched thus allowing uninterrupted
access until all of the packages that need to change can be changed.  This
shouldn't be a hardship for anybody since they're already forced to use
<webroot>/cgi-bin in that capacity right now.

>  Brian> Once all the packages have changed over, then webmasters can
>  Brian> start using the "/cgi-bin/" alias for what it was intended:
>  Brian> local CGI programs.
>         I see two problems. The name space pollution has not been
>  reduced -- since all scripts live in the same dir on disk; my
>  cgi-file could be overwritten by a debian package. All we have done
>  is created two names for the same underlying directory; but not given
>  the sysadmin a private place to keep his files that is safe.

Your personal cgi-script should _not_ be in /usr/lib/cgi-bin.  That's the
problem I'm trying to correct.  Packages should place scripts under that
directory but webmasters should use ~www-data/cgi-bin.  Right now, those
two are the same thing but this split will remove that dependency.

                                 ( bcwhite@precidia.com )

   If you love something, set it free.  If it comes back, it was, and always
     will be yours.  If it never returns, it was never yours to begin with.

Reply to: