[389-devel] various admin server stuff
Rich Megginson
rmeggins at redhat.com
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://lists.fedoraproject.org/pipermail/389-devel/attachments/20091008/df948a3f/attachment.bin
More information about the 389-devel
mailing list