Hi John,
That's an interesting background and list of wants. I've been using
Qubes for some time and can try to address a few of your issues.
On 3/15/19 10:31 PM, John Goold wrote:
Issues...
* When launching a program from the Qubes menu, particularly if the
target appVM has to be started, the program often fails to be
launched. This happens very frequently with the Text Editor.
This is annoying as one waits a bit in case one is simply being
impatient, or at least I do, so as not to launch two copies of the
program by accident.
This well-known bug appears to center on programs based on Gtk+ and/or
Gnome. The only way to consistently avoid it is to install Qt/KDE or
other non-Gtk+ software in the templates. KDE works well and Debian+KDE
is what the Whonix templates are based on.
The steps on Debian 9:
$ sudo apt-get remove gnome*
$ sudo apt-get install gnome-icon-theme task-kde-desktop
$ su -c "echo export XDG_CURRENT_DESKTOP=KDE >/etc/profile.d/qkde.sh"
After that, you'll need to adjust the Applications tab in the template's
Settings, and possibly for some of the VMs that are based on it.
(Also switching dom0 to KDE is an option, and this has solved a raft of
usability issues for me.)
* When a USB device is attached to an appVM, there is an appropriate
notification. When it is detached, there is a notification that the
device is being detached, but no notification to indicate that it has
been successfully detached so how long should one wait before
unplugging it?
There is probably no delay required but a couple of seconds suffices for me.
* Ignoring whonix (I do not use it... yet), there are two template VMs
in the vanilla Qubes 4.0.1 installation: Fedora and Debian. However,
they have not been treated equally, with Debian being the loser. The
Qubes documentation indicates that Fedora was favoured for security
reasons.
IIRC there is mention that Fedora was chosen for convenience, not
security. Fedora actually presents a security problem for Qubes and
there is an open issue for moving Qubes off of it.
The problem with the Debian template is that its not preconfigured with
an array of familiar apps, and when you do add them some of the default
file/app associations remain set to unfriendly substitutes (like text
files being associated to emacs, pictures set to imagemagik or gimp,
etc.). Switching to KDE has set these associations to reasonable defaults.
Its also doesn't have the full set of kernel firmware packages installed
but that's easy to remedy.
Since I had been using Linux distributions based, directly or
indirectly, on Debian, when I first set up Qubes, I created my appVMs
based on Debian. That was painful as I then had to install a lot of
basic software.
When I re-read the documentation, I realized the security reasons,
so I switched all my appVMs (except one!) back to Fedora. It was not
painful, but I would have rather have spent the time doing something
else.
I would like to know where it says this about security. Most Qubes users
consider Debian to be (in general) more secure. The open issue for
migration away from Fedora is at:
https://github.com/QubesOS/qubes-issues/issues/1919
The kicker came when Firefox stopped playing Flash content in my
untrusted appVM, complaining that I needed an up to date version of
Flash. I installed the most recent version, but that did not solve
the problem. The problem is/ was something to do with Fedora (or the
version of Firefox for Fedora or ??).
I haven't used Flash in a long time so I can't help there. In general
its best to find an alternative that doesn't rely on Flash, which is
becoming a dead format. Typically Flash is replaced by HTML5 web apps
(and most websites have made this switch automatic).
* Screenshot only appears to work from Qubes Tools. I can "add"
"Screenshot" to appVMVs based on Fedora (but not on Debian). But it
does not work -- The dialog comes up but, having chosen to select an
area, I cannot do so.
Subsequent attempts to use Screenshot do not even present a dialog.
Although I have not seen this documented anywhere (which does not
mean it is not), it seems logical -- dom0 owns the screen (monitor),
so it makes sense that it handles screenshots. However, that means
screenshots are saved in dom0 and have to be moved (or, I suppose,
copied) to the desired appVM. It seems a bit awkward. If one is in a
program in an appVM and decides a screenshot would be nice, it is
probably focussed on that window or a portion of it. Since the OS
displaying the window "knows" what it is displaying, it seems logical
that some kind of screenshot could be made by that OS, but restricted
to its window.
If not, why is it possible to "add" Screenshot to an appVM?
Qubes doesn't limit which apps can be installed in templates. So this is
considered more of a "sensible defaults" issue, where screenshot apps
are not preconfigured in templates, and are preconfigured in dom0.
As for saving screenshots, there is an open issue and a mostly-finished
utility that attempt to address this. OTOH, I just use 'qvm-move-to-vm'
from the shell when I'm done snapshotting.
https://github.com/QubesOS/qubes-issues/issues/953
* About a week ago, I started having a problem: I could not
copy-and-paste between appVMs. Prior to that, I had been having
problems with Firefox freezing in different appVMs. Rebooting the
affected appVM solved (or should I say "worked around") the latter
issue; however, it had no effect on the former problem.
The current Firefox ESR does have a tendency to freeze temporarily when
memory gets low. I'm considering switching to the non-ESR 'firefox'
package in Debian to see if the newer versions are better in this respect.
I think someone reported here in qubes-users that copy/paste stopped
working for them. Since this is a dom0-controlled feature it may be that
your preference for long uptimes is overlapping with a Qubes daemon
stability issue -- sometimes a dom0 Qubes process will just exit,
although I haven't experienced this with copy/paste and I reboot on
average a couple times per week.
My Bottom Line:
I can live with most of the issues described above. What I cannot live
with (and worry about) are stability and reliability issues.
[Aside] I do not intend doing a daily full back-up. I do not wish to be
hypocritical, so full-disclosure: When I was managing the
internal hardware and software support teams at a Bell-Northern
Research lab., I insisted on daily backups. When managing the
"System Programming" group for a mainframe (same as the modern
"System Administration") the scheme involved daily, weekly,
monthly and annual backups of data files and backups whenever
the operating system was updated, withappropriate off-site
storage.
I'm about to release a beta for my backup utility that can perform quick
incremental backups of Qubes volumes. The working title is 'sparsebak'
and it works like Apple's Time Machine in a sense... you only need to do
one full backup (ever) and it can quickly recover space from old backup
sessions:
https://github.com/tasket/sparsebak/tree/new4
The idea behind sparsebak is similar to Time Machine -- that even VM
backups should be so efficient that you could backup many times each day
without experiencing a burden on your time or system resources. It
depends solely on the amount of change your volumes incur, so that even
very large files experiencing small changes are backed up in a flash.
Its pretty unique on Linux -- capable of updating a VM volume over Wifi
in 1 or 2 seconds -- and I feel the 'new4' branch is already at least
beta quality. The storage format is also simple enough so that regular
Linux tools can recover data from an archive. Although its CLI-based,
you might want to give it a try.
An alternative to this is to setup a Btrfs or ZFS storage pool for your
VMs (if you didn't already install Qubes on Btrfs) and use send/receive
for incremental backups. This also requires a Btrfs or ZFS volume on
your backup server if you wish the snapshots to stay integrated (IIRC
this is a requirement for ZFS anyway).
I need some reasonable assurance that data corruption on disk has a
very low probability. I need some reasonable assurance that the
operating system (the combination of Xen and dom0) is stable.
The best assurance is regular backups. I don't know what caused your
glitch but I've had vanishingly few on Qubes myself since 2013.
However, Qubes does require the use of snapshot-capable storage for
reasonable efficiency and this is not yet Linux' strength.
Between Thin LVM (Qubes default) and Btrfs storage options my experience
tells me that Btrfs is actually the more reliable system, as it can
survive system crashes even better than plain ext4; Storage integrity is
a core goal of Btrfs so this is expected. Another option that offers
high integrity is ZFS for which a Qubes guide exists.
-
I hope this response helps you out some. Right now Qubes appears to be
in a state that's mostly suitable for "security techies"; There is
certainly room for improvement and your critique has made me think that
some new issues need to be opened to help address the usability issues.
--
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/822f9c79-6be5-f2b2-f075-b7efa104ef65%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
