The diagnostic module shows that the SSL directory of the backup has the wrong permissions in EC2 setups: [2017-09-09 00:22:56.235466] E Exception: ############### [2017-09-09 00:22:56.235540] E Überprüfe Datei Berechtigungen [2017-09-09 00:22:56.235617] E Datei '/etc/univention/ssl/backup092.autotest092.local' hat Datei-Modus 770, 750 war erwartet.############### [2017-09-09 00:22:56.235663] [2017-09-09 00:22:56.235754] 81_diagnostic_checks.py:24: Exception That happens only on DC backups: http://jenkins.knut.univention.de:8080/job/UCS-4.2/job/UCS-4.2-2/job/AutotestJoin/8/SambaVersion=s3,Systemrolle=backup/testReport/00_checks/81_diagnostic_checks/test/
Still applies to UCS-4.4, where this test is the only failing one for Backup-w/o-samba for 12 runts: <http://jenkins.knut.univention.de:8080/job/UCS-4.4/job/UCS-4.4-1/job/AutotestJoin/55/SambaVersion=no-samba,Systemrolle=backup/testReport/00_checks/81_diagnostic_checks/backup092/> And the culprit is: management/univention-join/20univention-join.inst:110 »···test -d "/etc/univention/ssl/$hostname" && chgrp -R "DC Backup Hosts" "/etc/univention/ssl/$hostname" && chmod g+rwx "/etc/univention/ssl/$hostname" && find "/etc/univention/ssl/$hostname/" -type f | xargs chmod g+rw It gets fixed as soon as the `rsync /etc/univention/ssl/` cron jobs runs as the permission is only wrong on the backup, but correct on the master. Looking at the code slaves should also be affected... # tail -n2 /etc/audit/rules.d/audit.rules -a always,exit -F path=/etc/univention/ssl/backup -F perm=wa -a always,exit -F path=/etc/univention/ssl/backup.phahn.dev -F perm=wa # ausearch -f /etc/univention/ssl -i ---- type=PROCTITLE msg=audit(09/02/2019 11:46:17.376:70) : proctitle=chgrp -R DC Backup Hosts /etc/univention/ssl/backup type=PATH msg=audit(09/02/2019 11:46:17.376:70) : item=0 name=/etc/univention/ssl/backup inode=526412 dev=fd:00 mode=link,777 ouid=root ogid=nogroup rdev=00:00 nametype=NORMAL type=CWD msg=audit(09/02/2019 11:46:17.376:70) : cwd=/etc/univention/ssl_1909021138 type=SYSCALL msg=audit(09/02/2019 11:46:17.376:70) : arch=x86_64 syscall=fchownat success=yes exit=0 a0=0xffffff9c a1=0x560a521aec90 a2=0xffffffff a3=0x138d items=1 ppid=14791 pid=14826 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=chgrp exe=/bin/chgrp key=(null) ---- type=PROCTITLE msg=audit(09/02/2019 11:46:17.376:71) : proctitle=chmod g+rwx /etc/univention/ssl/backup type=PATH msg=audit(09/02/2019 11:46:17.376:71) : item=0 name=/etc/univention/ssl/backup inode=526435 dev=fd:00 mode=dir,750 ouid=backup$ ogid=DC Backup Hosts rdev=00:00 nametype=NORMAL type=CWD msg=audit(09/02/2019 11:46:17.376:71) : cwd=/etc/univention/ssl_1909021138 type=SYSCALL msg=audit(09/02/2019 11:46:17.376:71) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xffffffffffffff9c a1=0x563f6c63a0f0 a2=0770 a3=0x3c0 items=1 ppid=14791 pid=14827 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=chmod exe=/bin/chmod key=(null) ---- type=PROCTITLE msg=audit(09/02/2019 12:00:05.008:122) : proctitle=rsync -e ssh -o StrictHostKeyChecking=no -o ControlPath=none -az --delete backup$@m34.phahn.dev:/etc/univention/ssl/ /etc/univen type=PATH msg=audit(09/02/2019 12:00:05.008:122) : item=0 name=backup inode=526412 dev=fd:00 mode=link,777 ouid=root ogid=DC Backup Hosts rdev=00:00 nametype=NORMAL type=CWD msg=audit(09/02/2019 12:00:05.008:122) : cwd=/etc/univention/ssl type=SYSCALL msg=audit(09/02/2019 12:00:05.008:122) : arch=x86_64 syscall=lchown success=yes exit=0 a0=0x7ffddb089dd0 a1=0x0 a2=0xfffe a3=0x0 items=1 ppid=16814 pid=16815 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rsync exe=/usr/bin/rsync key=(null) ---- type=PROCTITLE msg=audit(09/02/2019 12:00:05.008:123) : proctitle=rsync -e ssh -o StrictHostKeyChecking=no -o ControlPath=none -az --delete backup$@m34.phahn.dev:/etc/univention/ssl/ /etc/univen type=PATH msg=audit(09/02/2019 12:00:05.008:123) : item=0 name=backup.phahn.dev inode=526435 dev=fd:00 mode=dir,770 ouid=backup$ ogid=DC Backup Hosts rdev=00:00 nametype=NORMAL type=CWD msg=audit(09/02/2019 12:00:05.008:123) : cwd=/etc/univention/ssl type=SYSCALL msg=audit(09/02/2019 12:00:05.008:123) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x7ffddb089dd0 a1=0750 a2=0x1519c684 a3=0x0 items=1 ppid=16814 pid=16815 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rsync exe=/usr/bin/rsync key=(null)
This is a lot more complicated as multiple scripts use different permissions and the final permission depend on which script was last used: base/univention-ssl/make-certificates.sh base/univention-ssl/debian/univention-ssl.postinst base/univention-ssl/ssl-sync base/univention-ssl/gencertificate.py base/univention-system-setup/usr/lib/univention-system-setup/scripts/setup-join.sh base/univention-system-setup/usr/lib/univention-system-setup/scripts/10_basis/10hostname base/univention-system-setup/usr/lib/univention-system-setup/scripts/10_basis/12domainname base/univention-system-setup/usr/lib/univention-system-setup/scripts/40_ssl/10ssl management/univention-join/univention-join management/univention-join/20univention-join.inst management/univention-join/debian/univention-join.postinst Some of those scripts even set different permission in consecutive lines. And the permissions depend on the system beging joined: group "DC Backup Hosts" only is known after that. I started documenting the target state, but this is still WIP and needs to be discussed more: <https://hutten.knut.univention.de/mediawiki/index.php/Zertifikat_Debugging#Berechtigungen> Also be aware of Bug #49036, which adds additional issues.
Most often backup092, but also backup093, so not S4 related.
The test case passes now. We could close this Bug as duplicate of Bug #49036 except that we should investigate if any of the files in comment 3 is still relevant/unfixed.
This issue has been filed against UCS 4.4. UCS 4.4 is out of general maintenance and components may have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.