Re: COSIGN: implement cosign cgis as php?

[Mark Montague <markmont@xxxxxxxxx>]

On Tue, 23 Mar 2004, kevin mcgowan wrote:

> What would you think about rewriting these CGIs in PHP -- strictly for
> enhanced performance/load resilience?  Would a dependency on PHP on the
> weblogin server be a deal breaker for anyone considering the use of
> Cosign?  Would it make installation of the weblogin server too
> complicated?  Is there anyone for whom this change would be a great
> positive?  Note that we're not considering doing it anytime soon -- I'm
> just trying to gather opinions.  Would mod_fastcgi support be more or
> less appealing than using PHP?  mod_perl?  rewriting the CGIs as an
> Apache module?

> I should note for completeness that PHP is already required by
> 'friend.'  Anyone using the friend guest account functionality is
> likely to have to install PHP anyway.  What I'm asking about is this
> idea of requiring PHP for the core functionality.

Any way to get rid of PHP for Friend? :) I've had some bad experiences
with PHP, and it's still evolving rapidly (in comparison to, say,
Perl 5).  I'm currently having what I suspect are race conditions
in threaded code betweeh Apache 1.3.29 and PHP 4.3.4 on Solaris 8 --
PHP works fine for me until the server load goes up, and then some
but not all pages start getting served without being executed (i.e.,
many users are treated to a view of the pages' source code).  I
haven't been able to track this down yet, but the next thing on
my list is to try PHP 5 and make sure both PHP and Apache are
using the same libraries for everything (but especially for
threading).

Given that I'm a system administrator, I'd prefer Perl if we had
to switch to a scripted language.

mod_fastcgi seems more like a halfway solution to me.  If we're
going to make a change, let's do it right and go all the way.

Honestly, I like the small size, easy auditabilty, lack of
dependencies, and security of the present C code.  But of course,
if the fork/exec is killing us under heavly load, we may have
to switch.

Rewriting the present C code as web server modules would
technicaly solve the problem, but since we currently have
multiple CGIs and multiple supported web servers, this is
a problem that grows c*s (O(n**2)) as the number of CGIs and
web servers increase.

Here's an out-in-left-field idea:  instead of pulling in a
huge scripting engine, how about writing (or finding) an
web server module that uses IPC to hand of the request to a
separately running threaded daemon?  This would mean rewriting
the current CGIs, but we'd only have to write the module once
for each web server, making it closer to an O(n) solution.
It's conceivable that this module (packaged as a separate
product) could be useful for other non-weblogin/cosign related
services.  And it isolates any security problems in the
weblogin daemons (formerly CGIs) from the web server processes;
the daemons could even run as a different user "for free".

I'm not seriously advocating this idea right now, just throwing
it onto the table.  As I said, it's out there in left field.

                Mark Montague
                LS&A Information Technology
                markmont@xxxxxxxxx