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.
Brian
( 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: