Each UCS server knows its own DN and uses that to bind to the LDAP directory for all of its services. Therefore moving the server object in the LDAP requires updating that information on the server whose object was moved. I’m not sure if that is done automatically; I doubt it somewhat.
Luckily this should be easy enough as the DN is stored in the UCR variable
ldap/hostdn. Personally I’d following a process such as:
- Log in to the server whose object you want to move via
ssh & become
- Move the server object in the LDAP directory
- Update the UCR variable
ldap/hostdn on the server:
ucr set ldap/hostdn=<new DN>
- Forcefully rebuild all configuration files from templates via
ucr commit (just in case)
- Reboot the server (easiest way to make sure all services using that information are restarted)
Note that when you move your DC Master’s object, the UMC will most likely cease to work almost instantly as the UMC uses the server’s host DN for authenticating any type of LDAP access, too. After a reboot things should be fine again, though.
This applies to a regular server. Things will be slightly different for Dockerized apps. Apps from the app center often come as Docker images which actually run a UCS member or slave server inside Docker. Therefore there are server objects for those “hosts”, too; they’re called
<shortened appname>-<random suffix>. For those all changes to the UCR variable must be done from inside the Docker container. You can spawn a shell into the app container with
univention-app shell <appname>, e.g.
univention-app shell nextcloud