[389-devel] various admin server stuff

Fri Oct 9 16:24:43 UTC 2009

Nathan Kinder wrote:
> 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.
Done.  admin server 1.1.10 and later has mod_admserv and mod_restartd in 
the source tree.
>>>>>>
>>>>>> 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'll work on this later.  For now, it's easy to edit admserv.conf to 
disable this.
>>>>>>
>>>>>> 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.
I've changed admin server - it will detect if the given apache binary 
has threading support.  If not, configure will error.  If you want to 
use a non-threaded Apache, you must specify the --disable-threading flag 
to configure.  In addition, mod_admserv will print a Notice to the error 
log if a non-threaded Apache is being used.
>>> 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.
This will require a little work to make them work with a standalone 
Apache, not much, some in the setup script, some in the build.
>>>>   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
>>   
>
> ------------------------------------------------------------------------
>
> --
> 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/20091009/557c0cb0/attachment.bin>