This being a place people are trying samba4 as a DC, I got a repeatable panic on one of the systems I am trying it on, as follows: .... crash: _kvm_kvatop(0) Crash version 9.99.69, image version 9.99.69. Kernel compiled without options LOCKDEBUG. System panicked: /: bad dir ino 657889 at offset 0: Bad dir (not rounded), reclen=0x2e33, namlen=51, dirsiz=60 <= reclen=11827 <= maxsize=512, flags=0x2005900, entryoffsetinblock=0, dirblksiz=512
Backtrace from time of crash is available. _KERNEL_OPT_NARCNET() at 0 _KERNEL_OPT_DDB_HISTORY_SIZE() at _KERNEL_OPT_DDB_HISTORY_SIZE sys_reboot() at sys_reboot vpanic() at vpanic+0x15b snprintf() at snprintf ufs_lookup() at ufs_lookup+0x518 VOP_LOOKUP() at VOP_LOOKUP+0x42 lookup_once() at lookup_once+0x1a1 namei_tryemulroot() at namei_tryemulroot+0xacf namei() at namei+0x29 vn_open() at vn_open+0x9a do_open() at do_open+0x112 do_sys_openat() at do_sys_openat+0x72 sys_open() at sys_open+0x24 syscall() at syscall+0x26e --- syscall (number 5) --- syscall+0x26e: .... The other panics differ only by the dir ino displayed; the rest is exactly the same. I forced fsck on / and repeated - with the same result. / is mounted with posix1eacls and I've ran tunefs as well. The panic occurs during the provision, using the exact command shown earlier in the thread, at the following moment of the provision: ... INFO 2020-07-28 17:55:16,331 pid:2844 /usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py #1586: Setting up well known security principals INFO 2020-07-28 17:55:16,358 pid:2844 /usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py #1600: Setting up sam.ldb users and groups INFO 2020-07-28 17:55:16,460 pid:2844 /usr/pkg/lib/python3.7/site-packages/samba/provision/__init__.py #1608: Setting up self join ..... Repacking database from v1 to v2 format (first record CN=FRS-Replica-Set-GUID,CN=Schema,CN=Configuration,DC=lorien,DC=lan) Repack: re-packed 10000 records so far Repacking database from v1 to v2 format (first record CN=foreignSecurityPrincipal-Display,CN=411,CN=DisplaySpecifiers,CN=Configuration,DC=lorien,DC=lan) Repacking database from v1 to v2 format (first record CN=IP Security,CN=System,DC=lorien,DC=lan) On the second machine I am trying this - which uses python3.8 and which provisioned OK with the previous version and worked for a few days, but - as was rightly explained earlier - the database was lost after a reboot, new provision fails at a later stage with a message that an object has not been found; I rebooted and forced fsck on /, which didn't find anything, but I got the same panic as above when i tried to 'rm -r /var/db/samba4/*' . So methinks there are still outstanding problems with the underlying file system code, as far as samba4 as dc is concerned. Chavdar On Tue, 28 Jul 2020 at 02:12, Christos Zoulas <chris...@zoulas.com> wrote: > > Done, thanks! > > christos > > > On Jul 27, 2020, at 8:49 PM, Matthias Petermann <m...@petermann-it.de> > > wrote: > > > > Hello everyone, > > > > with the introduction of FFS ACLs Samba can be used as windows domain > > controller (DC). The DC needs a directory to persist its policies and > > scripts - the so called Sysvol. > > > > The creation of the Sysvol typically takes place during the domain > > provisioning with samba-tool. At the moment, the default Samba4 from pkgsrc > > is configured to put Sysvol below /var/run/sysvol. Unfortunately, there is > > a critical issue with this location: Everything inside /var/run gets purged > > as part of the systems startup sequence. So this means losing all your > > policies, ultimately a corruption of the domain controller state at the > > next reboot. > > > > Therefore, Sysvol needs to be relocated to a persistent place. > > > > I checked how this is implemented elsewhere: > > > > * On Linux systems Sysvol is typically located at /var/lib/samba/sysvol > > * On FreeBSD the location is /var/db/samba4/sysvol > > > > As /var/lib is not mentioned in HIER(7) at all, I guess this is Linux > > specific. Therefore I would propose the FreeBSD-way and put it below > > /var/db/samba4/sysvol. In addition to that I think it would be a good idea > > to relocate the variable Samba data (databases, caches) currently located > > at /usr/pkg/etc/samba/private) as well. My proposal for the target is > > /var/db/samba4/private. > > > > Attached is a patch which applies to pkgsrc-current. I did perform the > > usual tests (removing all previous configuration and databases, > > provisioning a new domain, joining a Windows client to the domain) - no > > issues so far. > > > > What do you think? > > > > Kind regards > > Matthias > > <pkgsrc_net_samba4.patch.txt> > -- ----
