Re: [qubes-devel] USB devices disappearing after rebooting fedora-26
On Tuesday, 6 March 2018 23:44:15 UTC+8, Marek Marczykowski-Górecki wrote: > > It seems to be something that is triggered explicitly when shutting down > > this > > particular VM. > > Do the disappear from both qvm-usb tool and devices widget, or only the > widget? I have now tested this. They are still visible from qvm-usb. In other words, they only disappear from the widget. -- 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/9320b744-2827-40aa-a95d-26b35ede7847%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Qubes OS 4.0-rc5 has been released!
On Tuesday, March 6, 2018 at 8:03:04 PM UTC-5, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Qubes Community, > > We're pleased to announce the fifth release candidate for Qubes 4.0! Huzzah! Brendan -- 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/e9a22ac9-e312-4d4f-be6f-fce916c1bc3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Permission denied when using Qubes().domains
-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)
>>> 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
[qubes-devel] Qubes OS 4.0-rc5 has been released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Qubes Community, We're pleased to announce the fifth release candidate for Qubes 4.0! This release contains bug fixes for the issues discovered in the [previous release candidate][4.0-rc4]. A full list of the Qubes 4.0 issues closed so far is available [here][closed-issues]. Further details about this release, including full installation instructions, are available in the [Qubes 4.0 release notes][release-notes]. The new installation image is available on the [Downloads] page. As always, we're immensely grateful to our community of testers for taking the time to [discover and report bugs]. Thanks to your efforts, we're able to fix these bugs *before* the final release of Qubes 4.0. We encourage you to continue diligently testing this fourth release candidate so that we can work together to improve Qubes 4.0 before the stable release. The Qubes 4.0 stable release - If the testing of 4.0-rc5 does not reveal any major problems, we hope to declare it the stable 4.0 release without any further significant changes. In this scenario, any bugs discovered during the testing process would be fixed in subsequent updates. If, on the other hand, a major issue is discovered, we will continue with the standard [release schedule], and Qubes 4.0 stable will be a separate, later release. Current Qubes 4.0 Users - --- Current users of Qubes 4.0-rc4 can upgrade in-place by downloading the latest updates from the testing repositories in both [dom0][dom0-testing] and [TemplateVMs][domU-testing]. [4.0-rc4]: https://www.qubes-os.org/news/2018/01/31/qubes-40-rc4/ [closed-issues]: https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed [release-notes]: https://www.qubes-os.org/doc/releases/4.0/release-notes/ [Downloads]: https://www.qubes-os.org/downloads/ [discover and report bugs]: https://www.qubes-os.org/doc/reporting-bugs/ [release schedule]: https://www.qubes-os.org/doc/version-scheme/#release-schedule [dom0-testing]: https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories [domU-testing]: https://www.qubes-os.org/doc/software-update-vm/#testing-repositories This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqfOjgACgkQ203TvDlQ MDD85w/+NXqtxDpaC84CeETA/1/HK6WcbYoNmt1ZjRouKJmmrW2pxyUsYo7vZNsN +qgupvvHkE+AFhKuwRrQJq8k6fHPzaY2GWvLpJGQ/bEFqO8fWnrvFzR0OzQb/sYI NfRZoSA9lKyt05QJPfxG3aHqAXJeVwslj337arE/lhws6zsVS0zhtHxCyB9w/Wag c+YWy2BrWjzujlJZC1SDGFrD0bdd+voD2GTOcUrCSXOP4IxH9ym/VWVtD8O5Tssx WIU1qvSumpMaIWN2GsbVIQXqjxv2+AvtNg28neAyAoudpqq4EmX3/ugNe9ngVV0U 8wAKGnRAm5keV7tNV48Kqrsd26N95kkB/0U3AYLG5o1ZwTV2dId5ERxj1hkE8/FC TDIlFcC3S94N39pUwfMcE0wFr6q8m6Mt7XJdDjII2OCrhxbpgoPRrCeUOH0Vkj5d F8VETME1w1taoPjoVIO7jclgaBWChgLLBRjelYUj0fYFIRu3WCQDG1l86ZFWa96q qHLBPSdddzMxdj9G2MQFRamv4cmefUHZx9XbDLK5tjZcX8lfKPS96avNg1iAa3x8 wZGwkk96Lo5MoapH+ZlYde0oTacyssmDSvDw4qmhSAyRbM1TrFlCCtv2TMNkLFHW DaN4GgYeh1XSmw0M7fAf/TmBjjKVxz0oMOgaGhjrmK0vmH29C0w= =BkQO -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 qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/c8317548-c104-da04-194b-79b116ac3862%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Permission denied when using Qubes().domains
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.
Re: [qubes-devel] USB devices disappearing after rebooting fedora-26
On 6 Mar 2018 11:44 pm, "Marek Marczykowski-Górecki" < marma...@invisiblethingslab.com> wrote: > It seems to be something that is triggered explicitly when shutting down this > particular VM. Do the disappear from both qvm-usb tool and devices widget, or only the widget? That's a good question. It definitely disappears from the widget, and they can definitely be seen by lsusb in sys-usb. I'll check the result of qvm-usb in the morning. -- 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/CADtN0WJE7G2MdybNEVPUVef8Q7vNJ85LFLUsuN%3DjCWEANC3WFA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] USB devices disappearing after rebooting fedora-26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Mar 05, 2018 at 11:45:34PM -0800, Elias Mårtenson wrote: > On Tuesday, 6 March 2018 15:30:33 UTC+8, awokd wrote: > > > > You meant other templates besides fedora-26 will NOT cause the behaviour, > > right? > > That is correct. This only happens with the fedora-26 template. > > > > If I plug a USB device into the computer, then all USB devices show up > > > again. > > > > > > Note that the devices never actually disappear from sys-usb. Typing lsusb > > > in sys-usb constantly shows the correct output. > > > > Are any PCI devices assigned directly to your fedora-26 template? Is > > sys-usb based on the fedora-26 template? Does the behaviour still occur if > > you switch sys-usb to the debian-9 template? > > No devices are assigned to the template. In fact, other than enabling the > testing repositories and updating to the latest version (as well as adding > some packages) it's pretty pristine. I haven't done much in the way of > configuring this template, and I've had this behaviour since very shortly > after installing this machine (a few days after rc4 was released). > > It seems to be something that is triggered explicitly when shutting down this > particular VM. Do the disappear from both qvm-usb tool and devices widget, or only the widget? - -- 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/THMrX1ywFAlqetwEACgkQ24/THMrX 1ywZBAf8CGNivH3RSehFwaNnKdxi3QpaHKvxwaddX+jOgsJcp1+AmhpKL56jxBVd Mup1voF5I4ClzG6tqpOQaRt8Ulzmojnql5+B22tL5Vly7kpP9MY1gOzaC0tPJBoj OckKcH1ygzLOOIckFPbgJzolpmBP55ghMDHcizfeGAuM7TC40cXY1LVrssyJVyvf swq6pnYlS67lAmdWqe1uUQTVa0cq4vk96l/KgQN7YyLHsvyKZed3i5bKWOMzDII8 3s1a2Crnb2PsnkvjTQP2OsSi3UT+UMenNgJZraannQIGsykajmQV5w3kulIyM8qf sEP4gLGoFxOdM+7RLjUWp28bpGR3wQ== =kYA7 -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 qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180306154232.GY7364%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] USB devices disappearing after rebooting fedora-26
On Tue, March 6, 2018 7:45 am, Elias Mårtenson wrote: > On Tuesday, 6 March 2018 15:30:33 UTC+8, awokd wrote: >> Is >> sys-usb based on the fedora-26 template? Does the behaviour still occur >> if you switch sys-usb to the debian-9 template? > > No devices are assigned to the template. In fact, other than enabling the > testing repositories and updating to the latest version (as well as > adding some packages) it's pretty pristine. I haven't done much in the way > of configuring this template, and I've had this behaviour since very > shortly after installing this machine (a few days after rc4 was released). > > > It seems to be something that is triggered explicitly when shutting down > this particular VM. Can you try switching sys-usb to debian-9 and testing? That could help narrow down the issue. Sounds vaguely similar to that kernel regression around network attach/detach. -- 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/ee512132efbe93ebd16b8546e9680c2b.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
