Brian LaMere wrote:
seems to, yes (some values changed, but consistently):

# ldapsearch -LLL -h
<> -x -s base -b '' namingcontexts
namingcontexts: dc=briandomain,dc=com

However, when I go to the "oldserver" and look in the logs, I see this:

conn=1416 op=1 SRCH base="dc=brian,dc=internal" scope=0
filter="(objectClass=*)" attrs="namingContexts"

And this request came from newserver? I don't see where we would query namingContexts with this search base. Seems strange that something knew about the new basedn though.

Since I'm going from "dc=briandomain,dc=com" to "dc=brian,dc=internal"
  (mostly due to the forward and reverse lookups, which I don't want to
mess around with extensively for the actual domain) then looking for
namingContexts within that base won't work; I would like instead to just
grab everything from one base, and import it in to the new base.

Is it not working as you would expect it?  Or, is it just not possible
to do what I'm wanting?

Well, we want flexibility for sure, what you're asking for isn't unreasonable. Have you run the migration script and it failed or are you just worried that it isn't going to do the right thing?


Thanks :)

On Wed, Sep 22, 2010 at 12:44 PM, Rob Crittenden <
<>> wrote:

    Brian LaMere wrote:

        I know about --user-container and --group-container, but that's not
        sufficient; the domain is different, so I want to completely
        change the
        search base for migration.  Is this possible?


    It looks like it tries to auto-detect the remote search base using
    the equivalent of:

    ldapsearch -h remote_host -x -s base -b '' namingcontexts

    So for example, on my LDAP server it returns:

    namingcontexts: dc=example,dc=com

    Does this do the right thing for you?


Freeipa-users mailing list

Reply via email to