[qubes-users] Re: Does Qubes-OS 4.0.1 have support for KDE or GNOME desktop environment?

2019-06-12 Thread Jon deps

On 6/5/19 8:00 PM, Chris Laprise wrote:

On 6/2/19 3:41 AM, Finn wrote:

I've installed Qubes-OS 4.0.1 and it's XFCE desktop environment but I
would rather prefer either KDE or GNOME desktop environment. I found
this document[1] where mentioned that Qubes-OS is migrating towards
GNOME but at the time of installation only XFCE (neither KDE nor GNOME)
is available. I was wondering, is there a way I can use my preferred
desktop environment? Or, I have to wait for GNOME until migration is not
fully completed because it seems currently there is no support for KDE.


[1]: https://www.qubes-os.org/doc/usability-ux/


KDE does have support AFAIK, although its no long the default. If you 
can get used to the blank-space network icon, then I recommend KDE as 
there are many pluses.


I don't believe Qubes is actually going to migrate to Gnome. There was 
an aborted attempt and Gnome 3's paradigm (tablet touch UI, melded 
WM/app widgets) doesn't seem compatible with Qubes' concept.




https://www.qubes-os.org/doc/kde/

suppose one follow these instructions but does *not want to use  sddm 
nor change any windows management settings


on reboot

one is logged into XFCE  then,  in dom0  can type

startkde

or startkde --replace xfce  ?

but this seems to  result in 2 taskbars running


what would be the way to  choose the DM on login  or to startkde  and 
close xfce   or is that possible ?


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0fbaf002-8da5-f751-2969-a5afd6646e34%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present

2019-06-12 Thread Jon deps

On 6/12/19 8:14 AM, Jon deps wrote:
Hello, using the suspend function, when I awake the desktop, the usb 
mouse non longer functions.


have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start 
sys-usb  but it complained  couldn't connect  to qrexec  or so and failed.


so qvm-start sys-usb a 2nd time and then the mouse functions again


is this to be expected,  or  is there something to fix ?


---
looking around journalctl I didn't find much but did find this

un 12 07:52:01 dom0 kernel: sd 5:0:0:0: [sdb] Starting disk
Jun 12 07:52:01 dom0 kernel: sd 1:0:0:0: [sda] Starting disk
Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.7: Intel SPT PCH root 
port ACS workaround enabled
Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.3: Intel SPT PCH root 
port ACS workaround enabled

Jun 12 07:52:01 dom0 kernel: ACPI: Waking up from system sleep state S3
Jun 12 07:52:01 dom0 kernel: CPU3 is up
Jun 12 07:52:01 dom0 kernel:  cache: parent cpu3 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 3 spinlock event irq 147
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 3
Jun 12 07:52:01 dom0 kernel: CPU2 is up
Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak 
possible. See 
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for 
more details.

Jun 12 07:52:01 dom0 kernel:  cache: parent cpu2 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 2 spinlock event irq 140
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 2
Jun 12 07:52:01 dom0 kernel: CPU1 is up
Jun 12 07:52:01 dom0 kernel:  cache: parent cpu1 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 1 spinlock event irq 133
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 1
Jun 12 07:52:01 dom0 kernel: Enabling non-boot CPUs ...


went to the URL says something like I should be  "enable CPU buffer 
clearing"


but can't find how to do that, curious if it's actual needed ?



moral of the story don't suspend your qubes desktop ?




.any idea on the  "data leak possible"journal entry?

sounds a bit scary,  maybe I need to  look around in my UEFI  to disable 
 some cache-ing ?



BTW,  kudos to qubes team for the  dom0 copy to clipboard  widget , sure 
makes it easier  to get dom0  notes  out  !


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/619dd1d0-45f6-e271-c4de-2eb2303a0a8c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes: Unable to connect to VPN

2019-06-12 Thread 'Crypto Carabao Group' via qubes-users


>
> Install per the instructions for Mr.Laprise's excellent
> qubes-vpn-setup in an Template-based AppVM , don't miss any steps.
> ELSE
>
> delete the AppVM and startover make sure openvpn is installed in
> the Template chosen , make sure to enable proxy in the created AppVM
> , and for services add the openvpn in the qubes manager tab
>
> Which VPN provider are you using ?
>
>

Thanks. Turned out that we probably got it to work earlier, but didn't know how 
to test it properly.
So, we spent days trying to figure out a problem that didn't exist.

We were confused from Step 1 by fact that to create ProxyVM, one now has to 
know to create an AppVM, and check "provides network".

Setting "vpn-handler-openvpn" in the the Services for that qubes, as some 
thread suggested, is still something we are not sure about.

We've decided to move to a hardware device from the VPN provider.

With so many manual steps and several different ways to set it up, on top of 
VPN provider script variations, a device seems the safest option to avoid 
making some mistake or misunderstanding, because we are not security experts or 
developers in the field.
  
-
>
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/ac3b7cc3-eede-c2f3-d368-7de333dd3c2a%40riseup.net.
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ZMCpY0k63FxEEoDdmVtdC14qqJlZYEZTH-m9p7B5mUiIIKxzjT1TjRuQ8jSC0ONyt2DKRFHf0OC7XeDfTXd9J6TFdkjlamj967-cr97J1wM%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Full proper backup of Dom0 possible?

2019-06-12 Thread Chris Laprise

On 6/12/19 3:04 PM, Mike Keehan wrote:

On Wed, 12 Jun 2019 10:29:54 -0400
Chris Laprise  wrote:


On 6/11/19 6:50 PM, Chris Laprise wrote:

I think the best solution for a safe and comprehensive dom0 backup
is to have Qubes simply snapshot the root lv at boot time, before
its mounted as read-write. It shouldn't take more than a few script
lines in the dom0 startup. Then dom0 can be backed up like any
other vm.


I created an issue with a 3-line (barely tested) example here:

https://github.com/QubesOS/qubes-issues/issues/5094



Chris, have you some thoughts on how to restore such a backup?

Mike.


Good question. LVs can be renamed while they are active, so initiating a 
reboot process right after lvrename should work. Alternately, lvrename 
could be added to the shutdown process itself.


Another approach is to just mount the restored lv and retrieve the files 
you need from it.


The other issue with backing up dom0 is what to do about the boot 
partition. Its not active during normal use, so could be as simple as 
remounting as read-only, then 'dd' or 'tar' to a file on the root fs, 
then proceed with root snapshot and backup. Restoring it would be the 
reverse.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/39cc7d33-2a43-bc48-adb7-5cfe126c2d78%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?

2019-06-12 Thread 'interested_in_QubesOS' via qubes-users
"GRUB2. Should be UEFI with CSM disabled."

As in GRUB2 is needed for AEM?

(Just a good ol' yes or no will do, unless I'm missing an important piece of 
info.)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/GtuPNV72A9zLC7dN5q3cB64bii8owhBY_cFwUYJ9yV-dg94EyH4D5srLSTlZGc8yxnur8ilkh9BlfwJh9bsr0b0EuEZPx9js5Kd1Bun2HdE%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present

2019-06-12 Thread Daniel Moerner
On Wednesday, June 12, 2019 at 2:29:12 PM UTC-4, Jon deps wrote:
> Hello, using the suspend function, when I awake the desktop, the usb 
> mouse non longer functions.
> 
> have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start 
> sys-usb  but it complained  couldn't connect  to qrexec  or so and failed.
> 
> so qvm-start sys-usb a 2nd time and then the mouse functions again

This is a long-standing issue for some, resolved for some but not for others at 
different times. See https://github.com/QubesOS/qubes-issues/issues/4042

The situation has improved for me by getting kernel 4.19.43-1 from 
qubes-dom0-security-testing. You could try the new kernel. (But note that our 
problems might be a bit different, I never had a qrexec problem when restarting 
sys-usb after resume.)

If you need to automate restarting of sys-usb because you can't avoid this 
problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms 
for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You 
might need to qvm-kill sys-usb before suspend to get this to work reliably.

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9e6909ec-4055-416b-9db6-720f6c1363dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes: Unable to connect to VPN

2019-06-12 Thread Jon deps

On 6/12/19 2:53 PM, Chris Laprise wrote:

On 6/12/19 10:14 AM, 'Crypto Carabao Group' via qubes-users wrote:
We've also been trying for days to get a VPN to  resolve on a brand 
new R4.0 install, to either one of 2 different VPN providers, using 
the iptables and cli scripts:
https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts 


I've also set it up before on a 3.x cubes and it worked using the above.
So far, what's pretty certain is that these instructions were carried 
over automatically, but actually don't work for the R4.0 version.


BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or 
Debian 9  templates. So, wherever that came from, it's not in the new 
installer version we got.


There is no mention of a 'qubes-vpn-setup' in the vpn doc you linked to. 
That script is a part of my Qubes-vpn-support project on github. You 
might want to use that instead since the setup process is much simpler:


https://github.com/tasket/Qubes-vpn-support


Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs 
based on Fedora 29. (Haven't tried Debian 9 for that yet.)
That probably came from a particular VPN provider, and would have to 
be installed in the template anyway to persist, right?


There is no mention of 'update-resolv-conf' in the vpn doc, either.

One of the most frequent causes of failed vpn setups is when the user 
decides to mix or combine different instructions because 'more is 
better' or because they saw different people discussing the merits of 
different approaches. This does NOT work; you have to pick one and 
follow it.




It seems that the update-resolve-conf is a default script that ships 
with some distros, such as Mint (attached), and works on our other 
machine, and does the function that the "|qubes-vpn-handler.sh|" does 
in the Qubes VPN instructions, but it doesn't work on Qubes in our 
case for the same VPN provider either.
Seems to require a lot of modification and merge the two maybe, which 
will take us another several days to figure out, if ever.


Updating resolv.conf is not required at all to get DNS working for 
downstream appVMs. The instructions avoid doing this to help keep the 
VPN VM in a locked-down state, so it doesn't inadvertently try to access 
the tunnel for its internal programs (i.e. only downstream VMs get to 
access the tunnel).


What IS necessary is populating the DNAT rules in the firewall. Check 
the PR-QBS chain to see if your DNS server IPs were added: iptables -L 
-v -t nat PR-QBS





Install per the instructions for Mr.Laprise's  excellent 
qubes-vpn-setup   in  an  Template-based AppVM   , don't miss any steps. 
 ELSE


delete the AppVM and startover make sure  openvpn  is installed in 
the Template chosen ,   make sure to   enable proxy in the created AppVM 
, and  for services   add the  openvpn  in the   qubes manager tab



Which VPN provider are you using ?

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ac3b7cc3-eede-c2f3-d368-7de333dd3c2a%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Full proper backup of Dom0 possible?

2019-06-12 Thread Mike Keehan
On Wed, 12 Jun 2019 10:29:54 -0400
Chris Laprise  wrote:

> On 6/11/19 6:50 PM, Chris Laprise wrote:
> > I think the best solution for a safe and comprehensive dom0 backup
> > is to have Qubes simply snapshot the root lv at boot time, before
> > its mounted as read-write. It shouldn't take more than a few script
> > lines in the dom0 startup. Then dom0 can be backed up like any
> > other vm.  
> 
> I created an issue with a 3-line (barely tested) example here:
> 
> https://github.com/QubesOS/qubes-issues/issues/5094
> 

Chris, have you some thoughts on how to restore such a backup?

Mike.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190612200415.1932e84d.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] desktop suspend breaks sys-usb/ CPU bug present

2019-06-12 Thread Jon deps
Hello, using the suspend function, when I awake the desktop, the usb 
mouse non longer functions.


have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start 
sys-usb  but it complained  couldn't connect  to qrexec  or so and failed.


so qvm-start sys-usb a 2nd time and then the mouse functions again


is this to be expected,  or  is there something to fix ?


---
looking around journalctl I didn't find much but did find this

un 12 07:52:01 dom0 kernel: sd 5:0:0:0: [sdb] Starting disk
Jun 12 07:52:01 dom0 kernel: sd 1:0:0:0: [sda] Starting disk
Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.7: Intel SPT PCH root 
port ACS workaround enabled
Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.3: Intel SPT PCH root 
port ACS workaround enabled

Jun 12 07:52:01 dom0 kernel: ACPI: Waking up from system sleep state S3
Jun 12 07:52:01 dom0 kernel: CPU3 is up
Jun 12 07:52:01 dom0 kernel:  cache: parent cpu3 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 3 spinlock event irq 147
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 3
Jun 12 07:52:01 dom0 kernel: CPU2 is up
Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak 
possible. See 
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for 
more details.

Jun 12 07:52:01 dom0 kernel:  cache: parent cpu2 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 2 spinlock event irq 140
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 2
Jun 12 07:52:01 dom0 kernel: CPU1 is up
Jun 12 07:52:01 dom0 kernel:  cache: parent cpu1 should not be sleeping
Jun 12 07:52:01 dom0 kernel: cpu 1 spinlock event irq 133
Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 1
Jun 12 07:52:01 dom0 kernel: Enabling non-boot CPUs ...


went to the URL says something like I should be  "enable CPU buffer 
clearing"


but can't find how to do that, curious if it's actual needed ?



moral of the story don't suspend your qubes desktop ?

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3e735f62-644d-9f80-d580-ceb5ff07da94%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes: Unable to connect to VPN

2019-06-12 Thread Chris Laprise

On 6/12/19 10:14 AM, 'Crypto Carabao Group' via qubes-users wrote:
We've also been trying for days to get a VPN to  resolve on a brand new 
R4.0 install, to either one of 2 different VPN providers, using the 
iptables and cli scripts:

https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts
I've also set it up before on a 3.x cubes and it worked using the above.
So far, what's pretty certain is that these instructions were carried 
over automatically, but actually don't work for the R4.0 version.


BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or 
Debian 9  templates. So, wherever that came from, it's not in the new 
installer version we got.


There is no mention of a 'qubes-vpn-setup' in the vpn doc you linked to. 
That script is a part of my Qubes-vpn-support project on github. You 
might want to use that instead since the setup process is much simpler:


https://github.com/tasket/Qubes-vpn-support


Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs 
based on Fedora 29. (Haven't tried Debian 9 for that yet.)
That probably came from a particular VPN provider, and would have to be 
installed in the template anyway to persist, right?


There is no mention of 'update-resolv-conf' in the vpn doc, either.

One of the most frequent causes of failed vpn setups is when the user 
decides to mix or combine different instructions because 'more is 
better' or because they saw different people discussing the merits of 
different approaches. This does NOT work; you have to pick one and 
follow it.




It seems that the update-resolve-conf is a default script that ships 
with some distros, such as Mint (attached), and works on our other 
machine, and does the function that the "|qubes-vpn-handler.sh|" does in 
the Qubes VPN instructions, but it doesn't work on Qubes in our case for 
the same VPN provider either.
Seems to require a lot of modification and merge the two maybe, which 
will take us another several days to figure out, if ever.


Updating resolv.conf is not required at all to get DNS working for 
downstream appVMs. The instructions avoid doing this to help keep the 
VPN VM in a locked-down state, so it doesn't inadvertently try to access 
the tunnel for its internal programs (i.e. only downstream VMs get to 
access the tunnel).


What IS necessary is populating the DNAT rules in the firewall. Check 
the PR-QBS chain to see if your DNS server IPs were added: iptables -L 
-v -t nat PR-QBS


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/30080605-e0c5-4610-4279-1007b1e3b56f%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Full proper backup of Dom0 possible?

2019-06-12 Thread Chris Laprise

On 6/11/19 6:50 PM, Chris Laprise wrote:
I think the best solution for a safe and comprehensive dom0 backup is to 
have Qubes simply snapshot the root lv at boot time, before its mounted 
as read-write. It shouldn't take more than a few script lines in the 
dom0 startup. Then dom0 can be backed up like any other vm.


I created an issue with a 3-line (barely tested) example here:

https://github.com/QubesOS/qubes-issues/issues/5094

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5cb89da3-e586-88a0-5513-5a2b0a141010%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes: Unable to connect to VPN

2019-06-12 Thread 'Crypto Carabao Group' via qubes-users
We've also been trying for days to get a VPN to  resolve on a brand new R4.0 
install, to either one of 2 different VPN providers, using the iptables and cli 
scripts:
https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts
I've also set it up before on a 3.x cubes and it worked using the above.
So far, what's pretty certain is that these instructions were carried over 
automatically, but actually don't work for the R4.0 version.

BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or Debian 9  
templates. So, wherever that came from, it's not in the new installer version 
we got.
Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs based on 
Fedora 29. (Haven't tried Debian 9 for that yet.)
That probably came from a particular VPN provider, and would have to be 
installed in the template anyway to persist, right?

It seems that the update-resolve-conf is a default script that ships with some 
distros, such as Mint (attached), and works on our other machine, and does the 
function that the "`qubes-vpn-handler.sh`" does in the Qubes VPN instructions, 
but it doesn't work on Qubes in our case for the same VPN provider either.
Seems to require a lot of modification and merge the two maybe, which will take 
us another several days to figure out, if ever.

Openvpn actually does connect, but there's no DNS resolution, because the 
resolv.conf doesn't get updated.

One thing we noticed is that in the resolvctl the 8.8.8.8 and 8.8.4.4 and a 
couple of IPv6 servers are listed as "Fallback DNS Servers".
We can even resolve manually using them with dig.
However, the systemd-resolved or whatever is doing the resolution in this 
systemd mess, actually doesn't use them as a "Fallback" to resolve.

Don't know what to do next to fix this, except just more trial and error, and 
messy hack arounds...

On Tuesday, November 20, 2018 at 7:38:17 PM UTC, Otto Kratik wrote:
> Further update: I decided to try a completely different VPN provider's config 
> file, and to my surprise that one worked fine using the old simple method of 
> calling openvpn from the AppVM.
>
> Examining both files and looking for the difference between the two, it 
> appears the broken one did not ever invoke resolvconf include the following 
> lines:
>
> script-security 2
> up /etc/openvpn/update-resolv-conf
> down /etc/openvpn/update-resolv-conf
>
>
> Adding those lines to the non-functioning file and running it resulted in 
> success.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/J1cmNix8ygkshY3RKFWTEOuBvaV8rx7JRFEnnrurBo5JaFl-mRz9r9Osn1o3oh2vah8J4G7YPFcQ2ThmDp2U0TGQx7kV192unHv9mKU9H_M%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.


update-resolv-conf
Description: Binary data


publickey - cryptocarabao@protonmail.ch - 0x3F7D5EFD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?

2019-06-12 Thread 'awokd' via qubes-users

'interested_in_QubesOS' via qubes-users:

GRUB or GRUB2? Probably seems trivial but avoiding ambiguity makes things 
simpler. :-) A question I have to go along with this is what boot loader will 
the OS installer give me with CSM disabled?


GRUB2. Should be UEFI with CSM disabled.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6b39168a-21f2-9021-1cfb-9ba1fc0a4896%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.