[389-devel] various admin server stuff

Thu Oct 8 20:58:16 UTC 2009

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.
>>   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
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20091008/df948a3f/attachment.bin>