[deployment-guide/comm-rel: 158/727] updated 'Problems with NFS and NSCD' - BZ613096

[Jaromir Hradilek]

commit 8e161a2048466212b2cf5a8fef437107820b8bd3
Author: David O'Brien <davido at redhat.com>
Date:   Tue Jul 27 13:20:05 2010 +1000

    updated 'Problems with NFS and NSCD' - BZ613096

 en-US/SSSD.xml |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)
---
diff --git a/en-US/SSSD.xml b/en-US/SSSD.xml
index 369d282..ee52784 100644
--- a/en-US/SSSD.xml
+++ b/en-US/SSSD.xml
@@ -1289,6 +1289,22 @@ passwd: all authentication tokens updated successfully.
           </itemizedlist>
         </section>
 
+        <section><title>Problems with NFS and NSCD</title>
+          <para>
+            SSSD is not designed to be used with the <systemitem class="daemon">nscd</systemitem> daemon, and will likely generate warnings in the SSSD log files. Even though SSSD does not directly conflict with <systemitem class="daemon">nscd</systemitem>, the use of both at the same time can result in unexpected behavior (specifically with how long entries are being cached).
+          </para>
+          <para>
+            If you are using Network Manager to manage your network connections, it may take several minutes for the network interface to come up. During this time, various services will attempt to start. If these services start before the network is up (that is, the DNS servers cannot yet be reached) they will fail to identify the forward or reverse DNS entries they might need. These services will be reading an incorrect or possibly empty <filename>resolv.conf</filename> file. This file is typically only read once, and so any changes made to this file are not automatically applied.
+          </para>
+          <para>
+            This can result in the failure of some system services, and in particular can cause NFS locking to fail on the machine where the <systemitem class="daemon">nscd</systemitem> service is running, unless that service is manually restarted.
+          </para>
+          <para>
+            One method of working around this problem is to enable caching for <parameter>hosts</parameter> and <parameter>services</parameter> in the <filename>/etc/nscd.conf</filename> file, and to rely on the SSSD cache for the <parameter>passwd</parameter> and <parameter>group</parameter> entries. With <systemitem class="daemon">nscd</systemitem> answering <parameter>hosts</parameter> and <parameter>services</parameter> requests, these entries would have been cached and returned by <systemitem class="daemon">nscd</systemitem> during the boot process.
+
+          </para>
+          <note><para>Later versions of SSSD should negate any need for NSCD.</para></note>
+        </section>
       </section>
 
       <section