[virt-tools-list] [virt-manager PATCH 2/2] cli: stop forking into the background
Cole Robinson
crobinso at redhat.com
Tue May 1 13:05:49 UTC 2018
On 05/01/2018 04:01 AM, Daniel P. Berrangé wrote:
> On Mon, Apr 30, 2018 at 12:47:38PM -0400, Cole Robinson wrote:
>> On 04/30/2018 12:19 PM, Daniel P. Berrangé wrote:
>>> On Mon, Apr 30, 2018 at 12:12:08PM -0400, Cole Robinson wrote:
>>>> On 04/30/2018 08:33 AM, Daniel P. Berrangé wrote:
>>>>> The behaviour whereby virt-manager forks into the background was added
>>>>> way back in:
>>>>>
>>>>> commit 99c92b9471a6a55859307071aa4a0e712991f158
>>>>> Author: Daniel P. Berrange <berrange at redhat.com>
>>>>> Date: Mon Sep 10 20:10:20 2007 -0400
>>>>>
>>>>> Refactor startup to drop controlling TTY, avoiding annoying SSH prompts
>>>>>
>>>>> While it achieves its stated goal, this is quite a big hammer to use
>>>>> with unpleasant side effects. Most end users will launch virt-manager
>>>>> from the desktop which will fork the app into the background already.
>>>>> Even when running from the command line, modern desktop environments
>>>>> will have things setup up so that all SSH prompts are intercepted and
>>>>> presented via a graphical window. Forking into the background causes
>>>>> extra pain for developers as warnings that would otherwise appear on
>>>>> stderr get lost e.g.
>>>>>
>>>>> commit 24a8b66b35c92bed919a4a6beb7c7fb80e85b3b2
>>>>> Author: Daniel P. Berrangé <berrange at redhat.com>
>>>>> Date: Wed Apr 4 14:35:40 2018 +0100
>>>>>
>>>>> avoid referencing ConnectError if it is None
>>>>>
>>>>> Currently it throws an exception at startup which is hidden unless you
>>>>> run with --no-fork
>>>>>
>>>>> The limited benefit of forking is not worth the pain it causes, so
>>>>> just start "normally" as any other GTK app would.
>>>>
>>>> I'd love to be able to drop this, but consider this case: install
>>>> virt-manager to /usr/share with this patch, then run it from gnome-shell
>>>> and try to connect to an ssh host that requires a password. ssh will
>>>> print the password prompt to stdout which the user doesn't see, and the
>>>> connection attempt just hangs until whenever ssh times out.
>>>>
>>>> This is the crux of the problem and I don't know any way around it.
>>>> There's no way to force ssh to launch askpass without forking+setsid. if
>>>> we wanted to drop passwordauth entirely for ssh and mandate keys or
>>>> other auth, we can extend libvirt to allow passing -o
>>>> PasswordAuthentication=no to ssh, but then it'd still be years before we
>>>> could drop the --no-fork behavior.
>>>
>>> You can add the 'no_tty=1' URI parameter to any libvirt remote URI.
>>>
>>> This adds '-T -o BatchMode=yes -e none':
>>>
>>> -T Disable pseudo-terminal allocation.
>>> -e escape_char
>>> Sets the escape character for sessions with a
>>> pty (default: ‘~’). The escape character is
>>> only recognized at the beginning of a line.
>>> The escape character followed by a dot (‘.’)
>>> closes the connection; followed by control-Z
>>> suspends the connection; and followed by
>>> itself sends the escape character once. Set‐
>>> ting the character to “none” disables any
>>> escapes and makes the session fully transpar‐
>>> ent.
>>>
>>> BatchMode
>>> If set to yes, passphrase/password querying
>>> will be disabled. This option is useful in
>>> scripts and other batch jobs where no user is
>>> present to supply the password. The argument
>>> must be yes or no (the default).
>>>
>>> Even in BatchMode, the graphical agent prompt will still be used
>>> for passphrases to unlock keys.
>>>
>>
>> Ahh yes I definitely knew about that at one point, thanks for the
>> reminder. Though this will kill keyless ssh access with virt-manager,
>> unclear to me if it's worth the tradeoff
>
> How does keyless ssh access currently work though - it can't prompt on
> the terminal if we've forked into background, and it doesn't appear to
> ask for passwords in the graphical ssh agent dialog ? So I'm unclear
> what we'd be using by adding no_tty=1. Amuzingly, I actually added
> this no_tty=1 feature to libvirt just after doing this fork hack in
> virt-manager, and then forgot to ever make virt-manager use no_tty=1 :-)
If openssh-askpass is installed, ssh will launch that and ask for the
password. Last I checked it can only be convinced to launch it if we
fork though
- Cole
More information about the virt-tools-list
mailing list