Re: [PATCH] net/samba4: relocate Sysvol to persist between reboots & move variable data out of /usr/pkg/etc/...

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Wed, 29 Jul 2020 at 08:33, Matthias Petermann <mp%petermann-it.de@localhost> wrote:
>
> Hello Chavdar,
>
> Am 28.07.2020 um 18:48 schrieb Chavdar Ivanov:
> > 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:
> > ....
>
>
> that still looks like a file system inconsistency. Before the patch from
> Chuck I also had the case several times that a filesystem that was
> apparently repaired with fsck could no longer be trusted. After
> importing the patched kernel, to be on the safe side, I recreated all
> the file systems previously mounted with posix1eacls with newfs.

Hard that one, as it was the root file system... Anyway, a couple of
fsck's seem to have sorted out this one.

> Presumably fsck is not prepared for the kind of inconsistency, and only
> a newfs can restore a trustworthy initial state. What is the starting
> point for you? Has the file system been created after the patch, or has
> it only been treated with fsck so far?

I think it may have been created before the patch to the filesystem
code, but before the second version of the samba4 package.

>
> In any case, I would advise you - if you have not already done so - to
> use a separate partition or LVM volume for the sysvol with its own file
> system, and to mount only this with the posix1eacls option. It seems the
> ACL code still needs a lot of testingh, so at least you can be sure that
> your root filesystem will not be affected.

As this was running on a XCP-NG guest, I added a small 1GB disk to the
vm, created the filesystem (-O 2) and mounted it on /var/db/samba4.

I removed the 'posix1eacls' options from the other existing
filesystems and left it only for the one mounted on /var/db/samba4 .
In this case, the provisioning fails with a message that the
filesystem does not support acls - so it perhaps checks  the root
filesystem after all. I then re-added this option to /, newfs'd
/var/db/samba4, rebooted and retried the provisioning. This resulted
in a similar to the above panic, this time after perhaps 10 minutes
work of python8 doing database conversion from v1 to v2 - the third
database in the list. As this was seen on the console of the XCP-NG
guest, I took screenshots of the panic, in case someone is interested.

So no provisioning, unfortunately. The second machine I tried it on is
my main development box, perhaps I have been a tad too confident with
it, so I won't try for now on it, but will spin another box with only
samba4 installed via pkgin to make sure there is nothing in the way of
testing.

My problem may be related to having the 'log' option in the fstab, though.

>
> Definitely good to know that you also test with Samba - many eyes see
> more :-)

Sure, it is useful to get it running properly under NetBSD. So far I
always maintain a couple of Windows 2019 servers at home as DCs - the
evaluation versions come with six months license, but you have I think
rearm count of 5, so you can use it for three years, effectively for
free; I would like to test all other options, though - with second DC
under NetBSD etc.

I also can't figure out how to deal with DNS - I have a server in the
network, which is setup as a forwarder to the same subnet as the DC;
the DC registers in its internal database itself and all added hosts,
but the rest of the network can't resolve those - without manually
adding them to the other DNS server.

>
> Best wishes
> Matthias

Cheers,

Chavdar



-- 
----