ProtonVPN / proton-vpn-gtk-app

Official ProtonVPN Linux app
https://protonvpn.com/download-linux
GNU General Public License v3.0
152 stars 20 forks source link

Support VNC session #31

Closed devqore closed 2 months ago

devqore commented 4 months ago

Is there any chance to support VNC sessions in proton-vpn-gtk-app ? Currently, I'm starting VNC session with KDE (but the Desktop Environment is not important) and when I'm starting the app I'm getting:

2024-02-16T08:02:09.514193 | proton.vpn.connection.vpnconnector:168 | INFO | CONN:STATE_CHANGED | Disconnected (initial state)
2024-02-16T08:02:09.514507 | proton.vpn.app.gtk.app:57 | INFO | APP:PROCESS_START | self=<app.App object at 0xffff84484c40 (proton+vpn+app+gtk+app+App at 0xaaab2458dad0)>
2024-02-16T08:02:09.561668 | proton.vpn.app.gtk.widgets.main.tray_indicator:45 | INFO | AyanaAppIndicator3 not found: Namespace AyatanaAppIndicator3 not available
2024-02-16T08:02:09.700696 | dbus.proxies:407 | ERROR | Introspect error on :1.10:/org/freedesktop/login1/seat/auto: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/seat/auto'.
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/proton/vpn/app/gtk/widgets/vpn/vpn_widget.py", line 139, in _on_vpn_data_ready
    self.display(self._controller.user_tier, server_list)
  File "/usr/lib/python3.12/site-packages/proton/vpn/app/gtk/widgets/vpn/vpn_widget.py", line 164, in display
    self._controller.reconnector.enable()
  File "/usr/lib/python3.12/site-packages/proton/vpn/app/gtk/services/reconnector/reconnector.py", line 95, in enable
    self._session_monitor.enable()
  File "/usr/lib/python3.12/site-packages/proton/vpn/app/gtk/services/reconnector/session_monitor.py", line 61, in enable
    self._setup()
  File "/usr/lib/python3.12/site-packages/proton/vpn/app/gtk/services/reconnector/session_monitor.py", line 102, in _setup
    seat_properties = seat_auto_properties_proxy.GetAll(SEAT_INTERFACE)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/dbus/connection.py", line 634, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/seat/auto'.
2024-02-16T08:02:09.716784 | proton.vpn.app.gtk.services.refresher.vpn_data_refresher:148 | INFO | APP.VPN_DATA_REFRESHER:ENABLE | VPN data refresher service enabled.
2024-02-16T08:02:09.716858 | proton.vpn.app.gtk.services.refresher.client_config_refresher:68 | INFO | Client config refresher enabled.
2024-02-16T08:02:09.716919 | proton.vpn.app.gtk.services.refresher.client_config_refresher:107 | INFO | Next client config refresh scheduled in 2:39:28.999014
2024-02-16T08:02:09.716952 | proton.vpn.app.gtk.services.refresher.server_list_refresher:74 | INFO | Server list refresher enabled.
2024-02-16T08:02:09.717739 | proton.vpn.session.utils:25 | INFO | API:REQUEST | '/vpn/loads'
2024-02-16T08:02:09.754349 | proton.vpn.app.gtk.services.reconnector.reconnector:176 | INFO | Network connectivity was detected.
2024-02-16T08:02:10.692619 | proton.vpn.session.utils:29 | INFO | API:RESPONSE | '/vpn/loads'
2024-02-16T08:02:10.789967 | proton.vpn.app.gtk.services.refresher.server_list_refresher:126 | INFO | Next server list refresh scheduled in 0:17:36.605211

It's because VNC session doesn't allocate any seat and app hangs on:

image

I've installed packages in the following versions:

~ rpm -qa | grep -i proton
protonvpn-stable-release-1.0.1-2.noarch
python3-proton-core-0.1.16-1.fc39.noarch
python3-proton-vpn-logger-0.2.1-1.fc39.noarch
python3-proton-vpn-killswitch-0.2.0-1.fc39.noarch
python3-proton-vpn-connection-0.11.3-1.fc39.noarch
python3-proton-vpn-network-manager-0.3.3-1.fc39.noarch
python3-proton-vpn-network-manager-openvpn-0.0.4-1.fc39.noarch
python3-proton-vpn-killswitch-network-manager-0.2.0-1.fc39.noarch
python3-proton-vpn-session-0.6.5-1.fc39.noarch
python3-proton-vpn-api-core-0.20.3-1.fc39.noarch
proton-vpn-gtk-app-4.1.10-1.fc39.noarch
python3-proton-keyring-linux-0.0.1-1.fc39.noarch
python3-proton-keyring-linux-secretservice-0.0.1-1.fc39.noarch
proton-vpn-gnome-desktop-0.2.0-1.fc39.noarch
protonvpn-cli-2.2.11-9.fc39.noarch

Output from loginctl command:

~ loginctl                
SESSION  UID USER SEAT TTY STATE   IDLE SINCE
     c1 1000 XXX        n/a closing no        

1 sessions listed.

protonvpn-cli works, but it would be nice to use gtk-app on headless stations only with VNC session started.

calexandru2018 commented 2 months ago

We can't do this with the GUI at this point as w're using NM which relies on polkit, and it always requires a "sitting" user, so unless you modify it yourself the rules it won't work for you, but from our side since this is not a scenario that we cover we won't be "fixing" this.

devqore commented 2 months ago

so unless you modify it yourself the rules it won't work for you

@calexandru2018 could you elaborate? What rules can be added to make this work on the VNC session?

calexandru2018 commented 2 months ago

It honestly depends what is the version of the polkit, >= v0.106 have a different structure from <= v0.105. Lastly you can read more about actions here: https://wiki.archlinux.org/title/Polkit#Actions

It's quite extensive so it's a bit impossible to give you a breakdown, but in a very short TL;DR: You need to make sure that polkit allows changes to networks from a non present person (VNC, SSH), but rather remotely.

devqore commented 2 months ago

@calexandru2018 but how granting privileges will solve a reported problem:

2024-02-16T08:02:09.700696 | dbus.proxies:407 | ERROR | Introspect error on :1.10:/org/freedesktop/login1/seat/auto: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/seat/auto'.

there will be different privileges but still, there will be no such object, as in the VNC session seat is not allocated. Also, the network manager works without any issues. Also, usually, when the application lacks privileges it shows a popup to ask for a password to get them.

calexandru2018 commented 2 months ago

Hey @devqore you're right my bad I miss-read it. It seems that you don't have org.freedesktop.login1, in other words systemd-logind working. We require this process so that we can reconnect the user after a network change, network drop or when the sessions is locked (when locking screen or going to sleep). This leads me to thing that you don't have it running. Also DE is somewhat important because we currently only tests against Gnome DE and not KDE, and even though our app should work on KDE it's not tested and thus not fully (and officially) supported.

This should be solved once we release a new CLI, until then this won't be fixed because this is meant to be running on a usual desktop setup which has session handling.

devqore commented 2 months ago

Thank you @calexandru2018, for your answer, but still I think the case is a bit different. There is systemd-logind session, but there is no seat allocated. Let me try to show with a few commands, according to busctl tree there can be login /org/freedesktop/login1 session without a seat:

$ busctl tree org.freedesktop.login1                         
└─ /org
  └─ /org/freedesktop
    ├─ /org/freedesktop/LogControl1
    └─ /org/freedesktop/login1
      ├─ /org/freedesktop/login1/seat
      │ └─ /org/freedesktop/login1/seat/seat0
      ├─ /org/freedesktop/login1/session
      │ ├─ /org/freedesktop/login1/session/auto
      │ └─ /org/freedesktop/login1/session/c2
      └─ /org/freedesktop/login1/user
        ├─ /org/freedesktop/login1/user/_1000
        └─ /org/freedesktop/login1/user/self

and loginctl confirms existing session:

$ loginctl session-status
c2 - myusername (1000)
           Since: Sun 2024-03-24 20:40:39 CET; 3 weeks 3 days ago
          Leader: 2374 (xrdp-sesman)
         Display: :10
         Service: xrdp-sesman; type x11; class user
           State: active
            Idle: no
            Unit: session-c2.scope
                  ├─2374 /usr/sbin/xrdp-sesman --nodaemon
                  ├─2375 /bin/sh /home/myusername/.Xclients
                  ├─2376 Xvnc :10 -auth .Xauthority -geometry 1920x1162 -depth 32 -rfbauth /home/myusername/.vnc/sesman_passwd-myusername@my.hostname:10 -bs -nolisten tcp -localhost -dpi 96
                  ├─2378 /usr/sbin/xrdp-chansrv
                  ├─2697 /usr/bin/ssh-agent /home/myusername/.Xclients
                  └─2698 startplasma-x11

also confirms lack of the seat:

$ loginctl seat-status   
Could not get properties: Unknown object '/org/freedesktop/login1/seat/auto'.

systemd-logind service is also up and running:

$ systemctl status systemd-logind     
● systemd-logind.service - User Login Management
     Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
    Drop-In: /usr/lib/systemd/system/systemd-logind.service.d
             └─10-grub2-logind-service.conf
             /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2024-03-24 20:38:37 CET; 3 weeks 3 days ago
       Docs: man:sd-login(3)
             man:systemd-logind.service(8)
             man:logind.conf(5)
             man:org.freedesktop.login1(5)
   Main PID: 879 (systemd-logind)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18642)
   FD Store: 0 (limit: 512)
     Memory: 3.9M
        CPU: 2.778s
     CGroup: /system.slice/systemd-logind.service
             └─879 /usr/lib/systemd/systemd-logind

If I attach monitor and peripheral devices to this station (normally is started headless) and I'll start KDE session then app works correctly, but then is allocated seat, so the problem is not ratter related to DM (also on daily basis on regular workstation works perfectly with Xfce).

Of course, I have a workaround for it, and I'm managing ProtonVPN via CLI, but I really like GUI app, and still I'm thinking that's a valid use case to have a headless workstation for research purposes and not only use it via SSH but also with VNC/XRDP with a valid session but without a seat.

Anyway, thank you for your time, and I'm looking forward to CLI update, as recent updates broke something (right now I don't even remember what hack I had to apply, but possibly it was related to fedora packaging).

calexandru2018 commented 2 months ago

Yeah gotcha thanks for clarifying it 👍🏻 As I previously mentioned we do really depend on that mainly for the reconnect logic so there's no way around it currently. Can I ask you which CLI you were talking about, is the community one ?

devqore commented 2 months ago

No, about this one described here https://protonvpn.com/support/linux-vpn-tool/, the community one was the solution for me. On the headless machine, I don't have any proton VPN rpm installed:

$ rpm -qa | grep -i proton

but instead:

$ pip freeze | grep -i proton
-e git+https://github.com/ProtonVPN/linux-cli-community@568dc778c3247cc920d7af909c119d671d883900#egg=protonvpn_cli

But currently, I can't provide more details, also I didn't report it as I hoped to get GUI working. But I'm pretty sure that dependencies have been broken and CLI didn't exist or it was unusable in the mentioned in the documentation Fedora repositories. I'm using a Proton VPN Plus license.

If there is another possibility to use ProtonVPN via CLI which you recommend I can try to use it.

calexandru2018 commented 2 months ago

No, about this one described here https://protonvpn.com/support/linux-vpn-tool/

Hmm that's odd, we haven't made any changes to V3 so if it worked before it should continue working, unless some packages have been updated on the distro that somehow broke something, but that shouldn't be the case I suspect. But also do note that this client has been deprecated in favor of v4, so currently we don't have an official CLI but we'll try to prioritize it once we finish WireGuard for the current app.

the community one was the solution for me.

The community one will eventually be discontinued because we keep creating API hacks for it and it's becoming unsustainable, plus it has not been maintained in +2 years, so I would advise against using it if possible.

If there is another possibility to use ProtonVPN via CLI which you recommend I can try to use it.

You can always go the manual way:

You can download a config for a country instead of a server and this way you'll ensure that if that server goes into maintenance if always have backup servers to connect to.

devqore commented 2 months ago

Understood. I'm aware of WireGuard and OpenVPN but I'm changing often countries, and it would require a lot of manual configurations. Of course, I could automate it somehow but that's not the point if the app is (or should be) in place.