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