[389-devel] various admin server stuff

Thu Oct 8 21:06:29 UTC 2009

On 10/08/2009 01:58 PM, Rich Megginson wrote:
> Nathan Kinder wrote:
>> On 10/08/2009 01:29 PM, Rich Megginson wrote:
>>> Nathan Kinder wrote:
>>>> On 10/08/2009 11:37 AM, Rich Megginson wrote:
>>>>> I'd like to move mod_admserv and mod_restartd into the admin.git 
>>>>> repo as sub-directories.  I couldn't figure out a way to migrate 
>>>>> the CVS history data into a git subdirectory, so I was thinking 
>>>>> about just copying the files in there with no history.  Is this 
>>>>> ok?  We can always refer back to the old CVS repo if we need to 
>>>>> see history.
>>>> I think this is fine.  As you say, we can always look at the old 
>>>> CVS repo if needed.
>>>>>
>>>>> It turns out we can't get rid of mod_restartd and use mod_suexec.  
>>>>> mod_suexec explicitly forbids running CGIs as root, so we can't 
>>>>> use that to start the servers.  I don't really like the fact that 
>>>>> we have to support this module for the sole purpose of being able 
>>>>> to remotely start, restart, and create instances of servers that 
>>>>> run on low ports.  For one, mod_restartd is and always will be a 
>>>>> security nightmare waiting to happen - it is just a bad, bad idea 
>>>>> to execute CGIs as root (or run the admin server as root).
>>>> Agreed.  We can mitigate the risk some by constraining things with 
>>>> SELinux policy.
>>>>>   For another, usually init or something like daemontools does a 
>>>>> much better job of making sure remote servers are running (e.g. 
>>>>> restarting after a crash).  You always have to run 
>>>>> setup-ds-admin.pl when installing on a remote system, and that 
>>>>> creates the directory server instance, so I'm not really sure how 
>>>>> useful it is to be able to remotely create instances.  I'd like to 
>>>>> propose that we make this feature optional (that is, can build 
>>>>> admin server without it) and possibly get rid of it altogether.
>>>> It doesn't seem too common for people to run multiple instances on 
>>>> the same system out in the wild.  Even for those who do, I would 
>>>> imagine that instance creation is not a common occurrence, and this 
>>>> would really only affect Console users.  This would mean that 
>>>> changes are needed to Console to  get rid of the "Create Instance" 
>>>> task though.
>>>>>
>>>>> I would also like to relax the requirement that we have to use the 
>>>>> threaded model Apache.  The only reason we require this is because 
>>>>> mod_admserv caches the auth credentials and ACIs in memory, in 
>>>>> case you need to perform a task while the config DS is down (e.g. 
>>>>> like start or restart).  There are a few changes required to 
>>>>> mod_admserv to relax this restriction.
>>>> If the threaded model is not used, does that mean you can't perform 
>>>> tasks when the config DS is down, even with the changes you have in 
>>>> mind?
>>> You would not be able to perform CGI based tasks, such as - manage 
>>> certs, view logs, stop/start/restart, create instance - and you 
>>> would be able to do very few, if any, admin server web or console 
>>> tasks.
>>>
>>> The other way to do it would be to run apache in prefork mode, but 
>>> just have one server process (set the number of servers to fork to 
>>> 1).  Then you could use the prefork apache, with no threading, but 
>>> still have the cache available.
>> This sounds best to me.  Is there any real need for multiple 
>> processes here?  It's not like the admin server should be dealing 
>> with tons of requests from different clients.  The use case is really 
>> one administrator using console (or Admin Express) to manage their 
>> Directory Severs.  Is there some other benefit we lose by moving to a 
>> single process with no threading that I'm not thinking of?
> Gateway/phonebook/org chart - the default is to run these through the 
> primary admin server - those apps are stateless/cacheless and would 
> work just fine under plain old apache, regardless of the worker model.
So we could just recommend that those apps not be run under Admin Server 
in production environments for performance reasons, but instead run them 
under plain Apache webserver and configure as the admin sees fit.
>>>   If you have more than one process, each one will have a separate 
>>> cache, which may or may not contain the current auth and ACI cache, 
>>> so it will just be luck to have the correct apache process with the 
>>> correct cache serve your request.  Of course we could move to a 
>>> model where the cache is stored in shared memory, or disk file with 
>>> flock/lockf access, or some other IPC model, but that seems like a 
>>> lot of work for little benefit.
>> Yeah, too much work for no real benefit IMHO.
>>>   The whole point of this is to mitigate the effect of a downed 
>>> config DS, and some other method should be used to ensure that the 
>>> config DS is always available (e.g. init/daemontools - see above).
>> One point to bring up here is that it may be preferable to not use 
>> your config DS for anything other than being the config DS.  This 
>> would mean most people would want to create a second instance on the 
>> same system, which they would only be able to do with 
>> setup-ds-admin.pl if we pull that capability out of the Console/CGI.  
>> I don't think that is a big deal though.
> You can already use setup-ds-admin.pl to create another instance.
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> -- 
>>>>> 389-devel mailing list
>>>>> 389-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> -- 
>>>> 389-devel mailing list
>>>> 389-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> -- 
>>> 389-devel mailing list
>>> 389-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>
>> ------------------------------------------------------------------------
>>
>> -- 
>> 389-devel mailing list
>> 389-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
> ------------------------------------------------------------------------
>
> --
> 389-devel mailing list
> 389-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20091008/d00b3b6f/attachment.htm>