Hi Richard,
No negative criticism was considered etc from here; I'm sorry if my message seemed that way. I'm earnestly trying to figure out what the problem is so we can fix it. I've been using nsopenssl since y2k, so I lack having a fresh look at it.
Similarly, the thread you reference is early nsopenssl 3.0 release from 2003. The issues seem to be dealt with already. The current config.tcl mirrors Scott Goodwin's example AFAICT. config.tcl also has ns_section "ns/server/${server}/module/nsopenssl/defaults"
I don't know that there's a simple way around removing the default contexts 'users' and 'client'. As I understand it, the full flexibility of nsopenssl is available as is. If one wants to define another context, define it by using the 'admin' context as an example.
There's some config.tcl files out there that show how to setup virtual servers using http, and some discussion of revising the OpenACS default config.tcl to use that format. I like the idea, especially if it adds flexibility to installations and doesn't just add more work.
OpenACS has host-node mapping for serving multiple domains from one aolserver instance (incompletely implemented). Using virtual servers may be a cleaner way of accomplishing this, but I believe would lack sharing of db pools between instances.
https has an added requirement that each domain requires a different certificate/key (unless you're using self-signed certificates and don't mind the browser messages). Since CA cert/keys are an added cost, usually an organization splits the deployment into separate aolserver instances per key (and IP), to avoid any issues of two or more keys sharing the same IP address (different subdomains and/or ports). Often a requirement of a purchased key is that it runs on it's own IP for security reasons.
So, how is OpenACS limited with these contexts? Removing hard-coded things can be a good idea, but how is OpenACS limited by these hard coded contexts? What is the full flexibility of nsopenssl that OpenACS is not leveraging?
cheers,
Torben
