Converting SMB1 tests to SMB2

[Noel Power]

On 04/11/2019 09:23, Ralph Boehme via samba-technical wrote:
> On 11/1/19 7:31 PM, Noel Power wrote:
>> Hi All
>>
>> Just thought I summarize what we (myself & Ralph) discussed, for my own
>> benefit and the benefit of others.
>> ...snip...
> thanks for the summary!
>
>> problem 1)
>>
>> The mixture of xyz & xyz_smb1 test environments seems to cause strange
>> issues (see
>> https://gitlab.com/samba-team/devel/samba/pipelines/92945128), many
>> tests fail or hang. Running the tests against these environments
>> individually works no problems. Mostly I guess this is an issue with the
>> fact that the NETBIOS name of these 'duplicated' environments are the
>> same and this can cause clients to connect to the wrong server (from the
>> wrong environment)
> maybe you're just missing to assign IPs to the new testenvs in
> selftest/target/Samba.pm?

yep, good call, seems I have to pass down sever/hostname which (becomes
NETBIOSNAME), additionally the server is used as a key for interface
values which in turn are used for setting up unique IPs for each env.
Despite your best efforts to help I managed first to waste alot of time
going down the wrong road (because I didn't read carefully enough what
you meant above)

I am trying to work through the carnage resulting from my efforts to fix
this now, still lots of test erros mostly I guess just from silly
mistakes/typos while trying to modify the environments

>> problem 2)
>>
>> Yes, not being a test environment guru and being maybe a little lazy and
>> I wanted to avoid trying change the test environment foo to change or
>> pass down NETBIOSNAME  (seemed a little risky too, maybe there is other
>> things like this).  So I decided to create 2 new autobuild jobs to run
>> the smb1 tests. Unfortunately these fail in CI (see
>> https://gitlab.com/samba-team/devel/samba/pipelines/93029325) What is
>> really weird here is
>>
>>     a) running these autobuild jobs locally on my own machine causes no
>> problems, both jobs pass
>>
>>     b) running these jobs in the *same* docker container as CI uses
>> (using the same autobuild command) again works no problems
>>
>>     c) running the problematic jobs on sn-devel-184 using
>> autobuild-private-security.sh again works :-(
>>
>> I am trying (sofar unsuccessfully) to figure out why these are failing
> This looks unrelated, but maybe this will work too if you fix the above?

I don't think this is related to the ip issue because the
pseudo-duplicated testenvs were run in isolation, in fact I even
modified gitlab-ci.yml & autobuild.py to just run one of the problematic
tests (samba3.unix.info2) by itself and it fails like 99% of the time
and only passes infrequently. The test here is pretty simple, creates a
file and tests filesize (amongst other thing) test seems to fail due to
unexpected allocation file size (so seems maybe something to do with CI
filesystem funniness or something)

Anyway currently I try to get the tests running with the 'xyz_smb1' envs
running alongside the 'xyz' envs in the normal CI jobs