Changeset 1677 for branches/fc13-dev/server/doc/install-ldap

Timestamp:

Sep 27, 2010, 4:45:14 PM (14 years ago)

Author:

ezyang

Message:

More updates.

File:

• branches/fc13-dev/server/doc/install-ldap (modified) (9 diffs)

branches/fc13-dev/server/doc/install-ldap

@@ -6 +6 @@
   root# env NSS_NONLOCAL_IGNORE=1 useradd -r -d /var/lib/dirsrv fedora-ds
 - root# yum install -y policycoreutils-python
+- Temporarily move away the existing slapd-scripts folder
+  root# mv /etc/dirsrv/slapd-scripts{,.bak}
 - root# /usr/sbin/setup-ds.pl
     - Choose a typical install
@@ -14 +16 @@
     - Input directory manager password
       (this can be found in  ~/.ldapvirc)
-        [XXX: Got error: sh: semanage: command not found; turns out this is in
-        policycoreutils-python.  Don't know if this will cause problems.]
+- Move the schema back
+  root# cp -R /etc/dirsrv/slapd-scripts.bak/{.svn,*} /etc/dirsrv/slapd-scripts
+  root# rm -Rf /etc/dirsrv/slapd-scripts.bak
 - yum install ldapvi
 - Check if dirsrv starts: /sbin/service dirsrv start
+  then turn it back off: service dirsrv stop
 - Apply the following configuration changes.  If you're editing
   dse.ldif, you don't want dirsrv to be on, otherwise it will
@@ -41 +45 @@
 nsSaslMapFilterTemplate: (objectClass=posixAccount)
 
-- /sbin/service dirsrv stop
-- Add the scripts schemas to /var/lib/dirsrv/slapd-scripts [XXX: I don't
-  know how to do this, but placing them in /etc might be sufficient?]
 - Put LDAP keytab (ldap/hostname.mit.edu) in /etc/dirsrv/keytab.  Make
   sure you chown/chgrp it to be readable by fedora-ds
 - Uncomment and modify in /etc/sysconfig/dirsrv: KRB5_KTNAME=/etc/dirsrv/keytab ; export KRB5_KTNAME
-- mkdir -p /var/run/dirsrv
 - chown fedora-ds:fedora-ds /var/run/dirsrv
 - chmod 755 /var/run/dirsrv
-- /sbin/service dirsrv restart
-- Use ldapvi -b cn=config to add these indexes:
+- /sbin/service dirsrv start
+- Use ldapvi -b cn=config to add these indexes (8 of them):
 
 add cn=apacheServerName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config
@@ -191 +191 @@
 nsDS5ReplicaBindDN: uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu
 nsDS5ReplicaBindDN: uid=ldap/real-mccoy.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu
+nsDS5ReplicaBindDN: uid=ldap/better-mousetrap.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu
+nsDS5ReplicaBindDN: uid=ldap/old-faithful.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu
 # ADD SERVERS HERE AS YOU ADD NEW SERVERS
 nsds5ReplicaPurgeDelay: 604800
@@ -200 +202 @@
         weren't we going to replicate from only one server?  That is
         correct, however, simply binding won't mean we will receive
-        updates; we have to setup the $MASTER to send data $SALVE.
+        updates; we have to setup the $MASTER to send data $SLAVE.
 
     3. Although we allowed those uids to bind, that user information
@@ -224 +226 @@
        been one of the hosts mentioned in nsDS5ReplicaBindDN) and tell
        it to replicate to $SLAVE.
+
+       WARNING: There is a known bug doing full updates from 1.2.6 to
+       1.2.6, see https://bugzilla.redhat.com/show_bug.cgi?id=637852
 
 add cn="GSSAPI Replication to $SLAVE", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config
@@ -240 +245 @@
 nsDS5ReplicaTimeout: 120
 
-    4. Run the replication. (you could fold this into the previous step)
+    4. Run the replication.  This is perhaps the most risky step of
+    the process; see below for help debugging problems.
 
 # under cn="GSSAPI Replication to $SLAVE", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config
@@ -285 +291 @@
 ===============
 
-LDAP multimaster replication can fail in a number of colorful ways.
+LDAP multimaster replication can fail in a number of colorful ways;
+combine that with GSSAPI authentication and it goes exponential.
+
+If authentication is failing with LDAP error 49, check if:
+
+    * /etc/dirsrv/keytab
+    * fedora-ds is able to read /etc/dirsrv/keytab
+    * /etc/hosts has not been modified by Network Manager (you
+      /did/ uninstall it, right? Right?)
+
 If the failure is local to a single master, usually you can recover
 by asking another master to refresh that master with:
@@ -337 +352 @@
 ou: People
 
-add uid=ldap/real-mccoy.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu
+add uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu
 objectClass: account
 objectClass: top
-uid: ldap/real-mccoy.mit.edu
+uid: ldap/whole-enchilada.mit.edu