Everyone,
The timer on this case expires on Wednesday. Going through this
discussion, I want to confirm two recommended changes, and resolve a
naming headache they create:
1. Move the OpenDS componentry from /opt to /usr, consistent with
OpenLDAP and other FOSS products.
2. Update the documentation to recommend installation under user and
group "ldap", instead of "opends".
(1) needs clarification. If we follow the OpenLDAP example, then we
will be putting executables in /usr/bin and /usr/lib/opends. This will
cause problems in /usr/bin, since they have executables called
backup
status
manage-tasks
etc. Should the project team propose new names for the executables?
(OpenLDAP prefixes all their executables with "oldap".)
I'm assuming that nothing needs to go into /usr/sbin, even though
OpenLDAP puts components there.
-tdc
On Nov 14, 2008, at 1:06 AM, Ludovic Poitou wrote:
>
> On Nov 13, 2008, at 1:27 PM, Darren J Moffat wrote:
>
>> Ludovic Poitou wrote:
>>> Darren,
>>> On Nov 13, 2008, at 12:47 PM, Gilles Bellaton wrote:
>>>> I'm adding Carole and Ludo in copy as they will be able to answer
>>>> more precisely than me
>>>> to your questions.
>>>>
>>>>> The "into OpenSolaris" and an install location of /opt/opends
>>>>> are incompatible. If the intention is delivery as part of
>>>>> OpenSolaris then surely it should be installed in an integrated
>>>>> rather than unbundled location ?
>>>> Our intention is to deliver in the non WOS of OpenSOlaris as
>>>> described here :
>>>> http://wikihome.sfbay.sun.com/spe-re/Wiki.jsp?page=Indiana_docks
>>>> So in a way similar to netbeans and glassfish
>>
>>>> We were thinking that /opt would be the appropriate location for
>>>> such a delivery.
>>
>> Maybe but why should OpenDS be in /opt when PSARC/2008/507 approved
>> OpenLDAP for integration in /usr (with /usr/lib/openldap/ for the
>> server parts) ?
>>
>> They way the binaries are integrated into the RE doc is not really
>> an architectural issue, where it is installed is.
>>
>> This makes OpenLDAP a more "first class" citizen then OpenDS which
>> seems a little ironic to me.
>>
>>>>> What is the SMF service FMRI and what SMF method credential does
>>>>> it run with?
>>>> Carole, can you help me on this ?
>>> The FMRI as of today is planned as "network/ldap/opends". Feedback
>>> and alternate suggestions are welcome. I have little experience
>>> with the best practices for FMRI.
>>
>> svc:/network/ldap/server:opends
>>
>> This follows the same model as we use for http where ldap/server is
>> the service the use wants and opends is the software that provides
>> a particular instance of it. It also follows the precedent for
>> LDAP servers that is effectively setin PSARC/2008/507
>>
>> This allows for:
>>
>> svc:/network/ldap/server:openldap (Already defined in PSARC/2008/507)
>> svc:/network/ldap/server:sunjavaenterprisedirectoryserver :-)
>>
>>> After package installation, the Administrator must run a command
>>> to specify the location of the Database, the user and group for
>>> running the instance. If the user "opends" and group "opends"
>>> exist on the system, they will be proposed by default.
>>
>> Can't we have preconfigured defaults for all of that so that all
>> that is required is enabling the service ? I believe that is the
>> situation for the OpenLDAP server.
>
> In our experience, customers always have to do some initial
> configuration before enabling the service. The mandatory setup phase
> of OpenDS is a major added value over OpenLDAP, as it provides a
> better simple user experience.
>
>>
>>
>> Is this project proposing to add "opends" user and group ids to the
>> default Solaris config ?
>
> No, we're not proposing to add "opends" user and group ids.
> We plan on documenting how to run OpenDS as non root, which
> privileges are required and suggest "opends" ids.
>
>>
>>
>> Given that PSARC/2008/507 already proposed adding "openldap" user
>> and group but has not yet delivered I think it may be prudent to
>> change that case and this one to use an "ldap" user and group
>> rather than each having their own uid and gid.
>
> I would be fine with using an "ldap" user and group if it exists to
> the default Solaris config.
> I thought that PSARC/2008/507 gave up the idea of adding a specific
> user. If they change and deliver an "ldap" user, we will definitely
> leverage it.
>
>
> Ludovic.
>
>
>
>> This is similar to what has already been done for web servers, all
>> of them that we ship are defaulted to use the "webservd" user
>> account not each having their own.
>>
>>> The SMF method credentials would then be as below :
>>> <method_credential user='opends'
>>> group='opends'
>>>
>>> privileges='basic,net_privaddr,sys_resource,!proc_info,!
>>> file_link_any'
>>>
>>> limit_privileges='basic,net_privaddr,sys_resource,!proc_info,!
>>> file_link_any' />
>>
>> Looks good, modulo the above issue on the user/group names.
>>
>> --
>> Darren J Moffat
>
> Ludovic Poitou Sun Microsystems
> Inc.
> OpenDS Community Lead Directory Services
> http://blogs.sun.com/Ludo/ Grenoble Engineering Center -
> France
>
> Sun Microsystems requires the following notice:
> ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is
> prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
