Does not auto-start in newer templates

[VPNReyMan]

As a result of debugging issue #38 it has been discovered the script does not work in Fedora 29. No DNS can be resolved. Not even when using the qubes resolver scripts as noted in the docs: /usr/lib/qubes/qubes-vpn-ns up

Not even with copying the update-resolv-conf file from debian packages as this is not included in fedora packages will it work.

Utilizing the exact same installation method as in debian it simply does not work.

It should probably be noted in the documentation that this does not work in fedora >= 29 so that it saves people time. Especially considering fedora is the primary and default templates in qubes.

[tasket]

OK, thanks! Maybe I'll also find a workaround, but I suspect it may involve installing iptables or converting firewall scripts to nftables.

[VPNReyMan]

Fedora-29 utilizes iptables as far as I can tell. Iptables are installed in the default qubes templates, so they were definitely installed when I attempted.

I am pretty sure this worked in fedora 28, so it is a change between 28 -> 29. I tested it in 28 I believe before (it could have been qubes-tunnel though) and it worked. I believe I did it with the Azire free trial too.

This time I installed both qubes-tunnel and qubes-vpn-support (fresh templates each time) and it did not work. I then installed in debian using the same process and it worked as expected.

[dylangerdaly]

I can confirm it works with Fedora 29, but not Fedora 30.

For me at least.

[tasket]

@dylangerdaly @VPNReyMan
I'm testing it now and although I don't have fedora-29, I'm experiencing the problem on both fedora-30 and debian-10.

It appears related to the newer systemd not wanting to reload-then-start a newly registered service.

Also, notify-send is broken in these newer templates. The command hangs for 20sec and displays nothing.

Workaround

On a proxyVM with the Qubes-vpn-support installed, I could manually run sudo /rw/config/rc.local and after a while (due to notify-send) it would come online.

A better workaround might be to use debian-9 template for now.

[tasket]

Added issue #40 for notify-send delays.

[tasket]

There's a possible fix posted in 1.4.1 branch ... not tested.

[tasket]

The more I look at this, the more it appears to be solely caused by notify-send hanging. Here is the result of my testing:

• Debian 9 – Works
• Debian 10 – Works, unless KDE in template
• Fedora 30 – Not working. Notify-send delays result in constant vpn service restarts.

You should find that connection occurs normally and DNS works in regular Debian 9 and 10 templates.

The workaround for the rare Debian 10 KDE scenario is to comment-out all lines in '/usr/share/dbus-1/services/org.kde.plasma.Notifications.service'. This allows the 'mate' version of the service to operate.

A Fedora workaround is possible if you comment-out the notify-send lines in the scripts qubes-vpn-ns and qubes-vpn-setup. I've tried this and it works, but then there are no popup notifications for the connection.

[tasket]

The latest in the 1.4.1 branch has an automatic workaround for Fedora, but there are no popup notifications.

[tasket]

I might try zenity sometime, but would rather not switch to a GTK+ specific tool to avoid a large bug that Fedora needs to fix in their UI. OTOH, if notifications are no longer supported during system startup, Fedora needs to document that.

People tend to forget that Fedora is, by definition, a non-production quality OS. Its meant as a way to try out relatively untested code for later release in RHEL. The fact that Qubes still uses it is pretty scary.

[tasket]

I re-enabled notifications after some Fedora updates to see what would happen: The notification problem appears to be fixed and it now connects with popups.

If someone else wants to try the latest in 1.4.1 branch with fedora-30 that would be great.

[hugoncosta]

Using Fedora-30, with the newest version of this software, the notification appears as expected, thank you very much!