Multiple usability issues Qubes 4RC3

[Ahmed Al Aqtash]

Hello all!

I apologise for the vague subject, but I have been trying all kinds of things, and I simply can't understand half of the issues, and the other half I can't seem to find a solution to.

First of all I have all the respect in the world for the entire Qubes team, and I sincerely believe that you are making the world a better place.

The machine: ThinkPad X270 (full specs: https://www.uk.insight.com/en-gb/productinfo/portatili-e-notebook/0007017591). It has 8 GB RAM.

So.. to the issues..

1) A more general gripe with not having enough documentation to actually get through a setup process. I used Qubes 3.2 before, and I simply went about Qubes 4 the same way. I know that there have been multiple changes, and I honestly believe the changes are for the better.

But issues like moving a templates home directory to /etc/skel (meaning that appvm's inherit /etc/skel as home dir from the template) left me baffled with my first install.. I setup my template exactly as I wanted, created an appvm, and nothing was initialised. I had no idea what was going on, and the only way I could get some information was through a GitHub issue. Even after moving everything over to /etc/skel, I still have issues.. not everything is being carried over, not everything is being read correctly, and /etc/skel is not being synchronised either. If I add something new to /etc/skel AFTER creating a appvm, the appvm's homedir won't be updated.

I like the idea with moving all the GUI functionality to the shell. I prefer using the shell anyway. But for instance, in 3.2, you could allow access to through the firewall for a templatevm. Now it has to be done through qvm-prefs. This is not documented anywhere, and this was also an infuriating issue for me.

2) I have reinstalled qubes multiple times over the weekend (friday through sunday) to get my install at a state that I am actually satisfied with.

Most griping issues: sys-net and sys-firewall do not start on boot. Journalctl claims that there isn't enough memory to start sys-net on boot (I don't have anything more descriptive for sys-firewall).

I can easily start them after boot and login. If I need more memory, then I will happily upgrade. I intended to do so anyway, but I cannot understand why it worked fine in 3.2 with 8 GB RAM.

3) The issue mentioned under documentation with setting up a template exactly the way I want it.

To understand the issue in depth, I think it's in place to describe my setup:

Having 2 base templates (based on the debian 9 template):

  * One I call 'trusted' which is based on debian sid (unstable) that I install everything I use for daily usage (firefox, libreoffice, mpv, emacs, other open source tools). Primarily AppVM's will be based out of this template.

* One I call 'untrusted' that is going to be a clone of 'trusted', and that I install proprietary software in, that I also use on a daily basis (e.g. spotify). Also AppVM's out of this, but probably only 1 to start with.

* I will probably create a standalone VM based off of 'trusted' that I use for development. So I will install stuff like docker, golang, and all other stuff I would otherwise use for developing.

I have not been able to create my 'trusted' template in a proper manner, since I can't get /etc/skel to work properly.

NOTE: I use zsh with oh my zsh and spacemacs. Both of which are git repos that are cloned to the homedir of the user (meaning they are git repos cloned to /etc/skel)

If this is improper usage, then please guide me to how I should go about doing this instead, as I have no idea what the smartest solution would otherwise be.

Sorry for the long email, and thanks in advance for clarifying answers.

Best regards and all the best.

[Tom Zander]

On Monday, 8 January 2018 13:29:02 GMT 'Ahmed Al Aqtash' via qubes-users
wrote:

> But issues like moving a templates home directory to /etc/skel (meaning
> that appvm's inherit /etc/skel as home dir from the template) left me
> baffled with my first install..

Homedirs are completely separated from your template homedir.

I personally ended up setting up things like chrome and konsole, bashrc etc.
Making a tar off my setup and uncompressing it on other qubes.
Usage of /etc/skel is not something I suggest, that is *only* for first
initialisation of an AppVM and never gets updated again.

Bottom line; your homedir is unique and different in each and every VM.

--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[Tom Zander]

On Monday, 8 January 2018 13:29:02 GMT 'Ahmed Al Aqtash' via qubes-users
wrote:

> * One I call 'trusted' which is based on debian sid (unstable) that I
> install everything I use for daily usage (firefox, libreoffice, mpv,
> emacs, other open source tools). Primarily AppVM's will be based out of
> this template.
>
> * One I call 'untrusted' that is going to be a clone of 'trusted', and
> that I install proprietary software in, that I also use on a daily basis
> (e.g. spotify). Also AppVM's out of this, but probably only 1 to start
> with.

An alternative solution is to make your "untrusted" VM an AppVM and you
install the software in there using bind-dirs.
Then you *only* use that VM for running that software and you likely store
no personal data there (other than maybe your spotify cridentials).

Additional bonus would be to open any webpages in disposable VMs, should you
click on a link in any of those apps.

> * I will probably create a standalone VM based off of 'trusted' that I use
> for development. So I will install stuff like docker, golang, and all
> other
> stuff I would otherwise use for developing.

I may be wrong, but all those development tools are open source and likely
shipped by your distro. In which case I wonder what the benefit is to putting
them into its own VM?

In short, maybe the simplest way is to create;

* TemplateVM: debian9
* Work AppVM based on debian9
* Untrusted AppVM based on debian9, adds untrusted apps using binds
* any other AppVMs you need... All based on the same debian9 template.

> NOTE: I use zsh with oh my zsh and spacemacs. Both of which are git repos
> that are cloned to the homedir of the user (meaning they are git repos
> cloned to /etc/skel)

Using /etc/skel just causes the data to be copied to the appvm homedir on
first start.
You end up duplicating the data anyway, maybe you can use a different way to
copy everthing between VM homedirs.
Notice that you can just do a qvm-copy [dir] which copies recursively.

[a...@it-minds.dk]

> > * One I call 'trusted' which is based on debian sid (unstable) that I
> > install everything I use for daily usage (firefox, libreoffice, mpv,
> > emacs, other open source tools). Primarily AppVM's will be based out of
> > this template.
> >
> > * One I call 'untrusted' that is going to be a clone of 'trusted', and
> > that I install proprietary software in, that I also use on a daily basis
> > (e.g. spotify). Also AppVM's out of this, but probably only 1 to start
> > with.
>
> An alternative solution is to make your "untrusted" VM an AppVM and you
> install the software in there using bind-dirs.
> Then you *only* use that VM for running that software and you likely store
> no personal data there (other than maybe your spotify cridentials).
>
> Additional bonus would be to open any webpages in disposable VMs, should you
> click on a link in any of those apps.

This approach is actually quite nice. I have never used bind-dirs though. How would I go about this? Symlink from /usr/bin to the homedir of the VM, or how?

I actually already open all links in disposable VMs, unless of course it is something that I use/trust. So that part of the equation is solved :)

> > * I will probably create a standalone VM based off of 'trusted' that I use
> > for development. So I will install stuff like docker, golang, and all
> > other
> > stuff I would otherwise use for developing.
>
> I may be wrong, but all those development tools are open source and likely
> shipped by your distro. In which case I wonder what the benefit is to putting
> them into its own VM?

I may use libs that I haven't neccessarily looked through, or have no idea where originate from. Also, this VM will need to communicate more extensively with the Internet, as I make web utils or other stuff. I would prefer having this VM isolated at any rate :)

> In short, maybe the simplest way is to create;
>
> * TemplateVM: debian9
> * Work AppVM based on debian9
> * Untrusted AppVM based on debian9, adds untrusted apps using binds
> * any other AppVMs you need... All based on the same debian9 template.
>
> > NOTE: I use zsh with oh my zsh and spacemacs. Both of which are git repos
> > that are cloned to the homedir of the user (meaning they are git repos
> > cloned to /etc/skel)
>
> Using /etc/skel just causes the data to be copied to the appvm homedir on
> first start.
> You end up duplicating the data anyway, maybe you can use a different way to
> copy everthing between VM homedirs.
> Notice that you can just do a qvm-copy [dir] which copies recursively.

But it's fine by me if it only happens once. That means I just need to setup the template exactly the way I want, before I create AppVMs. I'd rather clone the repos and copy my settings files, .ssh, and other config/setup stuff in my template once, than doing it for all AppVMs.

Thanks again for your help Tom :)

I still need assistance with the initial start up of sys-net and sys-firewall though :(

[a...@it-minds.dk]

Another issue actually:
What is the best/recommended way of updating software in TemplateVMs?
Firing up a shell in the TemplateVM and running a standard 'sudo dnf update'/'sudo apt-get upgrade', or should we throw flags at it?

In 3.2 the GUI would happily say 'you have updates', but now (with my very limited knowledge) we have to check this manually?

Cheers

[Yuraeitha]

I believe the current solution is to check manually yes, but I also think it's a temporary issue. Maybe it'll be resolved in Qubes 4.1. or Qubes 5 even? There was so much to do in Qubes 4, that many things like these likely had to be put into lower priorities. But now that Qubes 4 is getting more stable and functional, perhaps the next focus is to regain such features as to show when updates are available in the Qubes widget, or similar.

I'm also inclinded to believe, that the work in Qubes 4, makes it more likely that we'll see a feature that can update all templates at once. Since updates are run through the Admin system, instead of direct internet to each and every template, then, perhaps the same updates can be used for the different templates.

Like imagine if the system knows there are updates available, then it'll also likely know which updates are available too. A single download could then download all the various updates to all the templates, and distribute to each template the required updates.

I don't know if this is the intention already, but Qubes 4 makes this much more feasible to do compared to Qubes 3.2. But all in due time if it really is something planned, since there is so much work to be done right now.

[a...@it-minds.dk]

Den mandag den 8. januar 2018 kl. 14.52.43 UTC+1 skrev Tom Zander:
> On Monday, 8 January 2018 13:29:02 GMT 'Ahmed Al Aqtash' via qubes-users
> wrote:
> > * One I call 'trusted' which is based on debian sid (unstable) that I
> > install everything I use for daily usage (firefox, libreoffice, mpv,
> > emacs, other open source tools). Primarily AppVM's will be based out of
> > this template.
> >
> > * One I call 'untrusted' that is going to be a clone of 'trusted', and
> > that I install proprietary software in, that I also use on a daily basis
> > (e.g. spotify). Also AppVM's out of this, but probably only 1 to start
> > with.
>
> An alternative solution is to make your "untrusted" VM an AppVM and you
> install the software in there using bind-dirs.
> Then you *only* use that VM for running that software and you likely store
> no personal data there (other than maybe your spotify cridentials).
>
> Additional bonus would be to open any webpages in disposable VMs, should you
> click on a link in any of those apps.

Okay, so I found the documentation for bind-dirs (https://www.qubes-os.org/doc/bind-dirs/), but was still wondering if you meant binding the AppVMs /usr/bin and /usr/local/bin, or was thinking of something else?

I would assume I need to bind all dirs that a given application is going to write to (such as potentionally /usr/share, /var/lib, etc).

Any thoughts?

[Tom Zander]

On Tuesday, 9 January 2018 08:54:02 GMT aaq via qubes-users wrote:
> Okay, so I found the documentation for bind-dirs
> (https://www.qubes-os.org/doc/bind-dirs/), but was still wondering if
> you meant binding the AppVMs /usr/bin and /usr/local/bin, or was thinking
> of something else?
>
> I would assume I need to bind all dirs that a given application is going
> to write to (such as potentionally /usr/share, /var/lib, etc).

Let me give you an example usage;

I have the binary build "keybase" app in its own AppVM.
It installs the majority of its files in /opt, as such I bind that dir.
(restart before install!).

There are a dozen files also being copied into the /usr/ dir-structure.
I copied those files into the /rw/keybase/usr/ dir structure
and I edited /rw/config/rc.local to copy those files back onto the /usr
dir-structure at vm-boot.

This was enough for this app, your actual usage may depend on how your app
installs itself.

[a...@it-minds.dk]

Den mandag den 8. januar 2018 kl. 14.29.06 UTC+1 skrev Ahmed Al Aqtash:

UPDATE:

So, I decided to go on with an install and with the knowledge of my previous misinstalls and guidance from here this is the result:

1) I decided to go on with the install and scheme that I already wrote about. I looked into bind-dirs, and it is definitely something I am going to use at some point, but the effort right now on a 'per-application basis' is simply too much (I just need a running system).

2) I still have an issue with sys-net/sys-firewall not being started on boot, but this problem isn't really a dealbreaker for me. It's just an annoyance.

3) Sound doesn't seem to be working in debian (unstable). None of the fixes seem to work either. This is kind of critical to me..

4) All around okay for now, but I can definitely tell that I would love some more stability, but that's just a matter of patience :)

Thank you for your assistance Tom, much appreciated.

I hope this thread can help others.

[a...@it-minds.dk]

Sorry forgot two things..

5) Weird screentearing in all apps, all appvm's. When I resize windows I get some weird tearing. Again, this is not critical.. just annoying.

6) Resizing a urxvt window in my debian unstable to a certain dimension (or fullscreen hotkey) crashes the terminal. If I have another window running the VM, and that window already 'broke' the dimensions in question, then urxvt has no issues taking on any dimensions. If urxvt is the only window running in the appvm, it will however keep crashing when it reaches a specific size.

There we go :)

[awokd]

On Fri, January 12, 2018 10:12 am, aaq via qubes-users wrote:

> 6) Resizing a urxvt window in my debian unstable to a certain dimension
> (or fullscreen hotkey) crashes the terminal. If I have another window
> running the VM, and that window already 'broke' the dimensions in
> question, then urxvt has no issues taking on any dimensions. If urxvt is
> the only window running in the appvm, it will however keep crashing when
> it reaches a specific size.

That sounds like this issue:
https://github.com/QubesOS/qubes-issues/issues/2617. Try starting from a
fresh Qubes Stretch template and upgrading it to unstable. If that's what
you did, it might be a regression.

[a...@it-minds.dk]

Can anything be done to fix this?
I can't seem to find a solution in that issue, other than core components being updated.

It's fine with me if there aren't any workarounds btw. Just wondering :)

[awokd]

You're right, it's fixed (or should be!) if you are running the stable
Qubes templates but all bets are off if you decide to go and upgrade them
to unstable. :)