Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Sat, 22 Dec 2018 18:48:56 -0800
In message <82004750-097A-47E5-9981-86B4B7A5F755_at_gmail.com>, Enji 
Cooper writes
:
> > On Dec 22, 2018, at 1:03 PM, Cy Schubert <Cy.Schubert_at_cschubert.com> =
> wrote:
>
> =E2=80=A6
>
> > Regarding the Red Hat bugzilla bug, looks like they're doing the right
> > thing by reaching out to VMware. This should be our position as well.
> > Add it to ssh_config or sshd_config if one must but have VMware fix
> > their bugs. Putting workarounds in our O/S to work around a bug in =
> some
> > other vendor's virtualization is something I don't support. If we must
> > add the #ifdefs to our ssh, then add an UPDATING entry to say that to
> > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable =
> it
> > in src.conf.
>
> This is the reason why I CCed mp_at_ :).. Mark works for VMware (I worked =
> with him a bit when I was at Isilon).
>
> =E2=80=A6
>
> > We, FreeBSD, should try to open a ticket or reach out to VMware to add
> > a +1 to the issue that RH has already opened. This is the right thing
> > to do. In this case we should consider ourselves an O/S vendor too,
> > which BTW we are.
>
> Yes, but unless there=E2=80=99s a champion internal to the project =
> driving this, it=E2=80=99s up to individual users to drive the bug =
> report/fix. If, however, there were regular regression tests run with =
> VMware (and this can be done with pyvmomi/paramiko, etc), then we the =
> project could provide this guarantee to VMware and vice versa if VMware =
> invested the time in making this so--which I thought they did with =
> 10.x=E2=80=A6 but if they don=E2=80=99t have an easy way to verify =
> changes, there=E2=80=99s a bit of a chicken and egg problem.

I'm suggesting we do.

Regression tests might require that FreeBSD have a VMware cluster of 
one or preferably two machines somewhere. That is if VMware is willing 
to "help" out. The reason I suggest a cluster of two is vmotion can 
negatively affect some applications (Oracle RAC comes to mind). It 
would be interesting to find out how FreeBSD and apps running on 
FreeBSD react to being vmotioned from one ESXi host to another.

Testing vCPU and vRAM hot add are other items that should be in our 
test suite.

How well would FreeBSD work with vNUMA?

>
> > BTW the 2018-11-08 entry in the RH bug talks about adding the
> > workaround to sshd_config.
>
> =E2=80=A6 which is what I did instead of making the code change.

Does this suggest that sshd on servers running under VMware are also 
affected, i.e. ssh session from a computer not running on VMware such 
as from real hardware or a from PuTTY session o a PC to sshd on a VM?

>
> Thanks so very much for the patch and (more importantly) for the =
> discussion/solution Yuri!! I really appreciate your unblocking me.

Yes, thank you Yuri for pointing out the problem and providing a 
solution.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_cschubert.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.
Received on Sun Dec 23 2018 - 01:51:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC