Univention Bugzilla – Bug 43692
Migrate Samba 4 DNS data from the legacy to the default partition
Last modified: 2023-11-10 11:44:21 CET
Created attachment 8480 [details] migrate_legacy_dns_zones.sh The DNS data should be migrated from the legacy position to the default DNS partition. We should at least have such a migration script. Maybe we can release the script as part of an erratum and use it by default later. The problem is, that the bind daemons on other joined Samba AD/DCs also need to be restarted (after the DRS replication is through). The attached script * stops if connector/s4/mapping/dns/position != legacy * does nothing if dns/backend != samba4 * stops bind9 & uinvention-s4-connector * backups the zone data found below DC=DomainDnsZones * backups the zone data found below DC=ForestDnsZones * copies the zones below CN=System to DC=DomainDnsZones sipping the ._msdcs records. * copies ._msdcs records below CN=System to DC=ForestDnsZones rewriting e.g. "foo._msdcs" below "dom.qa" to "foo" below "_msdcs.dom.qa" * Removes the corresponding DNS from "DN Mapping UCS" and "DN Mapping CON" * backups the legacy zone data found below CN=System * renames the legacy SOA ("DC=@") records to "DC=#@", so bind9 will not consider them any longer after restart * unsets connector/s4/mapping/dns/position * starts bind9 & uinvention-s4-connector again * runs samba_dnsupdate Before releasing this we still need to check a couple of points: * if this works reliably * if additional S4 Connector cache data needs to be removed. * if nameservers on other Samba/AD DCs continue to work until they are restarted at some point: E.g. does this still work?: host -t soa "$(dnsdomainname)" And what happens when a Windows client runs DDNS against it? What happens when samba_dnsupdate runs the next time?
*** Bug 34693 has been marked as a duplicate of this bug. ***
Reloading the remote bind9 servers could be done this way: univention-ssh /etc/machine.secret 'master30$'@backup31 /usr/sbin/rndc reload if this permission would be set: chgrp "DC Slave Hosts" /etc/bind/rndc.key But this only helps after the updated DNS data has been replicated via DRS.
Created attachment 8659 [details] migrate_legacy_dns_zones.sh Script adjusted: * Allow mixes case "dc: " and "DC: " attribute spelling * Output more progress info about the steps that are happening The final deactivation of the legacy data by renaming DC=@ to DC=#@ causes a reject in the S4-Connector. Maybe we can find some cleaner way to do this.
Created attachment 8660 [details] migrate_legacy_dns_zones.sh One additional case insensitive sed expression.
*** Bug 40494 has been marked as a duplicate of this bug. ***
Created attachment 9154 [details] migrate_legacy_dns_zones Updated version: * copies nTSecurityDescriptor attributes too * performs a "samba-tool dbcheck --fix --yes" in the end * logs to "migrate_legacy_dns_zones-${timestamp}.log"
We should check the most recent version of this script and ship it as part of univention-samba4.
(In reply to Arvid Requate from comment #7) > We should check the most recent version of this script and ship it as part > of univention-samba4. it might have helped to avoid cut&paste problems
Created attachment 10339 [details] migrate_legacy_dns_zones Updated version: * Save tmp and new ldifs to backup directory to simplify manual post-processing in error cases * Re-format script indentation to avoid crucial tabs * Finalize migration process even if samba-tool dbcheck returns != 0
Created attachment 10340 [details] migrate_legacy_dns_zones Updated version: * Prevent Bug #50361, by putting "_msdcs" on the ignorelist, just in case.
Should we make this a requirement before migrating to UCS 5.0?
(In reply to Ingo Steuwer from comment #11) > Should we make this a requirement before migrating to UCS 5.0? As we in support very frequently have this issue (and most of the time it is not found on the first sights) I would recommend to do so.
Well, I found a bug related to this which would have helped a lot... and possibly can help before migrating to UCS 5. Additionally raising it as "bug report" as the symptoms force DNS to ignore correct DNS zones. https://forge.univention.org/bugzilla/show_bug.cgi?id=49196
It would be great if we would have a anonymized way to assess how many licensed domains are still runing Samba/AD with the legacy DNS setup. Second best would be, if we could see, at what time apps have been installed. Given that we won't have these stats anytime soon, we don't know, how many customers are still affected by this. Addressing Bug #49196 would be good anyway.
As proposed by PO, we should adjust the preup to check samba4 domains if the DNS data is still in the legacy position and block the update in that case with a message pointing to the download URL for the migration script. We could also release the script with a 4.4 errata, but since it may need to be adjusted quickly if customer feedback points to some additional but common corner cases, it may be preferrable to find a way to minimize the turnaround time.
Is this still required to be fixed in UCS 5.0? Otherwise we should set the TM to UCS 5.0 candidates or create a User Story for it.
Yes it is still relevant. Just done a migration to 5.0 erata164 my dns is in a terrible mess (------ ): DEBUG_INIT WARNING): __get_s4_msdcs_soa: _msdcs sub-zone for zx01.org.live.com not found in S4 host gc._msdcs.$(ucr get domainname) 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: Host gc._msdcs.zx01.org.live.com not found: 3(NXDOMAIN) univention-s4search CN=MicrosoftDNS --cross-ncs dn | grep -i "cn=system" dn: CN=MicrosoftDNS,CN=System,DC=dx01,DC=org,DC=live,DC=com There should NOT be an entry in the “System” container (CN=system). I'm about 23 UCS rejected. all tied into _msdcs UCS DN: relativeDomainName=_ldap._tcp.pdc._msdcs,zoneName=.............. S4 DN: <not found> Filename: /var/lib/univention-connector/s4/1638802700.945887 and absolutely NO idea how to fix it... since your only article is in german and cannot even be found by google only bing.
clarification... it was a new CLEAN 5.0 with a takeover of AD
Ok something else seems to be going on. ucr get connector/s4/mapping/dns/position univention-s4search CN=MicrosoftDNS --cross-ncs dn | grep -i "cn=system" dn: CN=MicrosoftDNS,CN=System,DC=gp01,DC=org,DC=grown-up,DC=com host gc._msdcs.$(ucr get domainname) 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: now according to this: https://help.univention.com/t/problem-join-gives-error-or-users-can-not-login-sometimes-or-join-fails/11607 I should NOT see this line: dn: CN=MicrosoftDNS,CN=System,DC=gp01,DC=org,DC=grown-up,DC=com so if i run: ./migrate_legacy_dns_zones migrate_legacy_dns_zones-20211211075315.log INFO: No dnsZone objects found under CN=System, nothing to do.
Bug cannot be fixed in time for 5.0-1, moving milestone again.
> and absolutely NO idea how to fix it... since your only article is in german > and cannot even be found by google only bing. Which article are you referring to? > now according to this: > > https://help.univention.com/t/problem-join-gives-error-or-users-can-not-login-sometimes-or-join-fails/11607 > > I should NOT see this line: > > dn: CN=MicrosoftDNS,CN=System,DC=gp01,DC=org,DC=grown-up,DC=com I guess the wording of the article is misleading. It means to say that something like DC=_msdcs,DC=multi.ucs should not be below CN=MicrosoftDNS,CN=System. CN=MicrosoftDNS,CN=System by itself is a perfectly normal container. Please note that the purpose of this bug tracking system is to manage product improvements. Particular problems of specific customer environments should be either handled via support, if you have a contract for that or via https://help.univention.com/ , which helps to keep different specific issues separate from each other. Here it quickly would become a mess.
Ah. So the article is incorrect. Perhaps they should be correctly formulated if they are being used in the knowlage base. Far too many of the articles start on one thread, then suddenly skip to another line of thought. Perhaps any articles references in bug reports or to rectify & fault find should have a time rating that decreases the reliability of the article unless it is rechecked say every 6-12 months or new revision. UCS is a highly complex product to fault find and inaccurate info is not helping.
further on this script. It is possible that during the migration from 2008 to 5.0.x That there is a partial transfer of the DNS data. and that "_msdcs" somehow ends up in "DomainDNSZones" possibly related to the script running BEFORE the modification for the bug was made. this leaves _msdcs in the "wrong" place after the migration. running the newer script does not fix this prior bug. Therefore there should be an additional check to see if _msdcs is in DomainDNSZones and run a second mod to move it to "ForestDnsZones" rather than the script just checking "SYSTEM"
Created attachment 11125 [details] migrate_legacy_dns_zones.sh (In reply to Arvid Requate from comment #0) > Created attachment 8480 [details] > migrate_legacy_dns_zones.sh Here a version which runs with Python 3. I don't know if further adjustments needs to be done for UCS 5.0.
(In reply to Florian Best from comment #25) > Here a version which runs with Python 3. I don't know if further adjustments > needs to be done for UCS 5.0. Seems to work, thanks. Theses error messages where shown in the customer environment, so maybe an encoding problem: Failed to delete 'DC=\ xxxxx-xxxx-x204,DC=XXX.de,CN=MicrosoftDNS,CN=System,DC=XXX,DC=de' - objectclass: Cannot delete DC=\ xxxxx-xxxx-x204,DC=XXX.de,CN=MicrosoftDNS,CN=System,DC=XXX,DC=de, entry does not exist! Failed to delete 'DC=XXX.de,CN=MicrosoftDNS,CN=System,DC=XXX,DC=de' - subtree_delete: Unable to delete a non-leaf node (it has 1 children)!
Still not working with 5.0.5 and 4.4-9 root@ucs:~# /usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh Host gc._msdcs.dfm.lan not found: 3(NXDOMAIN) _gc._tcp.dfm.lan has SRV record 0 100 3268 ucs.dfm.lan. Host _ldap._tcp.gc._msdcs.dfm.lan not found: 3(NXDOMAIN) _ldap._tcp.dfm.lan has SRV record 0 100 389 ucs.dfm.lan. Host _ldap._tcp.dc._msdcs.dfm.lan not found: 3(NXDOMAIN) Host _ldap._tcp.pdc._msdcs.dfm.lan not found: 3(NXDOMAIN) Host _ldap._tcp.a6dc9851-6c89-45cc-b177-1b45b8224099.domains._msdcs.dfm.lan not found: 3(NXDOMAIN) Host _kerberos._tcp.dc._msdcs.dfm.lan not found: 3(NXDOMAIN) _kerberos._tcp.dfm.lan has SRV record 0 100 88 ucs.dfm.lan. _kerberos._udp.dfm.lan has SRV record 0 100 88 ucs.dfm.lan. _kpasswd._tcp.dfm.lan has SRV record 0 100 464 ucs.dfm.lan. _kpasswd._udp.dfm.lan has SRV record 0 100 464 ucs.dfm.lan. Located DC 'ucs' in site 'Saarlouis' Host 3fb3eee0-9b05-4f3e-b083-6a8bb605256b._msdcs.dfm.lan not found: 3(NXDOMAIN) ## Records for site Saarlouis: _ldap._tcp.Saarlouis._sites.dfm.lan has SRV record 0 100 389 srv2008-dc01.dfm.lan. _ldap._tcp.Saarlouis._sites.dfm.lan has SRV record 0 100 389 ucs.dfm.lan. Host _ldap._tcp.Saarlouis._sites.dc._msdcs.dfm.lan not found: 3(NXDOMAIN) _kerberos._tcp.Saarlouis._sites.dfm.lan has SRV record 0 100 88 srv2008-dc01.dfm.lan. _kerberos._tcp.Saarlouis._sites.dfm.lan has SRV record 0 100 88 ucs.dfm.lan. Host _kerberos._tcp.Saarlouis._sites.dc._msdcs.dfm.lan not found: 3(NXDOMAIN) ## Optional GC Records for site Saarlouis: _gc._tcp.Saarlouis._sites.dfm.lan has SRV record 0 100 3268 srv2008-dc01.dfm.lan. _gc._tcp.Saarlouis._sites.dfm.lan has SRV record 0 100 3268 ucs.dfm.lan. Host _ldap._tcp.Saarlouis._sites.gc._msdcs.dfm.lan not found: 3(NXDOMAIN) _kerberos.dfm.lan descriptive text "DFM.LAN" root@ucs:~# locate legacy_dns^C root@ucs:~# bash e08003da2ee3b63dca0c9efffbaa630c555886b1.sh INFO: No dnsZone objects found under CN=System, nothing to do. root@ucs:~# /usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh
Output of Python Script Comment 25 root@ucs:~# ./migratepy.sh INFO: No dnsZone objects found under CN=System, nothing to do. cp: reguläre Datei '/var/univention-backup/samba/dns-202311091345/tmp' kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
1. This shall not become a catch-all for all kinds of stuff regarding this script. 2. If you get NXDOMAIN from check_essential_samba4_dns_records.sh one should check that first before attempting to migrate. If you have a support entitlement, please make use of that, otherwise help.univention.de would be the place to discuss. 3. Thanks for reporting Comment 28, I'll check and create a bug/patch if I find something.
you can migrate your legacy zones in advance upgrade your ad structure and ad to 2008r2 delete zone _msdcs... recreate it restart netlogon and dns service your entries will be back Re: https://www.der-windows-papst.de/wp-content/uploads/2018/02/msdcs-Re-Create-gesamtstrukturweit.pdf then do ad-takeover and verify with check_essential_dns script cheers