[Fedora-directory-users] Admin console's default view is empty
Oscar A. Valdez
oscar.valdez at duraflex.com.sv
Fri Feb 2 21:15:00 UTC 2007
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
More information about the 389-users
mailing list