Univention Bugzilla – Bug 37828
Joinscript 85italc-windows.inst fails in autotest-201-ucsschool-singleserver-s4-with-slave
Last modified: 2019-03-12 10:58:50 CET
The joinscript 85italc-windows.inst currently fails in autotest-201-ucsschool-singleserver-s4-with-slave: ERROR: 85italc-windows.inst: cannot determine ou ldap base for cn=master201,cn=dc,cn=computers,dc=autotest201,dc=local This is why: ============================================================================ ++ univention-ldapsearch -xLLL '(&(objectClass=ucsschoolOrganizationalUnit)(ucsschoolHomeShareFileServer=cn= master201,cn=dc,cn=computers,dc=autotest201,dc=local))' dn + ou_base= + '[' -z '' ']' ++ basename /usr/lib/univention-install/85italc-windows.inst + echo 'ERROR: 85italc-windows.inst: cannot determine ou ldap base for cn=master201,cn=dc,cn=computers,dc=autotest201,dc=local' ============================================================================ The slave has been registered instead: ============================================================================ root@master201:~# univention-ldapsearch -xLLL \ '(&(objectClass=ucsschoolOrganizationalUnit)(ucsschoolHomeShareFileServer=*))'\ ucsschoolHomeShareFileServer dn: ou=School1,dc=autotest201,dc=local ucsschoolHomeShareFileServer: cn=slave202,cn=dc,cn=server,cn=computers,ou=Scho ol1,dc=autotest201,dc=local ============================================================================
Maybe this triggers Bug 37830
Joinscript 85italc-windows.inst failed also on a DC-backup VM, single server S4: root@backup:~# univention-join :: :: Configure 79univention-printserver.inst done Configure 79univention-squid.inst done Configure 80ucs-school-umc-printermoderation.inst done Configure 81univention-nfs-server.inst done Configure 82univention-ucs-school-import-custom-attributes.done Configure 85italc-windows.inst failed ************************************************************************** * Join failed! * * Contact your system administrator * ************************************************************************** * Message: FAILED: 85italc-windows.inst **************************************************************************
Just happened on a customer system. Does it have any other effetcs or is there a workaround? Added Ticket to bug.
@Maintainer: Any idea about Comment 3?
This issue has been filled against UCS@school 4.0. The maintenance with bug and security fixes for UCS@school 4.0 has ended on May 31, 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3 (or later). Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
With 4.4 this prevents backup server to join into a single server environment.
The join script now uses a fixed DN for creating iTALC share objects on master and backup systems: "cn=iTALC-Installation-${hostname},cn=shares,${ldap_base}". For school slaves everything remains the same. e8c9427bb Bug #37828: add advisory 445cfe6fb Bug #37828: use fixed DN for iTALC samba share for DC master and DC backup Package: italc-windows Version: 5.0.0-2A~4.4.0.201902271109 Branch: ucs_4.4-0 Scope: ucs-school-4.4
- --position "cn=shares,${ou_base}" \ - --set name="iTALC-Installation" \ + --position "$position" \ + --set name="iTALC-Installation${name_suffix}" \ AFAICS this will lead to existing singlemaster systems having two shares (in two positions), if they rerun the join script. A migration (rename) is needed for those cases.
(In reply to Daniel Tröder from comment #8) > - --position "cn=shares,${ou_base}" \ > - --set name="iTALC-Installation" \ > + --position "$position" \ > + --set name="iTALC-Installation${name_suffix}" \ > > AFAICS this will lead to existing singlemaster systems having two shares (in > two positions), if they rerun the join script. > A migration (rename) is needed for those cases. The Joinscript version is not increased in this bug, i.e. the systems concerned do not immediately receive an additional release object. If several share objects for the same Samba name exist in LDAP, one of the two LDAP objects wins, because the listener writes the config to the same file below /etc/samba/shares.conf.d/. If there is a conflict, you can delete the "wrong" share object as a workaround.
OK Share is created -> OK Forced joinscript execution with share already set up on demoschool -> share still works -> OK -> Verified
UCS@school 4.4 v1 has been released. https://docs.software-univention.de/release-notes-ucsschool-4.4v1-de.html If this error occurs again, please clone this bug.