Converting SMB1 tests to SMB2

Noel Power NoPower at suse.com
Wed Dec 4 09:38:46 UTC 2019


Hi Ralph

On 03/12/2019 15:18, Ralph Boehme wrote:
[...]
>> ok, I poked around a bit with this again today, with the ad_dc_ntvfs
>> changes the landscape of errors seems a little different and my
>> impression is not as many now hang. So maybe such instructions could be
>>
>>   + apply a small patch to the existing skip file [1]
>>
>>   + apply patches we have already to make the envs default not negotiate
>> SMB1 (with the exception of ad_dc_ntvfs)
>>
>>   + run autobuild or submit to gitlab and scrape the stdout logs with [2]
>>
>> That should suffice for (re)creating a skip file
>>
>> skip file at
>>
>> https://gitlab.com/samba-team/devel/samba/commits/npower_with_smb2_ntvfs
>>
>> was generated using above steps, verified here
>>
>> https://gitlab.com/samba-team/devel/samba/pipelines/99046676
> Looking much better.
>
> Many, many torture test really could be run only against one env instead
> of ad_dc and nt4_dc, eg
>
> samba3.base -> fileserver (and then fileserver_smb1)
> samba3.raw -> dito
>
> But that is probably a lot of work only saving one smb1 env.

so just to be clear, for example samba3.base .* tests run generally in
one or more of three environments (ad_dc, fileserver, nt4_dc) either
fileserver *or* both (ad_dc & nt4_dc) so you propose as a general rule
we run all these tests now in fileserver ? (realising of course there
may be some tests that for some reason really do need to run in ad_dc or
nt4_dc but not both)

and same proposal for samba3.raw (which uses ad_dc, nt4_dc or
*simpleserver*) so again run all in fileserver ?

I know these are probably boring questions but currently while I
understand a bit about the mechanics of how the test system works I
don't really have any knowledge about the environments and what they
target, when you should use one instead of another etc. So... hopefully
you will understand why I currently look for specific (and probably
obvious to everyone else) details

>
[...]
>> & >= SMB2 the following environments are affected
>> e.g. The following are just a few examples of legitimate tests (that
>> don't need porting) that currently would fail if run against
>> environments that cannot negotiate SMB1
>>
>> samba3.blackbox.acl_xattr.NT1\(fileserver\)
> remove this one, only run the SMB3 variant.
>
>> samba3.blackbox.inherit_owner.default.NT1\(fileserver\)
> dito. Also likely true for all the other blackbox tests that run NT1 and
> SMB3. BUt again please make micro commits so we can review and test
> individually.
>
>> samba3.blackbox.smbclient_basic.NT1\(nt4_dc_schannel\)
> remove it.
>
>> samba3.blackbox.smbclient_large_file -mNT1 -e NTLM\(nt4_dc:local\)
> remove it.
I thought from previous conversations that there was a requirement to
leave all SMB1 tests intact and running until the SMB1 code is removed?
Is this no longer a requirement or is there a special rule to use when
wielding the ax (just to be clear I am not opposed to remove SMB1 tests
:-) I just want to understand to understand the ambiguity (or realise if
I misunderstood)
>> Additionally there are quite a few tests that  use smbclient4 (and other
>> s4 clients, e.g. cifsdd, locktest etc.) and these all will fail because
>> they afaics cannot handle smb2. Could we replace use of smbclient4 with
>> s3 smbclient in these tests?
> Oh, that's a good question. :) I guess at least the
> samba4.blackbox.kinit tests could use smbclient from s3.
good
>
>> what is the plan for smbclient4, it doesn't
>> seem fully featured, is it really used outside the tests, is it worth
>> investing time to convert it to use smb2 ?
> No.
ok :-)
>
>> I see cifsdd is part of the
>> samba suite so this one needs adjusting to be able to use >= SMB2
> If feel like removing it, but maybe someone want to convert it. Until
> then the test uses ad_dc_ntvfs env, so it can stay as it is.
well cifsdd is afaics not specific to ad/dc or ad_dc_ntvfs, probably
fileserver is a better choice, I already started to port it (and have an
ugly version working, on the back burner for the moment, I guess I'll
come back to it later)
>
>> What about s4member? (and other envs that are dependant on ad_dc_ntvfs)
>> should these be additionally treated the same as ad_dc_ntvfs and allow
>> SMB1 also ?
> Iirc s4member still uses the NTVFS s4 fileserver in my branch, so yes,
> iirc my idea was that all those should keep smb1.
ok

>
> btw I opened https://gitlab.com/samba-team/samba/merge_requests/947 for
> some prep work to split tests so they can be divided across envs that
> are SMB2 only and still support SMB1 (if we ever get to that point :->>>>)
> I'll take a look tomorrow!
>
thanks alot,

Noel



More information about the samba-technical mailing list