On 03/04/2018 09:30 AM, Marek Marczykowski-Górecki wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Mar 04, 2018 at 05:46:39AM -0500, Chris Laprise wrote:
On 02/21/2018 06:20 AM, Wojtek Porczyk wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Feb 20, 2018 at 10:45:55PM -0500, Chris Laprise wrote:
Using python3 in dom0, trying to access qubes.Qubes().domains results in the
following error:
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.136 [...] and kernel driver
It does work when using 'sudo python3' instead.
I don't know if this is considered normal behavior or a bug, as I would
normally expect admin objects to be accessible with normal user privs.
Yes, that's expected. qubes.Qubes() is meant to be used from qubesd and if
you'd like to get knowledge about domains, you should use qubesadmin (even as
root). See the qvm-* tools as an example.
Is there an analog to the R3.2 function vm.run()? Looking at the difference
in R4.0 qvm-run source, that doesn't seem to be the case.
Yes, there is `vm.run()`.
I've double-checked the source and tried some runs and I think my
initial assessment was right: There's no real analog to R3.2's vm.run()
in R4.0.
If I use vm.run() in R4.0 it waits for the guest process to exit and
then returns the stdout+stderr as byte strings. The guest process will
exit with an error if it asks for input. But in R3.2 vm.run(passio=True)
streamed the guest output to the terminal as it was being written.
This difference shows up in the two versions of qvm-run. Sans
documentation, it looks like you have to create custom event loops in
R4.0 to get the same result as vm.run(passio=True) in R3.2. This leads
me to think that python programs needing to run guest tools in R4.0 are
better off using subprocess.call(qvm-run(passio=True)).
-
Speaking of documentation and APIs, I initially thought (based on public
announcements) that "Qubes Admin API" was what I needed. Then I'm told I
need to use "qubesadmin" which is different. That's confusing. And the
internal API is documented while the app/utility API is not?
Additionally, looking at the tools source there is this pattern of use
that says essentially: Acquire the qubesadmin API via the Qubes parser.
That also seems odd.
--
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-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/ee3a0c5c-d149-e672-6dcd-ae23ea19ad5e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
