Thanks so much. Ideally 'git
revert 997fbcbc902d945eb5261ddc6667f830fbcd5931' on origin/master or
origin/v4-15-test would restore the previous behaviour, but it is also
quite likely to do something else entirely.
That is because with previous (to an extent, if not individually
tested) and subsequent development (GD's patches are a series, lots of
other changes along with this specific change) would rely on that
commit and so the revert produces a new previously unintended
codepath.
You could look over the whole series and work revert it all, that
command would be:
git checkout origin/master && git revert
e168a95c1bb1928cf206baf6d2db851c85f65fa9..5ecda3bc3fbf899602a7e953d7c424f6435577d5
--no-edit && make -j
It would be an interesting data point if that worked or didn't, but
from here really we just need to wait for some of GD's developer time
to look into it. Of course you can continue using 4.14 in your
production.
I thank you deeply for all the time you have put into this, it is
really valuable to dig into this so diligently.
Andrew Bartlett
On Sun, 2021-10-17 at 15:17 +0200, Ingo Asche via samba
wrote:> Ok, I started the git bisect over and it stops working at the same
> point:
>
> commit 997fbcbc902d945eb5261ddc6667f830fbcd5931 (HEAD)
> 4.15.0pre1-GIT-997fbcbc902
>
> I will try at least the next two or three ones to see if something
> changes.
>
> That leaves the question why the revert didn't worked. Maybe I did
> something wrong. To be sure what would be the correct procedure
> again?
>
> Regards
> Ingo
>
> Ingo Asche via samba schrieb am 16.10.2021 um 12:09:
> > Hi Guys,
> >
> > the second test of git revert for
> > 22d500ec5411c3e0e82711217b15e3a6e52e0224 didn't worked either.
I'm
> > truly puzzled. I hope I done all steps correct...
> >
> > I will start the bisect over to see if it get's the same point for
> > the
> > bad one...
> >
> > Regards
> > Ingo
> >
> > Ingo Asche via samba schrieb am 15.10.2021 um 20:23:
> > > Hi all,
> > >
> > > sorry for answering so late, but it seems the git revert
didn't
> > > worked on the "git checkout
> > > 997fbcbc902d945eb5261ddc6667f830fbcd5931".
> > >
> > > To be sure I have done the test two times.
> > >
> > > I will also do the test again on "git checkout
> > > 22d500ec5411c3e0e82711217b15e3a6e52e0224" to be on the sure
> > > side...
> > >
> > > Regards
> > > Ingo
> > >
> > > Andrew Bartlett schrieb am 15.10.2021 um 11:18:
> > > > Thanks G?nther,
> > > >
> > > > I agree, I'm really surprised also. I was sure it was
going to
> > > > be a
> > > > regression in the KDC or such (we know of one of those), but
> > > > this is
> > > > why we do ask for a bisect.
> > > >
> > > > I'm also really busy so just work with Ingo when you get
the
> > > > time, and
> > > > anyone else with the issue is welcome to try the same revert
to
> > > > confirm
> > > > the meantime.
> > > >
> > > > "git revert 997fbcbc902"
> > > >
> > > > Thanks so much!
> > > >
> > > > Andrew Bartlett
> > > >
> > > > On Thu, 2021-10-14 at 23:57 +0200, G?nther Deschner wrote:
> > > > > Hi Andrew,
> > > > >
> > > > > wow, how can this patch cause such a failure?
> > > > >
> > > > > The dsgetdcname interface is only used in the s3 join
code
> > > > > (including
> > > > > offline joins where this patch became necessary) and in
some
> > > > > few
> > > > > exotic
> > > > > s3 netlogon server calls as well as in winbind. Are
there any
> > > > > logs/traces available to allow to compare success and
failure
> > > > > without
> > > > > and with the patch?
> > > > >
> > > > > I guess the real cause for the failure could be more in
the
> > > > > correctnes
> > > > > fixes for the returned dcinfo (like those in
> > > > > 22d500ec5411c3e0e82711217b15e3a6e52e0224). Maybe these
> > > > > changes show
> > > > > up
> > > > > visible in other places. I have started on a testsuite
to
> > > > > test the
> > > > > DsGetDCname interface output at least on the netapi
layer a
> > > > > while
> > > > > back
> > > > > but it is not finished yet. It could help to check if
any of
> > > > > this
> > > > > output
> > > > > mismatches expectations though.
> > > > >
> > > > > Unfortunately I'm out of office this and next week
(and
> > > > > travelling
> > > > > over
> > > > > the weekend) so I cannot really research it myself
right now.
> > > > > Sorry
> > > > > but
> > > > > I can only take a closer look again on monday.
> > > > >
> > > > > Thanks,
> > > > > Guenther
> > > > >
> > > > >
>
>
--
Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT https://catalyst.net.nz/services/samba
Samba Development and Support, Catalyst IT - Expert Open Source
Solutions