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. Is this project proposing to add "opends" user and group ids to the default Solaris config ? 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. 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
