Updating window. When clicking to do vm updates, an ‘Update All’ option would be helpful, I feel. Needing to manually check each and every vm checkbox is time consuming, if one wants to update all vms. An option to enable ‘All’ with then the ability to uncheck one or two of the already checked vms, if desired, would be quicker and easier.
2 Likes
It’s already implemented in new Qubes Update tool.
3 Likes
Wonderful, thanks! Is there any way to change out the 4.1 version Updater for the 4.2 Updater?
1 Like
That will automatically be done when you upgrade to 4.2 (it’s still not released)
1 Like
Super. Thanks
1 Like
Thanks for this. Yeah OpenBSD folks have always been a bit slow to the virtualization party so no surprise more Xen work needs to be done before even the porting of the Qubes stuff is possible. They definitely don’t have the man power of some of the other FOSS to be fair. Honestly now I got SELinux working in a Fedora minimal dvm I use for sys-net and sys-firewall OpenBSD might even be a security down grade (especially with user scripts and hacks). And its nice even today I am able to use an pared down OpenBSD HVM standalone console for accessing my router and other high security stuff. With the OpenBSD KARL mechanism and random seed it works better un-templated and is less work to maintain. So in the scheme of things Qubes today is fine and happy with what I already got.
2 Likes
I wish I had a way to easily save and restore dom0 settings.
1 Like
@dispuser Workaround, not solution: the Qubes Backups tool for dom0 does backup your home directory.
If you’re familiar with symbolic links, then symlinking the config files that you modify from your home directory can be a way to make them more convenient to back up.
Of course you need you organize them in a way that allows you to figure out where the symlinks need to be re-created after restoring a backup, but that shouldn’t be too hard?
1 Like
Take notes, and expand bash history file size and save it.
1 Like
It’s not the files that I lose that are in dom0.
It’s needing to reinstall qubes-task-gui, qubes-windows-tools, it’s having to put back custom wallpaper which takes a long time, it is the need to change custom settings, it’s having to make windows and qubes compatible again. Reinstalling qubes is not fast and qubes breaks. It’s the best OS out there but the reinstalls take far too long. It’s needing to customize the panel again. When I restore Qubes, the IP addresses are not the same, so I have to reconfigure anything that requires manual entry of a gateway.
I can’t just load up what I had. Any time I reinstall qubes, it takes about 12 hours to get things somewhat the way I had it before, not including restoring the previous Qubes by restoring backups. I have reinstalled Qubes a lot. Why does it have to be like that?
It’s such a great OS but if I just used something like Kali with virt-manager it would probably save me a lot of time. So many things that harden qubes need to be redone after reinstalling Qubes. It’s not easy to just run a script in dom0 to get back to how things were before.
2 Likes
All the xfce settings are stored in the home directory, when you restore a backup, it’s in a directory in /home/user (if your dom0 user is user) in dom0, you need to:
- reboot qubes OS
- not log-in, but press ctrl+alt+F2 to run commands as root in a tty
- move the backup outside /home/user
- delete /home/user
- rename the backup as /home/user
- press ctrl+alt+F1
- log-in as user
your desktop environment should be like you left if during the backup
4 Likes
Better and more clear soucing of entropy for disk encryption. I always get systemd crashes that reference
insufficient entropy. The entire disk encryption/decryption process should be made more clear, especially
how the Xen hypervisor is involved and how systemd is involved.
1 Like
Better notification of which QSBs and XSAs currently affect QubesOS/Xen and are currently in use in the wild. How can we know which attacks are currently being used in the wild?
1 Like
What difference does it make? If you’re going to decide whether to patch or not based on someone telling you that there are or not exploits “in the wild”, then you’re certainly under- or over-patching widely. I really don’t get the point of this question.
Either you know you need to patch, and you do no matter what the internet says, or you’re in that very specific case that doesn’t need the patch, and I don’t see how the fate of random folks “in the wild” may change that.
5 Likes
Let me rephrase. Would it be possible to tag QubesOS updates with the corresponding QSB or XSA, so that an administrator knows what the patch is actually covering/fixing?
Matching the patch with the vulnerability for better tracking of the application of patches so that you can
generate a history of the patches you’ve actually applied, and which vulnerabilities they’ve addressed.
It would make it much easier to produce a log of all the patches that have been applied and the corresponding XSA/QSB/CVE those patches address so you can see if your system is up to date with patching.
We need a log file for patches/microcode updates with the corresponding XSA/QSB/CVE
1 Like
You could open a GitHub issue for this feature request. It’s quite active there and you may have a quick reply, at least if it’s something interesting the devs.
1 Like
Let me make explicit something that may not be obvious to all.
As stated the dom0 backup copies your home directory. But this will NOT include backup profiles (/etc/qubes/backup), any changes made to policies (/etc/qubes/policy.d) or any services you write (/etc/qubes-rpc).
Also if you did any sort of thing with salt states or anything like that, they won’t get backed up either. Any script you wrote in /usr/bin or /usr/local/bin will not get backed up.
I wrote a script to do the dom0 backup, and the first thing it does is to copy these three areas into places inside my home directory, so they WILL be backed up. However, a restore requires that you remember to copy the files back into those directories.
3 Likes
Isn’t that the whole purpose of this thread?
1 Like
(Since I’m a new user, I am not allowed to post more than two links in a message. I have abbreviated the Github tickets for Qubes and i3 I am referring to as qubes-issues/#xxxx and i3/#xxxx respectively.)
-
More useful real-time logging in the Details pane of
qubes-update-gui. Right now you get all the output blurted out in one buffered chunk at the end, which is rather useless for anything other than auditing. Printing it as soon as it is produced by the package manager would help identify problems (e.g. the update DispVM freezing, which tends to happen from time to time on weak machines). I know the buffered output is a Salt limitation. There seem to be workarounds from a quick glance on Google, but I’m not salty enough to write and submit a patch for this for the update GUI. -
qubes-issues/#3267: I run into this issue several times a day where keyboard input or mouse clicks are sent to the wrong window, instead ending up being picked up by a different window in the same Qube. Most commonly, it happens with floating+sticky windows, where clicking them in one workspace causes a click to be sent to a tiled window on a different workspace (typically the workspace where the floating window was originally spawned). This is yet to cause any security mishaps on my part (only some close calls with middle-click pasting embarrassing DMs to the wrong recipient that I luckily caught before sending) but I can easily see how it could have really bad consequences. Mitigated slightly by only affecting windows running in the same Qube, but it’s a real headache to have to keep that in mind before doing pretty much any mouse clicks or key presses.
(This might be related to i3 as a whole, since it does have some recurring issues with input focus even for non-Qubes users: i3/#3609 ; i3/#2778 ; https://www.reddit.com/r/i3wm/comments/apsos1/problem_with_focus_on_new_windows/ )
-
The barrier for contributions to Qubes is unnecessarily dense. I have been meaning to submit a patch (qubes-issues/#6589) which ought to be correct since it’s just reverting a merge error, but have been putting off setting up a development environment for some basic functionality testing, because the information for how to do it is (or was, at the time) so esoteric.
I see now that there are a few pages documenting it in the developer docs, but skimming through them I still find myself wanting an overview before jumping into disparate sections titled “How to do <some very specific step>” with little to no context.
Specifically, I’d appreciate an introduction to building programs on Qubes and how (if?) it differs from system’s programming on ordinary Unix systems. Is there a different build process for dom0 packages vs AppVM ones? What are the various build tools (without delving into the details of how to set them up immediately)? What is a typical setup like? Can I do it in a Qube on my normal machine, or do I need a separate machine for testing, where I don’t care about the security of dom0?
I’m not necessarily too concerned about ending up with a neat RPM file ready for release either, just as long as I can compile a quick and dirty binary to test and make me confident enough to submit a pull request, from whence the CI system can help out with all that bureaucratic stuff
Maybe something like a “My First dom0 Package Build” tutorial would fit my need.I suppose a lot of distros struggle with the same dilemma of how much of the documentation should be targeted toward the full-time maintainers versus drive-by-contributors like me, so this is not in any way a criticism uniquely about Qubes.
-
Automatic closing of bug reports between major releases risks losing track of bugs. It’s not a huge deal to write a comment to reopen them (I just did for my ticket above) and I understand why some open source projects do this, but it’s yet another hurdle and it’s ever so slightly disheartening when you’ve put in many hours of research to write a useful bug report
-
When upgrading from 3.x to 4.x one of the quality-of-life packages I used (
unclutter) was silently removed. There is currently a discussion about reinstating it (qubes-issues/#2676) but it is unclear to me why it disappeared in the first place. For the time being I’ve reluctantly put up with the cursor staying on screen and being in the way (moving it out of the way is not always a great idea, since, due to the first bullet point of this post, that can cause tooltips from other programs in the same Qube to pop up instead). There is thexbanishprogram that ought to replace it, but the current version in Qubes is really old and does not support hiding the cursor after a timeout (instead only doing so when typing). I presume this will sort itself out if 4.2 contains a newer version.
4 Likes