from:"Chris Laprise"

Re: [qubes-users] sys-net and KDE

2018-11-17 Thread Chris Laprise

On 11/17/2018 04:44 AM, aaq via qubes-users wrote:

Hello!

So, I switched to KDE as you can see in some other threads, and honestly I like
it way better than XFCE.

My biggest issue right now however is, that the network manager applet does not
show in KDE. I get notification when I start my session that I am connected to
my network, and I do have connectivity. I am however not able to use the applet
to connect to new networks or generally initiate network manager related
actions.

I run Qubes 4.0.0, and my sys-net runs the fedora-28 template (without
modifications).

I have tried googling around but could not seem to find a solution. I found an
old fedora thread stating that there is a package that can be used for network
manager in KDE (I can't seem to find it again). That package didn't work
however.

I have tried opening a terminal in sys-net, killing nm-applet and starting it
again. That does not seem to work either.

Any comments/suggestions welcome!

Thanks in advance!

This is a known issue with KDE. You should still have a blank icon
representing Network Manager in the systray. Finding it is easy, just
hover your pointer over the icon spaces and you'll see '[sys-net]
Network Manager Applet'. Its pretty easy to use it like this once you're
used to it.

I've done some investigation for (hopefully) a permanent fix, but don't
have time to work on it right now.

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/65137488-24b2-e0a1-428c-21bc4a56157e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] alternative to bloated templates for faster work and minimal boot time/resources used

2018-11-15 Thread Chris Laprise

On 11/15/2018 12:29 PM, 799 wrote:

Hello,

Am Do., 15. Nov. 2018, 09:44 hat <mailto:travorfirefuel...@gmail.com>> geschrieben:

Is it possible to transfer sys-net/sys-usb/sys-vpn/sys-whonix to
100mb templates based on musl/busybox/sysvinit linux ?
(...)

my sys-vms are based on fedora-28-minimal templates.
Honestly I like the idea and think smaller is better, but as I am
running lots ~8-12 AppVMs when working productively most ressources are
used by those VMs.

I don't think that you gain that much ressources by switching sys-vms.
And honestly storage capacity is not a big deal today ;-)

Disk capacity shouldn't be a big issue unless you like to make lots of
template variations.

For RAM efficiency the available templates are already pretty efficient,
but the Qubes RAM allocation algorithms could be better. Manually
setting the maximum RAM has worked great on my 8GB system: about 350MB
for each service VM, 700-900MB for media playback, 1500-2500MB for
browsing and other heavy apps. Finally, I set the dom0 max to 1500MB in
/etc/default/grub. Using debian-9 templates, these ranges result in a
system that is *much* more usable than it would be with the default RAM
allocation; I highly recommend it.

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/d272fbef-32ad-5db6-1a7a-9ad012f8e072%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Two VPN questions and one Qube Manager question.

2018-11-01 Thread Chris Laprise

On 11/01/2018 11:55 AM, Fidel Ramos wrote:

‐‐‐ Original Message ‐‐‐
On Thursday, November 1, 2018 1:59 AM, Chris Laprise wrote:

On 10/31/2018 03:06 PM, entiosis via qubes-users wrote:

1. I’ve successfully managed to set up a “ProxyVM” (or “AppVM” as it is called
in Qubes 4.0) to run as VPN gateway with Private Internet Access (PIA)/Openvpn
by following the guide in qubes documentation;
https://www.qubes-os.org/doc/vpn/ and
https://www.youtube.com/watch?v=K1_zqT7_N7k
PIA provides 33 gateways around the world to choose from, what I wonder
is; how can I (easily) change and choose the various gateways of the sys-vpn
(ProxyVM) as I normally can when directly using PIA? I may need to make my IP
appear to come from one specific country, or have the desire to change from
which country I’ve been connected to after a while. Also, can the ProxyVM be
set to make gateway connections at random?

It would not be too hard to write a shell script that shows all the ovpn
files in the /rw/config/vpn dir and lets you pick one. Then simply link
('ln -s') the chosen ovpn file to "openvpn-client.ovpn". Finally, tell
openvpn to (re)start. It also wouldn't be too hard to do this manually
if you don't change locations very frequently.

I'm starting work on a systray icon for Qubes-vpn-support that will make
changing the VPN configuration a breeze. Please check out this Github issue:

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

Thanks for mentioning this. It got buried in my stack of open tabs and I
needed a reminder :)

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/39eb4dc9-58b1-8ea6-5549-0e056cafb3ec%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Two VPN questions and one Qube Manager question.

2018-10-31 Thread Chris Laprise

On 10/31/2018 03:06 PM, entiosis via qubes-users wrote:

1) I’ve successfully managed to set up a “ProxyVM” (or “AppVM” as it is called
in Qubes 4.0) to run as VPN gateway with Private Internet Access (PIA)/Openvpn
by following the guide in qubes documentation;
https://www.qubes-os.org/doc/vpn/ and
https://www.youtube.com/watch?v=K1_zqT7_N7k
PIA provides 33 gateways around the world to choose from, what I wonder is; how
can I (easily) change and choose the various gateways of the sys-vpn (ProxyVM)
as I normally can when directly using PIA? I may need to make my IP appear to
come from one specific country, or have the desire to change from which country
I’ve been connected to after a while. Also, can the ProxyVM be set to make
gateway connections at random?

2) The Qubes doc mention that if I want to be able to use the Qubes Firewall I
should create a new Firewall VM. How do I actually create a Firewall VM that
uses Qubes Firewall? I assume there must be a different process than a normal
“create new qube”.
Also, is it actually needed to add a firewall behind the VPN? AppVM →
sys-vpn-firewall → sys-vpn → sys-firewall → sys-net, it just seems like a
overly long line to me.

A Debian or Fedora AppVM created with "provides network" is by default a
Qubes firewall. But it is unnecessary to stack them so extensively in
Qubes 4.0. If your VPN provider uses verification certificates (most do)
then all you probably need is AppVM -> sys-vpn -> sys-net. If you wish
to add firewall rules to protect an AppVM you can do so on the Firewall
tab of the AppVM's settings; in my example sys-vpn will then act on
those rules and in your example sys-vpn-firewall would act on them.

3) The “Autorefresh” button in Qube Manager have magically disappeared from the
tool bar. Its supposed to be located in Dom0 Qube Manager, to the right of the
three icons; Global Setting → Backup Qubes → Restore Qubes From Backup →
“Missing” Qube Refresh.
Is there any fairy dust I can sprinkle on the terminal in dom0 to make that
button reappear?

Wish I could help you there. QM has been in a lot of flux for the past year.

Please keep in mind that I'm a newbie Qubes user and a fairly new Linux (Mint)
user of just a couple of years if/when you of you reply to these questions.

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/59af7254-458c-d2d4-b7ee-fc32adc931d4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installation Problem

2018-10-29 Thread Chris Laprise


On 10/29/2018 03:32 PM, Andy Powell wrote:

Well that clears it up! Thanks!!!

Very surprising...guess I’ll go to another distro. Bye Qubes!



Its not surprising at all. Qubes is a bare-metal OS, and one of its core 
features is to isolate risk at the hardware level.  This means on a Mac 
it _replaces_ OS X -- it doesn't run on it. A more logical arrangement 
would be to run OS X on Qubes which is the reverse of what you seek.


--

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/9840f411-1cd4-2fe9-c7b4-0a4675db90ca%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN-setup ''mv: cannot stat ... No such file or directory''

2018-10-23 Thread Chris Laprise

On 10/23/2018 11:52 AM, alexander.ibrahi...@gmail.com wrote:

Den tisdag 23 oktober 2018 kl. 17:25:11 UTC+2 skrev unman:

On Tue, Oct 23, 2018 at 08:08:50AM -0700, alexander.ibrahi...@gmail.com wrote:

Den tisdag 23 oktober 2018 kl. 16:29:29 UTC+2 skrev unman:

On Mon, Oct 22, 2018 at 01:40:24PM -0700, alexander.ibrahi...@gmail.com wrote:

Hello,

I am trying to follow this guide:

https://www.reddit.com/r/Qubes/comments/6h4ue2/guide_setting_up_a_vpn_with_mullvad_on_qubes/

But I am not using mullvad, I am using Nordvpn. But I've been told this guide
should be compatible.

I am on the secound part of stage 3:

Start your VPN-Proxy-VM and run:

sudo mkdir /rw/config/vpn

Move your .ovpn file into this folder by typing:

mv openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn

mv openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn command does not
work. I get this error:

mv: cannot stat 'openvpn-client.ovpn': No such file or directory

If I have understood this right it should automatically find this file in my
/home/user/Downloads folder. My Nordvpn config file was named something
different, but I renamed it correcly to ''openvpn-client.ovpn''.

I am lost, I don't know how to solve this.

Whatever route you decide to take, the problem you have here is that the
instructions aren't clear, and 'mv' doesn't work as you think it does.

Your target file is in /home/user/Downloads, but you are in /home/user.
'mv' expects you to specify a file to move. If you don't give an absolute
path then it works relative to where you are.
So your command is looking for a file in /home/user, but the file is
in /home/user/Downloads. That's why it says "No such file".
'mv' will not look about and "find the file" - you need to tell it where the
file is.

If I understood you correcly if I would want to type such a command, I would
need to type...

mv /home/user/Downloads/openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn

Would I need to type anything between the two different dirs?

That's exactly right.
You can use a relative path also - if you are in /home/user then :
mv Downloads/openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn
will work.

Also ~ is a shortcut for your home directory.

mv ~/Downloads/openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn

. means "the directory Im in"
.. means the directory up

Thanks Unman for your followups, but I'm still getting some errors.

Also thanks for the ~ explanation, I didn't understand that until now.

I am following Chris guide: https://github.com/tasket/Qubes-vpn-support/

But I am stuck at secound stage: sudo unzip ~/ovpn-configs-example.zip

First of all, my config file from Nordvpn is a .ovpn file (text document), but
I do have a installation .deb file (nordvpn-release_1.0.0_all.deb) which has a
package icon like an zip file. Both these files are in my ~/Downloads directory.

When I type:

sudo unzip ~/Downloads/nordvpn-release_1.0.0_all.deb

... it says this:

unzip: cannot find or open /home/user/Downloads/nordvpn-release_1.0.0_all.deb,
/home/user/Downloads/nordvpn-release_1.0.0_all.deb.zip or
/home/user/Downloads/nordvpn-release_1.0.0_all.deb.ZIP.

The "deb" indicates it is a custom program written by NordVPN. You
should probably avoid this since NordVPN probably doesn't adjust their
code for Qubes networking (there will be DNS and security problems). The
Qubes-vpn-support page links to a NordVPN page that contains only the
openvpn configs in zip form, which is what you want.

Also, this step cannot be taken verbatim, since different VPN providers
will have differently-named files. This requires enough familiarity with
the Linux shell to be able to interpret what the exact unzip or copy
commands should be. The gist of this step is that you should obtain ovpn
configs from your provider, put them in /rw/config/vpn, and make sure
one of them appears there as "vpn-client.conf" which is what the "ln"
link command is for (but you can use "cp" instead of "ln" if you wish).

I'd also advise you not to try performing more than one solution at the
same time as this only causes confusion.

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/affa2dd4-8f51-023a-f9f4-794da0604546%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN-setup ''mv: cannot stat ... No such file or directory''

2018-10-23 Thread Chris Laprise

On 10/23/2018 09:45 AM, alexander.ibrahi...@gmail.com wrote:

Den tisdag 23 oktober 2018 kl. 02:27:49 UTC+2 skrev Chris Laprise:

On 10/22/2018 04:40 PM, alexander.ibrahi...@gmail.com wrote:

Hello,

I am trying to follow this guide:

https://www.reddit.com/r/Qubes/comments/6h4ue2/guide_setting_up_a_vpn_with_mullvad_on_qubes/

But I am not using mullvad, I am using Nordvpn. But I've been told this guide
should be compatible.

I am on the secound part of stage 3:

Start your VPN-Proxy-VM and run:

sudo mkdir /rw/config/vpn

Move your .ovpn file into this folder by typing:

mv openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn

mv openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn command does not
work. I get this error:

mv: cannot stat 'openvpn-client.ovpn': No such file or directory

I am lost, I don't know how to solve this.

This is just a rehash of the official Qubes instructions, though it
introduces security risk by pulling scripts from pastebin.

A more foolproof way to setup your VPN is to run this in a new proxyVM:

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

Its better in all regards than the old scripts, including ease of use.

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

Hi,

Thanks for you answer, but will I be as safe?

The safety features are at least as good as the old scripts (I wrote the
old and the new ones).

In terms of trust, the Qubes-vpn-support code is signed by me and you
can verify the signature if you wish. This is better than grabbing it
from pastebin pages. There are also dozens of Qubes users who have used
it to setup their VPNs, and it is often discussed here on the mailing list.

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/ab6b0d37-5fb9-fe5c-5694-b13858c24185%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN-setup ''mv: cannot stat ... No such file or directory''

2018-10-22 Thread Chris Laprise

On 10/22/2018 04:40 PM, alexander.ibrahi...@gmail.com wrote:

Hello,

I am trying to follow this guide:

https://www.reddit.com/r/Qubes/comments/6h4ue2/guide_setting_up_a_vpn_with_mullvad_on_qubes/

But I am not using mullvad, I am using Nordvpn. But I've been told this guide
should be compatible.

I am on the secound part of stage 3:

Start your VPN-Proxy-VM and run:

sudo mkdir /rw/config/vpn

Move your .ovpn file into this folder by typing:

mv openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn

mv openvpn-client.ovpn /rw/config/vpn/openvpn-client.ovpn command does not
work. I get this error:

mv: cannot stat 'openvpn-client.ovpn': No such file or directory

I am lost, I don't know how to solve this.

This is just a rehash of the official Qubes instructions, though it
introduces security risk by pulling scripts from pastebin.

A more foolproof way to setup your VPN is to run this in a new proxyVM:

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

Its better in all regards than the old scripts, including ease of use.

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/ce23d2e5-b5f3-e8f1-a9eb-cfe5f4d47daa%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup verification error

2018-10-17 Thread Chris Laprise

On 10/17/2018 06:13 PM, 'awokd' via qubes-users wrote:

Kelly Dean wrote on 10/17/18 6:00 PM:
On Qubes 4.0, I did a full backup to an external hard drive using the
standard backup utility, which completed successfully. 225GB total,
compressed 130GB, took about 12 hours.

Then I tried to verify it (restore with verify-only option), and
watched it for a few minutes to make sure it was running ok, then left
it alone. Last line in the message window at the time was:

Extracting data: 209.6 GiB to restore

Came back a few hours later and the next line was:
Finished with errors!

And there was a dialog box:

[Dom0] Backup error!
ERROR: failed to decrypt
/var/tmp/restorexnuw0a8p/vm31/private.img.034.enc: b'scrypt:
Decrypting file would take too much CPU time\n'
Partially restored files left in /var/tmp/restore_*, investigate them
and/or clean them up
OK

So now I don't know if I have a good backup. The error message also
leaves me doubtful that I'd be able to restore the backup even if it
is good.

The indicated file doesn't exist in dom0. Neither does any other
/var/tmp/restore* file. Googling the message (Decrypting file would
take too much CPU time) finds nothing.

Looks like that error string comes from scrypt. There is a command line
option (-f) to scrypt that forces it to proceed even if it might take
excessive memory or CPU time, but I'm not sure how to pass it on through
qubes-backup-restore.

Looking at the scrypt source, this error code results from the estimated
number of operations exceeding a max time limit. Using -f should
override this check.

In restore.py the function 'def launch_scrypt' contains the line
starting with:

command_line = ['scrypt', action, input_name

This could be changed to:

command_line = ['scrypt', action, '-f', input_name

Of course, this advice is offered "at your own risk" and a backup copy
of restore.py should be made before doing any modification.

BTW, since your backups are rather large, you might be interested in a
new backup tool I'm writing that can perform fast incremental backups
even on large volumes:

https://github.com/tasket/sparsebak

Its still experimental but could be in beta as soon as December.

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/ddd8b81d-9558-9bfc-aeee-a950e3236cb4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Post-install inability to create qube

2018-10-14 Thread Chris Laprise

On 10/12/2018 01:44 AM, 'awokd' via qubes-users wrote:

newpa...@gmail.com wrote on 10/12/18 5:37 AM:

Hello,

After completing install (for my first time), I was able to login.

Going to the menu, "Create Qubes VM," getting the dialog box titled
"[Dom0] Create new qube," the Template select drop-down control only
has "default(none)," even if I select type Standalone rather than AppVM.
Also, I don't see anything anywhere like work, personal and untrusted,
neither sys-net or sys-usb. /var/lib/qubes/vm-templates has a debian
and fedora folder, but it seems like these are not available when
trying to create qubes via CLI via qvm-create. journalctl all show an
AssertionError.

Any ideas?

Did you receive any errors on the first post-install boot? There's a
step there that is supposed to configure all those templates. Is it
possible you skipped it? Otherwise, often a misbehaving network device
causes sys-net creation to break, which then causes the rest to fail to
get created. In that case, try disabling your wifi card temporarily,
then reinstalling. You can re-enable it afterwards and add it back to
your sys-net in Qube Settings/Devices.

Try 'sudo dnf list qubes-template*' to see a list of installed
templates. If there are none, try mounting the installation media,
locate a qubes-template*rpm file and install the rpm file directly. This
should be a lot less time-consuming than re-installing Qubes.

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/03a9bdf6-2506-2b8f-ce6e-623ec43acde1%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Fujitsu Lifebook U757

2018-10-12 Thread Chris Laprise

On 10/12/2018 04:42 PM, Gep Petto wrote:

Why can't Qubes OS be installed on the Fujitsu Lifebook U757?
http://www.fujitsu.com/global/products/computing/pc/notebooks/lifebook-u757/

Did you try?

Keep in mind that selecting a computer for Qubes comes with some general
constraints, so here is my 'compatibility lecture':

1. Computer must be compatible with open source OS/drivers. If open
source developers had to guess in order to make compatible drivers, then
the level of compatibility and stability may be poor.

2. Computer must have advanced virtualization and memory management
features which must be correctly configured and programmed by the
hardware vendor. But some of these features end up in models that aren't
marketed to advanced users, so the features are left unsupported or
mis-configured by the BIOS/motherboard to save on engineering costs.

Usually when Qubes doesn't work on a particular model its because of
some combination of 1 and 2. This is not surprising with models like the
U757 because the Fujitsu data sheet only lists MS Windows as a
compatible operating system.

My advice is to start looking for a Qubes laptop on the HCL page below
and/or look at business models from the 'big 3' manufacturers Dell,
Lenovo and HP in addition to Linux-focused System 76 and Purism which
the manufacturer describes as "Linux compatible" and does _not_ rely on
Nvidia graphics. Although that doesn't specifically address the Xen
aspect of Qubes, this is a pretty good starting point in general for
finding compatible hardware.

https://www.qubes-os.org/hcl/

Users should note that "Compatible with MS Windows" is not the Good
Housekeeping Seal Of Approval For Linux Users... It means a partnership
exists between the hardware vendor and Microsoft without regard as to
whether or not design specs required to write good drivers have been
made available to open source/Linux developers or anyone else. It can
also mean that Microsoft intended that partnership (and hardware info)
to be exclusive meaning the info _won't_ be distributed to anyone else.

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/56425a3b-6a2a-5e67-7986-5ddba3692c93%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] nftables vs iptables

2018-10-10 Thread Chris Laprise

On 10/10/2018 01:47 PM, David Hobach wrote:

On 10/10/18 3:33 PM, unman wrote:

On Wed, Oct 10, 2018 at 03:17:47PM +0200, Illidan Pornrage wrote:

On 10/10/18 3:14 PM, unman wrote:

On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:

On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
    > On 01/10/2018 03:47 PM, Connor Page wrote:
    >> The official templates use nftables so shouldn’t be 
mixed with
iptables. I didn’t have time to learn about nftables, so just 
removed

nftables package from debian 9 template. YMMV.
    >
    > Hmmm, I was just thinking how Qubes' own guest scripts 
still use

    > iptables even in fedora-26.
    >
    > IIUC, iptables and nft are two different interfaces
to netfilter. I
    > don't know if it really matters, at least for the R4.0 
window. I'd

    > prefer to put the syntax change (for docs) off until
a later release.

I was recently thrown by the mix of both nftables and iptables 
in R4.

The qubes docs don't clarify much.  The qubes firewall scripts 
use

nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The 
upgrade
instructions (going from R3.2 to R4) did not mention 
converting rules
from iptables to nftables.  It looks like other related 
projects (one

example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I 
get the
impression that nftables and iptables should not both by used 
at the

same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, 
Fedora 28

template)?  Are we to be using, exclusively, nftables in R4?

The last I read about this (for 4.0) is that nftables is used 
in Fedora

Qubes code, but Debian Qubes is still using iptables. That
still appears
to be the case since nftables is not installed in my
debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands 
only, with
the intention to transition to nftables (or that other new 
interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is 
just

starting a project might be better off going with nftables.

... until yet another packet filtering mechanism replaces 
nftables (in

that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given 
how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) 
IMHO it
wasn't worth it. The OP's post confirms there's quite some 
confusion
about how it interacts with iptables, and the official 
documentation is

far from helpful.
I'm quite proficient with iptables and networking in general but 
it took
me half an hour to understand how to tweak Qubes' nftables rules 
last
time I wanted to change something in the firewall, while I would 
have
done that task in less than one minute with iptables. I could 
have spent
a few hours learning nftables to improve the official doc but at 
my age
I prefer to spend time learning tech that significantly improves 
things

(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 

I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).

Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?

nb.  This is not meant to be a criticism at all.  I very much
appreciate the hard (and complicated) work going into Qubes.  I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.

As an example:  I'm wanting to enable some specific network traffic
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). 

   qubes-firewall-user-script also specifies iptables rules.  But
qvm-firewall implements the rules it manages using nftables.  So the
firewall VMs have both iptables rules and nftables rules in 
effect.  And
these are different sets of rules.  It's not that the iptables 
command
and the nft command are just two user interfaces showing the same 
packet
filtering rules.  They are different packet filtering rules.  This 
seems

like a receipt for disaster.

Is this the wrong forum for this discussion?  Should this be on
qubes-devel, or an issue in qubes-issues at
https://github.com/QubesOS

Re: [qubes-users] Enabling and disabling external monitors based on laptop lid status

2018-10-04 Thread Chris Laprise

On 10/04/2018 04:59 AM, Ivan Mitev wrote:

On 10/4/18 11:10 AM, 'Mads R. Havmand' via qubes-users wrote:

I'm scratching my head over this... How are people configuring their QubeOS 4
instances to enable and disable external monitors based on the laptops lid
status?

I've been through this too - see below.

Current laptop (EliteBook 1040 g2) works flawlessly with Qubes (even
suspend...) and my only current issue is that I have to manually enable and
disable screens when I dock the machine.

I too manually enable/disable screens but I have configured a keyboard
shortcut that runs a custom shell script with xrandr commands based on
the presence - or lack thereof - of my external monitor.
All it takes is to dock the laptop and hit the shortcut - lightning fast.

Normally, I'd use ACPI hooks and I'm guessing this needs to be done in dom0 (I
don't suppose any DomU's have access to reconfigure screens?) but acpid isn't
available om dom0.

Yes this needs to be done in dom0.

On moderm distros systemd handles lid events provided no other
application has inhibited ("overridden") the event. See `man logind.conf`.

In the case of Qubes, Xfce's power manager overrides HandleLidSwitch=
(but not HandleLidSwitchedDocked=). There's an option in xfce power
manager to turn the display off when the lid is closed but it won't be
able to differentiate when the laptop's docked or not so it's useless.

IIRC there are a few ways to run a script based on lid events without
resorting to installing acpid (which is not even guaranteed to work):
eg. listening for dbus lid close/open events, monitoring
/proc/acpi/button/lid/LID/state, ... ; An alternative is to run stuff on
dock/undock events, via dbus and/or udev rules.

In the end my hacky keyboard shortcut "solution" worked well enough that
I didn't spend time to investigate the solutions above...

What would you recommend? I guess a possible solution could be to source an
acpid RPM, or find the source code, and install that manually in dom0?

This is one of several problems I resolved by simply switching back to
KDE. Xfce had too many bugs and omissions for me.

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

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/03ce78ce-ce8d-3ab6-7931-a122bdb78b5a%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] I still want anti virus with Qubes OS. but which one is compatible?

2018-10-03 Thread Chris Laprise


On 10/03/2018 11:09 PM, ccchan...@gmail.com wrote:

hi~

i got enough CPU and RAM and SSD,

I want an extra layer of protection in addition to qubes 's protection.

what can I do?

I used to use ubuntu with sophos free anti virus for linux.

What can I install on a qubes OS?

thanks


Before going down the detection route, keep in mind that by default 
Qubes VMs have little if any _internal_ protection from malware. So it 
makes sense to restore normal defenses first...


https://github.com/tasket/Qubes-VM-hardening/

Qubes-VM-hardening goes a bit beyond re-enabling sudo authentication in 
that it will also do a minimum level of protection and sanitizing by 
default. This protects VMs in ways that could also benefit regular Linux 
systems.


Going beyond that, antivirus is an option. One way to run it is from a 
dispVM to which you attach various private volumes (one at a time) for 
scanning. Another way is to use Qubes-VM-hardening as a way to launch 
the AV scanner at normal appVM startup, at the instant before the 
private volume is brought online.


--

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/f1d74045-4a8f-0537-d51e-1c43f82a4ca0%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] nftables vs iptables

2018-10-01 Thread Chris Laprise

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
 > On 01/10/2018 03:47 PM, Connor Page wrote:
 >> The official templates use nftables so shouldn’t be mixed with 
iptables. I didn’t have time to learn about nftables, so just removed 
nftables package from debian 9 template. YMMV.

 >>
 >
 > Hmmm, I was just thinking how Qubes' own guest scripts still use
 > iptables even in fedora-26.
 >
 > IIUC, iptables and nft are two different interfaces to netfilter. I
 > don't know if it really matters, at least for the R4.0 window. I'd
 > prefer to put the syntax change (for docs) off until a later release.

I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use nft. 
Most of the discussion on the qubes website documentation is about 
iptables, but there are also a few mentions of nft.  The upgrade 
instructions (going from R3.2 to R4) did not mention converting rules 
from iptables to nftables.  It looks like other related projects (one 
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the 
impression that nftables and iptables should not both by used at the 
same time.  Even if technically possible (i.e. both sets of rules 
applied correctly), it strikes me as not a great idea to maintain packet 
filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28 
template)?  Are we to be using, exclusively, nftables in R4?

The last I read about this (for 4.0) is that nftables is used in Fedora 
Qubes code, but Debian Qubes is still using iptables. That still appears 
to be the case since nftables is not installed in my debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands only, with 
the intention to transition to nftables (or that other new interface in 
Linux, name escapes me just now) for Qubes 4.1. Someone who is just 
starting a project might be better off going with nftables.

--

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/7a160df8-414a-721a-569c-f7c540b5a0e8%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] /dev/mapper/qubes_dom0-root does not exist

2018-10-01 Thread Chris Laprise

On 10/01/2018 05:24 PM, Chris Laprise wrote:

On 10/01/2018 02:50 PM, Micah Lee wrote:
I recently installed Qubes 4.0 on a laptop, installed updates in dom0
and my templates, restored a backup, and did a bunch of custom
configuration. And then when I rebooted, Qubes wouldn't boot up due to
a partitioning error. (It looks like it's the same problem described
here [1]). During boot, I get a hundreds of lines that says:

dracut-initqueue[343]: Warning: dracut-initqueue timeout - starting
timeout scripts

Followed by:

dracut-initqueue[343]: Warning: Could not boot.
dracut-initqueue[343]: Warning: /dev/mapper/qubes_dom0-root does not
exist

dracut-initqueue[343]: Warning: /dev/qubes_dom0/root does not exist
Starting Dracut Emergency Shell...

Then it drops me into an emergency shell.

When I run lv_scan, I can see:

Scanning devices dm-0 for LVM logical volumes qubes_dom0/root
qubes_dom/swap

inactive '/dev/qubes_dom0/pool00' [444.64 GiB] inherit
inactive '/dev/qubes_dom0/root' [444.64 GiB] inherit
ACTIVE '/dev/qubes_dom0/swap' [15.29 GiB] inherit
inactive '/dev/qubes_dom0/vm-sys-net-private [2 GiB] inherit

And it continues to list another inactive line for each private or
root partition for each of my VMs. Only swap is active.

I spent a little time trying to troubleshoot this, but ultimately
decided that it wasn't worth the time, since I have a fresh backup. So
I formatted my disk again, reinstalled Qubes, restored my backup, etc.
After installing more updates and rebooting, I just ran into this
exact same problem *again*. I think this could be a Qubes bug.

Any idea on how I can fix this situation? The dracut emergency shell
doesn't seem to come with many LVM tools. There's lvm, lvm_scan,
thin_check, thun_dump, thin_repair, and thin_restore. I could boot to
the Qubes USB and drop into a troubleshooting shell to have access to
more tools.

[1]
https://groups.google.com/forum/#!searchin/qubes-users/dracut-initqueue$20could$20not$20boot|sort:date/qubes-users/PR3-ZbZXo_0/G8DA86zhCAAJ

If you do 'sudo lvdisplay qubes_dom0/root' it will probably say LV
status is 'Not Available'. This could mean an 'lvchange' somewhere set
those volumes (pool00, root, etc) to setactivationskip=y.

You can attempt to fix it at least temporarily like so:

sudo lvchange -kn -ay qubes_dom0/pool00
sudo lvchange -kn -ay qubes_dom0/root
sudo lvchange -kn -ay qubes_dom0/vm-sys-net-private

Then use lvdisplay to verify the LV status has changed.

BTW if you can run 'lvm' in the rescue shell then you can use that for
various lv* commands including 'lvchange'. Just run 'lvm' by itself and
that will put you in an lvm shell where the 'lvchange' command and
others are accessible.

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/9f8ce612-f061-62d2-9237-55ef0a5e7193%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] /dev/mapper/qubes_dom0-root does not exist

2018-10-01 Thread Chris Laprise

On 10/01/2018 02:50 PM, Micah Lee wrote:
I recently installed Qubes 4.0 on a laptop, installed updates in dom0
and my templates, restored a backup, and did a bunch of custom
configuration. And then when I rebooted, Qubes wouldn't boot up due to a
partitioning error. (It looks like it's the same problem described here
[1]). During boot, I get a hundreds of lines that says:

dracut-initqueue[343]: Warning: dracut-initqueue timeout - starting
timeout scripts

Followed by:

dracut-initqueue[343]: Warning: Could not boot.
dracut-initqueue[343]: Warning: /dev/mapper/qubes_dom0-root does not exist
dracut-initqueue[343]: Warning: /dev/qubes_dom0/root does not exist
Starting Dracut Emergency Shell...

Then it drops me into an emergency shell.

When I run lv_scan, I can see:

Scanning devices dm-0 for LVM logical volumes qubes_dom0/root
qubes_dom/swap

And it continues to list another inactive line for each private or root
partition for each of my VMs. Only swap is active.

I spent a little time trying to troubleshoot this, but ultimately
decided that it wasn't worth the time, since I have a fresh backup. So I
formatted my disk again, reinstalled Qubes, restored my backup, etc.
After installing more updates and rebooting, I just ran into this exact
same problem *again*. I think this could be a Qubes bug.

[1]
https://groups.google.com/forum/#!searchin/qubes-users/dracut-initqueue$20could$20not$20boot|sort:date/qubes-users/PR3-ZbZXo_0/G8DA86zhCAAJ

If you do 'sudo lvdisplay qubes_dom0/root' it will probably say LV
status is 'Not Available'. This could mean an 'lvchange' somewhere set
those volumes (pool00, root, etc) to setactivationskip=y.

You can attempt to fix it at least temporarily like so:

sudo lvchange -kn -ay qubes_dom0/pool00
sudo lvchange -kn -ay qubes_dom0/root
sudo lvchange -kn -ay qubes_dom0/vm-sys-net-private

Then use lvdisplay to verify the LV status has changed.

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/956595f3-512f-bf91-d829-01104752e733%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Enabling OpenVPN auto start

2018-09-28 Thread Chris Laprise

On 09/26/2018 08:38 PM, Stuart Perkins wrote:

Well, got the proxyVM created. Based it on Fedora-28. Have it squeezed
between sys-firewall and sys-net. It runs automatically due to the dependency,
but the vpn does not run automatically, which is what I want. I setup a
shortcut to start the open vpn and another to kill it. It seems to work, but
my ability to test it out is not complete right now. I'll know more after I
test it some more tomorrow. That keeps my storage of VPN credentials away from
sys-net, while still enabling sys-firewall. That is the part I need to test
more fully. I have one appVM firewalled to only access my home system for
backup purposes as well as other appVMs with full access. I'll do some serious
testing tomorrow and report the results. I can synthesize being away from home
by using my smartphone for internet. I will need to access my home network
when connected to the VPN, which I ought to be able to, and a traceroute should
go through my home system's DNS server. This may be the best solution for my
need for now. It is better than the previous sys-net hosted openvpn instance.
Thanks to Chris for the explanation as to why to use qubes-tunnel.

Stuart

FYI, I just posted a fix for a blocked traffic problem on Qubes 3.2 (4.0
is not affected).

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/2a40a030-94a1-1b31-1970-2d6d32cf540b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Enabling OpenVPN auto start

2018-09-26 Thread Chris Laprise

On 09/26/2018 08:38 PM, Stuart Perkins wrote:

It should run openvpn automatically, unless there was a typo or a step
was skipped. You can check its log with 'sudo journalctl -u qubes-tunnel'.

I setup a shortcut to start the open vpn and another to kill it. It
seems to work, but my ability to test it out is not complete right now.
I'll know more after I test it some more tomorrow. That keeps my
storage of VPN credentials away from sys-net, while still enabling
sys-firewall. That is the part I need to test more fully. I have one
appVM firewalled to only access my home system for backup purposes as
well as other appVMs with full access. I'll do some serious testing
tomorrow and report the results. I can synthesize being away from home
by using my smartphone for internet. I will need to access my home
network when connected to the VPN, which I ought to be able to, and a
traceroute should go through my home system's DNS server. This may be
the best solution for my need for now. It is better than the previous
sys-net hosted openvpn instance. Thanks to Chris for the explanation as
to why to use qubes-tunnel.

There are two ways to access a LAN while connected to a VPN with
qubes-tunnel. One is to add exceptions to the ProxyVM internal iptables
rules, the other (recommended way) is to connect the particular VM
requiring LAN access to a clearnet VM such as sys-firewall (assuming you
have sys-firewall still connected directly to sys-net).

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/2f5e1f1d-c77d-f02f-5ea6-bf7a501cc681%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN Tunnels - any date for official release?

2018-09-26 Thread Chris Laprise


On 09/26/2018 11:39 AM, qubes-...@tutanota.com wrote:

Is there anything new with the Integration of VPN Tunnels for Qubes? The 
release of the U2F Proxy was an excellent move. Is there any date to officially 
launch the VPN Tunnels for less technically skilled users?

If someone finds the time to give it some love, we would be significantly 
happier \o/

Thank you!


I'm working on getting the packaging correct so that it integrates 
properly with qubes-builder. Its a bit more complicated than I expected 
but I think it could happen this week.



--

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/aab46d42-2b8d-dd3f-722a-142a8ffd88cf%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Enabling OpenVPN auto start

2018-09-25 Thread Chris Laprise

On 09/25/2018 05:27 PM, Stuart Perkins wrote:

On Tue, 25 Sep 2018 12:52:16 -0700 (PDT)
Ninja-mania via qubes-users wrote:

Dude I actually love you (no homo).

Spent 20+ trying to set vpn up (Big ass noob) and never came across the Qubes
tunnel. It’s awesome. You’re awesome.

Glad to help!

I have two separate VPN's on my Qubes 3.2 laptop.

One Cisco VPN running via OpenConnect in a dedicated appVM for a client.
One OpenVPN running in a secondary copy of sys-net which I switch to when I
need it. I run the server OpenVPN on a VM on my home server (Debian and
VirtualBox).

When I want to connect EVERYTHING to the VPN, I switch out and run the copy of
sys-net with the VPN credentials and scripts.

When I want to access the client, I start the appVM with the OpenConnect Cisco
VPN client and credentials. I also use this appVM to run client specific
software through Wine for most of my work on their equipment, although I do a
fair amount of straight up command line stuff on their system as well. I can
run this on top of the other VPN if absolutely necessary, but performance is
not fast since my home connection is not fast.

Haven't had occasion to try the Qubes tunnel. Is there a particular reason to?

Its good practice to use a Qubes-specific tool like qubes-tunnel to
ensure that DNS packets (and everything else) gets routed through the
tunnel and never _around_ it even when the link goes down. This is
important for Qubes because any service VM (NetVM or ProxyVM) that runs
VPN software is acting like a router, not a PC, and Qubes also has
special requirements for proper routing of DNS in this situation.

In your case the AppVM with OpenConnect acts like a PC endpoint and is
probably not a security issue. But the sys-net copy is acting like a
router as previously mentioned and that's an issue on Qubes; to improve
security you could move your openvpn config to a ProxyVM and use
qubes-tunnel.

There is also the issue of VPN passwords or keys being stored in a
sys-net type VM, since these VMs are considered vulnerable to attack.
Moving the VPN to a ProxyVM increases the security of your VPN secrets.

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/294449c7-773c-f239-13d9-9092cc047212%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Enabling OpenVPN auto start

2018-09-25 Thread Chris Laprise


On 09/25/2018 02:13 PM, Ninja-mania via qubes-users wrote:

In using the following command:
edit /etc/default/openvpn
Then attempting to remove the # next to “#AUTOSTART=“all”” I am unable to 
remove the hash.

Can anyone tell me why i’m unable to remove the hash? And how to go about 
removing it so I can auto start openvpn.

Thanks



I'm not familiar with 'edit'. Most would use 'sudo vim' or 'sudo nano' 
to edit a settings file in the terminal.


Also, if you're looking for a VPN solution I'd recommend using 
https://github.com/tasket/qubes-tunnel which automatically takes care of 
the Qubes-specific DNS and iptables details.


--

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/cd8a0a3f-ba65-db71-28a9-50e323ca775c%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: location of root.img in v4.0

2018-09-22 Thread Chris Laprise

On 09/22/2018 11:01 AM, Chris Laprise wrote:

On 09/22/2018 05:01 AM, lik...@gmx.de wrote:

On 21/09/2018 23:43, Chris Laprise wrote:

On 09/21/2018 05:30 PM, Chris Laprise wrote:

On 09/21/2018 05:10 PM, liked2-mmb7mzph...@public.gmane.org wrote:

Hi,

there are several topics in the documentation pointing to the
location of files like: root.img, volatile.img, private.img

here:
https://www.qubes-os.org/doc/hvm/
or here:
https://www.qubes-os.org/doc/windows-template-customization/
or here:
https://www.qubes-os.org/doc/reinstall-template/

All of them are refering to a location of these file to:
/var/lib/qubes/{appvms,vm-templates}/MY_VM/

Unfortunately, as of version 4.0 I cannot find these files there.
Where did they moved to?

The R4.0 default is to use thin-provisioned lvm for storage instead
of image files. You can think of these "logical volumes" as being
like partitions and they have device entries under /dev/mapper. To
view and manipulate them directly you'll need to use lvm commands
like "lvs" and "lvrename" etc. although its best to first try using
the qvm-* commands like "qvm-volume".

To be a bit more specific, a Qubes AppVM called "work" within this
lvm system will boot from an lvm volume named "vm-work-root-snap".
This is because Qubes takes a read-only snapshot of the template root
when the AppVM is started.

Thanks a lot Chris. With this explanation, does the stripping still
makes sense documented here:

https://www.qubes-os.org/doc/windows-template-customization/
mentioned in the last paragraphs?

I could even think that's even counterproductive, because when the
space is filled with zeros, the volume size will be increased. Is
there a possibility to strip this space or should we ad a remark to
the documentation, that it's not reasonable to do so as of R4.0?

This depends on whether Windows is configured to use TRIM/discard on its
disks. I don't recall what the default is for various versions of
Windows, but there is an easy way to tell... if Qube Manager shows the
disk usage for the template going down as you remove stuff then you
don't need to do anything. Otherwise, I suggest following Microsoft
instructions for enabling TRIM.

If you still want to duplicate the kind of wipe+sparse copy the Qubes
doc recommends (i.e. if you removed a lot of stuff _before_ TRIM was
enabled), its possible to do this using lvm commands and 'dd
conv=sparse'... but you need to familiarize with Linux lvm first.

Also should mention the 'fallocate' command. It has a way to deallocate
zero blocks in-place so you probably won't need to use issue lvm
commands directly:

sudo fallocate --dig-holes /dev/mapper/qubes_dom0-vm--untrusted--private

This method can also be used on .img files (for Qubes installations that
use them).

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/5ef51942-e061-668c-7434-b616aa901dc6%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: location of root.img in v4.0

2018-09-22 Thread Chris Laprise

On 09/22/2018 05:01 AM, lik...@gmx.de wrote:

On 21/09/2018 23:43, Chris Laprise wrote:

On 09/21/2018 05:30 PM, Chris Laprise wrote:

On 09/21/2018 05:10 PM, liked2-mmb7mzph...@public.gmane.org wrote:

Hi,

there are several topics in the documentation pointing to the
location of files like: root.img, volatile.img, private.img

here:
https://www.qubes-os.org/doc/hvm/
or here:
https://www.qubes-os.org/doc/windows-template-customization/
or here:
https://www.qubes-os.org/doc/reinstall-template/

All of them are refering to a location of these file to:
/var/lib/qubes/{appvms,vm-templates}/MY_VM/

Unfortunately, as of version 4.0 I cannot find these files there.
Where did they moved to?

To be a bit more specific, a Qubes AppVM called "work" within this lvm
system will boot from an lvm volume named "vm-work-root-snap". This is
because Qubes takes a read-only snapshot of the template root when the
AppVM is started.

Thanks a lot Chris. With this explanation, does the stripping still
makes sense documented here:

https://www.qubes-os.org/doc/windows-template-customization/
mentioned in the last paragraphs?

I could even think that's even counterproductive, because when the space
is filled with zeros, the volume size will be increased. Is there a
possibility to strip this space or should we ad a remark to the
documentation, that it's not reasonable to do so as of R4.0?

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/b051addf-6eeb-8118-df65-6c3c9d9f35c3%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] location of root.img in v4.0

2018-09-21 Thread Chris Laprise

On 09/21/2018 05:30 PM, Chris Laprise wrote:

On 09/21/2018 05:10 PM, lik...@gmx.de wrote:

Hi,

there are several topics in the documentation pointing to the location
of files like: root.img, volatile.img, private.img

here:
https://www.qubes-os.org/doc/hvm/
or here:
https://www.qubes-os.org/doc/windows-template-customization/
or here:
https://www.qubes-os.org/doc/reinstall-template/

All of them are refering to a location of these file to:
/var/lib/qubes/{appvms,vm-templates}/MY_VM/

Unfortunately, as of version 4.0 I cannot find these files there.
Where did they moved to?

The R4.0 default is to use thin-provisioned lvm for storage instead of
image files. You can think of these "logical volumes" as being like
partitions and they have device entries under /dev/mapper. To view and
manipulate them directly you'll need to use lvm commands like "lvs" and
"lvrename" etc. although its best to first try using the qvm-* commands
like "qvm-volume".

To be a bit more specific, a Qubes AppVM called "work" within this lvm
system will boot from an lvm volume named "vm-work-root-snap". This is
because Qubes takes a read-only snapshot of the template root when the
AppVM is started.

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/71c78d9e-3b8f-1517-300a-836971813979%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] location of root.img in v4.0

2018-09-21 Thread Chris Laprise

On 09/21/2018 05:10 PM, lik...@gmx.de wrote:

Hi,

there are several topics in the documentation pointing to the location
of files like: root.img, volatile.img, private.img

here:
https://www.qubes-os.org/doc/hvm/
or here:
https://www.qubes-os.org/doc/windows-template-customization/
or here:
https://www.qubes-os.org/doc/reinstall-template/

All of them are refering to a location of these file to:
/var/lib/qubes/{appvms,vm-templates}/MY_VM/

Unfortunately, as of version 4.0 I cannot find these files there. Where
did they moved to?

The R4.0 default is to use thin-provisioned lvm for storage instead of
image files. You can think of these "logical volumes" as being like
partitions and they have device entries under /dev/mapper. To view and
manipulate them directly you'll need to use lvm commands like "lvs" and
"lvrename" etc. although its best to first try using the qvm-* commands
like "qvm-volume".

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/bfb48e9b-0c37-22bf-c400-0447b3d9638f%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Crossover on Qubes

2018-09-20 Thread Chris Laprise

On 09/20/2018 11:04 AM, Black Beard wrote:

Hey guys,

im interessted to install Crossover-Linux on my Qubes OS.

For this project, I have already written off the customer support, whether a smooth installation and use is possible.

The support was not sure for this.

I hope, that someone can help me here :)

Can i use Crossover on my Qubes OS?

If yes, is there some tutorial to install this Software?

About messages i very happy.

regarda and thx in advance

GPU access would be the biggest factor, since Crossover prides itself in
good GPU/games support. But this consideration is similar to regular
Linux apps as well and most of those work fine in Qubes.

I don't know of a tutorial, but you could try your app under Wine first
(last time I checked, Crossover was a tweaked version of Wine).

If Crossover requires installation to /usr, etc. (i.e. it doesn't reside
in /home) then you'll have to install it in either a template or a
standalone VM made from a template (this is an option in the Qubes
Create VM dialog). The latter should make Crossover installation simpler
for testing purposes.

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/17b21492-9552-1d80-c4b2-6f01a2946421%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: New to Qubes having issues logging into my vpn service despite following the Qubes instructions

2018-09-18 Thread Chris Laprise

On 09/18/2018 12:39 PM, Wolf moon wrote:

see > https://nordvpn.com/tutorials/linux/openvpn/

Followed it to a T in both the nord appvm terminal and the disposable fedora 26
vm terminal an voila! both worked and completed the vpn link in the terminal
just like on my raspberry pi!...However...On opening the firefox pages of both
then googling ip tracker...well in the nord appvm it wont go onto the internet
at all and that is with allowing network etc..on the disposable fedora 26
firefox it goes on the internet but still says exactly where I am even when I
deleted history again ( which shouldnt matter as it deletes the who history and
vm every time you close it )

So I am puzzled...

Its understandable that the NordVPN guide would connect but not route
traffic to your appVMs because there are no Qubes-specific steps.

A few points to make here:

1. Please try only one approach/guide at a time. It doesn't make sense
to mix them unless you're an expert and have unusual needs.

2. Qubes-vpn-support is the easiest and most complete guide for now.

3. NordVPN doesn't have a guide for Qubes and won't be able to help much
(if at all) in addressing special Qubes networking requirements. From
what I can tell, however, their service is very traditional (using
openvpn) so accessing it from Qubes should be the same as accessing
other VPN services from Qubes (i.e. following Qubes-specific
instructions is best).

What you do need NordVPN for is to supply the configs and you already
have those.

The point of Qubes guides like Qubes-vpn-support is to have the user
take their VPN's configs and add them to the Qubes-specific scripts. The
same is true for qubes-os.org/doc/vpn script guide, but with that guide
you'll also have to edit files manually and the result won't run as
smoothly as Qubes-vpn-support - you can trust me on this because I wrote
both of them. :)

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/76ea1b89-0f93-f32d-e912-fb6f2d127204%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Workspace names (even per-monitor)?

2018-09-17 Thread Chris Laprise

On 09/17/2018 02:23 PM, Teqleez Motley wrote:

Thanks for the reply. I have already the names technically just there as you
say, but they do not show up in the switcher unless..:

a) I have to hover over the WS in the switcher to get a pop-up showing the
name, but that only works if;
b) I have either minimized all windows so that no window shows in the WS switcher, or at
least not maximized any of them, so that it leaves a tiny spot that I guess is possible
to "hit", but which makes it too inconvenient, too easy to point to an open
window instead of the workspace background, which then causes the popup to show the
window name instead of the WS name.

So the point is how to show the workspace names without pointing, just visible
all the time.

Alternatively, if each WS could be given a customizeable color, maybe that
panel app could put a colored frame around each one, so we can easier
distinguish between them.

And: 2+ monitors adds to the need for visible names:

With 2 or more monitors, both belonging as "monitor-0" and "monitor-1" to each WS, then the panel
app has 2 sets of "areas" per WS... This is very practical when showing miniature windows, BUT, it ends up
becoming an issue when we cannot see the WS name for the actual "pair". Not easy to see if it is the right or
left one that belongs in the same group as the one you are looking at in the panel.

Complicating perspective;
- We are most likely going to get _more_ monitors, not less...

On a side note, related to navigating open windows on multiple Workspaces:
- The Tails live USB system has an ultra-practical (and "cool") "hud" that
appears as an overlay when placing the cursor in the upper-right corner.
Is such a thing possible to get working with Qubes 4.x?

Yes,

KDE 5 pager settings lets you set how desktop workspaces are labeled.
KDE also resolves quite a few bugs and annoyances I had with Xfce,
although it does introduce a bug where VM systray icons aren't displayed
(but are still present and work).

I don't know about labeling screens, but the pager settings do have a
checkbox for displaying only the current screen.

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/2f29c4d6-a72e-d170-1ac2-73bf91f9754d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New to Qubes having issues logging into my vpn service despite following the Qubes instructions

2018-09-16 Thread Chris Laprise

On 09/16/2018 07:30 AM, unman wrote:

On Fri, Sep 14, 2018 at 08:21:53PM -0700, Wolf moon wrote:

Hi guys New to Qubes ( which is an amazing feat of cyber security engineering )
all working fine and learning my way around it.

My only issue is logging into my vpn service.

I have followed the Qubes instructions ( which the images are different to
Qubes 4.0 and after searching the net on this matter someone said that this is
a shot of the previous Qubes so not helpful there ) I also contacted my vpn
service on the matter. They read up on the Qubes instructions and emailed me
back a step by step guide but still no joy.

My vpn service works well on my Raspberry Pi 3 in the command line ( which I
found simple instructions for elsewhere on the internet ) and works fine on my
windows 10 system as its got an app interface you download.

Its just Qubes I am having issues with. I am by no means a hardcore techy, I am
learning and not afraid or unfamiliar using the command line in linux.

I have contacted the Qubes team after trying my best effort to resolve this on
my own as I know they are a small team of 5 or so last time I checked.

Any help and advice would be greatly appreciated.

Best,

Wolf Moon

Hi Wolf Man

Welcome to Qubes.

It would be easier to help if you gave some idea of what the problem is:
"still no joy" doesn't mean anything.

Also, "the Qubes instructions" cover a number of different approaches.
Which one did you try?
How did the instructions provided by your provider differ from the Qubes?

Can you say what provider is involved, and what flavour of vpn you are
trying to put in place.
Look in the log files for the service, and post relevant extracts - I
mean take some time to review the log yourself and then post.

The more relevant information you provide, the easier it will be to
help.

cheers

unman

Specifics are definitely needed for questions like this.

The thing that usually confuses people about the current (old) Qubes doc
is there is no button for "ProxyVM" on the R4.0 Create VM dialog. The
way to do this in R4.0 is to click on "Provides network" instead.

The newer (proposed) doc + qubes-tunnel as suggested by awokd are much
easier to install and run more smoothly, BTW.

https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md

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/3ee8ac9d-cd07-3514-c3db-3259f45ed19d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] syncing config across qubes

2018-09-14 Thread Chris Laprise

On 09/14/2018 05:31 PM, Daniel Allcock wrote:

Dear all,

I am wondering how you all deal with (for example) having an elaborate vim
or emacs environment built up over several decades, and being able
to use it in all of your regular everyday qubes (personal, work, untrusted, etc,
probably leave vault out). Of course, you expect it to keep evolving as you
figure out how some package solves a problem for you, or you write some
vimscript or elisp to stop an annoyance.

What is the qubes way to do this? I've considered several solutions from
the simple to the baroque:

(simple) do the common config in the template vm (but not in /home
or /rw or /usr/local) and replace the relevant config files/dirs in the
actual-work
vm's with symlinks to them.

(also simple) have a "config" qube where you keep the configs you want to sync,
but do no actual work there and have no net access. Set up a script to copy
the relevant files/dirs to your working qubes. When you find an annoyance, fix
it there, and then run the script.

(rather complicated) set up a git server (say in its own dvm)
and have your qubes push commits to it when
you make changes to one of the files-to-sync. That way you can make your
tweaks wherever you happen to be working at the time, and later accept
those changes on the server. Then you can download the updated version
on your working qubes (perhaps by a script).

All of these have different convenience levels and data-flow implications.
But I feel like maybe they are all wrong and I am overlooking something
obvious. Any thoughts appreciated!
Daniel

It gets more complicated if you want to keep settings in /home/user
updated. Otherwise, updating configs only in templates isn't hard.

The server idea would be OK if it were coordinated by a dom0 program and
used qvm-copy or sending via qvm-run+tar. An actual networked server
seems both more complicated and a security risk.

Another way you could keep /home/user settings updated is to stash the
settings somewhere in '/' and have a VM startup script copy the files
into home. You can already do this with the service in
Qubes-VM-hardening since it can deploy files from template to anywhere
in /rw at the moment the appVM mounts it...
https://github.com/tasket/Qubes-VM-hardening

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/2399b718-e727-4baa-eb2c-42aac658b354%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-14 Thread Chris Laprise


On 09/14/2018 03:25 PM, 22...@tutamail.com wrote:

Thank you Anac and Chris, appreciate your suggestions:

You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that?

I did check this...opened the connection to Any/Any but this didn't seem to be 
the issue. I also eliminated TOR for testing and connected directly to the 
sys-net(to also eliminate any sys-firewall potential issues)

Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template.

I tried with fedora-28 but also had the same TLS connection error. I ran the 
tests in step 3 as suggested and recieved the following errors with both the 
Debian and Fedora setup:

Fri Sep 14 10:30:53 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Sep 14 10:30:53 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Auth Username: My user name
Enter Auth Password: **
Fri Sep 14 10:32:34 2018 TCP/UDP: Preserving recently used remote address: 
[AF_INET]208.167.254.76:1198
Fri Sep 14 10:32:34 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 10:32:34 2018 UDP link local: (not bound)
Fri Sep 14 10:32:34 2018 UDP link remote: [AF_INET]208.x.x.x:port xx
Fri Sep 14 10:32:34 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:36 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:40 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:48 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:04 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:34 2018 TLS Error: TLS key negotiation failed to occur within 
60 seconds (check your network connectivity)
Fri Sep 14 10:33:34 2018 TLS Error: TLS handshake failed
Fri Sep 14 10:33:34 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 10:33:34 2018 Restart pause, 5 second(s)

Definitely strange considering it was working great for a few months...the good 
news is the kill switch functionality with this solution worked.

Any insight with the errors I recieved? If not I think a reinstall is my best 
course...


You would normally get operation not permitted if the internal firewall 
script is in effect, which is why this step comes before any scripts are 
added (i.e. its performed in a fresh VM).


You can either disable the firewall script in 
/rw/config/qubes-firewall.d and reboot, or try the test in a new VM 
connected to sys-net.



--

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/a48bdd20-e74d-20ea-ac6d-003ce44a4957%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-13 Thread Chris Laprise

On 09/13/2018 08:00 PM, Anac wrote:

On 09/14/2018 12:13 AM, 22...@tutamail.com wrote:
Unfortunately I have been under constant attack and a target and the
only solution I see is a fresh rebuild or new computer unless you have
another idea?

https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service

Step 3 of the revised doc is probably the most effective test you can
perform... its basically starting fresh with (at that point) no scripts
added. Its just openvpn + the config. If that doesn't work then you may
be right that something in Qubes itself has become broken and maybe a
reinstall is necessary.

Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template.

You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that?

When connecting to VPN through TOR, TCP is required but depending on
your provider's server config you may also have to change the port number.

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/f8ea83ca-9adc-add1-c376-a0791eac5062%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] wifi password storage

2018-09-12 Thread Chris Laprise

On 09/12/2018 03:44 PM, Stuart Perkins wrote:

I would do this without a separate network device. Create a clone of a clean
(no saved passwords) sys-net.

First set sys-net and sys-firewall to NOT autostart. Starting an appVM which
uses them will start them first anyway.

Create a shutdown script which...

stop all appVMs
stop sys-firewall
update sys-firewall to use the insecure, general sys-net
complete shut down

Use this shutdown script for all shut downs.

Then when you turn your machine on "not at work", it will be using the insecure
sys-net by default...you won't accidentally expose your work wifi credentials.

Startup at work will require running a script from dom0 to...

stop all appVMs if any are running
stop sys-firewall
stop sys-net
update sys-firewall to use work-sys-net
start work-sys-net
start sys-firewall
start usual work appVMs

All done without an additional network device

Clear out any saved work wifi credentials in sys-net

This is how I would approach this issue.

Its a decent suggestion. You could have versions of sys-net for home,
work and public. However on R4.0 it isn't so complicated: you can keep
all your dependent VMs running if you use 'qvm-run -u root sys-net
"halt"'. Then when you start the other sys-net* and set sys-firewall's
'netvm' property to use it, the connection should be usable.

Another alternative would be to configure a single sys-net with either
dispVM or Qubes-VM-hardening so that neither passwords nor malware would
be retained when sys-net is restarted. Then you could control wifi
connections from a dom0 script. This would be like having a separate
sys-net for each wifi connection, if you restart sys-net whenever the
wifi connection was changed.

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/c62bcd60-7d83-124a-85ca-4b9c4930cc84%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4 - Debian 9 as SYS-NET and SYS-FIREWALL

2018-09-09 Thread Chris Laprise


On 09/09/2018 05:53 PM, Dominique St-Pierre Boucher wrote:

Good afternoon,

Is there a list of step to use Debian 9 as template for sys-net and 
sys-firewall...

Thanks...

Dominique


For sys-net you may have to first install the 'firmware-linux' package. 
That's the only special step I have needed.


The debian-9 template already has everything it needs for sys-firewall use.


--

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/c63d2f90-ce92-c70e-441e-5e5321653fea%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-07 Thread Chris Laprise

On 09/07/2018 11:10 AM, 22...@tutamail.com wrote:

Thank you both for your responses...fair question John but I am the OP, lost
access to my old tutamail. Yes my VPN was working fine for a few months however
with a recent update it broke?? Its a little concerning because I did both a
Debian and Dom0 update. When trying to update Dom0 I was not able to update it
via Tor or VPN via Qubes??

I managed to confirm my VPN is spawning out in an attempt to connect but the
TLS is still not working...I tried it on 3 different networks.

I know you can modify the DNS resolver by adding the following to the OpenVPN
configuration:

setenv tunnel_dns '8.8.8.8'

But what would I add to "Specifying 'local'" in the OpenVPN configuration?

Thanks again for any help...

IIRC you only need to specify the IP address of a regular system
interface, which in this case is eth0. So do a 'sudo ip addr' and look
up the eth0 'inet' address and put 'local ' in the config.
There's a chance this might work.

If it doesn't work, and you know of no custom firewall rules or net
settings that you can check or remove, then I'd consider the following
possibilities:

1. Your VPN provider has changed their TLS certificate or other
connection parameters. In this case their special client software (e.g.
installed on other devices?) would automatically refresh the config
files while your Qubes config would remain stale and unable to complete
TLS verification of the remote.

Remedy for this is to download your provider's current openvpn configs
and put them in /rw/config/qtunnel (making sure that qtunnel.conf points
to a new config file).

2. Some residual network property of your VPN VM has triggered a bug
that prevents it from working correctly. Simple remedy would be to
create and setup a new proxyVM and use that instead.

3. Unlikely: Interference from malware, possibly residing in sys-net.

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/d6b0e16f-7b37-f078-689a-802336cca615%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-06 Thread Chris Laprise

On 09/06/2018 10:22 AM, 22...@tutamail.com wrote:

It appears as if I am getting a TLS error? Why would this suddenly start?

Wed Sep 5 17:23:39 2018 TLS Error: TLS handshake failed
Wed Sep 5 17:23:39 2018 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 5 17:23:39 2018 Restart pause, 5 second(s)
Wed Sep 5 17:23:44 2018 TCP/UDP: Preserving recently used remote address:
[AF_INET]xxx.xxx.xxx.xx:port xxx

I have restarted the computer, I am using Qubes 4.0 and leveraging a Debian 9
template.

The other devices are using OpenVPN...

Any ideas?

When I search on the TLS error I get results like this:
https://serverfault.com/questions/709860/fix-tls-error-tls-handshake-failed-on-openvpn-client#765205

Specifying 'local' may be worth a try.

It sounds like something has gone wrong with the virtual devices or the
Qubes firewall for that VM... perhaps triggered by the system update.

I'm also using Debian 9 on Qubes 4. dom0 is updated with
security-testing enabled. Check your kernel version, mine is 4.14.67-1.

Testing basic connectivity for the VM can be done by first disabling the
tunnel firewall rules... delete the link at
/rw/config/qubes-firewall.d/90_tunnel-restrict. Then restart VM and use
ping/traceroute.

John,
Not sure what " script in an appvm/qube instead of the "tunnel" version ?" is...I had
tried to set up the "iptables and CLI scripts" https://www.qubes-os.org/doc/vpn/ but really
struggled. I found the Tasket solution easier to set up for a relative novice in desperate need of VPN
security. I am also able to setup a few configurations so I can use different destinations. Is this the
version you are using?

You can think of the vpn doc as a much older version of qubes-tunnel. I
doubt switching to it would help.

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/1460cb9e-f9ff-12ed-0512-9c2d964a530f%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-05 Thread Chris Laprise

On 09/05/2018 11:32 AM, 22...@tutamail.com wrote:

Correctionmy TOR is working. Any ideas how to trouble shoot?

Everything has been working fine, however recently my VPN tunnel is failing?

I ran: sudo journalctl -u qubes-tunnel

and I get:

Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 All
connections have been connect-retry-max (7) times unsuccessful, e
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 Exiting
due to fatal error
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Main process exited,
code=exited, status=1/FAILURE
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1149]: STOP-ing network forwarding!
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Unit entered failed
state.
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Failed with result
'exit-code'.

Some additional notes:
My connection works on other devices
I am able to get Internet access via non-VPN connection
I did update Dom0 and my templates but it worked shortly afterwards

Did you reboot the computer after the updates? What kind of template is
the VPN VM using?

Perhaps your other devices use non-openvpn protocols, and the VPN
service's openvpn server has gone offline?

You can try to make the connection manually, like this:

sudo systemctl stop qubes-tunnel
sudo iptables -P OUTPUT ACCEPT
cd /rw/config/qtunnel
sudo openvpn --config qtunnel.conf --verb 3

This will show a lot of detail in the terminal. A successful connection
will show "Initialization sequence completed" at the end.

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/68267906-f16e-bef3-517d-b681e0dad062%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can I set an unencrypted external HD as /home folder for a VM

2018-09-03 Thread Chris Laprise

On 09/03/2018 06:03 PM, Guy Frank wrote:

On Friday, August 31, 2018 at 6:31:58 PM UTC-4, Chris Laprise wrote:

On 08/31/2018 01:40 PM, Guy Frank wrote:

On Friday, August 31, 2018 at 12:17:54 PM UTC-5, js...@bitmessage.ch wrote:

Guy Frank:

One question I had is whether there is any way to set an unencrypted (or
encrypted?) external HD as the /home folder for a VM?

Guy

Hi Guy,

I'm not sure about setting it as /home but i think it's possible. But
it's easy to attach an external HD to a vm and save your files to it.

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

Also it's pretty easy to encrypt it with luks for security, it just
takes a little longer each time.

--
Jackie

Thanks Jackie for your reply!

I remember it being fairly easy to attach USB devices w/ the right clicks here
& there. So, yes, I'd have access to the files on my external HD.

But it would be more convenient if I could get Qubes to mount the home folder
on the HD as the Home folder for the given virtual machine. I imagine that's
trickier and was wondering if there's a way to do it?

Maybe use a script to mount the attached USB drive home (/home/guyuser) over
the Qubes home directory? But then, if that's possible, some of the setup in
the Qubes home directory might get missed.

The key to using it as /home would be to setup a new storage pool to
hold that VM. Unfortunately the docs could use a rewrite:

https://www.qubes-os.org/doc/storage-pools/

The relevant commands are 'qvm-pool --add' and 'qvm-create --pool'.

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

Hi Chris: Thanks! This looks like a step in the right direction, but I have
some questions. I'm guessing the commands will tell Qubes to treat my
external HD as a potential place to store a VM. But that seems like it
wouldn't take the existing home directory on the external HD as the VM home
directory but instead store a VM file containing the VM's home directory
structure on the disk. That file would, I imagine, be difficult to access on
the Kubuntu I have running on my home desktop and wouldn't contain the files
currently on my external hard disk, which mirror my Kubuntu files.

Is that the case and is there any fix? Am beginning to think the only way to
work this is to simply attach my external HD as a USB device and give up on
trying to make the files my home directory.

You're right that it wouldn't readily treat a bare home directory as the
VM's own, but create a Linux disk image instead.

But if the other systems are Ubuntu or similar Linux, you have options.
First is encryption: Ubuntu should recognize a LUKS-formatted drive when
its inserted and prompt the user for a passphrase automatically to
unlock and mount it. This could make your work flows more secure.

Also, I recall Ubuntu having some way to mount disk image files from the
file explorer. But you can setup the drive with LVM on top of LUKS (use
the LVM Qubes driver), and I think in this case Ubuntu may try to make
the LVM volumes available to the user as soon as its unlocked (if not,
you could use gnome-disks as a GUI to do this, although a script with an
icon would work too).

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/2a97c1a3-4d5a-3e43-3589-9e324b47f631%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] setting up vpn issue

2018-09-02 Thread Chris Laprise


On 09/02/2018 04:07 PM, Chris Laprise wrote:

On 09/02/2018 12:42 PM, Nicola Schwendener wrote:

Hi Chris,
thank you for your reply:
this is what I got:
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 
18:37:07 2018 SENT CONTROL [Server-2203-1a]: 'PUSH_REQUEST' (status=1)
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 
18:37:07 2018 PUSH: Received control message: 
'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.54.0.1,route 
10.54.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.54.0.106 
10.54.0.105'
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 
18:37:07 2018 OPTIONS IMPORT: timers and/or timeouts modified

--
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 
18:37:07 2018 /usr/lib/qubes/qubes-vpn-ns up tun0 1500 1606 
10.54.0.106 10.54.0.105 init
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Using DNS 
servers 10.54.0.1
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Chain 
QBS-FORWARD (1 references)


from the Personal VM connected via ProxyVM I cannot resolve 
anything... but I can ping 8.8.8.8...

thank  you again

Nick


If you can ping 8.8.8.8 or other numbers directly then the basic IP 
connection is working.


DNS seems to be the problem. They're assigning '10.54.0.1' as DNS. You 
could try replacing that with 8.8.8.8 for instance. The way to do this 
is in the Qubes-vpn-support readme page... basically add a line to your 
ovpn config file like:


setenv vpn_dns '8.8.8.8'

Then restart the VM.


I should note there are privacy concerns about using a third-party DNS 
server (8.8.8.8 is operated by Google). But I would still use this for 
testing purposes and if it works, then contact ExpressVPN support to let 
them know their own DNS server isn't working.



--

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/fe13159a-6e07-c0fc-fccc-ad9ef28e58a8%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] setting up vpn issue

2018-09-02 Thread Chris Laprise


On 09/02/2018 12:42 PM, Nicola Schwendener wrote:

Hi Chris,
thank you for your reply:
this is what I got:
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 18:37:07 2018 
SENT CONTROL [Server-2203-1a]: 'PUSH_REQUEST' (status=1)
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 18:37:07 2018 
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option 
DNS 10.54.0.1,route 10.54.0.1,topology net30,ping 10,ping-restart 60,ifconfig 
10.54.0.106 10.54.0.105'
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 18:37:07 2018 
OPTIONS IMPORT: timers and/or timeouts modified
--
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Sun Sep  2 18:37:07 2018 
/usr/lib/qubes/qubes-vpn-ns up tun0 1500 1606 10.54.0.106 10.54.0.105 init
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Using DNS servers 
10.54.0.1
Sep 02 18:37:07 sys-vpn-Express qubes-vpn-setup[654]: Chain QBS-FORWARD (1 
references)

from the Personal VM connected via ProxyVM I cannot resolve anything... but I 
can ping 8.8.8.8...
thank  you again

Nick


If you can ping 8.8.8.8 or other numbers directly then the basic IP 
connection is working.


DNS seems to be the problem. They're assigning '10.54.0.1' as DNS. You 
could try replacing that with 8.8.8.8 for instance. The way to do this 
is in the Qubes-vpn-support readme page... basically add a line to your 
ovpn config file like:


setenv vpn_dns '8.8.8.8'

Then restart the VM.

--

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/58b626df-d92e-bbf2-08e1-1a599f5fd94d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] setting up vpn issue

2018-09-02 Thread Chris Laprise

On 09/02/2018 11:39 AM, Nicola Schwendener wrote:

Hello all,
I'm an happy user of Qubes OS 3.2 that just installed a new Laptop with Qubes
OS.
I'm installing right now a new Proxy (or AppVM with network) for my expressVPN
connection. I'm right now stuck with the VPN service that seems to start
correctly (both following the official Doc: https://www.qubes-os.org/doc/vpn/
and the https://github.com/tasket/Qubes-vpn-support service.
both of them ping 8.8.8.8 but once I ping www.google.com I cannot resolve
anything. I've just updated the appvm to the fedora-28 but still same problem.

The Qubes-vpn-support is the easier one to configure and troubleshoot.
Have you looked at the proxyVM log with 'journalctl'? It should have a
line saying "Using DNS servers ..." with the addresses. Near the end it
should also say "Initialization sequence completed".

When you try ping, is it from a downstream appVM (a regular appVM that
is connected to the proxyVM)?

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/f3890bdf-e201-3b3b-ef88-9673f9cbdbec%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can I set an unencrypted external HD as /home folder for a VM

2018-08-31 Thread Chris Laprise

On 08/31/2018 01:40 PM, Guy Frank wrote:

On Friday, August 31, 2018 at 12:17:54 PM UTC-5, js...@bitmessage.ch wrote:

Guy Frank:

One question I had is whether there is any way to set an unencrypted (or
encrypted?) external HD as the /home folder for a VM?

Guy

Hi Guy,

I'm not sure about setting it as /home but i think it's possible. But
it's easy to attach an external HD to a vm and save your files to it.

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

Also it's pretty easy to encrypt it with luks for security, it just
takes a little longer each time.

--
Jackie

Thanks Jackie for your reply!

I remember it being fairly easy to attach USB devices w/ the right clicks here
& there. So, yes, I'd have access to the files on my external HD.

Maybe use a script to mount the attached USB drive home (/home/guyuser) over
the Qubes home directory? But then, if that's possible, some of the setup in
the Qubes home directory might get missed.

The key to using it as /home would be to setup a new storage pool to
hold that VM. Unfortunately the docs could use a rewrite:

https://www.qubes-os.org/doc/storage-pools/

The relevant commands are 'qvm-pool --add' and 'qvm-create --pool'.

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/b82ef887-5be1-fd5c-bcd2-2727101d5d0e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Proxy VM option missing upon creating a new VM !

2018-08-25 Thread Chris Laprise

On 08/25/2018 03:59 PM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-08-25 14:24, 'awokd' via qubes-users wrote:

On Sat, August 25, 2018 7:01 pm, Chris Laprise wrote:

On 08/25/2018 02:25 PM, Rusty Bird wrote:

odindva0...@gmail.com:

I am using version R 4.O and recently decided to set up a new Vpn
connection . But when I try to select the type is only giving me AppVM
and Standalone option so obviously I can't move forward . I am
attaching picture of it so you can see it youself :
https://imgur.com/a/xTmpUDX .

Tick the "provides network" box, that's the R4.0 equivalent to ProxyVM
in older Qubes versions.

Rusty

I've come to the conclusion that attempting to change the terminology
for VM types was a mistake. People are getting confused and referring to
"network-providing appVM" in the generic is awkward at best --
especially if you are merely describing or referring to VMs instead of
giving instructions on creating them.

Think some additional text in the dialog box like "provides network
('ProxyVM')" would do it? Agree that "network-providing appVM" is a bit of
a mouthful.

If I understand correctly, it's not merely a terminological change.
Rather, there is simply no longer such a thing as a "ProxyVM" in Qubes
4.0, where a "ProxyVM" is understood to be a VM that has the inherent
property of proxying network access. Instead, "provides network" is a
switchable property can apply (or not) to *any* VM. You can flip the
switch on to make a VM play the role of a ProxyVM (and/or a NetVM?),
then switch it off again later, and it'll still be the same VM. At any
rate, that's what I gather from this comment from Marek:

https://github.com/QubesOS/qubes-issues/issues/1763#issuecomment-188786341

Except VMs internally still use the proxyVM term in /var/run/qubes for
example. Its how my VPN code makes decisions about where+what to run.

I'd vote for adding (ProxyVM) in parentheses to the "provides network"
label (not tooltip) in the create dialog.

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/f58e69f6-1724-571d-d2f0-c39562b3f32f%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Proxy VM option missing upon creating a new VM !

2018-08-25 Thread Chris Laprise


On 08/25/2018 02:25 PM, Rusty Bird wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

odindva0...@gmail.com:

I am using version R 4.O and recently decided to set up a new Vpn connection .
But when I try to select the type is only giving me AppVM and
Standalone option so obviously I can't move forward . I am attaching
picture of it so you can see it youself :
https://imgur.com/a/xTmpUDX .


Tick the "provides network" box, that's the R4.0 equivalent to ProxyVM
in older Qubes versions.

Rusty


I've come to the conclusion that attempting to change the terminology 
for VM types was a mistake. People are getting confused and referring to 
"network-providing appVM" in the generic is awkward at best -- 
especially if you are merely describing or referring to VMs instead of 
giving instructions on creating them.


--

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/985ef3e7-895f-cd11-c5ba-1b74d210dbb5%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Asking Template VM 'user' passsword after running autoremove.

2018-08-24 Thread Chris Laprise

On 08/24/2018 09:18 AM, wlmini...@gmail.com wrote:

Hi
I wanted to clean up my Template VM by running sudo dnf autoremove and sudo apt
autoremove..
But after this, Template vm started asking user's password which I don't know
and can run sudo..
And After restart qubes os, network manager is not running so I can't connect
to the internet..
How can I solve this issue?

You can try to revert the template's filesystem like this (dom0):

$ qvm-volume revert templatename:root

This will only work if you haven't restarted the template since it was
damaged.

The next-easiest solution is to switch (at least temporarily) to another
template for sys-net if you have one -- this is a good reason to have
more than one template, in case your main one gets damaged.

Another thing to try is to get your Qubes install media and see if you
can locate the template .rpm package files on it (I don't recall the
path at the moment); They could be installed manually.

Finally, you could try connecting using the damaged template/sys-net.
There are advice pages around the Internet that describe connecting
without NetworkManager for instance (I suggest doing this with ethernet
cable which is easier than wifi):

https://unix.stackexchange.com/questions/253030/how-to-setup-network-without-wicd-or-networkmanager

In order to execute commands to repair the template, you'll need to
start a root shell from dom0 like this:

$ qvm-run -u root vmname 'xterm'

Good luck!

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/104427f2-ef40-0bec-14fd-bc612d566f53%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Possible to downgrade to KDE4 in dom0?

2018-08-21 Thread Chris Laprise


On 08/21/2018 04:52 PM, 'Zeko' via qubes-users wrote:

Hello

I've been using Qubes R4.0 for several months now and I'm getting tired 
of Xfce, but KDE 5 is just unworkable on my nvidia GPU (yeah yeah I know 
nvidia and Linux...). Is it possible to downgrade or install KDE4 in 
dom0 somehow?


Ty
Zeko


You'd be better off switching to integrated graphics; much much simpler.


--

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/e34b7fa1-6602-d6f4-c187-dd2b8e3b1b58%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Shredding VM images

2018-08-20 Thread Chris Laprise


On 08/20/2018 11:34 AM, tierl...@gmail.com wrote:

What's the most convenient way to wipe these images? (I'm just talking about 
individual VM images)


To clarify on your first question: Since encryption is protecting the 
storage pool that contains the disk images and its on an SSD, the only 
sure way to 'wipe' them in general (not just in the other-VMs-can't see 
the data sense) is to throw away the encryption passphrase. This 
makes the entire pool unusable, but if this seems like a problem you can 
configure more than one storage pool each with its own encryption 
key+passphrase and store VMs inside them.



--

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/d1cc1013-3b70-e838-f2e7-5b1b8490d7b5%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Shredding VM images

2018-08-20 Thread Chris Laprise

On 08/20/2018 11:34 AM, tierl...@gmail.com wrote:

What's the most convenient way to wipe these images? (I'm just talking about
individual VM images)

I'm on Qubes 4.0, and I understand it's not that simple on SSDs, but whats the
situation?

The SSD's firmware determines 100% whether or not discard/TRIM commands
(generated when deleting files and VM volumes) cause data to be
physically erased.

Qubes does not pass discard/TRIM to the SSD by default however, so you
may want to enable that. https://www.qubes-os.org/doc/disk-trim/

The role discard does play in a default Qubes config is to deallocate
blocks from the pool-- these blocks are effectively wiped as far as any
future VM allocation is concerned (no domU VM can see the deallocated
data even if it later gains control over the deallocated blocks).

I see that /dev/mapper has a number of links to ../dm devices, these are
encrypted, right? Where is the key stored? How is that stored on disk, and is
it likely to leave fragments all over the drive?

In a default Qubes config, the ones prefixed with "qubes_dom0" are all
encrypted. It is possible to install Qubes differently, however, so that
these are not encrypted or use a different encryption scheme.

The key is normally stored in a LUKS disk header which itself gets
unlocked when you enter a correct passphrase.

Can a `shred -vzn 7` be done on these devices? Does it effectively erase the
data?

Its doubtful that shred would be of much use on an SSD, because shred
needs the drive to "rewrite data in-place" which SSDs almost never do.

The only thing that we know for sure protects your privacy with an SSD
is encryption.

I see that within /dev/mapper there's foo--private, foo--private--{0-9}+--back,
and foo--private--snap. What's the difference between these? How are they
created and used?

Unfortunately these are not well documented yet. The vm-foo-private-snap
volumes are working-copy snapshots while the VM is running (IIRC this
behavior is supposed to change for 4.1). The best docs on the storage
layer currently appear to be:

https://www.qubes-os.org/doc/template-implementation/
https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-storage.html

Am I right in thinking that only the private images hold VM specific states?
What about foo--volatile?

The volatile volumes are swap space. They are deallocated when the VM is
started/stopped.

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/d2ee4ec6-0432-a47d-7c35-fa8134eec8f4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Appvms dont have net via vpn vm

2018-08-19 Thread Chris Laprise

On 08/18/2018 09:47 PM, Stumpy wrote:

On 2018-08-18 22:30, Chris Laprise wrote:

On 08/18/2018 12:39 PM, Stumpy wrote:
I am able to ping via the vpn vm but when I try to connect to the net
with an appvm that is using the vpn vm I cant connect to anything. Im
using v4.0 and the script method, not the netmanager method. I have
double checked all the config files that I created and as far as I
can tell they are right. I havent been able to connect using this vpn
vm so its not a case of was working before. Is there a log or
something I can post to help diagnose this issue?

Thanks

To see log messages, you can test the client as suggested in Step 2.
It may help to use ping in the appvm, first with a known IP address
and then with a domain name (this tests basic connection and DNS).

If you think you might have made a mistake with the scripts, I created
a streamlined alternative with no file editing that is being
considered for inclusion in Qubes:

https://github.com/tasket/qubes-tunnel

The process is to run the installer as shown in the Readme, then run
qtunnel-setup and add your VPN config to the qtunnel directory. Full
instructions:

https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service

Thanks for that, I checked the iptables, and tried pinging startpage.com
and it seemed to go well enough but then again I am not wholly sure
about that. I posted the output here: https://pastebin.com/3bZwKr3k

The way you created, does that also have the "fail closed" feature?

Have you tried pinging an IP address from a connected appvm (not vpn vm)
like this:

ping 216.218.239.22

If that works but not "ping startpage.com" then there is a DNS handling
issue.

I wrote those script instructions long ago, then decided people needed
something easier and more robust. The new code at qubes-tunnel has all
of the fail closed features, too.

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/eb37b3ed-6630-01fd-7da8-c366d8906f34%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Appvms dont have net via vpn vm

2018-08-18 Thread Chris Laprise

On 08/18/2018 12:39 PM, Stumpy wrote:
I am able to ping via the vpn vm but when I try to connect to the net
with an appvm that is using the vpn vm I cant connect to anything. Im
using v4.0 and the script method, not the netmanager method. I have
double checked all the config files that I created and as far as I can
tell they are right. I havent been able to connect using this vpn vm so
its not a case of was working before. Is there a log or something I can
post to help diagnose this issue?

Thanks

To see log messages, you can test the client as suggested in Step 2. It
may help to use ping in the appvm, first with a known IP address and
then with a domain name (this tests basic connection and DNS).

If you think you might have made a mistake with the scripts, I created a
streamlined alternative with no file editing that is being considered
for inclusion in Qubes:

https://github.com/tasket/qubes-tunnel

The process is to run the installer as shown in the Readme, then run
qtunnel-setup and add your VPN config to the qtunnel directory. Full
instructions:

https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service

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/b79421cd-8ae9-c9eb-aaa5-6823b53a11b2%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is Qubes vulnerable to CVE-2018-3620?

2018-08-15 Thread Chris Laprise


On 08/15/2018 08:40 AM, Rusty Bird wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sphere:

https://www.bleepingcomputer.com/news/security/researchers-disclose-new-foreshadow-l1tf-vulnerabilities-affecting-intel-cpus/

There are other vulnerabilities disclosed along with this today and
if possible, I would like to confirm that as well.

On a side note, I have long disabled Hyperthreading on my machine.


To me as a layman, it looks like Qubes is indeed vulnerable to the
XSA-273 data leak, and that fixing it involves

1. disabling hyperthreading (by adding smt=off to the Xen command line)
2. AND upgrading Intel microcode to 20180807


On #2, assuming Intel has still abandoned Ivy Bridge and earlier CPUs, I 
wonder if this makes the CoreBoot targeted systems essentially 
unsafe/unusable.


Very bad.

--

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/6c1e9733-4a7d-bc0a-7ab0-927b4599e7f2%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How do I install this Firewall HVM ?

2018-08-14 Thread Chris Laprise

On 08/14/2018 02:22 PM, Steve Coleman wrote:

On 08/14/18 13:40, Who Cares wrote:

I am using qubes 4.0 and i am trying to install a firewall.

Qubes comes with an integrated firewall in the sys-firewall VM. It uses
managed iptables which provide the basic rules to protect the system,
but also allow you to make adjustments as required for your unique
situation.

So, I'm not sure why you think you need to add yet another firewall

The architecture is generally

YourVM -> sys-firewall -> sys-net -> LAN Network

You get this setup right out of the box, with no configuration required.

Perhaps you could explain better what you are trying to accomplish?

I hope anyone would spend some time helping me with this project of mine.

At the end it is one PC where is installed qubes. This one is a
local-server

This PC got 2 LAN devices i could attach separately.
I want 2 routes.

Route 1: Net-VM(LAN 1) --> firewall-VM(Kerio-Control with VPN)
Route 2: Windows-Server HVM with a specific Programm.(attached LAN 2)

Scenario 1: Local Network Windows PC working with a Programm wich need
this Windows Server Programm Service

Scenario 2: A dude located in Timbuktu(or whatever) want to work on
the same local Network using the kerio-control VPN and his Windows
device needs to communicate with the windows Server.

Any thougts about this ?

If you can find out which VPN protocol this kerio-control is using, then
you may be able to do this better with native Qubes tools.

Their VPN protocol appears to be IPsec (which isn't great BTW); you
could start with a Linux IPsec tutorial in a proxyVM to see if you can
connect to this other person.

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/b06c427a-1775-4f7d-c147-8220bd755254%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread Chris Laprise

On 08/13/2018 05:32 PM, joevio...@gmail.com wrote:

On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise wrote:

On 08/13/2018 04:47 PM,

Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread Chris Laprise

On 08/13/2018 04:47 PM, joevio...@gmail.com wrote:

Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread Chris Laprise

On 08/13/2018 04:26 PM, joevio...@gmail.com wrote:

Thanks.

Is Btrfs an option when installing Qubes 4.0?

Yes.

BTW,
Qubes fully recovered.

Like last time I messed things up by filling up the LVM,
Here are the steps:

Insert a bigger drive
create PV from new drive
added PV to VG
LVmove pool00_tdata from full drive to new PV
LVextended Pool00 to give room
LVextended pool00_tmeta (this was the corrupted part)
LVconvert --repair qubes_dom0/pool00
I did try all this yesterday, but the drive I put in, had a previous Qubes 4
install. Even with deleting the partitions, it seemed to still recognize the
Volume Group information on it. And since it is also named qubes_dom0... it
really messed things up and had me going down rabbit holes with a VG with a
MISSING PV. No commands really work when in that stuck state.

The issue still remains if anything will be done with Thin Provisioning to
prevent this from happening. Last time this happened, there was no disk storage
applet. This time, there was, but I just didn't see what a vmdk file was going
to be on disk.

There is an issue opened for this IIRC, and I think the target is R4.1.

Should VMs get automatically paused when approaching the limit?

That's my initial inclination because the user may not be at the
computer to take immediate action when the space crisis occurs. But I
think the resolution will also involve moving dom0 root out of the thin
pool to a static-sized lv.

Also, should dom0 be inside the thin pool? Or would it make sense to keep it as
its own LV? Yeah, it means dom0 cannot grow with the pool, but should it?

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/9bfbe632-0d1f-19a0-719f-7deb6b918c37%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Incredible HD thrashing on 4.0

2018-08-13 Thread Chris Laprise

On 08/13/2018 03:26 AM, Kelly Dean wrote:

Unman writes:

I don't recognise this on a somewhat under powered laptop with HDD -
definitely not "minutes at a time". Is there something significant about
the disks that you cite, or are those just examples?

Nothing significant about #21 in particular. The thrashing procs are whichever
ones handle the virtual disks for a qube that's thrashing.

System is a core i3 with 16GB RAM, and HD with about 100MB/s throughput.

Worst problems seem to be from swapping, and random times when I start a qube.

The swapping is unpredictable, but here's a typical best-case result for
starting an ordinary app qube with fedora-28 template:
T+0: start qube. Brief burst of CPU & disk activity for a second, then mostly
idle for 20 seconds.
T+20: heavy sustained disk thrashing starts.
T+40: pop-up notification that the domain has started. Thrashing continues.
T+60: thrashing abruptly stops.
That's only 1 minute, but when I'm unlucky, it can be several minutes.

How does that compare with your experience?

I don't have anything custom configured to run in the qube at startup, so all
the activity is from the template's defaults. Nothing special about fedora-28
either; I get similar results from debian-9 and whonix-ws.

Can Qubes access all of that RAM? Look at the total_memory figure from
'xl info'.

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/7a4a0c2c-7294-5a37-10d0-0615185a3073%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qube manager has unexpectedly stopped working

2018-08-13 Thread Chris Laprise

On 08/13/2018 03:07 PM, rumsey.anth...@gmail.com wrote:

On Monday, August 13, 2018 at 6:28:22 PM UTC, awokd wrote:

Do not reboot. Backup everything immediately. It is bad if your thin pool
is running low, and may have caused the issue. Once that's done, it's
probably safest to reinstall...

Too late not to reboot. No lost information though, so that won't be a problem.
Just was hoping to save the time required for a reinstall.

Thanks for the info. I'll just go ahead and reinstall.

Can you tell me what I did or how to avoid this issue with the thin pool in the
future? Was I just taxing my system resources too heavily? I'll have to look
into it because I don't really even know what the thin pool is.

Thanks

Unfortunately Qubes does not have very clear warnings or preventative
measures to avoid out-of-space problems; this may be addressed in R4.1.
For now its good to keep an eye on your disk space meter.

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/ccb32cd9-5ad8-cd6a-f168-a01c74e50418%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread Chris Laprise


On 08/13/2018 06:48 AM, 'awokd' via qubes-users wrote:

On Mon, August 13, 2018 7:59 am, joevio...@gmail.com wrote:


Should I mount each LV
and attempt to import the root.img and private.img files? How would I
mount those to get to the files, and how would import to Qubes?


Sounds pretty FUBARd. LVs don't have .img files; if you can manage to get
them mounted you might be able to recover contents. Boot from some
recovery distribution and get the Qubes PV attached, then "mount 
/dev/mapper/qubes_dom0-vm--vmname--private" for example.


Thin LVs can be imaged like normal volumes, however. I would try 
'vgchange -ay' then 'lvchange -ay' on the drive and then look for the 
vm*private volumes in /dev/mapper.


Once you got that, you can do stuff like this to backup:

# dd if=/dev/mapper/qubes_dom0-vm--work--private | gzip >work_img.gz

and this to restore:

#  gunzip -c work_img.gz | dd 
of=/dev/mapper/qubes_dom0-vm--work--private conv=sparse


This example is unencrypted, so take care with the remaining backup details.

Also keep in mind that thin-provisioned lvm is still pretty young -- it 
is NOT 'like' regular non-thin lvm, but more like a new filesystem on 
top of regular lvm. If reliability is high on your list then Btrfs may 
be better... it seems to be older with a lot more people using it, and 
has more internal error-correction mechanisms (but it still isn't 
recommended for RAID5/6). Btrfs is worth considering as an alternative.


--

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/69368c6b-9bc6-1690-5c5b-e47c02f45b8d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

2018-08-13 Thread Chris Laprise

On 08/13/2018 07:32 AM, qubes-...@tutanota.com wrote:

Chris, which guide did you follow when installing the new whonix 14 Template as a
"recommended whonix install procedure"? I found these two.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Qubes/Install#

<http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Qubes/Install#>

https://www.qubes-os.org/doc/reinstall-template/
<https://www.qubes-os.org/doc/reinstall-template/>

Thanks

It was a bit confusing, but from the wiki Install page I picked out
these relevant steps for dom0 (Qubes 4.0):

$ sudo qubes-dom0-update qubes-core-admin-addon-whonix
$ sudo qubesctl state.sls qvm.anon-whonix

The second command will start the download and install, although it does
not give much feedback.

Also, there is no need to clone old whonix-gw in the steps I mentioned
earlier; only whonix-ws is needed. Once you have your appVMs switched
over to whonix-ws-14 you can delete the clone.

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/c8938a67-4998-2681-a581-680b157c9a1b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

2018-08-12 Thread Chris Laprise

On 08/12/2018 05:23 PM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-08-12 14:26, 'awokd' via qubes-users wrote:

On Sun, August 12, 2018 6:16 pm, qubes-...@tutanota.com wrote:

I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My
question is what way it should be easier, based on the Q user
experiences. What would you propose - upgrade or re-install? Are
there any known issues which would call for one or other way?

Re-install is usually easier.

I have few VMs based on the Whonix template with data and
settings on it. Will the contents of these VMs remain, or will
it be destroyed - re-install vs upgrade?

Contents should remain, just set them to the new Whonix template.
Make sure to back up everything first.

The installation guide [1] states:

"Re-installation will destroy any existing user data stored in Whonix
VMs, unless it is backed up first. To avoid this scenario, it is
possible to upgrade Whonix 13 to 14 instead of following these
instructions."

This was puzzling to me, too, since TemplateVM upgrades usually don't
affect user data in TemplateBasedVMs. Could you shed some light on
this, Patrick?

What I did: Cloned the old whonix-ws template, switched appvms to the
clone, then did 'dnf remove' on the old templates and finally performed
the recommended whonix install procedure.

Later, I was able to switch existing whonix appVMs to whonix-ws-14.

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/4433888d-cbfe-8ea2-2143-1ba4a0dcae0e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Incredible HD thrashing on 4.0

2018-08-10 Thread Chris Laprise

On 08/10/2018 03:02 PM, Kelly Dean wrote:

Has anybody else used both Qubes 3.2 and 4.0 on a system with a HD, not SSD?
Have you noticed the disk thrashing to be far worse under 4.0? I suspect it
might have something to do with the new use of LVM combining snapshots with
thin provisioning.

The problem seems to be triggered by individual qubes doing ordinary bursts of
disk access, such as loading a program or accessing swap, which would normally
take just a few seconds on Qubes 3.2, but dom0 then massively multiplies that
I/O on Qubes 4.0, leading to disk thrashing that drags on for minutes at a
time, and in some cases, more than an hour.

iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and [21.xvda-1],
reading the disk at rates ranging from 10 to 50 MBps (max throughput of the
disk is about 100). At this rate, for how prolonged the thrashing is, it could
have read and re-read the entire virtual disk multiple times over, so there's
something extremely inefficient going on.

Is there any solution other than installing a SSD? I'd prefer not to have to
add hardware to solve a software performance regression.

I really don't know if LVM or Ext4 have an SSD/HDD mode, but Btrfs does.
The HDD mode avoids some thrashing.

Also, I remember installing a 4.0 release candidate on an external HDD
and didn't note unusual thrashing at the time.

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/ddf8ceb6-1758-3ca6-7f6d-3658de12460a%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Best Laptop for Qubes 4+ and Heads

2018-08-10 Thread Chris Laprise

On 08/10/2018 08:25 PM, Franz wrote:

On Fri, Aug 10, 2018 at 5:23 PM, Jonathan Brown
mailto:jonbrownmaste...@gmail.com>> wrote:

How bad does the RAM issue affect your VM number you want to run vs
what you can run? Can it handle all the required VMs needed by
default along with both Whonix templates and split GPG?

yes, a part from the system VMs, I usually run 6 VMs. When the machine
is fresh started I can easily reach 9 VMs. But after a couple of days
working it doesn't let me start new VMs.

How does it actually run performance wise?

Smooth and fast.

But I never tried gaming or specially intensive tasks.

The ivy bridge CPUs are pretty fast.. the last generation before Intel
cut max wattage in half with haswell.

BTW there are little tricks to improving RAM usage, as my regular system
has 8GB. Net and proxy VMs can usually be set to max 350MB RAM, and I
find dom0+KDE works smoothly with max RAM at 1500MB. Most personal and
work VMs do fine with max RAM at 1500 - 2000MB.

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/99d14434-bde6-8d93-f68c-d03e4b2d022b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Where to add command to turn wifi off

2018-08-08 Thread Chris Laprise


On 08/08/2018 12:05 PM, trueriver wrote:

Chris's suggestion was not quite right, but near enough for me to get it 
working. This is no reflection on Chris but is down to inconsistent naming 
conventions between different devs on different projects.

Chris said


You can open a terminal in your template and run the following:

sudo touch /var/run/qubes-service/network-manager


up to here is correct, but there are two points with the following line


sudo service network-manager start


Firstly, it tries to do it but suggests we use systemctl instead.

Secondly systectl does not know of a service by this name. I then did a bit of 
searching and it turns out that the correct command is

sudo systemctl start NetworkManager


Yes, I should have mentioned I worked that out on Debian 9. Fedora 
service names are different.



--

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/cdcb1349-4440-9ef2-5edf-fb566f9145d6%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Where to add command to turn wifi off

2018-08-08 Thread Chris Laprise

On 08/08/2018 09:10 AM, trueriver wrote:

What I am actually wanting to do is to alter sys-net so that the wifi does not
start without my deliberate intervention, regardless of whether it was enabled
at the most recent shutdown.

This is not to disable it totally, but to ensure that it only starts if I right
click the widget and tick the enable wifi checkbox.

At present the wifi is enabled on sys-net startup, even when disabled from the
system tray widget on the previous shutodwm. This is the exact reverse of what
I want!

I apologise for raising this here (it is more appropriately a NetwrokManager or
Fedora question) but it arises for me in the context of Qubes.

I have identified the command

nmcli radio wifi off

and am wondering where to insert this command in the start-up sequence. And do
you recommend it to be in the sys-net Qube /rw space, or in the template (so
that it actually runs at every startup).

Also, I am wondering if I have missed a config setting for NetworkManager that
will do this for me. I have pored over the man pages and googled NetwokrManager
disable but not found an answer. Plenty of ways to disable power management but
that turns out to be something different.

R~~

You can open a terminal in your template and run the following:

sudo touch /var/run/qubes-service/network-manager
sudo service network-manager start
nmcli radio wifi off

Then shutdown the template and restart sys-net. NM should remember the
setting you made in the template and start with wifi turned off. It can
be turned on by right-clicking the systray icon and enabling the wifi
checkbox.

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/be5e9436-14d0-bbf0-082d-c1f2d46a38b7%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0: copy/paste between VMs doesn't work

2018-05-23 Thread Chris Laprise


On 05/23/2018 11:29 AM, trucs.important...@gmail.com wrote:

Hi, I've reinstalled Qubes 4.0 and copy (ctrl+c / ctrl+alt+c) works but not 
paste (ctrl+alt+v / ctrl+v)...
An idea to resolve it?


The combination is Ctrl+Shift not Ctrl-Alt.


--

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/217ef03c-1c2a-0677-dae9-9f4e9f79a585%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] AEM boot = GPU hang, no graphics display

2018-05-23 Thread Chris Laprise

After setting up anti-evil-maid in R4.0 my laptop is unable to boot into 
a usable desktop: The resulting display is just a static wall of random 
stripes appearing before passphrase prompts; here I can press Esc for 
text mode.


After the disk comes online the graphics stripes return and I can't use 
the GUI. I can log in to a console terminal and access dmesg which has 
the following messages (grep i915):



[0.00] Kernel command line: placeholder 
root=/dev/mapper/qubes_dom0-root ro 
rd.luks.uuid=luks-dcf904cf-4f9e-4f06-9bb1-a95de63936f7 
rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap 
i915.preliminary_hw_support=1 rhgb quiet 
aem.uuid=390847c2-50ec-40d9-af24-f9f34a52a209 rd.luks.key=/tmp/aem-keyfile 
rd.luks.crypttab=no
[4.969412] i915: unknown parameter 'preliminary_hw_support' ignored
[5.158667] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[5.364560] [drm] Initialized i915 1.6.0 20170818 for :00:02.0 on minor 0
[6.601641] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   10.722959] i915 :00:02.0: Resetting chip after gpu hang
[   12.704533] i915 :00:02.0: Resetting chip after gpu hang
[   12.704743] [drm:i915_reset [i915]] *ERROR* GPU recovery failed
[   96.864496] snd_hda_intel :00:1b.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])



The GPU is Intel integrated HD graphics (Ivy Bridge). Qubes is updated 
using current/stable and the kernel version is 4.14.35-1.


I wonder if there is a kernel parameter I should be using to get the GPU 
working?


BTW, one alteration I had made to get around issue #2155 (lockup on 
boot) is to manually upgrade the tboot component (initially 1.9.4 then 
1.9.6) - Fedora 25's tboot version is very old. I don't know if the 
tboot update has an impact on graphics but thought I'd mention it.


--

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/ce1351af-7940-1ff5-a80f-b64fa7919356%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is it possible to create a fast clone/copy-on-write Qube?

2018-05-22 Thread Chris Laprise

On 05/22/2018 05:51 PM, fsharpn...@gmail.com wrote:

I want to do the following.

1. Create an HVM Qube. This Qube contains a clean install of an OS such as
Windows 8 or Arch.

2. Clone the Qube from #1. The files that make up this Qube should just contain
the delta from the parent Qube. Writes are made to the child Qube; reads go to
the child Qube (if the data being read was written previously) or to the parent
Qube if not (in other words, copy-on-write.) I want to install applications in
this Qube, so changes should persist.

Hyper-V does this with differencing disks (see
https://technet.microsoft.com/en-us/library/cc720381.aspx.)

It looks like Xen does this also, with fast cloning (see
https://docs.citrix.com/en-us/xencenter/6-2/xs-xc-vms/xs-xc-vms-copy.html.)

My question is, can this be done in Qubes? From searching the Web and the docs,
it looks like not, but I thought I'd see if I've overlooked anything.

One way would be to have a TemplateVM and a TemplateBasedVM, but have changes
to the TemplateBasedVM (outside of /home) be persistent. I don't know if Qubes
allows that.

One possible way (I think) would be to use Btrfs as the dom0 file system, but I
don't know if that's allowed either.

Otherwise, I'll have to create the parent Qube and then clone it with
qvm-clone, but it looks like that creates a full copy, which I'd rather avoid
if possible due to the disk space consumption.

By default, the Qubes 4.0 volume manager will always create COW (not
full) clones. If you choose btrfs instead, the effect will also be the same.

One Qubes 3.2, you have to choose btrfs (or prepare a pool with a
similar filesystem having COW reflinks) for this type of cloning to work.

Keep in mind that (as with Hyper-V) these block level differencing
volumes will diverge increasingly over time as updates are applied. That
means the initial space savings will begin to shrink. I don't know if
Hyper-V has a solution to this, but on Linux one way to help prevent
divergence is deduplication (such as in btrfs).

Overall, these cloning options (using LVM or btrfs) should work more
smoothly than Hyper-V storage. Note the warnings re: volume spoilage on
the Microsoft page don't apply to Qubes; you still have to update each
cloned OS, but there is no need for you to keep track of volumes to
avoid spoilage.

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/18714794-db7d-7b0f-a810-4ff8f2fbbbc0%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking freezing and impossible to restore without reboot

2018-05-17 Thread Chris Laprise


On 05/15/2018 08:01 PM, 'Evastar' via qubes-users wrote:


And 2th question:

Do you know how to restore all connections after proxyvm reboot. Yes, it's not 
possible to reboot it from qubes manager, but I can reboot it with terminal. 
Then, maybe, some simple steps exists to reconnect all AppVMs? This would help 
me a lot. It's my simpler to reboot only proxyVM vs all vms.


The way I'm familiar with involves re-setting the netvm of each 
downstream VM after the proxyVM has rebooted.


One way you could achieve this is with my 'findpref' script in dom0:
https://github.com/tasket/Qubes-scripts

$ findpref -p netvm sys-vpn sys-vpn


--

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/83fd76cc-1714-3b7f-3b7b-62f06116e909%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking freezing and impossible to restore without reboot

2018-05-17 Thread Chris Laprise

On 05/15/2018 07:51 PM, 'Evastar' via qubes-users wrote:

If the vif interfaces are going down, that suggests a bug either in

Today it happens again and now I open terminal at ethervpn and write "route".
It freeze, not totally freeze, but it print line by line output of this command and every
line took ~10 seconds to print. Maybe it's because I use imported ethervpn from 3.2.
backup? Something happens :(

Try adding '-n' option to route so it won't try to look up names for
each IP address.

tun and tap interfaces look similar in the sense that they're all

I don't know how to check this.

This can only be checked in the ethervpn code. You may wish to report
the behavior to the ethervpn people.

And other question. You are advanced user and you must know.

I'm trying to use this script to get correct gatewayIP to setup routes.

IP="$(ip addr | grep 'vpn_vpn' -A0 | tail -n1 | awk '{print $2}' | cut -f1
-d'/')"

(vpn_vpn is "dhclient vpn_vpn" )

"ip addr" print output: 192.168.30.10/24, this command give me 192.168.30.10,
but I need to find somehow and add to variable 192.168.30.1 then I want to use it with
this command:
ip route add default via $IP

So sure, I don't know why it's report .10/24 and not .1/24

Maybe you know where/how to get correct IP? My regular setup works with
hard-coded 192.168.30.1, but I want to parse it on the fly.

Normally I would use 'hostname -I' to find the VM's IP address.

Thanks

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/3e0ad9e2-eecd-2141-2594-8014ba53a03b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] What is the best recommended way to setup a bulletproof vpn on Qubes 4 ?

2018-05-15 Thread Chris Laprise


On 05/13/2018 12:21 PM, awokd wrote:

On Sun, May 13, 2018 3:34 pm, jhsdxs...@gmail.com wrote:

I'm new to Qubes and would like to have the traffic for all my Virtual
Machines go through a VPN. I am really not sure how to do this. I've tried
following the official Qubes Documentation page about VPNs but I haven't
had any luck. I'm on Qubes 4.0. Thanks


You can try tasket's updated documentation at
https://github.com/tasket/qubes-doc/blob/a19ddb67ba3820733986978676bcfd33e4743867/configuration/vpn.md.




The code that goes with the doc is here:
https://github.com/tasket/qubes-tunnel

--

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/203bfbc6-3768-3d17-081c-a475957644ca%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking freezing and impossible to restore without reboot

2018-05-15 Thread Chris Laprise

On 05/15/2018 03:37 AM, 'Evastar' via qubes-users wrote:

Posting back to qubes-users...

Sorry for direct message. Now, I use web-based mail it set direct answer by
default :(

A little more information. When it goes to "no network state" then I seeing at my ethervpn with "ip
route list" (as I remember) that all vif+ interfaces show as "down". It is the problem. I do not know
how to reconnect them and remove "down" mark.

Finally, if you find the solution involves restarting the ethervpn
client, you may want to run it with 'systemd-run --unit' to give you
better control over the process. You could even try running it with
qubes-tunnel using a drop-in file for the service (see 00_example.conf
and manpages for systemd.unit "overriding vendor settings").

Thanks. I will check this manpages. Maybe this will help.

If the vif interfaces are going down, that suggests a bug either in
Qubes or in ethervpn. Since other Qubes users don't seem to be reporting
this symptom, I'd guess that ethervpn is mistakenly including the vif
interfaces with tun/tap whenever a link goes down or restarts. (The vif,
tun and tap interfaces look similar in the sense that they're all
virtual.) Its probably worth reporting this behavior on the ethervpn
forum/list.

You might also try writing a small script to bring the vif interfaces up.

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/c4c6d117-e112-f398-30c7-f58bb79b5f40%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking freezing and impossible to restore without reboot

2018-05-14 Thread Chris Laprise

On 05/14/2018 06:23 PM, Evastar wrote:

Its important to know how you set up the VPN VM. If you used the Qubes

doc, that config can have problems recovering from a disconnected link.
If you used a recent version of Qubes-vpn-support or qubes-tunnel,
restarting the service is simple:
sudo systemctl restart qubes-vpn-handler
or
sudo systemctl restart qubes-tunnel

Thanks for your quick answer. I use my own vpn setup based not on openvpn, but
ethervpn. This qube come from 3.2. I use the same old code. I wrote it based on
old openvpn code. This code add routes on startup, then iptables fules for DNS
some other rules to prevent traffic leak. The same as UP handler from qubes-doc
do.

There are no "recovering setup". How to add this?

Need to delete rules added by this then execute this again? Is it recovery?
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr

I re-checked qubes vpn doc. It's almost the same, but no up/down handler. I
setup rules at rc.local. At 3.2. I do not have this problem. When my VPN loss
connection then it always work after my VPN client reconnected.

Posting back to qubes-users...

Probably there is someone who is familiar with ethervpn who can better
help you.

My advice is to monitor the ethervpn log for warnings/errors when the
blockage occurs. Then perhaps a simpler solution will become clear.

If you are using the same firewall rules as the Qubes doc, try
commenting-out the parts for 'OUTPUT'.

As for the DNAT rules, delete & re-add should only be necessary if the
DNS server changes. Also, when blockage occurs you can try pinging a
known IP address (not domain name) from an appVM; if it doesn't work
then DNAT is probably not the issue.

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/f512bce3-685b-c21a-12d4-ba7fff4a0636%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking freezing and impossible to restore without reboot

2018-05-14 Thread Chris Laprise

On 05/14/2018 05:23 PM, 'Evastar' via qubes-users wrote:

Hello,

I still have issues with my proxy/vpn-vms. Something happens, maybe my
vpn lose connection or not (I don't know). I only know that at some
point from timee to time all my AppVms lose network and it's not
possible to restore networking without restarting VPN-VM and all
connected VMs. Any solutions? How to simplify this process?

It's very uncomfortable every time to restart all AppVMs.

And I wrote that I don't know VPN loses connection or not. When I open
VPN-proxy-vm terminal I see that it's CONNECTED to VM, but maybe it's
after reconnection. But after that I don't know how to force all
AppVMs(connected to this proxy) to restore network!

Thank you!

Its important to know how you set up the VPN VM. If you used the Qubes
doc, that config can have problems recovering from a disconnected link.

If you used a recent version of Qubes-vpn-support or qubes-tunnel,
restarting the service is simple:

sudo systemctl restart qubes-vpn-handler

sudo systemctl restart qubes-tunnel

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/a392cf03-d456-ec6d-482f-2102c50f0d8e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-05-14 Thread Chris Laprise


On 05/12/2018 02:10 PM, get wrote:

Hi. script not working more on debian-9/fedora-26. Please fix it.

Tested vpn's : mullvad, privateinternetaccess, expressvpn and multiple random 
openvpn.

Guides:
https://github.com/tasket/Qubes-vpn-support
https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service
https://github.com/tasket/qubes-tunnel


This thread is for qubes-tunnel not Qubes-vpn-support.

Also I can't read minds... Can you describe a specific example with one VPN?


--

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/2a5cc0aa-4b2e-2584-c0a5-37ce1bbcbde9%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-05-14 Thread Chris Laprise

On 05/14/2018 09:09 AM, Chris Laprise wrote:

On 05/12/2018 03:11 PM, JonHBit wrote:

I've updating to 1.4beta4 and switched templates from debian-9 to
fedora-28, but I'm getting the same error - also it seems like openvpn
flag defaults changed, as it now returns an error for the up and down
arguments

Did you mean fedora-26?

Specifically, it parses /usr/lib/qubes/qtunnel-connect up as 2
arguments instead of 1; putting the whole phrase in double quotes
fixes this, which I see you did but for some reason the quotes seem to
be removed when ExecStart runs, i.e. checking systemctl status
qubes-tunnel shows the command without the quotes

I'm a little unclear: Did you get the link working like this?

I have two fedora 26 templates, one was last updated over 10 days ago
and the other updated today. The VPN link won't come up with the latter
one...

I did some tests and there seems to be an intermittent problem with
qubes-firewall on fedora only. This can prevent openvpn from connecting.

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/4c4fdb4a-c529-8cd2-7c68-8fd282a9efad%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-05-14 Thread Chris Laprise


On 05/06/2018 05:24 PM, morlan.aus...@gmail.com wrote:

Worked great for me with Qubes 4.0 and Fedora 26.

I'm unclear on how to use sys-firewall now though. Should it be sys-net -> 
sys-firewall -> VPN -> App?

Thanks.


That arrangement is OK. But you can take sys-firewall out of the path 
(connect VPN directly to sys-net) because a VPN qube configured with 
qubes-tunnel still does the job of a regular proxy qube (like sys-firewall).




--

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/95d94842-6f3a-6022-dadb-c97bf040ebfb%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-05-14 Thread Chris Laprise


On 05/12/2018 03:11 PM, JonHBit wrote:


I've updating to 1.4beta4 and switched templates from debian-9 to fedora-28, 
but I'm getting the same error - also it seems like openvpn flag defaults 
changed, as it now returns an error for the up and down arguments


Did you mean fedora-26?



Specifically, it parses /usr/lib/qubes/qtunnel-connect up as 2 arguments 
instead of 1; putting the whole phrase in double quotes fixes this, which I see 
you did but for some reason the quotes seem to be removed when ExecStart runs, 
i.e. checking systemctl status qubes-tunnel shows the command without the quotes


I'm a little unclear: Did you get the link working like this?

I have two fedora 26 templates, one was last updated over 10 days ago 
and the other updated today. The VPN link won't come up with the latter 
one...



--

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/d555adea-6f74-1ebb-36ed-d84a8f124bf6%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] sys-net self starts about 40min after boot

2018-05-01 Thread Chris Laprise

On 05/01/2018 08:50 AM, trueriver wrote:

I do not want my laptop to boot up and immediately look for a network
connection.

Therefore I set sys-net and sys-firewall NOT to start at boot.

The only domain that is currently set to start at boot time is one that has not
network connection. And dom0 of course ;)

At boot time those indeed are the only machines that are started.

I have twice noticed at around dom0 uptime = 40min that sys-net starts and
connects (or tries to). This is exactly what I am trying to avoid.

I am not yet entirely sure this is not just some clumsiness of my own, so am
not ready to declare an issue.

Question: is there some auto-update feature (of dom0, or templates, or
whatever) that may be automatically asking for a network connection?

Regards
River~~

See this issue:
https://github.com/QubesOS/qubes-issues/issues/3588

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/97baa5ec-27da-0ca5-f538-d85820ec5349%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-30 Thread Chris Laprise

On 04/29/2018 10:14 PM, vel...@tutamail.com wrote:

I just tried this version in 4.0 in the template. Some notes feedback:

1) When I tried changing the DNS to OpenDNS in my config file:
setenv vpn_dns '208.67.222.222 208.67.220.220'

I then went to:
http://welcome.opendns.com/

It failed and informed me I was not using OpenDNS.

Using debian 9, link indicates "Link is up", I get internet connection,
https://www.dnsleaktest.com/ indicates my VPNs IP(despite "setenv vpn_dns '208.67.222.222
208.67.220.220'" in my vpn configuration) when I use this configuration...

Its working when I try it. On dnsleaktest.com, your VPN provider IP
should always appear on the first page. Then when you click on a test
button it should show "OpenDNS, LLC" in the ISP column. The OpenDNS
addresses will also show up in the log alongside "Using DNS servers...".

The problem is you're mixing instructions from the two different
projects. This thread is for testing qubes-tunnel but you said you were
using Qubes-vpn-support (...but said you were using qtunnel* commands
which belong to qubes-tunnel and are not correct for Qubes-vpn-support).

If using 'qubes-tunnel-openvpn' service for your VPN VM, your configs
should reside in /rw/config/qtunnel and the setenv line that you add
will be:

setenv tunnel_dns '208.67.222.222 208.67.220.220'

It would be nice, however, if you made the switch to qubes-tunnel to
give us some testing feedback. :)

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/c5f727a8-f577-5a1e-0b64-9fc9df47202f%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-26 Thread Chris Laprise

On 04/26/2018 05:29 PM, JonHBit wrote:

On Wednesday, April 18, 2018 at 5:36:37 AM UTC-4, Chris Laprise wrote:

On 04/17/2018 11:42 PM, Chris Laprise wrote:

On 04/17/2018 09:20 PM, JonHBit wrote:

Worked well for me using a debian-9 template & commit 4e96ca8, only
trouble was that my VPN provider's configs used
/etc/update-resolv-conf and failed silently when it was missing - so
shipping it with qubes-tunnel and installing it by default may be
helpful.

Thanks!

This issue just became apparent to me when another user reported it. The
underlying problem is a bug (or several bugs) in openvpn's option parsing:

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

It only shows up when the config specifies its own scripts which is
rare. I'm trying out a workaround now which involves:

1. Removing the paths in the up & down options in the .service file.

2. Moving the up & down options to the beginning just after the openvpn
command.

3. Symlinking the up/down script from /usr/lib/qubes to the
/rw/config/qtunnel dir.

Hopefully this will override the config's up/down settings as intended.

I had to use a different approach but it should be fixed now. Update it
by copying new version to template and running installer. Then you'll
need to remove the 'qubes-tunnel' Qubes service for the proxyVM and add
'qubes-tunnel-openvpn' instead.

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

Hi Chris,

Good to see the update!

However I think that's a separate issue; what I'm referencing is these lines in
my .ovpn config:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

The VPN installer script will normally download this if it's missing - used to
change the DNS server to the VPN-provided one.

The script is here:
https://raw.githubusercontent.com/ProtonVPN/scripts/master/update-resolv-conf.sh

After adding it everything worked well.

The update will replace those lines because they should be overridden
with the Qubes-specific DNS handling. If dnat isn't setup for DNS then
those packets could get mis-routed.

You can check the dnat rules (which should have some address other than
10.139.1.x after connecting) with this:

sudo iptables -v -t nat -L PR-QBS

My guess why it might work with incorrect dnat addresses is that your
VPN provider takes the step of re-assigning DNS destination addresses to
its own. But this is unorthodox so I wouldn't count on it.

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/4bc0ca96-848c-adf5-05e0-d5dcdb7eda68%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-25 Thread Chris Laprise

On 04/20/2018 11:14 AM, cicero wrote:

On 04/20/18 04:58, Chris Laprise wrote:
Since there's no connection information in the template -- only the
VPN scripts & the OS are there -- templates don't affect configuration
issues like different locations. In any case, you have a proxyVM which
contains configurations for the connections to various sites, but each
proxyVM connects to only one VPN remote site at a time. So to have two
AppVMs routed through two different VPN sites, you need two proxyVMs
(one for each AppVM).

hmm, so I guess by installing the script in the Template(cloned), it
would save me from having to re-run the script in the AppProxyVMs,
that's it ?

You wouldn't have to install it into proxyVMs. But there is still one
script-running step when configuring a proxyVM with qubes-tunnel.

https://github.com/tasket/qubes-tunnel

But, if I'm just cloning the Original AppProxyVMs , to make a 2nd
geolocation, doesn't seem like saves me any work by not having to
re-run the script, as it is already in the cloned AppProxyVM ?

If you clone an already configured proxyVM, no further configuration is
required for the clone to connect to the same site. To change the site,
you will only need to change the qtunnel.conf link.

Do I have this correct?

But, sometime in the future, a possible newer version will only run in a
Template, but then the rest is about the same on configuration, ( a
separate AppProxyVM for each location wanted , unless one wanted to
manually change the symlink to change locations ?

That's the intention, to make qubes-tunnel (child of Qubes-vpn-support)
already available for use in the templates. This simplifies the setup
process for users.

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/357250d3-c88a-cff5-7bc2-b0dd2f4c8c04%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Preventing VPN leaks once VPN connection is disconnect

2018-04-22 Thread Chris Laprise

On 04/22/2018 02:39 PM, niepowie...@gmail.com wrote:

Also, if you run bitmask just in individual appVMs (instead of proxyVM,
which shares the connection with some number of appVMs) then in that
situation it probably won't need Qubes-specific rules to prevent leaks.

not true, bitmask in appVM's once VPN is disconnect allow clear and unencrypted
traffic.

In this case you're following the usage and threat model that LEAP
designed bitmask for. IOW, the appVM is like a regular Linux PC and the
user must be mindful of the connection state.

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

Is there option to add in firewall appVM rule that allows connection only with
VPN server ip? and once connection is disconnect traffic will be stopped?

Yes, if you connect the appVM to a proxyVM like sys-firewall, you can
add the allowed addresses to the 'Firewall rules' tab in the appVM's
settings window.

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/add22808-05ba-b168-2736-bd4d218b4a75%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Preventing VPN leaks once VPN connection is disconnect

2018-04-22 Thread Chris Laprise


On 04/22/2018 02:10 PM, niepowie...@gmail.com wrote:



Also, if you run bitmask just in individual appVMs (instead of proxyVM,
which shares the connection with some number of appVMs) then in that
situation it probably won't need Qubes-specific rules to prevent leaks.



not true, bitmask in appVM's once VPN is disconnect allow clear and unencrypted 
traffic.


In this case you're following the usage and threat model that LEAP 
designed bitmask for. IOW, the appVM is like a regular Linux PC and the 
user must be mindful of the connection state.


--

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/0b724372-99ed-e4bb-73bd-cf4e41ced5c9%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Preventing VPN leaks once VPN connection is disconnect

2018-04-22 Thread Chris Laprise

On 04/22/2018 01:43 PM, Chris Laprise wrote:

On 04/22/2018 12:52 PM, js...@bitmessage.ch wrote:

niepowie...@gmail.com:
I'm user of vpn bitmask software and accidentally, from time to time
connection disconnect and there is few second to connect again.

How is easiest way to set up firewall rules that prevent leaks with
clear and unencrypted traffic?

I'm pretty sure bitmask is supposed to block unencrypted connections
automatically when VPN connection drops (fail closed). The old version
of bitmask had problems when running in a qubes proxyVM (DNS leaks in
particular), but the new version in their debian stretch repo seemingly
fixes these problems. i'm not sure if not failing closed is still a
problem tho.

If you're running the most recent version of bitmask in a proxyVM and
it's not failing closed, maybe run it in the appVM instead? Others will
have to answer the firewall question tho because i don't know much about
that.

The regular release doesn't prevent leaks in Qubes proxyVMs, but the
next version will.

If you want to use bitmask in a proxyVM you can either download the
latest pre-release, or you can add a couple (internal) firewall rules to
the proxyVM in /rw/config/qubes-firewall-user-script:

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

BTW, these rules will block leaks, but they won't solve the other
problem of configuring DNS correctly in the proxyVM. So you're better
off either trying the pre-release or only using bitmask in an appVM that
doesn't "provide network".

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/4fcfa875-1720-8d05-8596-53c9bb317ee0%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Preventing VPN leaks once VPN connection is disconnect

2018-04-22 Thread Chris Laprise

On 04/22/2018 12:52 PM, js...@bitmessage.ch wrote:

niepowie...@gmail.com:

I'm user of vpn bitmask software and accidentally, from time to time connection
disconnect and there is few second to connect again.

How is easiest way to set up firewall rules that prevent leaks with clear and
unencrypted traffic?

The regular release doesn't prevent leaks in Qubes proxyVMs, but the
next version will.

If you want to use bitmask in a proxyVM you can either download the
latest pre-release, or you can add a couple (internal) firewall rules to
the proxyVM in /rw/config/qubes-firewall-user-script:

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

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/e81bac9a-411b-63a4-0ae9-a514738847cb%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Multi-update tool for Qubes 4.0 released

2018-04-22 Thread Chris Laprise


On 04/20/2018 09:24 AM, Chris Laprise wrote:
This script has a number of options for selecting templates and 
standalone VMs and it can update them all in a single run...


Link - https://github.com/tasket/Qubes-scripts

Enjoy!



Update: Fixed a typo in qubes-multi-update.

-

Also added another tool 'findpref':  Search and replace VM prefs.

Ex: findpref -p netvm sys-firewall sys-vpn
Finds all VMs using sys-firewall and switches them to sys-vpn.

--

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/ec9482ba-ec45-407c-efcb-1b082e35053e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Difficulty after attempted template re-install

2018-04-21 Thread Chris Laprise

On 04/21/2018 08:54 AM, Chris Laprise wrote:

On 04/21/2018 07:18 AM, 'awokd' via qubes-users wrote:

On Fri, April 20, 2018 11:38 pm, trueriver wrote:

Is that -root-tmp volume a sign of a bug, if so where?

I am not confident of reproducing the bug, if indeed it is one.

My gut feeling is that it may not enough to make a useful bugrep, but
will do so if you or awokd think I should.

One thought I had is how do I know f I run out of pool space - might
that

have triggered something like this or should I get an elegant warning?
Certainly my disk space is overcommitted, with the magic of sparse
files.

Don't think it's pool space related.

Not seeing this as a space issue, but as a possible lvm volume
organization issue which causes reinstall to abort part way through.

Tried to reproduce this. First installed the minimal template, tested,
then did an --action=reinstall. The menu shortcut for xterm stopped
working. Did a refresh applications in Qube Settings but that also failed
to start the template qube. qvm-run gave me "VM directory does not exist:
/var/lib/qubes/vm-templates/fedora-26-minimal" and ls confirms it does
not. This is probably a bug, possibly
https://github.com/QubesOS/qubes-issues/issues/3169. I'll make a note in
there.

Its definitely not the same as #3169 though it might as well be reported
there. As I mentioned, the storage layer was updated and its partly to
implement 3169.

OK, problem may be that 'qubes-core-admin/pull/203' hasn't reached
stable yet. I think this should be tried after updating from qubes*testing.

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/eda2b230-f683-53ec-ffd1-3677f7c24e07%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Difficulty after attempted template re-install

2018-04-21 Thread Chris Laprise

On 04/21/2018 07:18 AM, 'awokd' via qubes-users wrote:

On Fri, April 20, 2018 11:38 pm, trueriver wrote:

Is that -root-tmp volume a sign of a bug, if so where?

I am not confident of reproducing the bug, if indeed it is one.

My gut feeling is that it may not enough to make a useful bugrep, but
will do so if you or awokd think I should.

One thought I had is how do I know f I run out of pool space - might that
have triggered something like this or should I get an elegant warning?
Certainly my disk space is overcommitted, with the magic of sparse files.

Don't think it's pool space related.

Not seeing this as a space issue, but as a possible lvm volume
organization issue which causes reinstall to abort part way through.

Its definitely not the same as #3169 though it might as well be reported
there. As I mentioned, the storage layer was updated and its partly to
implement 3169.

At that point, "sudo dnf remove qubes-template-fedora-26-minimal" followed
by "sudo qubes-dom0-update qubes-template-fedora-26-minimal" worked with
no errors and restored proper function.

Next, I tested with the template running. --action=reinstall shutdown the
template before doing its work, but resulted in the same bug as before.

Doing a dnf remove with the template running failed with an error message
about same. I didn't see -root-tmp at any time; not sure what might have
created it.

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/c3e4a801-1862-5646-cc1f-a1a9fa8873d1%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Difficulty after attempted template re-install

2018-04-20 Thread Chris Laprise

On 04/20/2018 04:42 PM, trueriver wrote:

How can I sort this out?

Try the manual procedure again. Do you get any errors at any step?

No, none. Not till I try to run something.

It looks almost like it has re-installed it, it appears in the menu but with no
apps, just the settings.

In settings the app pane is empty, and the refresh button greys out to
''Refresh in progress' and never returns after much much longer than it usually
takes in a healthy domain.

Why has the action=reinstall not re-created everything the VM needs?

Not sure, it should work!

OK, short of a complete re-install after backing up the domains that still
work, what do I do now to repair this please?

The code that supports template re-install (and other volume-related)
functions was refactored late in the 4.0 pre-release cycle. Maybe this
should be opened as an issue.

Its conceivable that a bug left behind a similarly named meta-volume
that is now preventing a normal installation from completing. Comparing
the output of 'qvm-volume' with 'sudo lvs' may provide a clue if that's
the case.

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/8a6bac3a-add7-dfe3-df23-745a22f6d02b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-20 Thread Chris Laprise

On 04/20/2018 10:04 AM, cicero wrote:

On 04/20/18 03:12, Chris Laprise wrote:

On 04/20/2018 02:03 AM, cicero wrote:

On 04/19/18 14:04, Chris Laprise wrote:

On 04/19/2018 07:26 PM, john wrote:
I installed this in a App/proxy 4.0 VM, as I am familiar with the
3.2 CLI VPN creation.

I don't really understand how installing it in a Template or The
Template(not cloning it 1st) would allow me to swich between
geolocations ...

So, I used the AppVM, then I simply cloned the 1st one created
with the script and went into the PIA config file area and did
rm -f ln -s to the network manager thing.

and then recreated the ln -s to a new config file, which works ,
and Even wakes up from suspend (where in 3.2 it never did) ;
However,

If the AppVM using one of the VPN-foo as a netvm, and it is
started, and I want to switch to another VPN-foo1 it doesn't work
on the fly, I have to go and qvm-shutdown the AppVM and open it
again, which is a big pain. I am often running out of RAM, and
so try to just use one App-proxy-vpnVM , however ,

is this the expected behavior no switching vpn appvms on the fly ?

IIRC this is a bug in the versions of Linux kernel that Qubes 4.0
uses. There is an issue but I can't locate it at the moment.

So, I guess I'll learn to live with it , and try not to change VPNs
buy buying some more expensive RAM :)

But, I'm curious , If I install the new script in the Template/s ,
how would I switch VPN locations?

Or would every AppVM based on that Template be locked into whatever
geolocation's config file was symlinked to ?

Templates don't affect your ability to set a custom location script.
This is because the link that points from qtunnel.conf to any
particular config is stored in each proxyVM under /rw/config/qtunnel.

You can of course do one proxyVM setup, then clone it and change the
link in each clone.

BTW, thanks for trying it out!

Chris, what I'm trying to say is, if it is recommended to install it in
the Template or a cloned Template ; how then do I change the geolocation
to two different locations, one for each of , say, two AppVMs ?

Since there's no connection information in the template -- only the VPN
scripts & the OS are there -- templates don't affect configuration
issues like different locations. In any case, you have a proxyVM which
contains configurations for the connections to various sites, but each
proxyVM connects to only one VPN remote site at a time. So to have two
AppVMs routed through two different VPN sites, you need two proxyVMs
(one for each AppVM).

This is not an absolute rule BTW. Its just how our current tools are
most logically and safely configured. Conceivably you could rig a single
proxyVM to safely handle more than one VPN connection.

I could create symlinks in /rw/config/qtunnel? in the AppVMs ? or

I understand that if this is integrated later, then I probably need to
learn to use it in the Template now, to avoid more issues down the road,
I don't really like cloning the Template too much, as Qubes, is already
a challenge in its complexity

To clarify...

Cloning the template is recommended because the VPN software is still
being tested. Its just a way to backup in case something in the modified
template gets damaged.

Cloning a proxyVM is a quick way to make additional VPN VMs that can
connect to different VPN sites.

eg: my current dracut emergency shell situation PS: seems I had an old
Q3.2 in an enclosure, I was going to reformat but hadn't yet, and during
a reboot it was in the USB drive, and this seems to have caused Q4.0 in
efi installation to dump it's init to boot ; so do I go make a
fedora live usb drive and try to mount and save it ? and lose all the
configuration and restoring of 3.2 VMs or just reinstall Q4.0?

Boot issues aren't my strong suit, but this sounds serious enough to
start a separate thread for it.

I have read some folks on here , whom when trying to go back to Q3.2 are
having big issues, I don't really understand how efi works, my UEFI
still says Qubes 3.1 for some reason (I think there are some
gymnastics to try to get the EFI to update it's names but fear I'll lose
the windows 10 install on the 2nd HD, etc etc .

Strangely windows 10 "just works", but I digress .

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/d77cce73-dcd9-d9fc-8c11-b21589a5a6d9%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Multi-update tool for Qubes 4.0 released

2018-04-20 Thread Chris Laprise

This script has a number of options for selecting templates and 
standalone VMs and it can update them all in a single run...


Link - https://github.com/tasket/Qubes-scripts

Enjoy!

--

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/41b25408-96a1-7ce9-fbc0-c5d6e310ba97%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-20 Thread Chris Laprise

On 04/20/2018 02:03 AM, cicero wrote:

On 04/19/18 14:04, Chris Laprise wrote:

On 04/19/2018 07:26 PM, john wrote:
I installed this in a App/proxy 4.0 VM, as I am familiar with the
3.2 CLI VPN creation.

I don't really understand how installing it in a Template or The
Template(not cloning it 1st) would allow me to swich between
geolocations ...

So, I used the AppVM, then I simply cloned the 1st one created with
the script and went into the PIA config file area and did rm -f
ln -s to the network manager thing.

and then recreated the ln -s to a new config file, which works ,
and Even wakes up from suspend (where in 3.2 it never did) ;
However,

If the AppVM using one of the VPN-foo as a netvm, and it is started,
and I want to switch to another VPN-foo1 it doesn't work on the fly,
I have to go and qvm-shutdown the AppVM and open it again, which is
a big pain. I am often running out of RAM, and so try to just use
one App-proxy-vpnVM , however ,

is this the expected behavior no switching vpn appvms on the fly ?

IIRC this is a bug in the versions of Linux kernel that Qubes 4.0
uses. There is an issue but I can't locate it at the moment.

So, I guess I'll learn to live with it , and try not to change VPNs buy
buying some more expensive RAM :)

But, I'm curious , If I install the new script in the Template/s , how
would I switch VPN locations?

Or would every AppVM based on that Template be locked into whatever
geolocation's config file was symlinked to ?

Templates don't affect your ability to set a custom location script.
This is because the link that points from qtunnel.conf to any particular
config is stored in each proxyVM under /rw/config/qtunnel.

You can of course do one proxyVM setup, then clone it and change the
link in each clone.

BTW, thanks for trying it out!

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/52bbd116-5ccd-78a7-3423-b6952b2007c6%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] minimum size for a qube image

2018-04-18 Thread Chris Laprise

However... in terms of flexible _and_ secure deployment of software, 
Qubes could stand some improvement.


I wonder if there are compatible packaging systems that could be adapted 
to modular app deployment per-VM. Something like 'snaps' might work.


And the deployment method could be an additional non-persistent volume, 
but belonging to each configured VM not the template.



--

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/9caec6e8-7e48-ab02-882d-29b532f3bbbc%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] minimum size for a qube image

2018-04-18 Thread Chris Laprise

On 04/16/2018 04:50 PM, Jan Hustak wrote:

Hello,

I really like Qubes' isolation approach. I would also like to isolate
the programs I run from code they don't need. So I want to split not
just my data into separate qubes, but also the software that works with
said data.

One way to do this is to install required software under /usr/local in
each qube. That has the important drawback of ignoring the qube's
package manager and the consistent updates it provides.

Another option is to build my qubes as StandaloneVMs copied from a
minimalist template. The qubes have to be updated one by one but at
least it's still done using the package manager.

So I created a Debian template trimmed to about 2.5 GB. I identified my
task domains - there were about 10 - and planned to cut a 4GB qube for
each. This would eat up 40 GB from my 500 GB drive which I can live with.

However, The VM Manager insists on at least 10 GB for each qube. Giving
up 100 GB with 75 GB empty (i.e. 15 % of total disk space) is steep. So
my question is: how can I create smaller images for my qubes?

I'm also open to discussing the basic concept: is it worth trying to
keep, for example, Firefox and GIMP in separate qubes, or should I just
relax and use one fat TemplateVM with the union of all packages I need?

awokd is right about root non-persistence... its a good thing to keep. I
only use standalone VMs for rare types of tests.

I'm also not sure that separating large GUI apps from each other in
different VMs is an answer to anything; once you have the layers in
place to support one large app, you probably have most potential
app-related vulns installed at that point.

My personal recommendation is to use debian-9 for most things; create a
larger version with the usual desktop environment (KDE or Gnome) + apps
installed. The smaller one works for sys-net, firewall, vpn, etc. plus
browsing and email. The big one is for content creation and special
comms: office apps, media, messengers, etc.

The isolation concept works best (on Qubes at least) when applied to the
types of _tasks and risks_ you expose each VM to... not so much when
applied to specific apps (although occasionally risk types translate
into specific apps).

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/1f3f5cba-cc99-d819-2eb3-767c2f90fafe%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] replacing fedora template with fedora minimal

2018-04-18 Thread Chris Laprise


On 04/18/2018 06:46 AM, river14ap...@gmail.com wrote:

hi all,

I am currently running a Qubes 4 system with all my AppVMs based on Debian. (btw thanks 
to the Qubes devs for providing this "out of the box" when I know you prefer 
Fedora: very democratic :)


Fedora was chosen a long time ago because at the time it was more 
convenient.


Since then, the developers have expressed a need to move away from it 
toward Debian or similarly stable & secure distro. There is even an 
issue logged for it.


With Debian already being rather minimal I'd suggest using that for most 
VMs. I myself use Fedora only for sys-firewall (to handle dom0 updates), 
to test software compatibility, and occasionally to build a template.



--

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/f3b8b0b6-1a26-0c01-b036-9177afc7b2fe%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-18 Thread Chris Laprise

On 04/17/2018 11:42 PM, Chris Laprise wrote:

On 04/17/2018 09:20 PM, JonHBit wrote:

Thanks!

This issue just became apparent to me when another user reported it. The
underlying problem is a bug (or several bugs) in openvpn's option parsing:

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

It only shows up when the config specifies its own scripts which is
rare. I'm trying out a workaround now which involves:

1. Removing the paths in the up & down options in the .service file.

2. Moving the up & down options to the beginning just after the openvpn
command.

3. Symlinking the up/down script from /usr/lib/qubes to the
/rw/config/qtunnel dir.

Hopefully this will override the config's up/down settings as intended.

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/4123b1ac-7eaf-95f3-cb69-e01c86221770%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-04-17 Thread Chris Laprise

On 04/17/2018 09:20 PM, JonHBit wrote:

On Tuesday, April 17, 2018 at 2:13:29 PM UTC-7, Chris Laprise wrote:

Hello fellow Qubes users:

Per issue 3503 the Qubes project would like to incorporate VPN features
from Qubes-vpn-support -- which a number of you are already using --
into the Qubes 4.1 release.

I've set up a new project "qubes-tunnel" to act as a staging area for
testing and eventual forking into Qubes. It is nearly the same as
Qubes-vpn-support except some names & paths are different... and install
to template is required for obvious reasons :) .

Project Link... https://github.com/tasket/qubes-tunnel

Everyone with an available VPN service is welcome to try this out and
report here on your results!

PS - Some of you will wonder if installing qubes-tunnel into an existing
template already used for Qubes-vpn-support will cause a conflict; They
will not conflict as long as the two services aren't enabled for the
same ProxyVM(s).

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

Worked well for me using a debian-9 template & commit 4e96ca8, only trouble was
that my VPN provider's configs used /etc/update-resolv-conf and failed silently
when it was missing - so shipping it with qubes-tunnel and installing it by default
may be helpful.

Thanks!

This issue just became apparent to me when another user reported it. The
underlying problem is a bug (or several bugs) in openvpn's option parsing:

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

It only shows up when the config specifies its own scripts which is
rare. I'm trying out a workaround now which involves:

1. Removing the paths in the up & down options in the .service file.

2. Moving the up & down options to the beginning just after the openvpn
command.

3. Symlinking the up/down script from /usr/lib/qubes to the
/rw/config/qtunnel dir.

Hopefully this will override the config's up/down settings as intended.

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/43b11e07-760e-7357-566d-b74a926f4889%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ANN: Testing new VPN code for Qubes

2018-04-17 Thread Chris Laprise

Hello fellow Qubes users:

Per issue 3503 the Qubes project would like to incorporate VPN features
from Qubes-vpn-support -- which a number of you are already using --
into the Qubes 4.1 release.

Project Link... https://github.com/tasket/qubes-tunnel

Everyone with an available VPN service is welcome to try this out and
report here on your results!

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/ee24f104-efbc-23f7-aca3-6be86104ddaf%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes VM Hardening v0.8.2 Released!

2018-04-17 Thread Chris Laprise

On 04/17/2018 12:25 AM, none wrote:
Is there some official opinion on this from whomever the Qubes
developers are ?

This is the closest to an official opinion I guess:

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

Patrick/adrelanos (also on the Qubes team) has expressed positive
interest: https://github.com/tasket/Qubes-VM-hardening/issues/2

Looks like it's a bit non trivial, and interacts with dom0 ; hence I'm
likely to break Q4.0 trying to 'harden' it :)

I was thinking I could clone the Deb-9 Template, and all would be OK, if
I failed however ...

Its pretty benign to the OS itself. The dom0 commands should be
identical to the related Qubes doc about enabling sudo prompts:

https://www.qubes-os.org/doc/vm-sudo/#replacing-password-less-root-access-with-dom0-user-prompt

You can skip the sudo prompt configuration and use the alternative for
restoring internal VM security: Just remove the
qubes-core-agent-passwordless-root package from the template.

The main risk with the vm-boot-protect-root service is that any settings
or scripts that are subsequently added to VMs in /rw/config,
/rw/usrlocal, and /rw/bind-dirs may be deleted (although the first time
it backs up those dirs and those copies are kept indefinitely).

Am a bit curious who is officially a dev on here, I have a few guess,
besides Marek, but maybe its folks with the PGP sigs , shrug.

Just having a PGP sig doesn't indicate status with the project. The
Qubes core team is listed here:

https://www.qubes-os.org/team/

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/d50aba31-12f8-be7d-075e-443dcc916efc%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

< 1 2 3 4 5 6 7 8 9 10 >

401 - 500 of 1140 matches

Mail list logo