Converting SMB1 tests to SMB2

Noel Power NoPower at suse.com
Fri Nov 22 15:27:27 UTC 2019


Hi Ralph & all

I really need help with
https://gitlab.com/samba-team/samba/merge_requests/902

Currently it is marked WIP as I hoped there could be some
discussion/agreement as to the approach outlined there. In summary this
merge request imo satisfies the general discussions we had about the
approach to providing a way to iteratively push ported smb1 tests into
the codebase. As mentioned I didn't have much luck trying to make the
'_smb1' test environments fully independent, in the end it seemed this
would probably require more work than it was worth (afterall in the end
we will get rid of the smb1 tests and associated envs).

With this in mind I only create 'shallow copies' of the test envs that
have tests that fail against the new default environments which don't
support negotiation of SMB1. I added 2 new CI jobs to run the tests that
only run in environments that can negotiate SMB1. This passes CI currently

I'd really like to get this (with whatever changes are needed) upstream
so we can start on the porting proper. David is currently starting to
try and port some of the base tests and I started going through the
skip_smb1_fail list we have to split tests that mix SMB1 & >= SMB2, fix
tests that should run against SMB2 but dont't etc.

I also wanted to go through the motions of porting a test, marking it as
ported/done etc. Ralph, you had the idea of using alias environments
'_done' that I liked so I created a new branch

https://gitlab.com/samba-team/devel/samba/commits/npower_smb1_with_porting

This branch also includes the changes from
https://gitlab.com/samba-team/samba/merge_requests/902, on top of those
changes it

* creates alias '_smb1_done' envs that a test can be moved to when
'processed'
* fixes or splits tests that currently only run in a test env that can
negotiate SMB1
  e.g. where a test that mixes testing SMB1 & >=SMB2 protocols then the
test is modified so it can take a param to run either protocol, then
existing test is;
      a) modified to provide param to run SMB1 & test moved from '_smb1'
env to '_smb1_done' env
      b) copied & modified to provide a param to run >= SMB2 and test
now additionally runs against appropriate non '_smb1' env

  There are quite a few tests in the skip file that really are SMB1 only
tests,   in this case
      a) move the test from '_smb1' env to '_smb1_done' env

  In both cases the skip_smb1_fail file is updated with comments saying
the test
  has been processed

Currently ~70 tests have been 'processed' trivially in that branch. I
fear that the work there might be wasted (if the wrong approach is being
followed) so really it would be great to get this nailed down before
more complex changes happen

Noel

On 14/11/2019 12:12, Noel Power wrote:
> Just FYI
>
> I opened https://gitlab.com/samba-team/samba/merge_requests/902
>
> This branch is a return to the plan of just using some independent CI
> jobs to run the SMB1 tests (and tests failing in environments where SMB1
> can't be negotiated). These new jobs use simple 'shallow' copies of the
> existing environments.
>
> I returned to this approach due to the ever increasing amount of changes
> (and I admit failure) trying to create proper independent test
> environments (as described below)
>
> Maybe we can try with the approach outlined in the merge request and
> continue the discussion there. The sooner we have something in place
> upstream the sooner we can start chipping away at the tests :-)
>
> Noel
>
> On 08/11/2019 14:03, Noel Power via samba-technical wrote:
>> Hi All,
>>
>> On 06/11/2019 17:44, Andrew Bartlett via samba-technical wrote:
>>> On Fri, 2019-11-01 at 18:31 +0000, Noel Power via samba-technical
>>> wrote:
>>>> Hi All
>>>>
>>>> Just thought I summarize what we (myself & Ralph) discussed, for my own
>>>> benefit and the benefit of others.
>>> Thanks for writing this out.  I see in the rest of the thread that you
>>> have made some progress,
>> well yes and no :-)
>>
>> so, I did try and fix the ip uniqueness thing but...
>>
>> unique ips made some difference however there were more things, more
>> changes needed
>>
>> a) need to pass down a unique server name in order that the unique ip
>> can be created (there is a name -> interface_num hash)
>> b) but... we have alot of fake _smb1 envs and the number of interfaces
>> we have  breaks the current MAX_WRAPPED_INTERFACES limit, need to modify
>> this in third_party/socket_wrapper/socket_wrapper.c
>> c) missing certs for various tests which needed some new directories
>> (and content) setting up in various dirs under
>> selftest/manage-ca/CA-samba.example.com/DCs/
>> e) there is another problem, there is still interference between the
>> environments because an additional realm_to_ip_mappings where the realm
>> associated with the servername (and where the servername in turn is used
>> to get the ip address)
>> f) I then tried to use different realms with the smb1 environments who
>> should have entries in the table but this also was not enough, still
>> tests fail (I presume because lots of test data, database entries etc.
>> depend on the existing 'realms' used (this is speculation)
>>
>> So  CI still doesn't pass, at this point I just got too disheartened,
>> been going around in circles, don't know enough about the test setup (or
>> samba ad) to figure out (at least easily). I get the impression this is
>> a piece of string I could pull for a long time :-) and the only thing
>> that will be unravelled is my sanity
>>
>> The current errors with this approach can be seen here
>> https://gitlab.com/samba-team/devel/samba/pipelines/94064858
>>
>>>  but wanted to say that if you get really stuck
>>> again then I can certainly be of assistance. 
>> thanks, appreciated!!, I wonder would you think or agree that rather
>> than go down the rathole above that reverting to my backup plan which
>> just added 2 new smb1 jobs is a far easier route, we don't need the
>> runaway changes to the '_smb1' environments as above. ip uniqueness for
>> example should not be an issue as we run those tests in isolation in
>> their own CI job/container, these jobs/environments will go away when
>> SMB1 disappears anyway. Hopefully using such 'shallow' copy versions of
>> the environments isn't an issue or a stumbling block ? [1]
>>
>> But... there still remains the problem that in the last attempt a number
>> of tests were failing mysteriously in the new separate smb1 CI jobs. I
>> scratched my head on this, again I tried to reproduce the problems
>> locally, in docker and on sn-devel without success (everything passes
>> outside of CI). So, I returned to running just a single failing test on
>> CI (now with lots of DEBUG) and found for example that with the
>> samba3.unix.info2 test that immediately after creating a file with (0
>> bytes allocated) that STAT returns st_ex_blocks with a positive value.
>> Clearly this is something happening at the host os or filesystem level.
>> Comparing with passing tests in master the only difference is the
>> passing tests run on rackspace runners and with the failing case, the
>> tests run on shared runners. Changing the new smb1 jobs to run on
>> rackspace solves the problem
>>
>> see https://gitlab.com/samba-team/devel/samba/pipelines/94604792
>>
>> so...
>>
>> 1st can anyone enlighten me as to what is different with the rackspace
>> runners?
>> 2nd can we agree that adding the 2 new jobs is the simplest and easiest
>> way forward, once upstream this will allow us to iteratively tackle the
>> SMB1 failing tests
>>
>> thanks,
>>
>> Noel
>>
>>
>> [1] One potential problem is that the default 'make test' from source
>> will fail because of the mix or xyz & xyz_smb1 environments. However
>>   + personally I doubt that 'make test' reliably will succeed anyway
>> these days, we certainly don't test a full make test anywhere anymore,
>> imo the only reliable way to run tests is via gitlab CI (or autobuild)
>>   + with the python3 port there were jobs that were completely
>> unreliable until they were separated into python/python-3 jobs. There
>> were certainly a number of tests that couldn't be run multiple time in
>> the same env (due to destructive nature of the tests) so I think we have
>> already done this before
>>
>>


More information about the samba-technical mailing list