Univention Bugzilla – Bug 43217
nameserver2=dns/forwarder1 breaks LDAP/DHCP
Last modified: 2023-12-14 16:00:20 CET
Created attachment 8309 [details] strace dhcpd -d -f -t System setup configures a DC master with the following DNS configuration: nameserver1='10.200.17.28' # self-IP nameserver2='192.168.0.3' # DNS server entered during USS dns/forwarder1='192.168.0.3 # same as nameserver2 This breaks applications in a very suitable way, in this case ISC-dhcpd after fixing Bug #38438: - on startup dhcpd opens a connection to the server configured in /etc/dhcp/dhcpd.conf; in my case "ldap://master41.phahn.qa:7389". - this URI is passed to ldap_initialize(), which just stored that URI for first use. - inside server/ldap.c:set_ldap_real_base_dn() the first search is performed before the connection is autheticated; - the URI is then resolved by libldap-2.4.2 using libirs-export.so.95 from BIND9 - NOT libresolv.so.2 from libc6 - that library will perform both IPv4 and IPv6 queries in parallel and - depending on the phase of the moon - query one of the two configured name servers - it either gets the correct answer if the local host is queried - or a NOT-FOUND if the other host is queried - case 2 will make the lap_search_ext_s() return failure - dhcpd will terminate itself. I can trigger this behavior easily by running "dhcpd -d -f -t" from Bug #38438 - it fail or success randomly. Previously the search silently failed and some logic was skipped, leading to random behavior. If I do "ucr unset nameserver2" is never fails. The major bug is that in UCS' /etc/resolv.conf the given DNS servers are not equal: - An external DNS server cannot answer queries regarding the local domain - if an external DNS server is asked first, the query will return a NOT-FOUND. - On the other hand a DNS server of the UCS domain can answer the query and will return the expected RRs. (gdb) bt #0 sendmsg () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff767d3d8 in doio_send () from /lib/x86_64-linux-gnu/libisc-export.so.95 #2 0x00007ffff767dd2d in socket_send () from /lib/x86_64-linux-gnu/libisc-export.so.95 #3 0x00007ffff79641ff in resquery_send () from /lib/x86_64-linux-gnu/libdns-export.so.100 #4 0x00007ffff796a520 in fctx_query () from /lib/x86_64-linux-gnu/libdns-export.so.100 #5 0x00007ffff796bd33 in fctx_try () from /lib/x86_64-linux-gnu/libdns-export.so.100 #6 0x00007ffff796c3e4 in fctx_start () from /lib/x86_64-linux-gnu/libdns-export.so.100 #7 0x00007ffff7681cba in isc.taskmgr_dispatch () from /lib/x86_64-linux-gnu/libisc-export.so.95 #8 0x00007ffff7685c7b in isc.app_ctxrun () from /lib/x86_64-linux-gnu/libisc-export.so.95 #9 0x00007ffff7bd652f in getaddrinfo () from /lib/x86_64-linux-gnu/libirs-export.so.91 #10 0x00007ffff6e0ba6d in ldap_connect_to_host (ld=ld@entry=0x5555558b2ae0, sb=0x5555558b2ab0, proto=proto@entry=1, srv=srv@entry=0x5555558b2e40, async=async@entry=0) at os-ip.c:605 #11 0x00007ffff6df5d86 in ldap_int_open_connection (ld=0x5555558b2ae0, conn=0x555555877640, srv=0x5555558b2e40, async=0) at open.c:379 #12 0x00007ffff6e08fbd in ldap_new_connection (ld=0x5555558b2ae0, srvlist=0x7fffffffbce0, srvlist@entry=0x5555558b2be8, use_ldsb=0, use_ldsb@entry=1, connect=0, bind=0x0, m_req=0, m_res=0) at request.c:487 #13 0x00007ffff6df541a in ldap_open_defconn (ld=ld@entry=0x5555558b2ae0) at open.c:41 #14 0x00007ffff6e0a498 in ldap_send_initial_request (ld=ld@entry=0x5555558b2ae0, msgtype=msgtype@entry=99, dn=dn@entry=0x5555555e9013 "", ber=0x5555558b2ee0, msgid=1) at request.c:130 #15 0x00007ffff6df9445 in ldap_pvt_search (ld=ld@entry=0x5555558b2ae0, base=0x5555555e9013 "", scope=0, filter=0x7fffffffd120 "namingContexts=*", attrs=0x7fffffffd0f0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=0, deref=-1, msgidp=0x7fffffffd024) at search.c:128 #16 0x00007ffff6df958e in ldap_pvt_search_s (ld=0x5555558b2ae0, base=<optimized out>, scope=<optimized out>, filter=<optimized out>, attrs=<optimized out>, attrsonly=<optimized out>, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=0, deref=-1, res=0x7fffffffd0e8) at search.c:174 #17 0x00007ffff6df9640 in ldap_search_ext_s (ld=<optimized out>, base=<optimized out>, scope=<optimized out>, filter=<optimized out>, attrs=<optimized out>, attrsonly=<optimized out>, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=0, res=0x7fffffffd0e8) at search.c:150 #18 0x00005555555a4436 in set_ldap_real_base_dn (ld=<optimized out>) at ldap.c:135 #19 ldap_start () at ldap.c:1282 #20 0x00005555555a73c5 in ldap_read_config () at ldap.c:1787 #21 0x0000555555561a19 in main (argc=<optimized out>, argv=0x7fffffffe228) at dhcpd.c:615 Here's a simple reproducer using <https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch12.html> apt-get install libbind-export-dev touch config.h gcc -I/usr/include/bind-export -I. -lirs-export /home/phahn/src/extern/bind9/lib/export/samples/sample-gai.c ./a.out master41.phahn.qa It will fail randomly. The UCRVs are set by 90univention-bind-post.inst: grep -e nameserver -e dns/forwarder config-registry.replog 2016-12-19 12:06:01: set dns/forwarder1=192.168.0.3 old:[Previously undefined] 2016-12-19 12:06:01: set nameserver2=192.168.0.3 old:[Previously undefined] 2016-12-19 12:06:01: set nameserver1=10.200.17.4 old:192.168.0.3 less setup.log Configure /usr/lib/univention-install/90univention-bind-post.inst 2016-12-19 15:06:00.448503240+01:00 (in jointscript_init) Create dns/backend W: The config registry variable 'nameserver2' does not exist W: The config registry variable 'nameserver3' does not exist Create dns/forwarder1 File: /etc/bind/named.conf.proxy File: /etc/bind/named.conf.samba4 Create nameserver2 Seting nameserver1 File: /etc/resolv.conf Restarting bind9 daemon: ...done. ... 2016-12-19 15:06:11.312907138+01:00 (in joinscipt_save_current_version)
r75436 | Bug #43217 dns: Remove transition code r75435 | Bug #43217 dns: Fold grep into sed r75434 | Bug #43217 dns: Fix quoting r75433 | Bug #43217 dns: Fix registration of UCS-domain and forward name servers r75442 | Bug #43217 dns: Fix wrong path name Package: univention-bind Version: 11.0.0-4A~4.2.0.201612201550 Version: 11.0.0-5A~4.2.0.201612201634 Branch: ucs_4.2-0 QA: IMHO the bug should be fixed in UCS-4.1-x too, as the DNS mis-configuration must be corrected BEFORE the update to UCS-4.2. I've added the following extra change, but it might not be enough in all cases: r75438 | Bug #43217 dhcp: Require fix DNS configuration Package: univention-dhcp Version: 11.0.0-4A~4.2.0.201612201604 Branch: ucs_4.2-0
r75513 | Bug #43217 dns: Convert addresses to string for UCR r75517 | Bug #42380 bind: Depend on fixed runit Package: univention-bind Version: 11.0.0-7A~4.2.0.201612221408 Branch: ucs_4.2-0
The IP address of the nameserver1 is now set to 127.0.0.1. Was it part of this bug? It looks like it breaks the appbox docker installation. Anyway, we need a changelog entry for this bug and the changes.
The other problem. What happens if we configure bind0 to be broken after an update? Previously, our update server was still reachable since we have the forwarder as second nameserver configured.
127.0.0.1 is problematic for docker container. appbox based container may work (see Bug #43458), but non-appbox container have a real problem. Docker seems to copy /etc/resolv.conf to the container during create/run. If something like 127.0* is set as nameserver, this line is removed. If nothing is left, a public DNS server is added (8.8.8.8). So if we have a UCS system with only nameserver1=127.0.0.1: * docker container can't resolve the UCS server * if the system has no access to the internet, no DNS It is possible to set custom DNS servers and domains (--dns-search=, --dns= parameter for docker run/create) but this would require more changes in the appcenter docker code. So the question, is it really worth it.
I've installed a UCS 4.2 preview version and the dns/forwarder1 was not set. 192.168.0.3 is the nameserver I set during the installation: root@master211:~# ucr search --brief "(dns/forwarder|nameserver)" dns/forwarder1: <empty> dns/forwarder2: <empty> dns/forwarder3: <empty> dns/nameserver/registration/forward_zone: <empty> dns/nameserver/registration/reverse_zone: <empty> nameserver/external: false nameserver/option/timeout: 2 nameserver1: 127.0.0.1 nameserver2: 192.168.0.3 nameserver3: <empty> root@master211:~# __MSG__:Configure 90univention-bind-post __STEP__:39 Configure /usr/lib/univention-install/90univention-bind-post.inst 2017-01-31 04:55:46.033423485-05:00 (in joinscript_init) Create dns/backend File: /etc/resolv.conf Restarting bind9 Domain Name Server (DNS): samba4 ldap proxy failed! invoke-rc.d: initscript bind9, action "restart" failed. Wait for bind9: .Restarting bind9 Domain Name Server (DNS): samba4 ldap proxy. done done Object modified: cn=default-settings,cn=dns,cn=dhcp,cn=policies,dc=deadlock21,dc=intranet Object exists: cn=services,cn=univention,dc=deadlock21,dc=intranet Object created: cn=DNS,cn=services,cn=univention,dc=deadlock21,dc=intranet Object modified: cn=master211,cn=dc,cn=computers,dc=deadlock21,dc=intranet 2017-01-31 04:56:00.756591663-05:00 (in joinscript_save_current_version) __MSG__:Configure 91univention-saml
(In reply to Stefan Gohmann from comment #4) > The other problem. What happens if we configure bind0 to be broken after an > update? Previously, our update server was still reachable since we have the > forwarder as second nameserver configured. Maybe, we can solve this by adding a static entry for updates.software-univention.de (IPv4 + IPv6).
(In reply to Stefan Gohmann from comment #6) > I've installed a UCS 4.2 preview version and the dns/forwarder1 was not set. > 192.168.0.3 is the nameserver I set during the installation: > > root@master211:~# ucr search --brief "(dns/forwarder|nameserver)" > dns/forwarder1: <empty> > dns/forwarder2: <empty> > dns/forwarder3: <empty> > nameserver1: 127.0.0.1 > nameserver2: 192.168.0.3 > nameserver3: <empty> r76502 | Bug #43217 bind: Use non-loopback-IP address and validate UCS domain servers DNS servers are now moved from nameserverX to dns/forwarderY is they cannot resolve SRV _domaincontroller_master._tcp.$(domainname) Also "get_default_ip()" is now used instead of 127.0.0.1 Disabled when nameserver/external=true Package: univention-bind Version: 11.0.0-10A~4.2.0.201702071609 Branch: ucs_4.2-0 (In reply to Stefan Gohmann from comment #7) > (In reply to Stefan Gohmann from comment #4) > > The other problem. What happens if we configure bind0 to be broken after an > > update? Previously, our update server was still reachable since we have the > > forwarder as second nameserver configured. > > Maybe, we can solve this by adding a static entry for > updates.software-univention.de (IPv4 + IPv6). As discussed this has multiple aspects: 1. we don't want to hard-code their addresses, as DNS can be updated more easily than shipped packages. We also will hopefully get a 2nd ftp server soon. 2. UCS is using "hosts: files dns" in /etc/nsswitch.conf, adding the IPs to /etc/hosts would prevent any DNS lookup for them; "dns files" would solve this, but would breaks using the hostname (or the hostname of the DC master) while DNS is down. We would need a "files.fallback"... 3. Before UCS-4.0, only UCS DNS servers were used in UCRVs 'nameserverX' and external DNS servers in UCRVs 'dns/forwarderY' - the change was only introduced with the switch-over to the Debian-Installer (and Univention-System-Setup) with UCS-4.0. But we don't know if it is so on every system. 4. Fact: Using mixed UCS domain DNS servers and external DNS servers in UCRV nameserverX is wrong - this lead to multiple problems in the past: - univention-dhcp no longer starts - while the UCS named is down, any query will get a negative answer from the external fallback DNS server, which is cached by nscd. So even after the restart is completed, the cache is poisoned... - ... Ideas for mitigation: - write a Nagios check/UCS diagnostics module to check for working $(repository/online/server) DNS resolving and connection - Check for working named on start/network-up and fall back to static IP addresses if DNS does not work - Tell users to do a "ucr set nameserver1=8.8.8.8 ; apt-get update ; apt-get upgrade" to get back a working BIND if things go wrong badly. - Add a fallback to a static configuration in the updater if DNS does not work; APT would need to use the same faked DNS as well... - ...
r76654 | Bug #43217 dns: Reload configuration after change Package: univention-bind Version: 11.0.0-11A~4.2.0.201702141505 Branch: ucs_4.2-0
Created attachment 8451 [details] fix-ucr-dns Ok generally the script works. There are some points I propose to fix like in the attached adjusted version: * We should only do changes to UCR if we can proove that a configured nameserver is responding in a futile manner. Otherwise we should not touch anything. * We need exception handling around the DnsRequest calls, otherwise a non-reachable server causes a traceback. * Only force own default address as nameserver1 if DNS responds there. * If an IP is configured as nameserver* and not as dns/forwarder but fails validation because the DnsRequest call fails, then keep it anyway. This is especially true for any local address. * Set default log level to INFO, required for support cases. * More detailed log messages, especially log the actual UCR changes. * In log messages differenciate between "myself" default address and just any local link addresses. * I prefer not using a module name as variable name.
(In reply to Arvid Requate from comment #10) > Created attachment 8451 [details] > fix-ucr-dns > > Ok generally the script works. There are some points I propose to fix like > in the attached adjusted version: > > * We should only do changes to UCR if we can proof that a configured > nameserver is responding in a futile manner. Otherwise we should not touch > anything. > > * We need exception handling around the DnsRequest calls, otherwise a > non-reachable server causes a traceback. Which was somehow wanted to abort any change if things go wrong. But as the script might be called by a admin, lets add it anyway. > * Only force own default address as nameserver1 if DNS responds there. > > * If an IP is configured as nameserver* and not as dns/forwarder but fails > validation because the DnsRequest call fails, then keep it anyway. > This is especially true for any local address. > > * Set default log level to INFO, required for support cases. okay. > * More detailed log messages, especially log the actual UCR changes. okay. FYI: map(str, values) is "evil" - consider what happens for unicode values... > * In log messages differentiate between "myself" default address and just > any local link addresses. okay. > * I prefer not using a module name as variable name. okay. r77080 | Bug #43217 DNS: Improve fix-ucr-dns Package: univention-bind Version: 11.0.0-12A~4.2.0.201702231907 Branch: ucs_4.2-0 QA: EXT='8.8.8.8' SELF='127.0.0.1' OTHER=$(dig +short $(dig +short $(dnsdomainname) ns|grep -v $HOSTNAME|head -n1)) printf "#\n\ndomainname: %s\ninterfaces/eth0/address: $SELF\ninterfaces/eth0/netmask: 255.0.0.0\nldap/master: localhost\n" "$(dnsdomainname)" >head.conf run () { printf "$@" >main.conf cat head.conf main.conf >base.conf UNIVENTION_BASECONF=$PWD/base.conf ./fix-ucr-dns -nv } run "" # nameserver1=$SELF run "nameserver1: ::1\n" # - run "nameserver1: $SELF\n" # - run "nameserver1: $EXT\n" # nameserver1=$SELF forwarder1=$EXT run "nameserver1: $EXT\ndns/forwarder1: $SELF\n" # nameserver1=$SELF forwarder1=$EXT run "nameserver1: $EXT\nnameserver2: $SELF\n" # nameserver1=$SELF nameserver2= forwarder1=$EXT run "nameserver1: $EXT\nnameserver2: $SELF\ndns/forwarder1: $EXT\n" # nameserver1=$SELF nameserver2= forwarder1=$EXT run "nameserver1: $SELF\nnameserver2: $OTHER\ndns/forwarder1: $OTHER\n" # - /etc/init.d/bind9 stop;run "";/etc/init.d/bind9 start # Traceback iptables -A OUTPUT -d $EXT -j REJECT;run "nameserver1: $EXT\n" # - NOT nameserver1=$SELF forwarder1=$EXT iptables -F OUTPUT
Ok, that's good. Please add a changelog entry and some note in the release notes <chapter id="relnotes:post"> that nameserver UCR settings get checked and fixed automatically during update on servers that have univention-bind installed. And we still have the open question how we deal with systems running univention-dhcp but not univention-bind. We could cover them easily if we move this script to some more generic package like univention-config-registry. After all it's mainly a DNS client configuration issue here. Or should we ignore this as an unlikely corner case? I'm unsure, what do you think? Sure, on a system where no univention-bind is installed this may cause an invalid nameserver to get moved to dns/forwarder which is not considered there at all. But that would be ok from my point of view.
I've installed a UCS 4.2 environment with master and backup. After the installation, the DNS configuration on the master doesn't look right: ------------------------------------------------------------------------------ root@master421:~# univention-check-join-status Joined successfully root@master421:~# rgrep nameserver /var/log/univention/config-registry.replog 2017-02-23 20:00:22: set nameserver/option/timeout=2 old:[Previously undefined] 2017-02-23 15:00:27: set nameserver1=192.168.0.3 old:[Previously undefined] 2017-02-23 15:09:47: set nameserver/external=false old:[Previously undefined] 2017-02-23 15:13:18: unset 'nameserver1' old:192.168.0.3 root@master421:~# ucr search --brief "(nameserver|dns/forwarder)" | grep -v nameserver/ dns/forwarder1: 192.168.0.3 dns/forwarder2: <empty> dns/forwarder3: <empty> nameserver1: <empty> nameserver2: <empty> nameserver3: <empty> root@master421:~# dpkg -l | grep univention-bind | grep ^ii ii univention-bind 11.0.0-12A~4.2.0.201702231907 all UCS - DNS server root@master421:~# ------------------------------------------------------------------------------ The configuration on the backup looks better but: ------------------------------------------------------------------------------ root@backup422:~# ucr search --brief "(nameserver|dns/forwarder)" | grep -v nameserver/ dns/forwarder1: 192.168.0.3 dns/forwarder2: 8.8.8.8 dns/forwarder3: <empty> nameserver1: 10.201.42.1 nameserver2: <empty> nameserver3: <empty> root@backup422:~# univention-check-join-status Joined successfully root@backup422:~# dpkg -l | grep univention-bind | grep ^ii ii univention-bind 11.0.0-12A~4.2.0.201702231907 all UCS - DNS server root@backup422:~# ------------------------------------------------------------------------------ 10.201.42.1 is the IP of the master. Join output from master (10.201.42.1): ------------------------------------------------------------------------------ Configure /usr/lib/univention-install/90univention-bind-post.inst 2017-02-23 15:13:18.124419896-05:00 (in joinscript_init) Create dns/backend 2017-02-23 15:13:18,697 INFO __main__.ucr/ns Found server 192.168.0.3 from UCRV nameserver1 2017-02-23 15:13:18,700 WARNING __main__.val UCS master SRV record is unknown at 192.168.0.3, converting into forwarder 2017-02-23 15:13:18,701 INFO __main__.xor Skip removing nameservers from forwarders 2017-02-23 15:13:18,702 INFO __main__.ucr/self Default IP address configured in UCR: 10.201.42.1 2017-02-23 15:13:18,703 ERROR __main__.ns DNS lookup of NS records in deadlock42.intranet against 127.0.0.1 failed 2017-02-23 15:13:18,704 ERROR __main__.ldap DNS lookup of master421.deadlock42.intranet against 127.0.0.1 failed 2017-02-23 15:13:18,704 INFO __main__.ucr Updating 'dns/forwarder1': None -> '192.168.0.3' 2017-02-23 15:13:18,704 INFO __main__.ucr Updating 'nameserver1': '192.168.0.3' -> None 2017-02-23 15:13:18,988 INFO __main__.ucr Reloading BIND ------------------------------------------------------------------------------ And from backup (10.201.42.2): ------------------------------------------------------------------------------ Create dns/backend 2017-02-23 15:34:12,868 INFO __main__.ucr/fwd Found forwarder 192.168.0.3 from UCRV dns/forwarder1 2017-02-23 15:34:12,869 INFO __main__.ucr/ns Found server 10.201.42.1 from UCRV nameserver1 2017-02-23 15:34:12,869 INFO __main__.ucr/ns Found server 8.8.8.8 from UCRV nameserver2 2017-02-23 15:34:12,872 INFO __main__.val Validated UCS domain server: 10.201.42.1 2017-02-23 15:34:12,895 WARNING __main__.val UCS master SRV record is unknown at 8.8.8.8, converting into forwarder 2017-02-23 15:34:12,895 INFO __main__.xor Skip removing nameservers from forwarders 2017-02-23 15:34:12,900 INFO __main__.ucr/self Default IP address configured in UCR: 10.201.42.2 2017-02-23 15:34:12,902 ERROR __main__.ns DNS lookup of NS records in deadlock42.intranet against 127.0.0.1 failed 2017-02-23 15:34:12,907 ERROR __main__.ldap DNS lookup of master421.deadlock42.intranet against 127.0.0.1 failed 2017-02-23 15:34:12,908 INFO __main__.ucr Updating 'dns/forwarder2': None -> '8.8.8.8' 2017-02-23 15:34:12,908 INFO __main__.ucr Updating 'nameserver2': '8.8.8.8' -> None 2017-02-23 15:34:13,192 INFO __main__.ucr Reloading BIND ------------------------------------------------------------------------------ I guess it should be something like this: master: nameserver1: 10.201.42.1 dns/forwaeder1: '192.168.0.3 backup: nameserver1: 10.201.42.2 nameserver2: 10.201.42.1 dns/forwaeder1: '192.168.0.3 dns/forwarder2: 8.8.8.8
(In reply to Stefan Gohmann from comment #13) > Join output from master (10.201.42.1): > ----------------------------------------------------------------------------- > 2017-02-23 15:13:18,703 ERROR __main__.ns DNS lookup of NS records > in deadlock42.intranet against 127.0.0.1 failed r77091 | Bug #43217 DNS: Handle install time in fix-ucr-dns This happens as during setup LDAP and DNS are empty, thus the query for SRV will fail. r77099 | Bug #43217 DNS: Move fix script for DNS settings to univention-server I also added a sanity check to abort if no nameserver remains Package: univention-bind Version: 11.0.0-13A~4.2.0.201702241011 Version: 11.0.0-14A~4.2.0.201702241328 Branch: ucs_4.2-0 @QA: You can easily test it with my shell-test from comment 11 and change "domainname: something.other" in head.conf - named must be running (In reply to Arvid Requate from comment #12) > Please add a changelog entry and some note in the release notes <chapter > id="relnotes:post"> that nameserver UCR settings get checked and fixed > automatically during update on servers that have univention-bind installed. r77087 | Bug #43217 DNS: Changelog and Release Note fixes > And we still have the open question how we deal with systems running > univention-dhcp but not univention-bind. We could cover them easily if we > move this script to some more generic package like > univention-config-registry. Please not u-c-r, as it is not a base UCR thing. univention-base-files would be better, but that already is a collections of foo. I picked univention-server. > After all it's mainly a DNS client configuration > issue here. Or should we ignore this as an unlikely corner case? It's also a problem on backup and slave, as there univention-bind is optional. Therefore the script was moved to univention-server and is now both called in univention-bind and univention-updater/postup on all server roles. Package: univention-server Version: 12.0.0-3A~4.2.0.201702241324 Branch: ucs_4.2-0 Package: univention-updater Version: 12.0.3-10A~4.2.0.201702241321 Branch: ucs_4.2-0 Future: management/univention-management-console-module-diagnostic/umc/python/diagnostic/plugins/nameserver.py should be extended to check nameserverX for SRV _domaincontroller_master._tcp
r77116 | Bug #43217 DNS: Move fix script for DNS settings to univention-server Package: univention-bind Version: 11.0.0-15A~4.2.0.201702270910 Branch: ucs_4.2-0
Created attachment 8471 [details] fixes_for_ucsschool.patch For UCS@school: * The ldap/master must not be added on School Slave Samba/AD DCs * Servers found in NS-records must not be added See attached patch which disables both script options by default.
r77136 | Bug #43217 DNS: Change default for adding master or nameservers Package: univention-server Version: 12.0.0-4A~4.2.0.201702280748 Branch: ucs_4.2-0
r77139 | Bug #43217 DNS: Fix duplicate -n option Package: univention-server Version: 12.0.0-5A~4.2.0.201702281104 Branch: ucs_4.2-0
Please redirect the output to the updater.log: ------------------------------------------------------------------------------ root@ucs-3620:~# univention-upgrade Starting univention-upgrade. Current UCS version is 4.1-4 errata353 [...] Starting update process, this may take a while. Check /var/log/univention/updater.log for more information. Running postup.sh script:2017-02-28 14:35:09,611 INFO __main__.ucr/fwd Found forwarder 192.168.0.3 from UCRV dns/forwarder1 2017-02-28 14:35:09,612 INFO __main__.ucr/ns Found server 10.201.33.1 from UCRV nameserver1 2017-02-28 14:35:09,633 INFO __main__.val Validated UCS domain server: 10.201.33.1 2017-02-28 14:35:09,634 INFO __main__.xor Skip removing nameservers from forwarders 2017-02-28 14:35:09,635 INFO __main__ No action required. done. ------------------------------------------------------------------------------
r77163 | Bug #43217: Redirct fix-ucr-dns output Package: univention-updater Version: 12.0.3-14A~4.2.0.201702281516 Branch: ucs_4.2-0
Ok, updater.log looks good now. I've added this recommendation to the release notes: * We recommend to check the values of these &ucsUCRV;s * Wir empfehlen die Werte dieser &ucsUCRV;n zu prüfen.
r77374 | Bug #43217 DNS: Add --force-self Force adding self when univention-bind is joined Package: univention-bind Version: 11.0.0-16A~4.2.0.201703061501 Branch: ucs_4.2-0 Package: univention-server Version: 12.0.0-8A~4.2.0.201703061507 Branch: ucs_4.2-0 QA: univention-join && ucr search --brief --non-empty ^dns/forwarder[123] ^nameserver[123]
Ok, the joining DC puts itself first now: Test setup: ucs_4.2-0-20170309-103310-dvd-amd64.iso Master & Backup automatically joined during installation: root@backup101:~# ucr search --brief --non-empty \ ^dns/forwarder[123] ^nameserver[123] dns/forwarder1: 10.200.8.1 dns/forwarder2: 10.200.8.100 nameserver1: 10.200.8.101 nameserver2: 10.200.8.100 join.log says: ============================================================================== Configure 90univention-bind-post.inst Thu Mar 9 17:14:07 CET 2017 2017-03-09 17:14:07.904173540+01:00 (in joinscript_init) Create dns/backend 2017-03-09 17:14:08,482 INFO __main__.ucr/fwd Found forwarder 10.200.8.1 from UCRV dns/forwarder1 2017-03-09 17:14:08,485 INFO __main__.ucr/fwd Found forwarder 10.200.8.100 from UCRV dns/forwarder2 2017-03-09 17:14:08,485 INFO __main__.ucr/ns Found server 10.200.8.100 from UCRV nameserver1 2017-03-09 17:14:08,488 INFO __main__.val Validated UCS domain server: 10.200.8.100 2017-03-09 17:14:08,488 INFO __main__.xor Skip removing nameservers from forwarders 2017-03-09 17:14:08,491 INFO __main__.ucr/self Default IP address configured in UCR: 10.200.8.101 2017-03-09 17:14:08,492 INFO __main__.ns Skip adding NS 2017-03-09 17:14:08,492 INFO __main__.ldap Skip adding master 2017-03-09 17:14:08,492 INFO __main__.ucr Updating 'nameserver1': '10.200.8.100' -> '10.200.8.101' 2017-03-09 17:14:08,492 INFO __main__.ucr Updating 'nameserver2': None -> '10.200.8.100' 2017-03-09 17:14:08,766 INFO __main__.ucr Reloading BIND ==============================================================================
I've adjusted the release notes to reflect the changes of Comment 14.
UCS 4.2 has been released: https://docs.software-univention.de/release-notes-4.2-0-en.html https://docs.software-univention.de/release-notes-4.2-0-de.html If this error occurs again, please use "Clone This Bug".