freeipa

#9828 ipa-migrate tool is renaming host records & host info in automount information
Closed: fixed by rjeffman. Opened by jyoung.

Closed: fixed
Reopen Issue

Issue

When using ipa-migrate to move ipa data from one domain to another. In this example we are migrating from:
example.com to prod.example.com

The ipa-migrate is:

  • Renaming computer/host records to new IDM domain
    server1.example.com gets renamed to server1.prod.example.com

    * This is an issue as you loose host group associations trying to fix this.
Though also clients are not going to migrate to prod.example.com they
will still be on example.com.

  • Automount rules get messed up as hosts in mounting infromation get messed up as well.
    storage1.example.com gets switched to storage1.prod.example.com

Steps to Reproduce

  1. From server you are migrating to (prod.example.com)
  2. kinit admin
  3. Run
    ipa-migrate \
    prod-mode \
    -F \
    --skip-config \
    --skip-schema \
    --cacertfile /tmp/example.idm-crt \
    idm1.example.com

Expected behavior

Hosts records and automount infromation should not be renamed during migration.

Looking at code

The issue appears to be in ipaserver/install/ipa_migrate.py in fuction convert_value()
and lines:
# Replace domain
if self.remote_domain in val and self.local_domain not in val:
val = val.replace(self.remote_domain, self.local_domain)

In limited testing removing this works, though has unintended concequences and apparnetly breaks other things.

What could happen here is passing down the "entry_type" and then a conditional statment that if entry_type is "computer" to not rename it.

Sorry, I would have sworn I had a discussion on this, maybe it was done outside the ticket.

So the use case is renaming the IPA domain (and realm) but keeping the clients in the original domain?

Can you expand on how things get messed up related to grouping and automember? Is it that trying to undo the renaming results in data loss or that data is lost during the migration?

Renaming only parts of the infra is not a scenario we imagined so it is not handled. I'm not even sure how one would specify which hosts would move and which would stay.

Correct. We want to have a new domain and REALM. But to NOT rename hosts in it. But it also goes through automount rules and does the same.

In the end hostname for hosts & automount rules should not be manipulated. Just migrated over as they are.

No issue with automembers. But big issue with hostgroup data getting lost as host profiles have to be deleted and recreated to fix. So if you have the host profile already there and that is apart of a hostgroup already. Systems can just reregister to the migrated IDM domain and all data and processes around the host are good.

So I have done this. I moved from one domain to another using the command above. The issue was host records & automount records were manipulted so that ALL hosts had the new domain name. We don't want to do this as the hosts DON'T need to and may never be apart of the new domain from a host name prospective.

This is often not even valid in that hosts may not live on that domain and still be registered to IDM. Same with automount rules. Those ususally are not on the domain as they are usually from file servers often not associated with the domain.
Edited by jyoung

I see what you're saying. I suspect we'd have to do an all or nothing sort of approach.

For the case where only the IPA servers are changing domain/realm the new IPA server should be able to retain its new domain. All migrated entries would retain the existing domain.

We'd like to avoid adding a dozen flags for all the corner cases but this one seems relatively straightforward.

@mreynolds what do you think?

I see what you're saying. I suspect we'd have to do an all or nothing sort of approach.

For the case where only the IPA servers are changing domain/realm the new IPA server should be able to retain its new domain. All migrated entries would retain the existing domain.

We'd like to avoid adding a dozen flags for all the corner cases but this one seems relatively straightforward.

@mreynolds what do you think?

Ok I need to look at this more depth tomorrow, but convert_value() is used everywhere. We should be able to define "subtrees" that are excluded from this conversion and have an option to turn it on and off, but I want to run some tests...

@jyoung Hi I'd like to confirm which attribute you were concerned about with automount rules. I was provide some sample data from @rcritten and the only attribute I see that has domain info is automountInformation:

dn: description=export,automountmapname=auto.share,cn=baltimore,cn=automount,
dc=example,dc=test
automountKey: export
automountInformation: -ro,soft,rsize=8192,wsize=8192 ipa.example.test:/shared/
 export
...
...

If you can confirm if this is correct, or if there are other attributes I need to be concerned about, that would be great.

The the text of the hostname in attribute "automountInformation" where the
host name "ipa.example.test" ..

if I migrate to a domain that is named "newexample.test2". It will change
the attribute to be

automountInformation: -ro,soft,rsize=3D8192,wsize=3D8192
ipa.newexample.test2t:/shared/

On Thu, Oct 23, 2025 at 1:17=E2=80=AFPM Mark Reynolds pagure@pagure.io wr=
ote:

mreynolds added a new comment to an issue you are following:
``
@jyoung Hi I'd like to confirm which attribute you were concerned about
with automount rules. I was provide some sample data from @rcritten and
the only attribute I see that has domain info is automountInformation=
:

dn: description=3Dexport,automountmapname=3Dauto.share,cn=3Dbaltimore,cn=3Dau= tomount, dc=3Dexample,dc=3Dtest automountKey: export automountInformation: -ro,soft,rsize=3D8192,wsize=3D8192 ipa.example.test:/shared/ export ... ...

If you can confirm if this is correct, or if there are other attributes I
need to be concerned about, that would be great.
``

To reply, visit the link below or just reply to this email
https://pagure.io/freeipa/issue/9828

@jyoung Ok so we have a fix out for review: https://github.com/freeipa/freeipa/pull/7996 and we have a concern we want to run by you, and that is updating the realm from a migrated host/computer... krbprincipalname contains the FQDN and the realm. Currently we decided to leave the FQDN intact but convert the realm to the new one. Are there any concerns with this approach? Or do think the realm should also be left intact?

Changing the REALM should be fine. As you are moving to the new realm. But the FQDN of the host name is the big thing.
Also systems will end up re-registering to the new domain just using the existing record there. So don't see any issue.

It can complicate the client configuration. The IPA client configurator will handle the mapping automatically but it's something to consider.

it shouldn't. Clients will rergister to the new domain. So they will first "ipa-client-install --uninstall" & then they would "ipa-client-install ".

Key thing here is their record is already in new domain. But also if they apart of any hostgroups and such all of that is preserved.
Edited by jyoung

master:

  • bf976293f81c241c494046d95fe5ec1915feb58c ipa-migrate - do not convert hostnames/realm for computers and automounts

ipa-4-13:

  • 6e18d622a3dd259dda37dee8cc40a96f7934e785 ipa-migrate - do not convert hostnames/realm for computers and automounts

ipa-4-12:

  • f125252a4b46ee4d1684bfdfca189c552129bb50 ipa-migrate - do not convert hostnames/realm for computers and automounts

Metadata Update from @rjeffman:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.