Marek Marczykowski-Górecki> feelfree to report them in qubes-issues
adding a note its an UX issue.
Knowing the direction Qubes want to take, I will. Not knowing what
direction Qubes is taking, raising UX-issues in a security-project would
have felt out of place.
> I've seen some users written bash completion plugins for qvm-* commands.
> We'd need to integrate one.
Yes. I know, but I take dom0-security very serious and working through a
lot of code is tedious.
> Well, actually DispVMs with auto_cleanup=False are quite useful too. For
> example as sys-usb or sys-firewall
I stand corrected!
>> qvm-run --dispvm [dvm-template] CMD
>> fails too often and without obvious reasons for me to count. (Guess it's
>> a RAM-problem.)
> Oh, indeed after printing "Not enough memory to start domain 'disp...'"
> there is a bunch of garbage messages.
It's not even that, most commonly it starts and halts again, no reason
given. I'll write a more detailed issue.
>> qubes-global-settings can't be used from the commandline but opens
>> GUI-window.
> Command line equivalent is qubes-prefs.
Not entirely. dom0 memory boost, minimal qube memory and dom0 UpdateVM
don't exist in qube-prefs (though I guess dom0 UpdateVM maps to
updatevm? I would expect the former to be used exclusively for dom0, the
latter as update-proxy); there is "check_updates_vm" in qubes-prefs, but
"Check for dom0 updates" and "Check for qube updates by default" in
qubes-global-settings. On the other hand, there are many settings in
qubes-prefs. I would not have intuitively thought qubes-prefs to be
intended as CLI-global-settings.
>> qvm-copy now opens a window that needs interaction. This is awful for
>> copying many files, VM-name has to be typed for every file. Not to
>> mention I had some automated scripts that copied some files which are
>> now much more cumbersome as well.
>
> But even for old "qvm-copy-to-vm" you've got GUI window to confirm the
> operation.
And it was just that. I could let my script choose VMs, glance the
window and hit enter. Now I have to know what vm to type in. (I echo the
VM-name before qvm-copy)
> For automated operations, you can edit qrexec policy for qubes.Filecopy
Which would be fine for single-purpose VM-interaction. I had one VM
dedicated to ssh-ing my work-server, while also having a backup-VM and
general-purpose development-VM. So after doing some coding, I would want
to copy my work to backup and work. Since development has all sorts of
weird tools installed (node), I wouldn't want it to generally talk to
other VMs without me knowing. And since what files to transfer depends
on the project, a dom0-script makes little sense. (Yes, I could
implement a whole qrexec-service, but again, I criticise usability, not
possibility)
>
>>> -> qvm-usb to assing usb devices
>> This was the big improvement (for me) in Qubes 3.2. Credit where credit
>> is due, this is awesome!
>
>> qvm-block on the other hand ...
>> - no attaching of image-files anymore (used to do my backups that way)
>
> You can, if you attach it to loop device first (losetup in that VM).
Thanks, tried mount to create loopback devices, didn't work, gave up.
Move it from the "impossible" to the "cumbersome" bin. I'll write an issue.
>> - detaching requires full path as well (horrible if blockdevice is in
>> dispvm)
>
> What do you mean?
Qubes 3.2:
qvm-block -a work disp1:dm-1
qvm-block -d work
Qubes 4.0:
qvm-block a work disp7592:dm-0
qvm-block d work disp7592:dm-0
I need to type in the whole device-path. If the device exists in a
dispVM (which I do quite often to decrypt drives), I have to figure out
the random 4 digits of the specific dispVM that's holding the drive.
>> - documentation of features is especially lacking (e.g. could do
>> qvm-block [TARGET] [SOURCE] -f xvdz, now frontend-device is a feature of
>> qvm-device I have to look up how to use every time I need it.)
>
> You mean the option is named "-o frontend-dev=xvdz" instead now of "-f xvdz"?
> We can add an alias for that...
That would be great! But furthermore, qvm-block --help doesn't tell me
this is possible. man qvm-block opens man qvm-device instead
(confusing). The command is specified as
"qvm-device [options] DEVICE_CLASS ..."
Later on, the description of device_class "block" reads "available
options: -frontend-dev ..."
But instead of accepting "frontend-dev" as option ("qvm-device
frontend-dev xvdz block ...", I have to use the option "--option". This
is frustratingly confusing.
So much for Qubes CLI. As mentioned before, I'll write some issues.
Sincerely
GammaSQ
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/34dd8700-bd1e-3035-48fc-e65c2c37b059%40gmx.at.
For more options, visit https://groups.google.com/d/optout.
