Univention Bugzilla – Bug 29755
Update to Samba 4.0.3
Last modified: 2013-03-25 19:56:42 CET
Wir haben in UCS 3.1 bereits den rc6 integriert plus einige weitere Patches. Wir sollen mit 3.1-1 auf die aktuelle Upstream Version aktualisieren.
http://www.samba.org/samba/history/samba-4.0.3.html
The errata patches need to be merged, e.g. the one for Bug #30135.
The merged errata bugs need to go into the changelog as well..
Test with the latest i386 DVD: WARNING: No path in service IPC$ - making it unavailable! NOTE: Service IPC$ is flagged unavailable. ldb: module version mismatch in ../source4/dsdb/samdb/ldb_modules/acl.c : ldb_version=1.1.13 module_version=1.1.15 ldb: failed to initialise module /usr/lib/ldb/modules/ldb/samba/acl.so : Unavailable ldb: failed to initialise module /usr/lib/ldb/modules/ldb/samba : Unavailable ldb: failed to initialise module /usr/lib/ldb/modules/ldb : Unavailable ldb: failed to initialise module /usr/lib/ldb/modules : Unavailable ERROR(<type 'exceptions.MemoryError'>): uncaught exception - File "/usr/lib/python2.6/dist-packages/samba/netcmd/__init__.py", line 175, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/samba/netcmd/domain.py", line 401, in run use_rfc2307=use_rfc2307, skip_sysvolacl=False) File "/usr/lib/python2.6/dist-packages/samba/provision/__init__.py", line 2054, in provision schemadn=names.schemadn) File "/usr/lib/python2.6/dist-packages/samba/schema.py", line 82, in __init__ self.ldb = SamDB(global_schema=False, am_rodc=False) Samba4 provision failed, exiting /usr/share/univention-samba4/scripts/setup-s4.sh
@Comment 4: fixed by rebuilding tdb, talloc, ldb (all packages from debian experimental) and samba4. The most recent tevent version only fixes some FreeBSD epoll/select problem, which seems to have been addressed by a larger number of changes in tevent. Since samba4 currently does not explicitely require that tevent version, I would be conservative at this point. Basic tests were successful: * OK: A joined Win7 client remains joined. If the client clock was not in sync with the domain and thus the client initiated DDNS-update failed in UCS 3.1-0 or previous, one reboot triggers the ntp sync again and during a second reboot, the client succeeds with the DDNS-update (a couple of seconds after receiving the Windows Login screen). * OK: A new Win7 client can join and after the initial reboot the NTP sync is triggered. A second reboot triggers a successful DDNS update. * Note: After updating the master, and with e.g. a Slave still not updated, the "samba-tool drs showrepl" first showed WERR_SEM_TIMEOUT and WERR_BADFILE messages in the outbound communication. After restarting samba4 on the UCS 3.1-0 Slave, the error messages vanieshed on the master and bidirectional replication worked (e.g. a Windows7-Client could be joined to the Slave and appeared in the sam.ldb on the master). Some more tests are required.
(In reply to comment #5) > @Comment 4: fixed by rebuilding tdb, talloc, ldb (all packages from debian > experimental) and samba4. The most recent tevent version only fixes some > FreeBSD epoll/select problem, which seems to have been addressed by a larger > number of changes in tevent. Since samba4 currently does not explicitely > require that tevent version, I would be conservative at this point. The ucs-test run this night failed, because samba4 and bind9 failed to start after the upgrade to ucs-3.1-1 from testing.univention.de. After the DNS did no longer work, which broke the update. http://jenkins.knut.univention.de:8080/job/ucs-test_EC2-SingleMaster_64/281/ # dpkg-query -W bind9 samba\* \*tdb\* bind9 1:9.8.0.P4-1.100.201212102125 libtdb1 1.2.10-2.31.201207251945 python-tdb 1.2.10-2.31.201207251945 python2.6-tdb samba samba-client samba-common 2:3.6.8-1.558.201211011340 samba-common-bin 2:3.6.8-1.558.201211011340 samba-dsdb-modules 4.0.3-1.363.201303041401 samba-gtk samba-ldb-tools samba-tools samba4 4.0.3-1.363.201303041401 samba4-clients 4.0.3-1.363.201303041401 samba4-common samba4-common-bin 4.0.3-1.363.201303041401 tdb-tools 1.2.10-2.31.201207251945 Looks like tdb_ 1.2.11-2.1.34.201303051256 didn't reach the mirror.
(In reply to comment #6) > The ucs-test run this night failed, because samba4 and bind9 failed to start > after the upgrade to ucs-3.1-1 from testing.univention.de. After the DNS did no ... > # dpkg-query -W \*tdb\* > libtdb1 1.2.10-2.31.201207251945 > python-tdb 1.2.10-2.31.201207251945 > python2.6-tdb > tdb-tools 1.2.10-2.31.201207251945 > > Looks like tdb_ 1.2.11-2.1.34.201303051256 didn't reach the mirror. Still failing as of 2013-03-07: 950 ? S 0:00 runsvdir -P /etc/service log: so : Unavailable?ldb: module version mismatch in ../source4/dsdb/samdb/ldb_modules/acl.c : ldb_version=1.1.13 module_version=1.1.15?ldb: failed to initialise module /usr/lib/samba ucs-test still reboots the (broken) host and starts running its test. At the end it tries to mail the (mostly failed) results to 1und1.de, which is not resolvable because of the broken DNS setup.
(In reply to comment #7) > Still failing as of 2013-03-07: That was a bug in repo-ng, the mirror is now up-to-date.
I've applied the patch for https://bugzilla.samba.org/show_bug.cgi?id=9709.
Samba 4.0.3 with patches for Bug #30771 is functional in ucs3.1-1. changelog-3.1-1 is updated.
Currently the Windows7 Group Policy Management Tool is unhappy with the NTACLs of a newly created GPO. Looks like the 93_bug_28737.patch, which was only partly applied in UCS 3.1-0 (due to broken patch markup) and fixed for ucs3.1-1, is not giving the desired results. E.g. with log level 10+ log.smbd shows +[2013/02/13 13:47:01.786286, 10, pid=17861, effective(0, 5020), real(0, 0), class=vfs] ../source3/modules/vfs_acl_common.c:395(get_nt_acl_internal) + get_nt_acl_internal: blob hash does not match for file arucs31i0.qa/Policies/{3CE62A4B-5D56-472F-8457-AFF364D88713} - returning file system SD mapping. during access to a freshly created GPO. IIRC this could be due to an interference of the XATTR NTACL blob hashes with the UCS-specific additional default-fACLs we set on sysvol. I guess we need to revisit this, if we want "samba-tool ntacl sysvolcheck" to work (Bug 29737). For now I would recommend shipping samba 4.0.3 without this patch. Bug 29712 can be used to improve upon this. Samba4 is built now without the patch. GPO creation works now again. samba-tool ntacl sysvolcheck gives a traceback, but that is expected.
Note: the following cases can be found in the filesystem of a Samba4 DC updated from UCS 3.1-0 to ucs3.1-1: root@master10:~# ls -l /var/lib/samba/sysvol/arucs31i0.qa/Policies/ ## The two standard default ACLs: drwxrwx---+ 4 Administrator Domain Users 4096 12. Feb 13:15 {31B2F340-016D-11D2-945F-00C04FB984F9} drwxrwx---+ 4 Administrator Domain Users 4096 12. Feb 13:15 {6AC1786C-016F-11D2-945F-00C04FB984F9} ## A GPO created in UCS 3.0-x, and the sysvolreset on update to UCS 3.1-0: drwxrwx---+ 4 Administrator Domain Admins 4096 12. Feb 19:02 {F087A019-ABC7-458F-87AC-077CE11048CB} ## A GPO created in UCS 3.1-0 and never sysvolreset: drwxrwx---+ 4 5000 Domain Admins 4096 12. Feb 19:04 {9D46426C-37A4-42D8-874E-EB55269EC90C} ## A GPO created after the update to ucs3.1-1: drwxrwx---+ 4 root Domain Admins 4096 12. Feb 19:12 {6FA3557D-4A4C-477F-B046-57BCC46C83AE} The windows client does not care, as it only sees the NTACLs. But if this is too ugly, "samba-tool ntacl sysvolreset" can be called once after the update. Should we automate this (adding a version-dependend block to the joinscript)?
(In reply to comment #12) > The windows client does not care, as it only sees the NTACLs. But if this is > too ugly, "samba-tool ntacl sysvolreset" can be called once after the update. > Should we automate this (adding a version-dependend block to the joinscript)? If the windows client does not care, then we could do it in the next S4 erratum. (In reply to comment #11) > Currently the Windows7 Group Policy Management Tool is unhappy with the NTACLs > of a newly created GPO. Looks like the 93_bug_28737.patch, which was only > partly applied in UCS 3.1-0 (due to broken patch markup) and fixed for > ucs3.1-1, is not giving the desired results. E.g. with log level 10+ log.smbd > shows OK, this works now. Also successful tested: - Windows 7 Join: OK - Windows 2k8r2: OK - New GPO created: OK TODO: - IPv4 DRS replication test - IPv6 DRS replication test - Join Windows XP / Windows 8 - GPO evaluation - S3 → S4 inplace migration - S3 → S4 stepwise migration - Password change - Share access - Printer access
Successful tested: - IPv4 DRS replication test: OK - IPv6 DRS replication test OK - Join Windows XP / Windows 8: OK - GPO evaluation: OK - Password change: OK - Share access: OK - Printer access: OK TODO: - S3 → S4 inplace migration - S3 → S4 stepwise migration
- S3 → S4 inplace migration: OK - S3 → S4 stepwise migration: Failed, see below - AD Takeover: OK - Changelog: OK I had to set samba-tool domain passwordsettings set --max-pwd-age 0 after the the new S4 system was joined. Maybe you ca add it to or is there a bigger problem? http://wiki.univention.de/index.php?title=Migration_from_Samba_3_to_Samba_4#Update_Scenario_1_-_Stepwise_migration_from_Samba_3.2FNT4_to_the_Samba_4.2FAD_domain Everything else is verified.
Ok, the inplace migration guide already include a this recommendation, so I added it as well to http://wiki.univention.de/index.php?title=Migration_from_Samba_3_to_Samba_4#Installation_of_the_first_Samba_4_DC It might be due to a combination of Bug 24237 and Bug 29775, but in the stepwise migration I would have assumend that finally this results in the default max password age value of 42.
OK
UCS 3.1-1 has been released: http://download.univention.de/doc/release-notes-3.1-1_en.pdf http://download.univention.de/doc/release-notes-3.1-1.pdf If this error occurs again, please use "Clone This Bug".