-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Mar 06, 2018 at 06:05:26PM -0500, Chris Laprise wrote: > 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.
Hmm, indeed vm.run() use vm.run_service_for_stdio() method. vm.run_service() returns subprocess.Popen object. > 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. You can use vm.run_service: $ python3 Python 3.5.4 (default, Oct 9 2017, 12:07:29) [GCC 6.4.1 20170727 (Red Hat 6.4.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import qubesadmin >>> app = qubesadmin.Qubes() >>> vm = app.domains['sys-net'] >>> p = vm.run_service('qubes.VMShell') >>> type(p) <class 'subprocess.Popen'> >>> p.stdin.write(b'date\n') 5 >>> # this is to tell you don't want more commands, alternatively >>> # you can write b'command; exit\n' to stdin (especially when you >>> # want to send some data to the application's stdin >>> p.stdin.close() >>> p.stdout.read() b'Wed Mar 7 00:15:42 CET 2018\n' And if you want connect it to terminal, just pass stdout=None: >>> p = vm.run_service('qubes.VMShell', stdout=None) >>> p.stdin.write(b'date\n') 5 >>> p.stdin.flush() >>> Wed Mar 7 00:16:01 CET 2018 >>> repr(p.stdout) 'None' If you want connect stdin from terminal too, then it's a little more complex, because you need to pass the command first. You can either add a simple loop that copy stdin (that's what qvm-run does), or enter command from outside (the thing interacting with this script). > 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? There is https://dev.qubes-os.org/projects/core-admin/en/latest/ for qubesd side, and https://dev.qubes-os.org/projects/core-admin-client/en/latest/ for client side. The latter one have actual content accessible through module index. Generic concepts are explained in the former, client side mostly expose subset of functions from qubesd (internally through Admin API). Wojtek, could you add links to both of those sites from http://dev.qubes-os.org/? Both are already linked from https://www.qubes-os.org/doc/ > 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. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqfO2YACgkQ24/THMrX 1yxnDgf/RMu0ZTIGvbL6Eu92rG07jG3SeFY33V20apco1N300h2ihkKptJ+AhuQs vzmKXw5VneO/izV5KtMOKieP3KOvf1v8f3x0hr9hsekAqIG85OjxomAIIRsBc2Kq U99aIoKo5aMKg6SSLw4lc6u8PZX5hGkOU3GmFHhVfID/EyI0YxcGlZZ/vytDCfRb VWnu5AGrZ204ORo8LYSXQ2/QqdusAUPK52OHJDPdmvlL1rWirImusgZtq15Hxog1 XQwMpgIlUDGa77GF/XBzrpkS68DGoaaq8cBIVyMX4qGRbHp3UiABBkl1Ey0oWeXa qeygYY6frscoRW4zedpYXpxl2FQrLw== =Awh4 -----END PGP SIGNATURE----- -- 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 firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180307010725.GC7364%40mail-itl. For more options, visit https://groups.google.com/d/optout.