RE: logout and cosign.cgi question

["Brett Lomas" <b.lomas@xxxxxxxxxxxxxx>]

An Apache configuration fragment would be good, which is included by

<IfModule mod_cosign.c>
 Include conf/cosign.conf
</IfModule>

I think it should be --with-apache2 and --with-apache or --enable-apache2
and --enable-apache, but this is me being pedantic :)

If the common code was correctly cross-platform (from my looking around it
is pretty close) it would be pretty easy... I have been playing and got
reasonably far: for example libsnet would have dir layout like:
libsnet/  <- containing the *nix compile and source files
libsnet/win32 containing the Visual Studio project files and perhaps an
ntmakefile
libsnet/{debug,release}

etc
etc

This would bring the common code into the one product and help with the bug
fixing I would think... given you will fix the bug in only one place...

Cheers


------------

Brett Lomas
Integration Architect
Information Technology Systems and Services
The University of Auckland
New Zealand

Phone:		+64 9 3737 599 extn 86499
Mobile:		+64 21 757 096


-----Original Message-----
From: kevin mcgowan [mailto:clunis@xxxxxxxxx] 
Sent: Thursday, 22 April 2004 3:50 p.m.
To: Brett Lomas
Cc: 'Cosign Discussion'
Subject: Re: logout and cosign.cgi question


On Apr 21, 2004, at 10:44 PM, Brett Lomas wrote:

> I think the cgi-bin/logout with script alias works well, but I am just
> thinking from an installation point of view.
>
> I would like to see CoSign much easier is intall, and this what I am 
> trying

agreed.  One of the upcoming changes that will make configuration, at 
least, a lot easier is the advent of a more general conf file.  This 
should eliminate the need for most of the compile-time only options 
that exist right now.

> to for the UoA as a first step to putting CoSign into production here. 
> So
> from my point of view, the least amount of changes needed to the 
> httpd.cond
> and ssl.conf etc etc would be the best, as long as it is (of course) 
> reason
> to have this.

> Although I am looking at perhaps writing something so the make
> process and alter the httpd.conf etc appropriately for the basic
> configurations and then is can be tweaked if needed. Thoughts?

I think this sounds reasonable.  Are you thinking of a perl script or 
similar?  Parsing every httpd.conf file in the world to install 
directives in the right place strikes me as too awful a task to take on 
... even apxs doesn't do it properly. :)

Perhaps it would be sufficient just to build an httpd.conf fragment 
that includes recommended configuration and examples of all of the 
various Apache directives based on the user's configure options?  Then 
we could instruct them to use Include to load it or to copy/paste the 
parts they want into their own httpd.conf files.

> I am also in the process of making the configure script a little more
> consistent (eg --enable-apache2 and --with-apache-apxs) and 
> configurable
> based on the prefix etc...

what's the inconsistency there?  Are you suggesting it should be: 
--enable-apache-2?

> I am also thinking of bringing the IISCosign source in the filters 
> directory
> and alter the common code (in the common directory and libsnet) to 
> compile
> on both win32 and linux. I think this makes for a cleaner development
> environment.

Would this also include making it possible for windows user's to 
compile mod_cosign for windows Apache?  I don't know how the visual 
studio project would like being merged into the main source tree.  
Perhaps Jarod has an opinion here?

> What are your thoughts?
>
> Please do not take my suggestions as criticism :) These are things I 
> want to
> do and I would like my work to useful to the wider community also, so
> suggestions would be good :)

I would never take generous contributions of time, effort, and skill as 
criticism.  Good to have you on board. :)

Kevin