xpra icon
Bug tracker and wiki

Opened 8 months ago

Last modified 3 months ago

#1527 assigned enhancement

win32 system shadow service

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.3
Component: platforms Version: trunk
Keywords: win32 Cc:

Description

Split from #389, similar to #1105 for Linux, we want to have a system wide service running even before the user logs in.
Users can then trigger a login.

Some links already added in ticket:389#comment:23.

Attachments (5)

service-mingw.patch (2.7 KB) - added by Antoine Martin 8 months ago.
patch for building the service example with mingw
start-shadow-from-proxy.patch (8.1 KB) - added by Antoine Martin 8 months ago.
ugly work in progress patch to use on top of r15971
logon.patch (22.6 KB) - added by Antoine Martin 8 months ago.
work in progress logon patch
logon-v2.patch (50.2 KB) - added by Antoine Martin 8 months ago.
logon succeeds but launching the new process does not..
logon.py (17.8 KB) - added by Antoine Martin 8 months ago.
this implementation does not work - but has some useful functions

Download all attachments as: .zip

Change History (15)

comment:1 Changed 8 months ago by Antoine Martin

Status: newassigned

Blocked by #1528.

comment:2 Changed 8 months ago by Antoine Martin

With the cx_freeze 5 workarounds added in ticket:1528#comment:2 and the service stub added in r15933 +

r15934 (based on cx_Freeze samples: service), a "Xpra-Service.exe" is created - it just doesn't do anything when you run it...

The documentation is non-existent, and the executable doesn't give you any help at all. But I eventually found that we're supposed to install it by running:

Xpra-Service.exe --install NAME [configfile]

Problem is that this fails with:

Service not installed. See log file for details.

What log file you ask? Well "./.log" obviously, NOT. This file contains:

[04380] 2017/05/23 22:46:14.473 starting logging at level ERROR
[04380] 2017/05/23 22:46:14.520 Win32 error 0x5 encountered.
[04380] 2017/05/23 22:46:14.520     Context: cannot open service manager
[04380] 2017/05/23 22:46:14.520     Message: Access is denied.

[04380] 2017/05/23 22:46:14.520 ending logging

Fine, let's run it as administrator:

[02964] 2017/05/23 22:49:55.695 starting logging at level ERROR
[02964] 2017/05/23 22:49:55.757 Win32 error 0x57 encountered.
[02964] 2017/05/23 22:49:55.757     Context: cannot start service
[02964] 2017/05/23 22:49:55.757     Message: The parameter is incorrect.

[02964] 2017/05/23 22:49:55.773 ending logging

At least the service is registered and visible in the "Services" control tool, and the same error message is available in the "eventvwr".
We'll need to get rid of "cx_Logging", it's unmaintained since 2014, undocumented (which filename is used from the service?) and generally not helpful.

Last edited 8 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 8 months ago by Antoine Martin

OK, the reason why this fails with the cryptic error 0x57 is because the path to the service binary is empty (for whatever reason).
Assuming that the service has been installed using:

Xpra-Service.exe --install XPRA-TEST

The path can then be changed using regedit, or using Sc config.
First query the service:

sc qc XpraXPRA-TEST

Change the path:

sc config XpraXPRA-TEST binPath= "C:\Program Files\Xpra\Xpra-Service.exe"

We can now also set it to auto-start:

sc config XpraXPRA-TEST start= auto

With these changes, starting the service takes longer to fail.. but fail it does with: Error 1053: The service did not respond to the start or control request in a timely fashion
We can find the service PID with:

sc queryex XpraXPRA-TEST

Then kill it with:

taskkill /f /pid $PID

We could workaround the broken path installation by running the "sc config" commands after the service registration, still as part of the EXE / MSI

installation process.

But the fact that the process does not respond is more problematic...
Ideas:

  • maybe the paths workarounds need to be applied to the service class (in C)
  • maybe use a simple shim? a simple C service that (re)starts the real xpra proxy server?

The shim would allow us to continue to use cx_freeze 4.x (no need for #1528). Some links for that:

Last edited 8 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 8 months ago by Antoine Martin

Difficulties in building the Complete Service Example with mingw:

Last edited 8 months ago by Antoine Martin (previous) (diff)

Changed 8 months ago by Antoine Martin

Attachment: service-mingw.patch added

patch for building the service example with mingw

comment:5 Changed 8 months ago by Antoine Martin

Stub cx_freeze5 service removed in r15960 (#1528 re-scheduled), replaced in r15962 by a shim implemented in C.

Still TODO:

  • fix authentication problems
  • remove hard-coded command line path: load settings from a config file?
  • innosetup script changes: upgrading windows service using inno setup - maybe just ship the "SvcConfig?" and "SvcControl?" command line tools instead?
  • start new sessions / locate existing ones and run the shadow under that user account
  • fix event logging: we have to use event codes in the resource file (yuk)
  • re-enable SSL: substitute commonappdata to locate the cert - or just generated the path in the config file

Notes:

Last edited 8 months ago by Antoine Martin (previous) (diff)

Changed 8 months ago by Antoine Martin

ugly work in progress patch to use on top of r15971

Changed 8 months ago by Antoine Martin

Attachment: logon.patch added

work in progress logon patch

comment:6 Changed 8 months ago by Antoine Martin

The ugly and incomplete patch above does:

And adds a small Login-Test.exe utility. Problem is that this works when running from the service context, but not when running directly from the utility - even when running from an administrator shell. This is going to make development and testing tedious.

Some useful links:

Last edited 8 months ago by Antoine Martin (previous) (diff)

Changed 8 months ago by Antoine Martin

Attachment: logon-v2.patch added

logon succeeds but launching the new process does not..

comment:7 Changed 8 months ago by Antoine Martin

With the patch above, I could logon but when trying to start the server, or even a test application like whoami.exe with all of its dlls installed, the event log would show:

Application popup: Xpra_cmd.exe - Application Error : \
The application was unable to start correctly (0xc0000142). Click OK to close the application.

The environment looked suspicious, but since we use the LOGON_WITH_PROFILE flag, it should be OK. (will need to re-check that)
See What is up with "The application failed to initialize properly (0xc0000142)" error?, which has lots of relevant information. (and some dead links too.. sigh)
Also some pointers here: The Perils and Pitfalls of Launching a Process Under New Credentials.
It was just missing the desktop name in the STARTUPINFO.... (not obvious)
Now maybe we also need permission to access that desktop? As per CreateProcessAsUser() windowstations and desktops, because the resulting screen is empty.

comment:8 Changed 8 months ago by Antoine Martin

r15980 adds all the hooks for starting the shadow process from the service.
Still TODO:

  • remove hard-coded command line path: load settings from a config file?
  • innosetup integration
  • add firewall rules: How to use the "netsh advfirewall firewall", ie:
    C:\Windows\system32>netsh advfirewall firewall add rule name="Open Port 14500" d
    ir=in action=allow protocol=TCP localport=14500
    
  • re-enable SSL: substitute commonappdata to locate the cert - or just generated the path in the config file
  • innosetup script changes: ​upgrading windows service using inno setup - maybe just ship the "SvcConfig??" and "SvcControl??" command line tools instead?
  • don't use a fixed TCP port, use named pipes via the system proxy - or enhance the client to support a redirect and use OTP (which we can supply to the shadow process using env auth)
  • html5 client connection fails, re-tries: we end up creating new shadow server instances... don't retry on fatal error (html5), don't create a new shadow if one exists!
  • fix event logging: we have to use event codes in the resource file (yuk)
  • the desktop we get is empty! why?
  • start new sessions / locate existing ones and run the shadow under that user account
  • integrate with "remote desktop services" #1532
Last edited 8 months ago by Antoine Martin (previous) (diff)

Changed 8 months ago by Antoine Martin

Attachment: logon.py added

this implementation does not work - but has some useful functions

comment:9 Changed 6 months ago by Antoine Martin

Milestone: 2.12.2

too late for 2.1

comment:10 Changed 3 months ago by Antoine Martin

Milestone: 2.22.3
Note: See TracTickets for help on using tickets.