Oscar A. Valdez wrote: >El vie, 02-02-2007 a las 12:36 -0800, Noriko Hosoi escribi?: > > >>Thanks for the output. It looks the Admin Server is thinking the rdn is >>"ou=duraflex.com.sv" and the Directory Server "ou=duraflex". It may >>work if you change one side to match the other, but it could cause some >>other mismatches. The safest way to recover should be dump your >>contents into an LDIF file (you may need to store schema files somewhere >>in the safe place if you added or modified.) Install a fresh FDS and >>import the LDIF file onto the FDS... >> >> > >I'm willing to try changing the Admin Server over to "ou=duraflex". How >can I do that? > > > >>>I suspect this may have happened when I imported a backed up database >>>from a crashed DS into the new server. The backup might have contained a >>>different RDN than the fresh install. >>> >>>How can I make sure, and if so, how should I fix it? >>> >>> >>That'd explain the current status... "A backed up database" is made by >>db2bak or db2ldif? If it is from db2bak, it contains the entire >>database including the config data (o=netscaperoot tree). The data is >>not supposed to restore onto the other DS instance (unless everything is >>identical). Again, the safest way is to run db2ldif against the backend >>which contains your entries (e.g., userRoot) to create an LDIF file. >>Install a new server, then import the LDIF file by ldif2db. >> >> > >The backup was created and restored with db2bak. Would this imply that >the backup contained the Admin Server's ou=duraflex.com.sv" and that it >was imported into a Directory Server with "ou=duraflex"? > > That's most likely what happened to your server... >Again, as I said, I'm willing to try changing the Admin Server over to >"ou=duraflex". I'll appreciate your pointers on how to do it. > > Well, I'd try the following, but since we haven't tested it, we don't know how it ends up... 1. shutdown the admin server and console 2. go to your <server_root>/admin-serv/config 3. replace "ou=duraflex.com.sv" with "ou=duraflex" in all the files in the directory 4. restart the admin server, then console 5. login on the console Hope it goes fine... --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070202/867f81a9/attachment.bin