[Devel] [ openser-Patches-1464264 ] support for TLS client domains (name based and socket based)

[Dan Pascu]

On Thursday 06 April 2006 13:24, Klaus Darilion wrote:
> Storing the config in the database is one thing. The other thing is
> about the SSL context. Currently, the contexts are generated at startup
> and when a new TLS connection is needed, the existing SSL contexts are
> used. When adding new TLS domains in runtime during a database table,
> there are two options (like in the domain module):
>
> - Caching: which needs a reload command like the domain module. In this
> case the SSL contexts can be generated in advance durign reload
>
> - Non-caching: In this case, the SSL contexts are generated when the
> TLS connection is needed. I do not know if generating the SSL contexts
> takes lot of time and may influence performance. Has someone more
> knowledge about this?

I don't think it matters. The openser parent process (or another process 
that will perform this reload) can load the new tls settings, compute the 
SSL contexts (it doesn't matter how long it takes) and when all are 
available will switch the old config with the new config for the worker 
processes. From the worker process point of view the transition is 
instantaneous.

> Is is the status in ser's TLS implementation. Jan has written a parser
> (which in the moment is a little bit buggy) for an external
> configuration file. Does someone of you knows existing frameworks for
> configuration files? I do not want to write the whole parser - I guess
> there will existing frameworks (like for .ini files in Windows).

That's why a database table is probably the simplest solution.

> If either the config is stored in a DB with caching, external file or
> in openser.cfg, reloading is not a trivial task. You still would have
> to keep old SSL contexts for currently open TLS connections. There may
> also be race conditions between reloading and concurrently created TLs
> connections.

Not necessarily (see above). The new configuration can be loaded, contexts 
computed and when available all you have to do is to commute a pointer to 
the new configuration (assuming the whole tls config is kept in a 
structure referenced by a pointer). This pointer change is an atomic 
operation. After this the old tls config can be discarded and the 
transition will be atomic and instantaneous for all worker processes.

-- 
Dan