Assigned static IP address, but SAMSL verification remembers DHCP address How to correct?

When the machine was first configured for Univention, it was assigned DHCP address of 10.1.10.124

Later we bound it to static address of 10.1.10.15. After a reboot, all worked fine,

except SAMSL start up.

System Diagnostic says the below. What do I do to change the cached address in univention of 10.1.10.124 to 10.1.10.15 for this one module?

[ I may ask IT to assign the address back to 10.1.10.124 if this is too difficult!]

SAML certificate verification failed!

Failed to load certificate https://10.1.10.124/simplesamlphp/saml2/idp/certificate: HTTPSConnectionPool(host=‘10.1.10.124’, port=443): Max retries exceeded with url: /simplesamlphp/saml2/idp/certificate (Caused by NewConnectionError(’: Failed to establish a new connection: [Errno 113] No route to host’)) Re-execute the join-script 92univention-management-console-web-server via [“Domain join” module](javascript:void(0)) or execute univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server on the command line as user root.

TEST AGAIN

Well, after searching, I found this page: Templates for configuration files in Univention | LINET Services GmbH / Das IT-Systemhaus für die Region Braunschweig where the gentleman advised on how to customize ucr templates to add your own configuration changes ins a supported way and so tried ucr commit to ask that the system regenerate everything; it did so, but problem remained…

Then finding this page: System Diagnostic in Shell? - #4 by Moritz_Bunkus

I can find the source to the script that is running this test, to try to understand what the disagnotic script is running that gives the bad IP address.

It advises looking in /usr/share/pyshared/univention/management/console/modules/diagnostic/plugins for the files; but they aren’t there; no worries, running the script gives me the name:

ran 03_check_notifier_replication successfully.

########################## Start 04_saml_certificate_check ##########################
## Check failed: 04_saml_certificate_check - SAML certificate verification failed! ##
Failed to load certificate https://10.1.10.124/simplesamlphp/saml2/idp/certificate (https://10.1.10.124/simplesamlphp/saml2/idp/certificate): HTTPSConnectionPool(host='10.1.10.124', port=443): Max retries exceeded with url: /simplesamlphp/saml2/idp/certificate (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fabac5445c0>: Failed to establish a new connection: [Errno 113] No route to host'))
Re-execute the join-script <tt>92univention-management-console-web-server</tt> via {join} or execute <tt>univention-run-join-scripts --force --run-scripts 92univention-management-console-web-server</tt> on the command line as user <i>root</i>.
########################### End 04_saml_certificate_check ###########################

ran 10_gateway successfully.

ran 11_nameserver successfully.

and a find discovers the path to the file:

find / -name "*04_saml_certificate_check*" -print
/usr/lib/python3/dist-packages/univention/management/console/modules/diagnostic/plugins/__pycache__/04_saml_certificate_check.cpython-37.pyc
/usr/lib/python3/dist-packages/univention/management/console/modules/diagnostic/plugins/04_saml_certificate_check.py

Here I see that the script does ucr get ucs/server/sso/fqdn

ucr get ucs/server/sso/fqdn

Running this at the command line, and then looking up the address I see the problem:

root@ucs-7340:~# ucr get ucs/server/sso/fqdn
ucs-sso.mydomain.intranet
root@ucs-7340:~# nslookup ucs-sso.mydomain.intranet
Server:		10.1.10.15
Address:	10.1.10.15#53

Name:	ucs-sso.mydomain.intranet
Address: 10.1.10.124
Name:	ucs-sso.mydomain.intranet
Address: 10.1.10.15

root@ucs-7340:~#

Both the old address AND the new address for the ucs-sso.mydomain.intranet are in the DNS being served by the machine!

Now to find where the DNS records are…

Ok, going to the management console, https://xxx/univention/umc/ then Domain, then DNS, then mydomain.intranet i see

ucs-sso 10.1.10.124, 10.1.10.15 Host Record

Delete the 10.1.10.124 and test again…

Yeah, this error is fixed!

Mastodon