Support for built-in vnc client on Mac

[detiber]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind enhancement

What happened:

virtctl vnc currently requires installing a third party application on Mac OS X in order to function

What you expected to happen:

virtctl vnc to use the built-in vnc client on Mac OS X

How to reproduce it (as minimally and precisely as possible):

Run virtctl vnc <name> on a Mac OS X host without having one of the supported third-party vnc clients installed

Anything else we need to know?:

This could either wrap open vnc://<url> or potentially call directly or potentially call the binary directly /System/Library/CoreServices/Applications/Screen\ Sharing.app/Contents/MacOS/Screen\ Sharing

[kevtheappdev]

Hi! I'm interested in working on this along with some colleagues of mine as part of a course on Virtualiztion at UT Austin. Can we work on this issue? Thanks!

[rmohr]

@kevtheappdev probably too late, but yes definitely. The client would have to be added at https://github.com/kubevirt/kubevirt/blob/master/pkg/virtctl/vnc/vnc.go#L223.

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[detiber]

/remove-lifecycle stale

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[detiber]

/remove-lifecycle stale

[rmohr]

To implement this, someone with a mac would have to take this. @mlsorensen maybe you know someone who can do that?

[xphyr]

@rmohr I am going to take a look at this, and look to implement with the open vnc://<url> command. It might actually be possible to simplify some of the OSX VNC detection code then down to just using the open command, but I need to do a little more research on this. (I do have a mac, so I can test this out... ).

[xphyr]

OK, I have spent some time testing/mocking this up. It would appear that the built in MacOS client /System/Library/CoreServices/Applications/Screen\ Sharing.app/Contents/MacOS/Screen\ Sharing requires that there be a password on the vnc server side. It will not progress with an empty password.

Doing some quick searching on the Internet pulls up a few others running into this for other projects:

• VNC connection requires password elgalu/docker-selenium#360
• https://dtechsmag.com/gns3-2-2-5-lite-vs-prolite-vs-ultimate/. (see the second to last comment)

The Screen Sharing tool does not have much documentation, and I have been unable to find any way around this requirement so far.

@detiber do you have any thoughts on this, since you opened the bug. Are you aware of anyway around this requirement?

[xphyr]

Given that the default OSX client requires a password to be used/present and password authentication is not currently supported by kubevirt, I do not think this request can be implemented. An interesting request/issue would be to enable vnc password authentication support within kubevirt to add an additional layer of security to the vnc console, then it might be possible to leverage the OSX client.

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[rmohr]

Given that the default OSX client requires a password to be used/present and password authentication is not currently supported by kubevirt, I do not think this request can be implemented. An interesting request/issue would be to enable vnc password authentication support within kubevirt to add an additional layer of security to the vnc console, then it might be possible to leverage the OSX client.

Maybe we can fake the password authentication in virctl on our proxy when we select this viewer?

[kubevirt-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[kubevirt-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

[kubevirt-bot]

@kubevirt-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.