[2246] | 1 | # b |
---|
[2066] | 2 | # To set up a new LDAP server: |
---|
[861] | 3 | |
---|
[2066] | 4 | # Temporarily move away the existing slapd-scripts folder |
---|
| 5 | mv /etc/dirsrv/slapd-scripts{,.bak} |
---|
[1645] | 6 | |
---|
[2066] | 7 | # Setup directory server |
---|
| 8 | /usr/sbin/setup-ds.pl |
---|
| 9 | # - Choose a typical install |
---|
| 10 | # - Tell it to use the fedora-ds user and group |
---|
| 11 | # - Directory server identifier: scripts |
---|
| 12 | # - Suffix: dc=scripts,dc=mit,dc=edu |
---|
| 13 | # - Input directory manager password |
---|
| 14 | # (this can be found in ~/.ldapvirc) |
---|
| 15 | |
---|
| 16 | # Move the schema back |
---|
[2246] | 17 | cp -R /etc/dirsrv/slapd-scripts.bak/* /etc/dirsrv/slapd-scripts |
---|
[2066] | 18 | rm -Rf /etc/dirsrv/slapd-scripts.bak |
---|
| 19 | |
---|
[2246] | 20 | # Check and make sure the sysconfig references the correct keytab |
---|
| 21 | svn revert /etc/sysconfig/dirsrv-scripts |
---|
| 22 | |
---|
[2066] | 23 | # Turn dirsrv off: |
---|
[2246] | 24 | systemctl stop dirsrv@scripts.service |
---|
[2066] | 25 | |
---|
| 26 | # Apply the following configuration changes. If you're editing |
---|
| 27 | # dse.ldif, you don't want dirsrv to be on, otherwise it will |
---|
| 28 | # overwrite your changes. [XXX: show how to do these changes with |
---|
| 29 | # dsconf, which is the "blessed" method, although it seems |
---|
| 30 | # dsconf only exists for Red Hat] |
---|
| 31 | |
---|
| 32 | vim /etc/dirsrv/slapd-scripts/dse.ldif |
---|
| 33 | <<<EOF |
---|
| 34 | |
---|
[1645] | 35 | # Inside cn=config. These changes definitely require a restart. |
---|
| 36 | nsslapd-ldapilisten: on |
---|
| 37 | |
---|
| 38 | # Add these blocks |
---|
| 39 | |
---|
| 40 | # mapname, mapping, sasl, config |
---|
| 41 | # This is the most liberal mapping you can have for SASL: you can |
---|
| 42 | # basically add authentication for any given GSSAPI mechanism by |
---|
| 43 | # explicitly creating the UID for that SASL string. |
---|
| 44 | dn: cn=mapname,cn=mapping,cn=sasl,cn=config |
---|
| 45 | objectClass: top |
---|
| 46 | objectClass: nsSaslMapping |
---|
| 47 | cn: mapname |
---|
| 48 | nsSaslMapRegexString: \(.*\) |
---|
| 49 | nsSaslMapBaseDNTemplate: uid=\1,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 50 | nsSaslMapFilterTemplate: (objectClass=posixAccount) |
---|
| 51 | |
---|
[2066] | 52 | EOF; |
---|
[861] | 53 | |
---|
[2246] | 54 | systemctl start dirsrv@scripts.service |
---|
[2066] | 55 | |
---|
| 56 | ldapvi -b cn=config |
---|
[2759] | 57 | # Add these indexes (6 of them): |
---|
[2066] | 58 | |
---|
| 59 | <<<EOF |
---|
| 60 | |
---|
[1473] | 61 | add cn=scriptsVhostName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
| 62 | objectClass: top |
---|
| 63 | objectClass: nsIndex |
---|
| 64 | cn: scriptsVhostName |
---|
| 65 | nsSystemIndex: false |
---|
| 66 | nsIndexType: eq |
---|
| 67 | nsIndexType: pres |
---|
[880] | 68 | |
---|
[1473] | 69 | add cn=scriptsVhostAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
| 70 | objectClass: top |
---|
| 71 | objectClass: nsIndex |
---|
| 72 | cn: scriptsVhostAlias |
---|
| 73 | nsSystemIndex: false |
---|
| 74 | nsIndexType: eq |
---|
| 75 | nsIndexType: pres |
---|
| 76 | |
---|
[1532] | 77 | add cn=scriptsVhostAccount, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
| 78 | objectClass: top |
---|
| 79 | objectClass: nsIndex |
---|
| 80 | cn: scriptsVhostAccount |
---|
| 81 | nsSystemIndex: false |
---|
| 82 | nsIndexType: eq |
---|
| 83 | nsIndexType: pres |
---|
| 84 | |
---|
[1473] | 85 | add cn=memberuid, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
| 86 | objectClass: top |
---|
| 87 | objectClass: nsIndex |
---|
| 88 | cn: memberuid |
---|
| 89 | nsSystemIndex: false |
---|
| 90 | nsIndexType: eq |
---|
| 91 | nsIndexType: pres |
---|
| 92 | |
---|
| 93 | add cn=uidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
| 94 | objectClass: top |
---|
| 95 | objectClass: nsIndex |
---|
| 96 | cn: uidnumber |
---|
| 97 | nsSystemIndex: false |
---|
| 98 | nsIndexType: eq |
---|
| 99 | nsIndexType: pres |
---|
| 100 | |
---|
| 101 | add cn=gidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config |
---|
| 102 | objectClass: top |
---|
| 103 | objectClass: nsIndex |
---|
| 104 | cn: gidnumber |
---|
| 105 | nsSystemIndex: false |
---|
| 106 | nsIndexType: eq |
---|
| 107 | nsIndexType: pres |
---|
| 108 | |
---|
[2066] | 109 | EOF; |
---|
| 110 | |
---|
[1473] | 111 | - Build the indexes for all the fields: |
---|
| 112 | |
---|
| 113 | /usr/lib64/dirsrv/slapd-scripts/db2index.pl -D "cn=Directory Manager" -j /etc/signup-ldap-pw -n userRoot |
---|
| 114 | |
---|
[1645] | 115 | (/etc/signup-ldap-pw is the LDAP root password, make sure it's |
---|
| 116 | chmodded correctly and chowned to signup. Also, make sure it doesn't |
---|
| 117 | have a trailing newline!) |
---|
| 118 | |
---|
[1473] | 119 | - Watch for the indexing operations to finish with this command: |
---|
| 120 | |
---|
| 121 | ldapsearch -x -y /etc/signup-ldap-pw -D 'cn=Directory Manager' -b cn=tasks,cn=config |
---|
| 122 | |
---|
[1645] | 123 | (look for nktaskstatus) |
---|
| 124 | |
---|
| 125 | - Set up replication. |
---|
| 126 | |
---|
| 127 | We used to tell people to go execute |
---|
| 128 | http://directory.fedoraproject.org/sources/contrib/mmr.pl manually |
---|
| 129 | (manually because that script assumes only two masters and we have |
---|
| 130 | every one of our servers set up as a master.) However, those |
---|
| 131 | instructions are inaccurate, because we use GSSAPI, not SSL and |
---|
| 132 | because the initializing procedure is actually prone to a race |
---|
| 133 | condition. Here are some better instructions. |
---|
| 134 | |
---|
| 135 | LDAP replication is based around producers and consumers. Producers |
---|
| 136 | push changes in LDAP to consumers: these arrangements are called |
---|
| 137 | "replication agreements" and the producer will hold a |
---|
| 138 | nsDS5ReplicationAgreement object that represents this commitment, |
---|
| 139 | as well as some extra configuration to say who consumers will accept |
---|
| 140 | replication data from (a nsDS5Replica). |
---|
| 141 | |
---|
| 142 | The procedure, at a high level, is this: |
---|
| 143 | |
---|
| 144 | 1. Pick an arbitrary existing master. The current server will |
---|
| 145 | be configured as a slave to that master. Initialize a changelog, |
---|
| 146 | then request a replication to populate our server with |
---|
| 147 | information. |
---|
| 148 | |
---|
| 149 | M1 <---> M2 ---> S |
---|
| 150 | |
---|
| 151 | 2. Configure the new server to be replicated back. |
---|
| 152 | |
---|
| 153 | M1 <---> M2 <---> S |
---|
| 154 | |
---|
[1983] | 155 | 3. Set up the rest of the replication agreements. |
---|
[1645] | 156 | |
---|
| 157 | M1 <---> M2 |
---|
| 158 | ^ ^ |
---|
| 159 | | | |
---|
| 160 | +--> S <--+ |
---|
| 161 | |
---|
[1983] | 162 | 4. Push a change from every existing server (to the new server), and |
---|
| 163 | then a change from the new server to (all) the existing servers. |
---|
| 164 | In addition to merely testing that replication works, this will |
---|
| 165 | set up the servers' changelogs properly. |
---|
| 166 | |
---|
[1986] | 167 | If this step is not completed before any server's LDAP server |
---|
| 168 | shuts down, then the replication agreements will fall apart the |
---|
| 169 | next time a change is made. You may wish to intentionally reboot |
---|
| 170 | any servers that look like they want to crash _before_ beginning |
---|
| 171 | this process. |
---|
[1983] | 172 | |
---|
[1645] | 173 | Here's how you do it. |
---|
| 174 | |
---|
[2066] | 175 | NOTE: There's this spiffy new tool MMR hammer which automates some of |
---|
| 176 | this process. Check the "MMR Hammer" sections to see how. Install it |
---|
| 177 | here: https://github.com/ezyang/mmr-hammer |
---|
| 178 | |
---|
[1986] | 179 | 0. Tell -c scripts not to go off and reboot servers until you're |
---|
| 180 | done (or to get any rebooting done with first). |
---|
[1983] | 181 | |
---|
[1645] | 182 | 1. Pull open the replication part of the database. It's fairly empty |
---|
| 183 | right now. |
---|
| 184 | |
---|
[1680] | 185 | ldapvi -b cn=\"dc=scripts,dc=mit,dc=edu\",cn=mapping\ tree,cn=config |
---|
[1645] | 186 | |
---|
| 187 | 2. Configure the server $SLAVE (this server) to accept $MASTER |
---|
| 188 | replications by adding the following LDAP entries: |
---|
| 189 | |
---|
| 190 | add cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
| 191 | objectClass: top |
---|
| 192 | objectClass: nsDS5Replica |
---|
| 193 | cn: replica |
---|
| 194 | nsDS5ReplicaId: $REPLICA_ID |
---|
| 195 | nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu |
---|
| 196 | nsDS5Flags: 1 |
---|
| 197 | nsDS5ReplicaBindDN: uid=ldap/bees-knees.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 198 | nsDS5ReplicaBindDN: uid=ldap/busy-beaver.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 199 | nsDS5ReplicaBindDN: uid=ldap/cats-whiskers.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 200 | nsDS5ReplicaBindDN: uid=ldap/pancake-bunny.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 201 | nsDS5ReplicaBindDN: uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 202 | nsDS5ReplicaBindDN: uid=ldap/real-mccoy.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[1677] | 203 | nsDS5ReplicaBindDN: uid=ldap/better-mousetrap.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 204 | nsDS5ReplicaBindDN: uid=ldap/old-faithful.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[1698] | 205 | nsDS5ReplicaBindDN: uid=ldap/shining-armor.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[2066] | 206 | nsDS5ReplicaBindDN: uid=ldap/golden-egg.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[2246] | 207 | nsDS5ReplicaBindDN: uid=ldap/miracle-cure.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 208 | nsDS5ReplicaBindDN: uid=ldap/lucky-star.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[1645] | 209 | nsds5ReplicaPurgeDelay: 604800 |
---|
| 210 | nsds5ReplicaLegacyConsumer: off |
---|
| 211 | nsDS5ReplicaType: 3 |
---|
| 212 | |
---|
| 213 | $REPLICA_ID is the scripts$N number (stella $HOSTNAME to find |
---|
| 214 | out.) You might wonder why we are binding to all servers; |
---|
| 215 | weren't we going to replicate from only one server? That is |
---|
| 216 | correct, however, simply binding won't mean we will receive |
---|
[1677] | 217 | updates; we have to setup the $MASTER to send data $SLAVE. |
---|
[1645] | 218 | |
---|
| 219 | 3. Although we allowed those uids to bind, that user information |
---|
| 220 | doesn't exist on $SLAVE yet. So you'll need to create the entry |
---|
| 221 | for just $MASTER. |
---|
| 222 | |
---|
[2066] | 223 | REMEMBER: You need to use FOO.mit.edu for the names! Otherwise you will get |
---|
| 224 | unauthorized errors. |
---|
| 225 | |
---|
[1645] | 226 | add uid=ldap/$MASTER,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 227 | uid: ldap/$MASTER |
---|
| 228 | objectClass: account |
---|
| 229 | objectClass: top |
---|
| 230 | |
---|
| 231 | 4. Though our $SLAVE will not be making changes to LDAP, we need to |
---|
| 232 | initialize the changelog because we intend to be able to do this |
---|
| 233 | later. |
---|
| 234 | |
---|
| 235 | add cn=changelog5,cn=config |
---|
| 236 | objectclass: top |
---|
| 237 | objectclass: extensibleObject |
---|
| 238 | cn: changelog5 |
---|
| 239 | nsslapd-changelogdir: /etc/dirsrv/slapd-scripts/changelogdb |
---|
| 240 | |
---|
| 241 | 5. Ok, now go to your $MASTER server that you picked (it should have |
---|
| 242 | been one of the hosts mentioned in nsDS5ReplicaBindDN) and tell |
---|
| 243 | it to replicate to $SLAVE. |
---|
| 244 | |
---|
[1680] | 245 | The last line runs the replication. This is perhaps the most |
---|
| 246 | risky step of the process; see below for help debugging problems. |
---|
| 247 | |
---|
[2068] | 248 | MMR Hammer: |
---|
| 249 | mmr-hammer -h $MASTER init agreements $SLAVE |
---|
| 250 | mmr-hammer -h $MASTER update $SLAVE # XXX pick a better name |
---|
[1677] | 251 | |
---|
[2066] | 252 | ldapvi -b cn=\"dc=scripts,dc=mit,dc=edu\",cn=mapping\ tree,cn=config |
---|
| 253 | |
---|
[1645] | 254 | add cn="GSSAPI Replication to $SLAVE", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
| 255 | objectClass: top |
---|
| 256 | objectClass: nsDS5ReplicationAgreement |
---|
| 257 | cn: "GSSAPI Replication to $SLAVE" |
---|
| 258 | cn: GSSAPI Replication to $SLAVE |
---|
| 259 | nsDS5ReplicaHost: $SLAVE |
---|
| 260 | nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu |
---|
| 261 | nsDS5ReplicaPort: 389 |
---|
| 262 | nsDS5ReplicaTransportInfo: LDAP |
---|
[1680] | 263 | nsDS5ReplicaBindDN: uid=ldap/$MASTER,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[1645] | 264 | nsDS5ReplicaBindMethod: SASL/GSSAPI |
---|
| 265 | nsDS5ReplicaUpdateSchedule: "0000-2359 0123456" |
---|
| 266 | nsDS5ReplicaTimeout: 120 |
---|
| 267 | nsDS5BeginReplicaRefresh: start |
---|
| 268 | |
---|
| 269 | 5. Check that the replication is running; the status will be stored |
---|
| 270 | in the object we've been mucking around with. |
---|
| 271 | |
---|
| 272 | If it fails with LDAP Error 49, check /var/log/dirsrv on $MASTER |
---|
| 273 | for more information. It might be because fedora-ds can't read |
---|
[2066] | 274 | /etc/dirsrv/keytab or because you setup the account on the SLAVE |
---|
| 275 | incorrectly. |
---|
[1645] | 276 | |
---|
| 277 | 6. Replicate in the other direction. On $MASTER, add $SLAVE |
---|
| 278 | as a nsDS5ReplicaBindDN in cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config |
---|
[2066] | 279 | Also, add an account for $SLAVE if it doesn't exist already. |
---|
[1645] | 280 | |
---|
| 281 | add uid=ldap/$SLAVE,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 282 | uid: ldap/$SLAVE |
---|
| 283 | objectClass: account |
---|
| 284 | objectClass: top |
---|
| 285 | |
---|
| 286 | On $SLAVE, |
---|
| 287 | |
---|
[2066] | 288 | MMR Hammer: mmr-hammer -h $SLAVE init agreements $MASTER |
---|
| 289 | |
---|
[1645] | 290 | add cn="GSSAPI Replication to $MASTER", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config |
---|
| 291 | objectClass: top |
---|
| 292 | objectClass: nsDS5ReplicationAgreement |
---|
| 293 | cn: "GSSAPI Replication to $MASTER" |
---|
| 294 | cn: GSSAPI Replication to $MASTER |
---|
| 295 | nsDS5ReplicaHost: $MASTER |
---|
| 296 | nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu |
---|
| 297 | nsDS5ReplicaPort: 389 |
---|
| 298 | nsDS5ReplicaTransportInfo: LDAP |
---|
| 299 | nsDS5ReplicaBindDN: uid=ldap/$SLAVE,ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 300 | nsDS5ReplicaBindMethod: SASL/GSSAPI |
---|
| 301 | nsDS5ReplicaUpdateSchedule: "0000-2359 0123456" |
---|
| 302 | nsDS5ReplicaTimeout: 120 |
---|
| 303 | |
---|
| 304 | If you get a really scary internal server error, that might mean you |
---|
| 305 | forgot to initialize the changelog. Remove the replication |
---|
| 306 | agreement (you'll need to turn off dirsrv), add the changelog, and |
---|
| 307 | then try again. |
---|
| 308 | |
---|
[1983] | 309 | 7. Repeat step 6 to complete the graph of replications (i.e., from |
---|
| 310 | every other server to the new server, and from the new server to |
---|
| 311 | every other server). |
---|
| 312 | |
---|
| 313 | Note the only difference between steps 5 and 6 is the lack of |
---|
| 314 | nsDS5ReplicaRefresh: start. That only needs to be done once, to the |
---|
| 315 | new server. |
---|
| 316 | |
---|
[2066] | 317 | With MMR hammer, that's something like: |
---|
| 318 | |
---|
| 319 | for i in $SERVER_NAMES; do mmr-hammer -h $i init agreements $SERVER_NAMES; done |
---|
| 320 | |
---|
[1983] | 321 | 8. If at this point you look at the new server's changelog with |
---|
| 322 | cl-dump (preferably /mit/scripts/admin/cl-dump.pl, to not prompt you |
---|
| 323 | for a password), you won't see the servers you added in step 7. So, |
---|
| 324 | from each of those servers, make a change to some record so it gets |
---|
| 325 | propagated to the new server, and then one from the new server so it |
---|
| 326 | gets propagated to all the existing servers' changelogs. This is |
---|
| 327 | also good for making sure the replication agreements actually work. |
---|
| 328 | |
---|
[2066] | 329 | With MMR hammer, that's something like: |
---|
| 330 | |
---|
| 331 | for i in $SERVER_NAMES; do mmr-hammer -h $i test; sleep 20; done |
---|
| 332 | |
---|
[1672] | 333 | Troubleshooting |
---|
| 334 | =============== |
---|
| 335 | |
---|
[1677] | 336 | LDAP multimaster replication can fail in a number of colorful ways; |
---|
| 337 | combine that with GSSAPI authentication and it goes exponential. |
---|
| 338 | |
---|
| 339 | If authentication is failing with LDAP error 49, check if: |
---|
| 340 | |
---|
| 341 | * /etc/dirsrv/keytab |
---|
| 342 | * fedora-ds is able to read /etc/dirsrv/keytab |
---|
| 343 | * /etc/hosts has not been modified by Network Manager (you |
---|
| 344 | /did/ uninstall it, right? Right?) |
---|
| 345 | |
---|
[1672] | 346 | If the failure is local to a single master, usually you can recover |
---|
| 347 | by asking another master to refresh that master with: |
---|
| 348 | |
---|
| 349 | nsDS5BeginReplicaRefresh: start |
---|
| 350 | |
---|
| 351 | In practice, we've also had problems with this technique. Some of them |
---|
| 352 | include: |
---|
| 353 | |
---|
| 354 | * Something like https://bugzilla.redhat.com/show_bug.cgi?id=547503 |
---|
| 355 | on Fedora 11 ns-slapd, where replication is turned off to do the |
---|
| 356 | replication, but then it wedges and you need to forcibly kill the |
---|
| 357 | process. |
---|
| 358 | |
---|
| 359 | * Failed LDAP authentication because another master attempted to do |
---|
| 360 | an incremental update. |
---|
| 361 | |
---|
| 362 | * Repropagation of the error because the corrupt master thinks it still |
---|
| 363 | should push updates. |
---|
| 364 | |
---|
| 365 | So the extremely safe method to bring up a crashed master is as follows: |
---|
| 366 | |
---|
| 367 | 1. Disable all incoming and outgoing replication agreements by editing |
---|
| 368 | /etc/dirsrv/slapd-scripts/dse.ldif. You'll need to munge: |
---|
| 369 | |
---|
| 370 | nsDS5ReplicaBindDN in cn=replica,cn=dc\3Dscripts\2Cdc\3Dmit\2Cdc\3Dedu,cn=mapping tree,cn=config |
---|
| 371 | |
---|
| 372 | and all of the push agreements. Deleting them outright works, but |
---|
| 373 | means you'll have to reconstruct all of the agreements from scratch. |
---|
| 374 | |
---|
| 375 | 2. Bring up the server. |
---|
| 376 | |
---|
| 377 | 3. Accept incoming replication data from a single server. |
---|
| 378 | |
---|
| 379 | 4. Initiate a full update from that server. |
---|
| 380 | |
---|
| 381 | 5. Finish setting up replication as described above. |
---|
| 382 | |
---|
| 383 | If your database gets extremely fucked, other servers may not be able |
---|
| 384 | to authenticate because your authentication information has gone missing. |
---|
| 385 | In that case, the minimal set of entries you need is: |
---|
| 386 | |
---|
| 387 | add dc=scripts,dc=mit,dc=edu |
---|
| 388 | objectClass: top |
---|
| 389 | objectClass: domain |
---|
| 390 | dc: scripts |
---|
| 391 | |
---|
| 392 | add ou=People,dc=scripts,dc=mit,dc=edu |
---|
| 393 | objectClass: top |
---|
| 394 | objectClass: organizationalunit |
---|
| 395 | ou: People |
---|
| 396 | |
---|
[1677] | 397 | add uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu |
---|
[1672] | 398 | objectClass: account |
---|
| 399 | objectClass: top |
---|
[1677] | 400 | uid: ldap/whole-enchilada.mit.edu |
---|