Bug#32263: Splitting CGI-BIN

[Brian White <bcwhite@precidia.com>]

> > > What would y'all think about having cgi-bin managed more like, umm:
> > >         /usr/lib/cgi-bin/
> > >                 <packages dump CGI scripts in here willy-nilly>
> > >         ~wwwdata/cgi-bin/
> > >                 <packages make symlinks to /usr/lib/cgi-bin/blah in postinst,
> > >                  based on some setting in /etc/ somewhere>
> > This has how I've done my site, but it's a pain.
> 
> It's only a pain because at the moment you have to make the symlinks
> yourself, though, isn't it?

That's part of it.  Since packages don't announce what they are putting
something in to /usr/lib/bin, I usually don't see it.  It's also a pain when
I'm not paying attention during an upgrade an Apache changes the /cgi-bin/
ScriptAlias, but since that's my own fault, I can't really complain
too much. :-)


> > Also, many webmasters
> > run virtual websites and thus such symlinks would have to be done (or not
> > done) for each webspace and that's not something can be easily automated.
> 
> Hrm. If they want the same CGI scripts on all their web sites, it's easy,
> just point the cgi-bin alias for each vhost to the one directory.

That would also assume that all CGI scripts were the same for all virtual
sites, which is not necessarily true just because they want each to have
access to a script installed from a Debian package.


> If they want fine-grained control over their CGI scripts ("This client
> only gets access to any given CGI script when it's approved by the
> techies, and they pay $5"), then it's not an issue, since they'll be
> making the symlinks by hand anyway.
> 
> It's only when they want fine-grained control of local CGI scripts,
> but all the pre-packaged CGI scripts on each vhost, that we could do any
> better. Of course, if they _really_ want that, they could just setup the
> cgi-lib alias themselves. But I would've _thought_ the other two cases
> would be the common ones, though?

Setting up the cgi-lib alias isn't the problem, though.  The problem is
all the package pages that reference their scripts via <webroot>/cgi-bin.
Changing those is the point of the exercise, but it's necessary to get
some support (i.e. the alternative "<webroot>/cgi-lib") from the webservers
first.

                                          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.