Converting SMB1 tests to SMB2
slow at samba.org
Thu Dec 5 11:30:36 UTC 2019
On 12/4/19 11:30 AM, Noel Power wrote:
> On 03/12/2019 14:20, Ralph Boehme wrote:
>> sorry for late reply, but I've got my head wrapped in
>> Sure. Btw, how did you figure out which tests hang?
> Looking in the CI logs
>> Do you have a list
>> of those?
> In the last mail I sent, there were instructions for generating the list
> tests that fail when all the envs by default do not negotiate SMB1, part
> of the instructions included an initial skip list, that list was
> attached to the mail,
yeah, I know, but I was not asking for the list of failing tests, but a
list with *only* the hanging tests.
I was just curious, if you don't have this, nevermind.
Btw, can you add a commit with the instructions and the script? Easier
to find then a mail in this thread... :)
this list also is the list of hanging tests. As
> mentioned my impression was the amount of hanging tests was greatly
> reduced by your ntvfs branch.
>> Ideally we can make the skiplist a knownfail list. Then every commit
>> that moves a failing test to a new *_smb1 env can comment out the list
> well that would mean starting from a point where we have tests not
> running, I don't really like that
well, only starting at one point in the patchset where you disable smb1,
but at the end of the patchset all tests would be running again. My idea
was, that this would aid in having clear, simple, reviewable, CIable
>>>> $ egrep 'ad_dc_ntvfs|ad_dc_default|ad_dc_slowtest|chgdc'
>>>> selftest/skip_smb1_fails | wc -l
>>>> 4. Add three new envs that support smb1: ad_dc_smb1, ad_member_smb1,
>>>> fileserver_smbd1, maybe more if featurewise required.
>>> when you say adding envs do you mean just 'shallow' copies or do we
>>> really need to try and go the extra mile to make these new environments
>>> properly independent (my previous attempt failed and it looked like
>>> perhaps alot of changes could ripple from trying this for little gain
>>> since the environments will be removed)
>> yes, just normal/full envs.
> I do believe (from my previous experience) that this is a can of worms,
> admittedly I may have been trying to do this the wrong way or just don't
> see the 'easy' solution, I'll try again
Let me know if you need help. 4a7ec5b7604 is an example how to add a s3
env. Just remember to also update get_realm_ip_mappings() when adding
new s4 DC envs.
Ralph Boehme, Samba Team https://samba.org/
Samba Developer, SerNet GmbH https://sernet.de/en/samba/
More information about the samba-technical