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"? 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. -- Oscar A. Valdez -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
