i already used the correct ucs-NUMBER.
I just write UCS-1234 instead of my real UCS number as i though that could be somewhat sensitive data like the servers ip which might not flow around public accessible posts.
So its still valid. The last one returns the UCS IP while the rest does not return any information
dig +short -p 53 @127.0.0.53 _domaincontroller_master._tcp.codenauten.intranet. srv # ❓ works and returns 0 0 0 ucs-1234.codenauten.intranet as expected
dig +short -p 53 @127.0.0.53 ucs-1234.codenauten.intranet. any # ❓ does not, which should just resolve that name to an IP address.
Both should go via your local resolver to the same DNS server, which is able to answer those queries as has been proven by querying that server directly.
What currently confuses me is your nmcli output from above:
That mydomain.intranet does not match your later codenauten.intranet. Can you please re-check the output of nmcl.
Also please check /etc/NetworkManager/NetworkManager.conf if in section [main] there is any dns=… setting. Probably not which will tell NM to use either systemd-resolved if
… /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, /run/systemd/resolve/resolv.conf, /lib/systemd/resolv.conf or /usr/lib/systemd/resolv.conf
or NMs own default, which would explain why that /etc/NetworkManager/dnsmasq.d/ucs.conf is not used.
Please check ps $(pgrep dnsmasq) for any running dnsmasq process (just to be sure it is not used)
Please check ps $(pgrep systemd-resolved) for any running process (to make sure it is running)
As the command resolvectl did work for you I strongly guess that systemd-resolved is used in your case. I have to dig deeper myself first how that beast can be tamed.
Iam sorry about this one. I wrote mydonmain.intranet as I liked to obfuscate the original domain name (wasn’t sure if they are somewhat sensitive)
It is indeed codenauten.intranet
No DNS setting here
Returns
1:[main]
4:[ifupdown]
7:[device]
Returns
/run/systemd/resolve/stub-resolv.conf
3&4: both returns two processes running. Ps and bash. However I wasn’t sure about that “for any running process” I just typed the line into the terminal.
That happens only when pgrep does not find such processes and thus ps was called without any extra argument, in which case it only returns itself and the shell. Please re-run this command instead of 3: ps $(pgrep systemd-resolve) which should print one process (there a limit of 15 characters per “process name”, so the trialing d needs to be stripped.)
Create a file like /etc/systemd/resolved.conf.d/ucs.conf with this content:
[Resolve]
# the IP of your DC Primary goes here:
DNS=192.168.2.X
# your UCS domain name goes here:
Domains=~codenauten.intranet
Restart the daemon: sudo systemctl reload-or-restart systemd-resolved.service
resolvectl should then list the DC Primary with its IP and domain name.
Check again that dig +short _domaincontroller_master._tcp.codenauten.intranet. srv returns a record and dig +short ucs-1234.codenauten.intranet. any is able to resolve the name into an IP address.
Afterwards give univention-domain-join another try: Make sure to enter codenauten.intranet into the field “Domain name or IP address”. (specifying the IP address of your UCS Primary there should also work.)
This returns one process the Command /lib/systemd/systemd-resolved
I did as described.
For the DNS in the conf file i used IP.of.your.UCS.
Thats the IP i can use to reach the UCS GUI.
However, it does not work so far but i guess we are a big step further.
The fail message changed:
“The domain join failed: For further informations look at /var/log/univention/domain-join-gui.log”
It seems like something about the LDAP goes bad.
Here is the log from today, i changed the occurrence of the actual server’s IP (which I put into the conf file) to IP.of.your.UCS.
2022-12-07 01:35:34,377 userinfo WARNING Warning: /etc/ldap/ldap.conf already exists.
2022-12-07 01:35:34,379 userinfo WARNING Warning: /etc/sssd/sssd.conf already exists.
2022-12-07 01:35:34,382 userinfo WARNING Warning: /etc/krb5.conf already exists.
2022-12-07 01:35:34,383 userinfo INFO Created a backup of all configuration files, that will be modified at '/var/univention-backup/20221207003534_domain-join'.
2022-12-07 01:35:35,222 userinfo INFO Getting the DN of the Administrator
2022-12-07 01:35:36,739 userinfo INFO Downloading the UCS root certificate to /etc/univention/ssl/ucsCA/CAcert.pem
2022-12-07 01:35:36,790 userinfo INFO Adding the UCS root certificate to the certificate store
2022-12-07 01:35:41,288 userinfo INFO Adding LDAP entry for this machine on the UCS DC
2022-12-07 01:35:42,189 userinfo CRITICAL Adding an LDAP object for this computer didn't work.
2022-12-07 01:35:42,190 userinfo CRITICAL Warning: Permanently added 'IP.of.your.UCS' (ED25519) to the list of known hosts.
2022-12-07 01:35:42,941 userinfo CRITICAL
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 78, in modify_old_entry_or_add_machine_to_ldap
udm_type, dn = get_machines_udm(dc_ip, admin_username, admin_pw, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/utils/ldap.py", line 77, in get_machines_udm
raise LookupError(dc_ip)
LookupError: IP.of.your.UCS
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/univention-domain-join", line 458, in run
distribution_joiner.join_domain()
File "/usr/lib/python3/dist-packages/univention_domain_join/distributions/ubuntu.py", line 115, in join_domain
LdapConfigurator().configure_ldap(self.dc_ip, self.ldap_server_name, self.admin_username, self.admin_pw, self.ldap_base, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 72, in configure_ldap
self.modify_old_entry_or_add_machine_to_ldap(password, dc_ip, admin_username, admin_pw, ldap_base, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 81, in modify_old_entry_or_add_machine_to_ldap
dn = self.add_machine_to_ldap(password, dc_ip, admin_username, admin_pw, ldap_base, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 133, in add_machine_to_ldap
raise LdapConfigutationException()
univention_domain_join.join_steps.ldap_configurator.LdapConfigutationException
I’ve got the feeling that we are about to close this case
A million thanks for your support
@pmhahn do you got any idea what i could check?
If necessary i could try to get the source files, set breakpoints on the specific lines, and post the variable values.
Somehow the ssh process on the server seems to fail.
Sorry for the delay, but other tasks kept me busy.
The code tries to add a machine account by running udm on your Primary. Your logfile /var/log/univention/domain-join-gui.log or /var/log/univention/domain-join-cli.log should contain the error message, (which should also have been printed to your console if you are using the CLI version.)
If you want to debug this yourself put a breakpoint() before line 128 and print out the command which gets executed: p udm_command
You can then login to the Primary yourself and run it there; bear in mind that you replace the argument after --bindpwfile to point to some other file which contains your admin password.
I totally understand if you need to take care of other tasks as well.
Iam very happy about any time you can spend to help me to get this done.
Its strange since its a complete fresh installation of ubuntu. I literally just installed ubuntu, downloaded the domain join script thats it.
Well, I used the gui to join and already posted the log file above at post number 16.
Thats how i came across these functions, but i dont get how to dig further.
executing the command from line 128 on primary wont do the trick? Otherwise the script wouldnt fail?
Do i oversee something?
UDJ builds a command to join your Ubuntu client to your domain, which is then executed on your Primary. This is done via ssh for which it needs the address of your Primary and your Administrator credentials to do the login. The later thing we have now solved, but the command the fails for some reason. I need to see that error message to figure out, what goes wrong and why that might happen in your environment.
The command with is executed is built in line 119-126 which is something like this:
The error message from that specific udm command hopefully will tell us the exact problem. Its output should be in the log files named above near the end if you search for Adding an LDAP object for this computer didn't work.
If you don’t find that message you could just login to your Primary itself and then execute the command there by hand, which should then show the same error. If you later on run UDJ again it should detect that the machine account already exists and should try to modify that already existing entry.
/var/log/univention/domain-join-gui.log or /var/log/univention/domain-join-cli.log from the client — the Ubuntu host where UDJ is executed.
Not for UDJ — for joining other UCS server roles /usr/share/univention-join/univention-server-join would log to ~Administrator/.univention-server-join.log.
For UDJ the failing command should be logged in the UDJ log files named above.
The 1st line is the header from line 131, the 2nd is from ssh (which can be ignored) but there is only a blank line after it, which I had hoped for to contains the error from that udm command.
Can you please insert a breakpoint() before line 130, so the code looks like this:
ssh_process = ssh(admin_username, admin_pw, dc_ip, udm_command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
stdout, stderr = ssh_process.communicate()
breakpoint()
if ssh_process.returncode != 0 or stderr.decode().startswith('E: '):
userinfo_logger.critical('Adding an LDAP object for this computer didn\'t work.')
Then run the client again and when the debugger starts print out some values for me:
p ssh_process.args
p ssh_process.returncode
p stdout
p stderr
When i run the CLI (for debug purpose) i ran into the same problem.
The Log also shows:
2022-12-22 11:46:19,573 userinfo CRITICAL An error occurred: . Please check /var/log/univention/domain-join-cli.log for more information.
2022-12-22 11:46:19,573 debugging CRITICAL
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 78, in modify_old_entry_or_add_machine_to_ldap
udm_type, dn = get_machines_udm(dc_ip, admin_username, admin_pw, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/utils/ldap.py", line 77, in get_machines_udm
raise LookupError(dc_ip)
LookupError: IP,of,your.ICS
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/codenauten/join-script/fromGit/univention-domain-join-ubuntu22.04/scripts/cli.py", line 192, in <module>
distribution_joiner.join_domain()
File "/usr/lib/python3/dist-packages/univention_domain_join/distributions/ubuntu.py", line 115, in join_domain
LdapConfigurator().configure_ldap(self.dc_ip, self.ldap_server_name, self.admin_username, self.admin_pw, self.ldap_base, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 72, in configure_ldap
self.modify_old_entry_or_add_machine_to_ldap(password, dc_ip, admin_username, admin_pw, ldap_base, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 81, in modify_old_entry_or_add_machine_to_ldap
dn = self.add_machine_to_ldap(password, dc_ip, admin_username, admin_pw, ldap_base, admin_dn)
File "/usr/lib/python3/dist-packages/univention_domain_join/join_steps/ldap_configurator.py", line 133, in add_machine_to_ldap
raise LdapConfigutationException()
univention_domain_join.join_steps.ldap_configurator.LdapConfigutationException
However the breakpoint() on line 130 wont trigger.
I also used a breakpoint inside of cli.py just to make sure that the debugger is running.
This one triggers.
I tried breakpoint somewhere else in the ldap_configurator.py.
However they dont trigger as well.
I also put breakpoints on lines such as 115 which obviously are executed.
Well i still was not able to actually trigger breakpoints.
I tried to reload modules, i hard imported the Joiner class from ubuntu , still an issue.
However, i copied different parts together into my version of the cli script and therefore i was able to trigger breakpoints as well as logging functions.
Therefore i was able to get the breakpoint and executed the debugger commands.
And this is what i got. (I shall notice that “mars” is the machines name):
(Pdb) p ssh_process.args
['sshpass', '-e', 'ssh', '-F', 'none', '-o', 'StrictHostKeyChecking=no', '-o', 'UserKnownHostsFile=/dev/null', '-l', 'Administrator', 'MY.UCS.SERVER.IP', '/usr/sbin/udm computers/ubuntu create --binddn uid=administrator,cn=users,dc=codenauten,dc=intranet --bindpwdfile /dev/shm/Administratordomain-join --position cn=computers,dc=codenauten,dc=intranet --set name=mars --set \'password=RANDOM_PASSWORD' --set operatingSystem=Ubuntu --set operatingSystemVersion=22.04']
(Pdb) p ssh_process.returncode
3
(Pdb) p stdout
b'E: Object exists: (uid) mars$\n'
(Pdb) p stderr
b"Warning: Permanently added '89.58.11.173' (ED25519) to the list of known hosts.\r\n"
(Pdb)
I hope this bring us closer!
Thank you so much and i want to wish you a happy new year!
PS: I edited IP and Password of the ssh args, just in case
I deleted the machine Mars via UCS Web GUI.
Restarted the original cli.py (not my debug version).
Aaaannnnnnndddd success:
Warning: /etc/ldap/ldap.conf already exists.
Warning: /etc/sssd/sssd.conf already exists.
Warning: /etc/krb5.conf already exists.
Created a backup of all configuration files, that will be modified at ‘/var/univention-backup/20230104194115_domain-join’.
Getting the DN of the Administrator
Adding LDAP entry for this machine on the UCS DC
Writing /etc/ldap/ldap.conf
Writing /etc/machine.secret
Writing /etc/sssd/sssd.conf
Configuring auth config profile for sssd
Restarting sssd
Writing /usr/share/pam-configs/ucs_mkhomedir
Adding groups to /etc/security/group.conf
Adding groups to /usr/share/pam-configs/local_groups
Updating PAM
Writing /etc/krb5.conf
Synchronizing time with the DC
The domain join was successful.
Please reboot the system.
The already existing entry should have triggered another code-path and add_machine_to_ldap() should never have been called. I’d need to take a look after my vacation why that happened.
Excellent: Glad to hear that it now worked for you.
Thank your reply.
I currently fiddling with more steps like roaming ubuntu profiles.
I going to give the whole process a complete “Vanilla 22.04.4 to UCS” try on another machines this week.
If this works out, without further problems I like to contribute a write-up for other users.
If there is any preferred style/kind of contribution for a guide i would be happy to follow them (Forum poss ,Blog post,Wiki, markdown text,…).
So at least i can give something back for all the time you spend to guide my through this process.
