[virt-tools-list] [virt-manager PATCH 2/2] cli: stop forking into the background

Cole Robinson crobinso at redhat.com
Mon Apr 30 16:47:38 UTC 2018


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

- Cole




More information about the virt-tools-list mailing list