Can an LDAP server be it's own client?

Question

In short yes, why would you want to do this? Many reasons, but mine is to be able to use ldap on laptops running Solaris and have them log into the machine with ldap credentials off the network. When we plug them back onto the network, I have a master server send any new data via one-way replication. I will give 2 separate ways to accomplish this. One is, to put it bluntly, a dirty hack to get it working. The second is much more elegant and it's the one I have stressed tested to verify that it works.
Disclaimer: I have only used these methods on Solaris10 update 3 with Trusted Extensions using directory server 5.2 as well as the administration server. I have used a few different kinds of machines (all x86) and have not had a problem with it. I do not know if it will work on any other version or hardware. I haven't even looked at the source code, all assumptions made here are from observing the systems behavior while making minor changes.
Now, the reasons why normally you can't be your own client (at least as far as I can tell) is because of the way the system boots and the dependencies that the ldap/client service needs to start up. If you boot a machine that is it's own client and ldap/client runs before the directory server starts, of course it will fail. The system boots the services first, then legacy init scripts. Directory Server 5.2 uses init scripts. Correct me if I am wrong, but that is the only real hurdle in your way.
So the first way to get it 'working' (dirty hack) is to delay the ldap/client smf service from starting until the directory server is started. After you become a client of yourself (in this case the global zone) disable the ldap/client serrvice.
svcadm disable ldap/clientThen enable it temporarily with the -t option
svcadm enable -t ldap/clientWell if you were to reboot now it would not work because the service would not start at boot because it is set to be administratively down. Edit the S72directory script in /etc/rc2.d and after the start commands just add the svcadm enable -t ldap/client command and it will load right after directory server starts. Will this work? Yes, is it a clean way to do it? NO. I used this method just for testing the theory that the only reason I could not be my own client was because of the booting issue.
Now the best way that I can see to accomplish this is to create your own smf services for the directory server and admin server. That way all you have to do is add a dependency to the ldap/client xml file to wait until the new directory server service is started before it starts. So in /var/svc/manifest/site create a folder called ldap (I put this in site because I didn't want to run into any issues of patching). In /var/svc/manifest/site/ldap/ create two xml files named:
quick note: These are the first services I have created. There may be a much better way to make them. If you can re-code it better, please let me know so I can look at them. Also there is no restart command in here (actually I just noticed that) so adding one of those would be wise.
ds_admin.xml and directory_server.xml.
ds_admin.xml contains<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!--
     Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
     Use is subject to license terms.
     ident     "@(#)client.xml     1.4     04/12/09 SMI"
     NOTE:  This service manifest is editable; its contents will not
     be overwritten by package or patch operations, including
     operating system upgrade.
-->
<service_bundle type='manifest' name='SUNWdsadmin:dsadmin'>
<service
     name='site/ldap/ds_admin'
     type='service'
     version='1'>
     <create_default_instance enabled='false' />
     <single_instance />
     <dependency
         name='fs'
         grouping='require_all'
         restart_on='none'
         type='service'>
          <service_fmri value='svc:/system/filesystem/minimal' />
     </dependency>
     <dependency
         name='net'
         grouping='require_all'
         restart_on='none'
         type='service'>
          <service_fmri value='svc:/network/initial' />
     </dependency>
     <exec_method
         type='method'
         name='start'
         exec='/lib/svc/method/ds_admin start'
         timeout_seconds='120' >
          <method_context>
               <method_credential user='root' group='sys' />
          </method_context>
     </exec_method>
     <exec_method
         type='method'
         name='stop'
         exec='/lib/svc/method/ds_admin stop'
         timeout_seconds='60' >
          <method_context>
               <method_credential user='root' group='sys' />
          </method_context>
     </exec_method>
     <stability value='Unstable' />
     <template>
          <common_name>
               <loctext xml:lang='C'>
               LDAP Admin server      
               </loctext>
          </common_name>
          <description>
               <loctext xml:lang='C'>
LDAP admin server
Information Service lookups
               </loctext>
          </description>
     </template>
</service>
</service_bundle>and directory_server.xml contains:
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!--
     Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
     Use is subject to license terms.
     ident     "@(#)client.xml     1.4     04/12/09 SMI"
     NOTE:  This service manifest is editable; its contents will not
     be overwritten by package or patch operations, including
     operating system upgrade.
-->
<service_bundle type='manifest' name='SUNWds:ds'>
<service
     name='site/ldap/directory_server'
     type='service'
     version='1'>
     <create_default_instance enabled='false' />
     <single_instance />
     <dependency
         name='usr'
         grouping='require_all'
         restart_on='none'
         type='service'>
          <service_fmri value='svc:/system/filesystem/minimal' />
     </dependency>
     <dependency
         name='net'
         grouping='require_all'
         restart_on='none'
         type='service'>
          <service_fmri value='svc:/network/initial' />
     </dependency>
  <dependency
            name='ds_admin'
            grouping='require_all'
            restart_on='none'
            type='service'>
                <service_fmri
                    value='svc:/site/ldap/ds_admin' />
     </dependency>
     <exec_method
         type='method'
         name='start'
         exec='/lib/svc/method/directory_server start'
         timeout_seconds='120' >
          <method_context>
               <method_credential user='root' group='sys' />
          </method_context>
     </exec_method>
     <exec_method
         type='method'
         name='stop'
         exec='/lib/svc/method/directory_server stop'
         timeout_seconds='60' >
          <method_context>
               <method_credential user='root' group='sys' />
          </method_context>
     </exec_method>
     <stability value='Unstable' />
     <template>
          <common_name>
               <loctext xml:lang='C'>
               LDAP directory server      
               </loctext>
          </common_name>
          <description>
               <loctext xml:lang='C'>
LDAP directory server
Information Service lookups
               </loctext>
          </description>
     </template>
</service>
</service_bundle>Now the start/stop scripts will be located in /lib/svc/method and are as followed:
ds_admin
#!/sbin/sh
case "$1" in
     start)
          /usr/sbin/directoryserver start-admin
     stop)
          /usr/sbin/directoryserver stop-admin
          echo "Usage: $0 { start | stop }"
          exit 1
esac
exit 0simple yes.
directory_server
#!/sbin/sh
HOST_NAME=`hostname`
SERVER_ROOT=/var/opt/mps/serverroot
DIRECTORY_SERVER_INSTANCE=slapd-${HOST_NAME}
case "$1" in
     start)
          ${SERVER_ROOT}/${DIRECTORY_SERVER_INSTANCE}/start-slapd
     stop)
          ${SERVER_ROOT}/${DIRECTORY_SERVER_INSTANCE}/stop-slapd
          echo "Usage: $0 { start | stop }"
          exit 1
esac
exit 0The only thing left to do is modify the ldap/client smf file to wait until the directory server starts before it loads.
So edit /var/svc/manifest/network/ldap/client.xml and right before the dependency for for /var/ldap/ldap_client_file add this
<dependency
            name='directory_server'
            grouping='require_all'
            restart_on='none'
            type='service'>
                <service_fmri
                        value='svc:/site/ldap/directory_server' />
        </dependency>
Any changes made to the /ldap/client xml file must be made after ALL zones have been installed. If this file is copied to a zone it will never work as the directory_server service is not loaded in the zones.
Now what? You must remove the legacy init scripts in /etc/rc2.d. Those would be S72directory and S73mpsadm. No need to keep them around, alternatively, you can just change the capital 'S' to lower case and they want start.
You can now either use svccfg to validate and import the new services or you can reboot. Typically, I reboot and use the '-m verbose' option on boot to watch the services for any errors. I haven't had any lately but on different systems I always watch to see if it behaves different.
That's it. I have rebooted all the machines many, many times without error. This of course does not address loading the directory server or adding users, tnrhdb file, etc... We have scripted most of loading out and once we get some error correction coded in I will post them.
Also, if you find any errors or even a better way to accomplish this, please post it.

Answer 1

This restriction is only in terms of implementing the Solaris support for LDAP as a naming service. If the Solaris OS is configured to use LDAP as a naming service, it can't use a LDAP server running on the same host.
The reason is that the LDAP server makes naming service calls before it gets fully started up. If the OS wants to use the LDAP server for the naming service, then a deadlock happens, where the LDAP server's gethostbyname() call can't complete because the LDAP server isn't up.
It is possible to configure the Solaris naming resolution to avoid this problem. I've got a system set up this way myself. Regardless, the official support channels won't support a system set up this way, so if you do this you do it at your own risk.