1 | To set up a new LDAP server: |
---|
2 | |
---|
3 | - Install the RPM 389-ds-base with yum |
---|
4 | root# yum install -y 389-ds-base |
---|
5 | - We want to run the directory server as its own user, so create fedora-ds |
---|
6 | root# env NSS_NONLOCAL_IGNORE=1 useradd -r -d /var/lib/dirsrv fedora-ds |
---|
7 | - root# yum install -y policycoreutils-python |
---|
8 | - Temporarily move away the existing slapd-scripts folder |
---|
9 | root# mv /etc/dirsrv/slapd-scripts{,.bak} |
---|
10 | - root# /usr/sbin/setup-ds.pl |
---|
11 | - Choose a typical install |
---|
12 | - Tell it to use the fedora-ds user and group |
---|
13 | - Directory server identifier: scripts |
---|
14 | Needed to remove this from the config file first |
---|
15 | - Suffix: dc=scripts,dc=mit,dc=edu |
---|
16 | - Input directory manager password |
---|
17 | (this can be found in ~/.ldapvirc) |
---|
18 | - Move the schema back |
---|
19 | root# cp -R /etc/dirsrv/slapd-scripts.bak/{.svn,*} /etc/dirsrv/slapd-scripts |
---|
20 | root# rm -Rf /etc/dirsrv/slapd-scripts.bak |
---|
21 | - yum install ldapvi |
---|
22 | - Check if dirsrv starts: /sbin/service dirsrv start |
---|
23 | then turn it back off: service dirsrv stop |
---|
24 | - Apply the following configuration changes. If you're editing |
---|
25 | dse.ldif, you don't want dirsrv to be on, otherwise it will |
---|
26 | overwrite your changes. [XXX: show how to do these changes with |
---|
27 | dsconf, which is the "blessed" method] |
---|
28 | |
---|
29 | # Inside cn=config. These changes definitely require a restart. |
---|
30 | nsslapd-ldapifilepath: /var/run/dirsrv/slapd-scripts.socket |
---|
31 | nsslapd-ldapilisten: on |
---|
32 | |
---|
33 | # Add these blocks |
---|
34 | |
---|
35 | # mapname, mapping, sasl, config |
---|
36 | # This is the most liberal mapping you can have for SASL: you can |
---|
37 | # basically add authentication for any given GSSAPI mechanism by |
---|
38 | # explicitly creating the UID for that SASL string. |
---|
39 | dn: cn=mapname,cn=mapping,cn=sasl,cn=config |
---|
40 | objectClass: top |
---|
41 | objectClass: nsSaslMapping |
---|
42 | cn: mapname |
---|
43 | nsSaslMapRegexString: \(.*\) |
---|
44 | nsSaslMapBaseDNTemplate: uid=\1,ou=People,dc=scripts,dc=mit,dc=edu |
---|
45 | nsSaslMapFilterTemplate: (objectClass=posixAccount) |
---|
46 | |
---|
47 | - Put LDAP keytab (ldap/hostname.mit.edu) in /etc/dirsrv/keytab. Make |
---|
48 | sure you chown/chgrp it to be readable by fedora-ds |
---|
49 | - Uncomment and modify in /etc/sysconfig/dirsrv: KRB5_KTNAME=/etc/dirsrv/keytab ; export KRB5_KTNAME |
---|
50 | - chown fedora-ds:fedora-ds /var/run/dirsrv |
---|
51 | - chmod 755 /var/run/dirsrv |
---|
52 | - /sbin/service dirsrv start |
---|
53 | - Use ldapvi -b cn=config to add these indexes (8 of them): |
---|
54 | |
---|
55 | add cn=apacheServerName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
56 | objectClass: top |
---|
57 | objectClass: nsIndex |
---|
58 | cn: apacheServerName |
---|
59 | nsSystemIndex: false |
---|
60 | nsIndexType: eq |
---|
61 | nsIndexType: pres |
---|
62 | |
---|
63 | add cn=apacheServerAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
64 | objectClass: top |
---|
65 | objectClass: nsIndex |
---|
66 | cn: apacheServerAlias |
---|
67 | nsSystemIndex: false |
---|
68 | nsIndexType: eq |
---|
69 | nsIndexType: pres |
---|
70 | |
---|
71 | add cn=scriptsVhostName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
72 | objectClass: top |
---|
73 | objectClass: nsIndex |
---|
74 | cn: scriptsVhostName |
---|
75 | nsSystemIndex: false |
---|
76 | nsIndexType: eq |
---|
77 | nsIndexType: pres |
---|
78 | |
---|
79 | add cn=scriptsVhostAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
80 | objectClass: top |
---|
81 | objectClass: nsIndex |
---|
82 | cn: scriptsVhostAlias |
---|
83 | nsSystemIndex: false |
---|
84 | nsIndexType: eq |
---|
85 | nsIndexType: pres |
---|
86 | |
---|
87 | add cn=scriptsVhostAccount, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
88 | objectClass: top |
---|
89 | objectClass: nsIndex |
---|
90 | cn: scriptsVhostAccount |
---|
91 | nsSystemIndex: false |
---|
92 | nsIndexType: eq |
---|
93 | nsIndexType: pres |
---|
94 | |
---|
95 | add cn=memberuid, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
96 | objectClass: top |
---|
97 | objectClass: nsIndex |
---|
98 | cn: memberuid |
---|
99 | nsSystemIndex: false |
---|
100 | nsIndexType: eq |
---|
101 | nsIndexType: pres |
---|
102 | |
---|
103 | add cn=uidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
104 | objectClass: top |
---|
105 | objectClass: nsIndex |
---|
106 | cn: uidnumber |
---|
107 | nsSystemIndex: false |
---|
108 | nsIndexType: eq |
---|
109 | nsIndexType: pres |
---|
110 | |
---|
111 | add cn=gidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
112 | objectClass: top |
---|
113 | objectClass: nsIndex |
---|
114 | cn: gidnumber |
---|
115 | nsSystemIndex: false |
---|
116 | nsIndexType: eq |
---|
117 | nsIndexType: pres |
---|
118 | |
---|
119 | - Build the indexes for all the fields: |
---|
120 | |
---|
121 | /usr/lib64/dirsrv/slapd-scripts/db2index.pl -D "cn=Directory Manager" -j /etc/signup-ldap-pw -n userRoot |
---|
122 | |
---|
123 | (/etc/signup-ldap-pw is the LDAP root password, make sure it's |
---|
124 | chmodded correctly and chowned to signup. Also, make sure it doesn't |
---|
125 | have a trailing newline!) |
---|
126 | |
---|
127 | - Watch for the indexing operations to finish with this command: |
---|
128 | |
---|
129 | ldapsearch -x -y /etc/signup-ldap-pw -D 'cn=Directory Manager' -b cn=tasks,cn=config |
---|
130 | |
---|
131 | (look for nktaskstatus) |
---|
132 | |
---|
133 | - Set up replication. |
---|
134 | |
---|
135 | We used to tell people to go execute |
---|
136 | http://directory.fedoraproject.org/sources/contrib/mmr.pl manually |
---|
137 | (manually because that script assumes only two masters and we have |
---|
138 | every one of our servers set up as a master.) However, those |
---|
139 | instructions are inaccurate, because we use GSSAPI, not SSL and |
---|
140 | because the initializing procedure is actually prone to a race |
---|
141 | condition. Here are some better instructions. |
---|
142 | |
---|
143 | LDAP replication is based around producers and consumers. Producers |
---|
144 | push changes in LDAP to consumers: these arrangements are called |
---|
145 | "replication agreements" and the producer will hold a |
---|
146 | nsDS5ReplicationAgreement object that represents this commitment, |
---|
147 | as well as some extra configuration to say who consumers will accept |
---|
148 | replication data from (a nsDS5Replica). |
---|
149 | |
---|
150 | The procedure, at a high level, is this: |
---|
151 | |
---|
152 | 1. Pick an arbitrary existing master. The current server will |
---|
153 | be configured as a slave to that master. Initialize a changelog, |
---|
154 | then request a replication to populate our server with |
---|
155 | information. |
---|
156 | |
---|
157 | M1 <---> M2 ---> S |
---|
158 | |
---|
159 | 2. Configure the new server to be replicated back. |
---|
160 | |
---|
161 | M1 <---> M2 <---> S |
---|
162 | |
---|
163 | 3. Set up the rest of the replication agreements at your leisure. |
---|
164 | |
---|
165 | M1 <---> M2 |
---|
166 | ^ ^ |
---|
167 | | | |
---|
168 | +--> S <--+ |
---|
169 | |
---|
170 | Here's how you do it. |
---|
171 | |
---|
172 | 1. Pull open the replication part of the database. It's fairly empty |
---|
173 | right now. |
---|
174 | |
---|
175 | ldapvi -b cn=\"dc=scripts,dc=mit,dc=edu\",cn=mapping\ tree,cn=config |
---|
176 | |
---|
177 | 2. Configure the server $SLAVE (this server) to accept $MASTER |
---|
178 | replications by adding the following LDAP entries: |
---|
179 | |
---|
180 | add cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
181 | objectClass: top |
---|
182 | objectClass: nsDS5Replica |
---|
183 | cn: replica |
---|
184 | nsDS5ReplicaId: $REPLICA_ID |
---|
185 | nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu |
---|
186 | nsDS5Flags: 1 |
---|
187 | nsDS5ReplicaBindDN: uid=ldap/bees-knees.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
188 | nsDS5ReplicaBindDN: uid=ldap/busy-beaver.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
189 | nsDS5ReplicaBindDN: uid=ldap/cats-whiskers.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
190 | nsDS5ReplicaBindDN: uid=ldap/pancake-bunny.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
191 | nsDS5ReplicaBindDN: uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
192 | nsDS5ReplicaBindDN: uid=ldap/real-mccoy.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
193 | nsDS5ReplicaBindDN: uid=ldap/better-mousetrap.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
194 | nsDS5ReplicaBindDN: uid=ldap/old-faithful.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
195 | # ADD SERVERS HERE AS YOU ADD NEW SERVERS |
---|
196 | nsds5ReplicaPurgeDelay: 604800 |
---|
197 | nsds5ReplicaLegacyConsumer: off |
---|
198 | nsDS5ReplicaType: 3 |
---|
199 | |
---|
200 | $REPLICA_ID is the scripts$N number (stella $HOSTNAME to find |
---|
201 | out.) You might wonder why we are binding to all servers; |
---|
202 | weren't we going to replicate from only one server? That is |
---|
203 | correct, however, simply binding won't mean we will receive |
---|
204 | updates; we have to setup the $MASTER to send data $SLAVE. |
---|
205 | |
---|
206 | 3. Although we allowed those uids to bind, that user information |
---|
207 | doesn't exist on $SLAVE yet. So you'll need to create the entry |
---|
208 | for just $MASTER. |
---|
209 | |
---|
210 | add uid=ldap/$MASTER,ou=People,dc=scripts,dc=mit,dc=edu |
---|
211 | uid: ldap/$MASTER |
---|
212 | objectClass: account |
---|
213 | objectClass: top |
---|
214 | |
---|
215 | 4. Though our $SLAVE will not be making changes to LDAP, we need to |
---|
216 | initialize the changelog because we intend to be able to do this |
---|
217 | later. |
---|
218 | |
---|
219 | add cn=changelog5,cn=config |
---|
220 | objectclass: top |
---|
221 | objectclass: extensibleObject |
---|
222 | cn: changelog5 |
---|
223 | nsslapd-changelogdir: /etc/dirsrv/slapd-scripts/changelogdb |
---|
224 | |
---|
225 | 5. Ok, now go to your $MASTER server that you picked (it should have |
---|
226 | been one of the hosts mentioned in nsDS5ReplicaBindDN) and tell |
---|
227 | it to replicate to $SLAVE. |
---|
228 | |
---|
229 | add cn="GSSAPI Replication to $SLAVE", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
230 | objectClass: top |
---|
231 | objectClass: nsDS5ReplicationAgreement |
---|
232 | cn: "GSSAPI Replication to $SLAVE" |
---|
233 | cn: GSSAPI Replication to $SLAVE |
---|
234 | nsDS5ReplicaHost: $SLAVE |
---|
235 | nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu |
---|
236 | nsDS5ReplicaPort: 389 |
---|
237 | nsDS5ReplicaTransportInfo: LDAP |
---|
238 | nsDS5ReplicaBindDN: |
---|
239 | uid=ldap/$MASTER,ou=People,dc=scripts,dc=mit,dc=edu |
---|
240 | nsDS5ReplicaBindMethod: SASL/GSSAPI |
---|
241 | nsDS5ReplicaUpdateSchedule: "0000-2359 0123456" |
---|
242 | nsDS5ReplicaTimeout: 120 |
---|
243 | |
---|
244 | 4. Reboot the server `service dirsrv restart`, then run the |
---|
245 | replication. (Don't fold this into the previous step! You might |
---|
246 | nuke your database!) |
---|
247 | |
---|
248 | # under cn="GSSAPI Replication to $SLAVE", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
249 | nsDS5BeginReplicaRefresh: start |
---|
250 | |
---|
251 | 5. Check that the replication is running; the status will be stored |
---|
252 | in the object we've been mucking around with. |
---|
253 | |
---|
254 | If it fails with LDAP Error 49, check /var/log/dirsrv on $MASTER |
---|
255 | for more information. It might be because fedora-ds can't read |
---|
256 | /etc/dirsrv/keytab |
---|
257 | |
---|
258 | 6. Replicate in the other direction. On $MASTER, add $SLAVE |
---|
259 | as a nsDS5ReplicaBindDN in cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config |
---|
260 | Also, add an account for $SLAVE |
---|
261 | |
---|
262 | add uid=ldap/$SLAVE,ou=People,dc=scripts,dc=mit,dc=edu |
---|
263 | uid: ldap/$SLAVE |
---|
264 | objectClass: account |
---|
265 | objectClass: top |
---|
266 | |
---|
267 | On $SLAVE, |
---|
268 | |
---|
269 | add cn="GSSAPI Replication to $MASTER", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
270 | objectClass: top |
---|
271 | objectClass: nsDS5ReplicationAgreement |
---|
272 | cn: "GSSAPI Replication to $MASTER" |
---|
273 | cn: GSSAPI Replication to $MASTER |
---|
274 | nsDS5ReplicaHost: $MASTER |
---|
275 | nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu |
---|
276 | nsDS5ReplicaPort: 389 |
---|
277 | nsDS5ReplicaTransportInfo: LDAP |
---|
278 | nsDS5ReplicaBindDN: uid=ldap/$SLAVE,ou=People,dc=scripts,dc=mit,dc=edu |
---|
279 | nsDS5ReplicaBindMethod: SASL/GSSAPI |
---|
280 | nsDS5ReplicaUpdateSchedule: "0000-2359 0123456" |
---|
281 | nsDS5ReplicaTimeout: 120 |
---|
282 | |
---|
283 | If you get a really scary internal server error, that might mean you |
---|
284 | forgot to initialize the changelog. Remove the replication |
---|
285 | agreement (you'll need to turn off dirsrv), add the changelog, and |
---|
286 | then try again. |
---|
287 | |
---|
288 | Troubleshooting |
---|
289 | =============== |
---|
290 | |
---|
291 | LDAP multimaster replication can fail in a number of colorful ways. |
---|
292 | If the failure is local to a single master, usually you can recover |
---|
293 | by asking another master to refresh that master with: |
---|
294 | |
---|
295 | nsDS5BeginReplicaRefresh: start |
---|
296 | |
---|
297 | In practice, we've also had problems with this technique. Some of them |
---|
298 | include: |
---|
299 | |
---|
300 | * Something like https://bugzilla.redhat.com/show_bug.cgi?id=547503 |
---|
301 | on Fedora 11 ns-slapd, where replication is turned off to do the |
---|
302 | replication, but then it wedges and you need to forcibly kill the |
---|
303 | process. |
---|
304 | |
---|
305 | * Failed LDAP authentication because another master attempted to do |
---|
306 | an incremental update. |
---|
307 | |
---|
308 | * Repropagation of the error because the corrupt master thinks it still |
---|
309 | should push updates. |
---|
310 | |
---|
311 | So the extremely safe method to bring up a crashed master is as follows: |
---|
312 | |
---|
313 | 1. Disable all incoming and outgoing replication agreements by editing |
---|
314 | /etc/dirsrv/slapd-scripts/dse.ldif. You'll need to munge: |
---|
315 | |
---|
316 | nsDS5ReplicaBindDN in cn=replica,cn=dc\3Dscripts\2Cdc\3Dmit\2Cdc\3Dedu,cn=mapping tree,cn=config |
---|
317 | |
---|
318 | and all of the push agreements. Deleting them outright works, but |
---|
319 | means you'll have to reconstruct all of the agreements from scratch. |
---|
320 | |
---|
321 | 2. Bring up the server. |
---|
322 | |
---|
323 | 3. Accept incoming replication data from a single server. |
---|
324 | |
---|
325 | 4. Initiate a full update from that server. |
---|
326 | |
---|
327 | 5. Finish setting up replication as described above. |
---|
328 | |
---|
329 | If your database gets extremely fucked, other servers may not be able |
---|
330 | to authenticate because your authentication information has gone missing. |
---|
331 | In that case, the minimal set of entries you need is: |
---|
332 | |
---|
333 | add dc=scripts,dc=mit,dc=edu |
---|
334 | objectClass: top |
---|
335 | objectClass: domain |
---|
336 | dc: scripts |
---|
337 | |
---|
338 | add ou=People,dc=scripts,dc=mit,dc=edu |
---|
339 | objectClass: top |
---|
340 | objectClass: organizationalunit |
---|
341 | ou: People |
---|
342 | |
---|
343 | add uid=ldap/real-mccoy.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
344 | objectClass: account |
---|
345 | objectClass: top |
---|
346 | uid: ldap/real-mccoy.mit.edu |
---|