[qubes-users] Workaround for building Ubuntu xenial+desktop with qubes-builder
Hey all,
Today I was trying to build the Ubuntu 16.04 Xenial+Desktop template
using qubes-builder with help from these instructions:
https://github.com/QubesOS/qubes-builder
Everything was alright until the `make qubes-vm` step where it would
fail on the following:
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream
> tarball found at ../xen_4.6.3.orig.tar.{bz2,gz,lzma,xz}
> dpkg-buildpackage: error: dpkg-source -b debian-vm gave error exit status 255
> /home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:196:
> recipe for target 'dist-package' failed
The build was looking for xen_4.6.3 when in fact xen_4.6.4 is in the
folder. As a workaround, simply copying the xen_4.6.4 to be named
xen.4.6.3 allowed the build to continue and eventually complete
successfully:
> cd /path/to/qubes-builder/chroot-xenial/home/user/qubes-src/vmm-xen; sudo cp
> -pr ./xen_4.6.4.orig.tar.gz ./xen_4.6.3.orig.tar.gz
Hope this helps someone while the script is being updated.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/o66u0i%24l0%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Truncating a non linux HVM?
What is the easiest way to truncate a non-linux HVM filesystem so that it can be smaller and take up less space? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/439184db-89f4-4653-8136-8e751e903ec4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Default UpdateVM and Issues while updating VM
Hi Chris, I just tried, and same error.. this is driving me nuts! This is the latest conf: Kali2-Template NetVM: sys-firewall UpdateVM: sys-net Kali2-Template has "allow connections to Updated Proxy" ticked, and the "01qubes-proxy" file present. sys-net has the qubes-update-proxy up and running, updating other templates works! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8aa8008f-9fe5-45e9-b4ad-5d4f804a2243%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Slow performance of Docker containers in AppVMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jan 23, 2017 at 07:55:30PM -0500, Garrett Robinson wrote: > On 01/23/2017 06:40 PM, Marek Marczykowski-Górecki wrote: > > Try placing /var/lib/docker in /rw using bind-dirs[1]. Something like > > this: > > > > $ cat /rw/config/qubes-bind-dirs.d/docker.conf > > binds+=( '/var/lib/docker' ) > > > > [1] https://www.qubes-os.org/doc/bind-dirs/ > > > > Thanks for sharing bind-dirs, I hadn't come across that feature yet! > However, do you think this would have different /performance/ > characteristics over just using a StandaloneVM (which I have tried, and > which did not improve matters noticeably?) There is one device-mapper layer less - but in case of StandaloneVM it's dm-linear (so 1:1 mapping), so not a big difference. I'm not sure what performance do you expect, but here is some really naive container startup benchmark (with the above bind-dir): $ time sudo docker run -i ubuntu:16.04 true real0m2.206s user0m0.065s sys 0m0.055s - -- 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- Version: GnuPG v2 iQEcBAEBCAAGBQJYhqiCAAoJENuP0xzK19csuacH/RJVo8PkuB70G6f4GUh4sEKh kVmZeTVJMMJhznfkRxxCgJ3o9YM8DwJs0hwXJb46MkJPlxULJ3SPGraqQHj9Ek11 1ywI4wtANkSNZgb7mH6cohR011rH0llSxhqbVcpqqIXUHqkiapCd50V9FGuhJUpz j8D4gX/iBSFPkSfQytmDVFdMT1z+8A9LBqKscjjllBg7gBcKvG8wTP8bmD40I0HJ B8yNdM8OXOG9CyefUqJitBnhua3JIclx7zZNiChlb3uouZok+VmpDA1fQT7ALmpf gOKtTK0G8JMgf5ge7lIkQYY1YhR0CFZ10klkAPP/6ijttZf8PrzmySIov6s1tAk= =Mptg -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170124010609.GF5268%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Slow performance of Docker containers in AppVMs
On 01/23/2017 06:40 PM, Marek Marczykowski-Górecki wrote: > Try placing /var/lib/docker in /rw using bind-dirs[1]. Something like > this: > > $ cat /rw/config/qubes-bind-dirs.d/docker.conf > binds+=( '/var/lib/docker' ) > > [1] https://www.qubes-os.org/doc/bind-dirs/ > Thanks for sharing bind-dirs, I hadn't come across that feature yet! However, do you think this would have different /performance/ characteristics over just using a StandaloneVM (which I have tried, and which did not improve matters noticeably?) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/51b7712c-883b-8648-b65f-eb42e0cc3f8f%40freedom.press. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Slow performance of Docker containers in AppVMs
On 01/23/2017 06:17 PM, Grzesiek Chodzicki wrote: > Have You tried using StandaloneVMs to host Docker? StandaloneVMs don't use > copy-on-write afaik so it should be at least a little faster. Great suggestion! Unfortunately, I just tried using a StandaloneVM and there was no noticeable performance improvement :( -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/211473d5-fd3f-0445-9431-4c3fe2257122%40freedom.press. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Slow performance of Docker containers in AppVMs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jan 23, 2017 at 02:55:28PM -0500, Garrett Robinson wrote: > I am working on transitioning my day-to-day software development work to > Qubes. The primary challenge that I face is widespread use of Vagrant > for provisioning development environments. I am aware of the challenges > and concerns around hacking Qubes to achieve nested virtualization, so I > am trying to avoid going down that road. > > A potential alternative is to use Docker, because there are no inherent > issues with using Linux containers inside virtual machines. Vagrant > supports using Docker as a "provider," so this seems like a viable > solution that could allow me to use my existing Vagrant-based > development environments on Qubes with only minor modifications. > > I set up a new TemplateVM (based on Fedora 24) and AppVM to experiment > with setting up a Vagrant+Docker-based development environment. It was > surprisingly easy; however, after some initial testing, I realized an > unfortunate truth: operations inside the Docker container are *very > slow* - so slow as to create an unacceptable level of overhead for > day-to-day development work. > > The slowdown appears to be due to slow disk IO. Running htop shows that > processes in the container have status "D", meaning "disk sleep > (uninterruptible)", for long periods of time. I tried switching the > Docker storage backend to "overlay" instead of the Fedora default of > devicemapper with loopback devices, which is a well-known technique for > improving Docker performance on Fedora. This was an improvement, based > on my experience as well as some simple dd-based IO benchmarks, but > overall performance is still much too slow--borderline unusable. > > My gut feeling is that this is due to the combination of Qubes' overlay > filesystem with Docker's overlay filesystem - I imagine that nesting COW > filesystems is naturally a prescription for degraded performance. > Unfortunately, I do not know enough about Qubes/Docker/filesystems to > know of the best way to test this hypothesis. > My questions for the list are: > > 1. Is anybody else successfully using Vagrant and/or Docker on Qubes? Do > you have any tips/tricks to share? > 2. Does anybody know or have any alternative theories as to what might > be causing these performance problems? 3. Even better: does anybody have > good advice for how to experimentally analyze these problems? Good ideas > for how to analyze the source of the slowdown, ideas for benchmarks, > useful analysis tools or techniques, etc.? > > I have some notes on my experience and a Docker environment for basic IO > benchmarking, which I am happy to share if anybody's interested. Try placing /var/lib/docker in /rw using bind-dirs[1]. Something like this: $ cat /rw/config/qubes-bind-dirs.d/docker.conf binds+=( '/var/lib/docker' ) [1] https://www.qubes-os.org/doc/bind-dirs/ - -- 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- Version: GnuPG v2 iQEcBAEBCAAGBQJYhpRpAAoJENuP0xzK19csydsH+QETCL/mCE9gIRk3H7MghZVi 5Ry8ZIVznH+RM6eyF9o2zco4Q/tYdlrwbi2jyiZSEQa+kEFGAnzeS8G7403xE6ic wp2EkKXX1n2L2zEFnfIOPdYyNV7Nd9JV7/hgGHKqa6Dv6yKeRIXpIllK978S96HV bWW3MeWJVqKTZAK4ucUkFG3eOqgfUU83DL6/u5p9cfBkSOK91kp8xrT1QmD2JEba anIF+C5/JTlqyH/W1aDz9u3m+JW+yDOIxAsYzwL7Xi5wUJ1yY3ZsiLzwJWWrlFTc ScYogM/M/UhbMQAHynLXqihrUhclgZHgyz3+JnBQaDarTRlehTZSmg2dphANiok= =nIBF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170123234024.GB7447%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Slow performance of Docker containers in AppVMs
W dniu poniedziałek, 23 stycznia 2017 20:55:31 UTC+1 użytkownik Garrett Robinson napisał: > I am working on transitioning my day-to-day software development work to > Qubes. The primary challenge that I face is widespread use of Vagrant > for provisioning development environments. I am aware of the challenges > and concerns around hacking Qubes to achieve nested virtualization, so I > am trying to avoid going down that road. > > A potential alternative is to use Docker, because there are no inherent > issues with using Linux containers inside virtual machines. Vagrant > supports using Docker as a "provider," so this seems like a viable > solution that could allow me to use my existing Vagrant-based > development environments on Qubes with only minor modifications. > > I set up a new TemplateVM (based on Fedora 24) and AppVM to experiment > with setting up a Vagrant+Docker-based development environment. It was > surprisingly easy; however, after some initial testing, I realized an > unfortunate truth: operations inside the Docker container are *very > slow* - so slow as to create an unacceptable level of overhead for > day-to-day development work. > > The slowdown appears to be due to slow disk IO. Running htop shows that > processes in the container have status "D", meaning "disk sleep > (uninterruptible)", for long periods of time. I tried switching the > Docker storage backend to "overlay" instead of the Fedora default of > devicemapper with loopback devices, which is a well-known technique for > improving Docker performance on Fedora. This was an improvement, based > on my experience as well as some simple dd-based IO benchmarks, but > overall performance is still much too slow--borderline unusable. > > My gut feeling is that this is due to the combination of Qubes' overlay > filesystem with Docker's overlay filesystem - I imagine that nesting COW > filesystems is naturally a prescription for degraded performance. > Unfortunately, I do not know enough about Qubes/Docker/filesystems to > know of the best way to test this hypothesis. > My questions for the list are: > > 1. Is anybody else successfully using Vagrant and/or Docker on Qubes? Do > you have any tips/tricks to share? > 2. Does anybody know or have any alternative theories as to what might > be causing these performance problems? 3. Even better: does anybody have > good advice for how to experimentally analyze these problems? Good ideas > for how to analyze the source of the slowdown, ideas for benchmarks, > useful analysis tools or techniques, etc.? > > I have some notes on my experience and a Docker environment for basic IO > benchmarking, which I am happy to share if anybody's interested. > > Thanks, > Garrett Have You tried using StandaloneVMs to host Docker? StandaloneVMs don't use copy-on-write afaik so it should be at least a little faster. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4d773fab-255c-4199-9f5b-d933055135dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] question about setting up VPN proxy vm
Hi All, I'm attempting to follow the docs here: https://www.qubes-os.org/doc/vpn/ and setup a proxyVM so I can tunnel traffic to a vpn for other appvms. I've setup the proxyVM and added the network-manager service in the vm's configuration. The docs next say to: "3. Setup your VPN as described in the NetworkManager documentation linked above." When I try and configure a VPN in the icon in the window manager tray I think it's setting up the vpn for sys-net. Is there a way to start the NetworkManager service for the proxyVM? Do I start the NetworkConnections app? I think this is a user error issue but I can't seem to get the proxyVM's networking setup. Thanks in advance. Brian -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/863f5b2c-66d6-ce7e-ccbd-41363c3a578b%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Web video suddenly plays at 1/6 speed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Closing the loop here since I partially diagnosed and ultimately fixed the issue. I had been booting Qubes in UEFI mode for as long as it was working normally. I then updated the kernel and must have done something wrong because after that the machine would only boot in BIOS mode. That was when the video playback issues started. I ended up re-installing the entire OS and restoring my individual VMs from backups, which was overkill to fix the boot issue but I wasn't sure at the time that that's what it was. Finally, to answer the question immediately above, I did try with totally fresh TemplateVMs and AppVMs to no avail. -BEGIN PGP SIGNATURE- wsBcBAABCgAGBQJYhn84AAoJEAtS3DZk/sPRnM4H/2k4b2lbKduxBqbWCxz1Na4Z sr7b1W1oIo4wOwnMj6voLWyNLVbkp3jxIwbbmsmnU9tnfxiOED15GrKqaRjEJssD 9y1WLCRpQ1yfb6s7FM/3sz7Kf8qcFNhxY72YRPJsos/BAOBju7Fy5eVUsAnM/R+m JbHkNYGKiYHZkgqVR9i9Wgva4DA31g9JOdryJ7FGfwnXhz2TvxGx34mFIOgMomHn nP2K8v9T5y1DEFBTs9p8tN0rX/8HJI5hSG5FTUclrOSyyRQcMCAdazEZkzWtUXv+ 6mZEK3WvcJcjE+evYFxNKM3G2s1atuytpHWbcSttMZI0ihIzhZz+dfHbBe/T8xU= =ktn1 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a3f5387f-db98-4c7d-99ba-48c31ff29480%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Attaching a USB printer scanner to Windows HVM via usbip (a workaround)
On Monday, January 23, 2017 at 10:00:09 PM UTC+3, raah...@gmail.com wrote: > On Monday, January 23, 2017 at 3:28:47 AM UTC-5, daltong defourne wrote: > > Hi! > > I've managed to plug a USB printer/scanner into Windows HVM via usbip (as > > workaround to current USB/PCI passthrough woes) > > > > Sharing with community: > > https://github.com/QubesOS/qubes-issues/issues/2597#issuecomment-274347172 > > > > NB! This thing requires that you have networking between windows HVM and > > your usbvm (or whatever the USB controller has been passed through to) > > can other appvms bet attacked by the usbvm after this setup? in my humble opinion, usbip from usbvm is bearable, but definitely not very good security-wise. (it's a complex piece of software with obscure, occult behavior, and a daemon running as root on usbvm) using it to take over the usbvm from a compromised windows box is definitely within possibility. If your usbvm doesn't manage dom0's input devices and if it has no networking beyond windows-vm <-> usbvm path, attacker will be likely limited to dropping malware on flash drives you connect to usbvm and such So IMHO (don't quote me on this) it's not very bad and most of increased susceptibility happens on windows7<->usbvm path It's a trade-of (most things in life are :() -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a5df96cc-dde0-42a4-bba7-092f80b0ffd6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Slow performance of Docker containers in AppVMs
I am working on transitioning my day-to-day software development work to Qubes. The primary challenge that I face is widespread use of Vagrant for provisioning development environments. I am aware of the challenges and concerns around hacking Qubes to achieve nested virtualization, so I am trying to avoid going down that road. A potential alternative is to use Docker, because there are no inherent issues with using Linux containers inside virtual machines. Vagrant supports using Docker as a "provider," so this seems like a viable solution that could allow me to use my existing Vagrant-based development environments on Qubes with only minor modifications. I set up a new TemplateVM (based on Fedora 24) and AppVM to experiment with setting up a Vagrant+Docker-based development environment. It was surprisingly easy; however, after some initial testing, I realized an unfortunate truth: operations inside the Docker container are *very slow* - so slow as to create an unacceptable level of overhead for day-to-day development work. The slowdown appears to be due to slow disk IO. Running htop shows that processes in the container have status "D", meaning "disk sleep (uninterruptible)", for long periods of time. I tried switching the Docker storage backend to "overlay" instead of the Fedora default of devicemapper with loopback devices, which is a well-known technique for improving Docker performance on Fedora. This was an improvement, based on my experience as well as some simple dd-based IO benchmarks, but overall performance is still much too slow--borderline unusable. My gut feeling is that this is due to the combination of Qubes' overlay filesystem with Docker's overlay filesystem - I imagine that nesting COW filesystems is naturally a prescription for degraded performance. Unfortunately, I do not know enough about Qubes/Docker/filesystems to know of the best way to test this hypothesis. My questions for the list are: 1. Is anybody else successfully using Vagrant and/or Docker on Qubes? Do you have any tips/tricks to share? 2. Does anybody know or have any alternative theories as to what might be causing these performance problems? 3. Even better: does anybody have good advice for how to experimentally analyze these problems? Good ideas for how to analyze the source of the slowdown, ideas for benchmarks, useful analysis tools or techniques, etc.? I have some notes on my experience and a Docker environment for basic IO benchmarking, which I am happy to share if anybody's interested. Thanks, Garrett -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8065ddd4-8153-3d13-dd15-edb7aafca62f%40freedom.press. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Default UpdateVM and Issues while updating VM
Hi Chris, I have also tried using sys-net as the update proxy, but I still get the same error... I've checked and in sys-net there are NAT rules for "you should see a redirect to local port 8028 for all traffic addressed to 10.137.255.254.", so no clue of what the issue may be now! Cheers -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4b47cfd7-0737-4afa-b2b6-b8172f79222a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Default UpdateVM and Issues while updating VM
On 01/22/2017 12:13 AM, adonis28...@gmail.com wrote: Hi mate, I finally had some time for testing, and still not working, although I got some more info. So I checked and the 01qubes-proxy is in there in the template I'm trying to create for Kali. After that, I checked the sys-firewall VM and yeah, update proxy didn't seem to be enabled, so I tried to follow what the docs you pointed me to say: (2) Firewall tab -> Allow connections to Updates Proxy; this setting works immediately (once OK is clicked) I rebooted and.. didn't work, the service (qubes-yum-proxy) had disappeared from the services tab! Once thing that may help clarify this is that every time I switch to the "Firewall" tab in sys-firewall, I keep getting the same error: "The sys-firewall AppVM is not network connected to a FirewallVM! You may edit the VM firewall rules, but these will not take any effect until you connect it to a working Firewall VM"... I also verified on a terminal that there are no NAT rules associated to the updated proxy!! That fw tab error is normal, since sys-net (netVMs in general) don't provide Qubes firewall services. You specify firewall rules on VMs that are connected to proxyVMs such as sys-firewall. So that error states something that is true, as the sys-firewall VM is network connected to sys-net, as it was after the initial installation, I haven't changed that! I'm guessing it is not the right configuration, but not sure how to set it up now... any ideas? Thanks! Is there a reason why you don't want the update proxy to work in sys-net? That is the Qubes default. Chris -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/be436bff-fb82-1d71-8a91-fce167a8d9fd%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AEM and TPM no longer working
On 01/21/2017 06:16 AM, Rusty Bird wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 qubenix: All tpm related tools believe tpm in disabled, and the prcs file is always empty with TXT or without. I am 100% sure that the chip is active in BIOS. Any other ideas? Not really, sorry. Maybe dmesg has something interesting? Rusty This is interesting, since AEM was created on a similar system (T420s IIRC) that probably has the same TPM chip. In this case, I would suggest updating the BIOS then enable TXT and properly clearing the TPM (w/ power-off) before taking ownership. Chris -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d5ae872d-40e3-0d7c-4372-88a8178ec90b%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Suggestions for RBAC for grsecurity-enabled kernel?
On 2017-01-23 12:05 PM, raahe...@gmail.com wrote: > On Sunday, January 22, 2017 at 6:25:42 PM UTC-5, Kopimi Security wrote: >> Hardened kernel with Grsecurity is coming along nicely - and there is yet >> more to come, as this medium-post shows >> https://medium.com/@securitystreak/living-with-qubes-os-r3-2-rc3-for-a-week-1a37e04c799e >> >> Here's the background, I just sent this mail to coldhak.ca: >> --- >> Referring to https://coldhak.ca/coldkernel/ >> >> 1. >> Please add that error-messages from "sudo update-grub2" can safely be >> ignored. >> As also stated in https://www.qubes-os.org/doc/managing-vm-kernel/ , >> "Installing PV GRUB2". >> >> 2. >> Also please add that one needs to change the kernel in appvms to pvgrub2 >> >> 3. >> And related, that one should also install paxtest and run it to confirm that >> grsecurity is running >> As mentioned at https://micahflee.com/2016/01/debian-grsecurity/ >> >> 4. >> And that there is the option to add further to securing the appvm, by using >> gradm2 in learning mode as explained at >> https://en.wikibooks.org/wiki/Grsecurity/The_Administration_Utility#Full_System_Learning >> --- >> >> And so I'd like to hear if you have any suggestions for RBAC given the >> opportunities for compartmentalization that Qubes OS provides. >> >> Cheers, >> C-c & C-v > > oh dam, thats taking it to the next level. lol. I could be wrong but I think > eventually you have to learn how to edit the file manually as the system > changes, which is beyond me. It would be easier to manage on sys-vms though I > would imagine. > Yeah, I tried it myself leaving my laptop turned on and on learning mode for three weeks straight, but it didn't catch everything and certain things still failed so there's definitely some manual massaging that needs to be done. Unfortunately, I don't know enough about the Qubes architecture to figure out what to white list, and while the Qubes architecture documentation is good with explaining the high-level way the processes work and interact with one another, it doesn't do much to define exactly just what binaries and libraries (either Qubes, Xen or otherwise) are actually responsible for doing the work. If I knew that, then things would be easy to manually white list within RBAC or to manually set PAX flags with paxctl and paxctld. With all the difficulties I've faced, I'm now leaning to just white listing all the Qubes/Xen stuff by default in order to be done with it, even though a small part of me dies inside while saying it since it goes against my personal philosophy of only white listing the absolute minimum needed to make things work. Another thing I haven't quite figured out is how to do the RBAC learning when you have one template VM serving a variety of different service VMs and AppVMs. An extreme example is using the default Fedora-23 template as both a firewall and AppVM. You could do the learning on both the firewall and AppVMs, but how do you then merge those RBAC rules onto the template when you're done? And should you even do that in the first place? For example, you'll want to blacklist a lot more on the firewall VM than you would on the AppVM, so how do you do that if they share the same template? The easy answer, of course, is to use different templates for each use case, but then the situation could easily degenerate into a 1:1 template-to-AppVM ratio, which is also silly and wasteful of disk space as well. I actually gave up on figuring out how to make RBAC work in Qubes for the moment until a better approach at white listing that fits the Qubes way of doing things can be found, although I really love the concept and how it'll deny anything that isn't explicitly allowed. Right now, my service VMs are running on minimal Fedora 25-based templates with just the coldkernel, but when Debian-9 hits stable, I'm going to switch those templates to a stripped down version of it since AppArmor seems to work fine with the default coldkernel at the moment. Hopefully someone out there smarter than me will be able to figure out how to get RBAC working properly within a Qubes environment soon. I really love the concept of it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/o65m2p%24pk2%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Another reason for Linux and QubesOS
On Monday, January 23, 2017 at 2:13:43 PM UTC-5, raah...@gmail.com wrote: > On Sunday, January 22, 2017 at 3:39:56 PM UTC-5, stevenwi...@gmail.com wrote: > > Windows Update Prioritizing itself over Chrome > > > > https://www.youtube.com/watch?v=GD3Lxyin8VY > > > > > > > > I do not know if this applies to other applications than Chrome but this is > > ridiculous. > > > > If i want to get something done then i dont want Updates to kill my > > connection. > > you can block it with windows on built in firewall even on windows 10 home > edition. > > What you can do is have a rule allow only dns service for svchost.exe (host > process). > > Then another svchost.exe rule for everything else. Keep that one always > blocked Make sure to enable logging for windows firewall so you can see if > you did something in error. Then only allow this one while updating. and > block it again when done. I've tried to have a svchost.exe rule that only allows the update processes, but coudln't get it working. windows still auto creates firewall rules, and if you remove them they can come back. But what you can do is set them to blocked when they appear. Its usually only for the "apps" from store. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f6865b77-8cd6-42ea-9776-dd5388d3b4de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Which templates update automatically?
On Sunday, January 22, 2017 at 5:59:48 AM UTC-5, FWM wrote: > From my experience, This auto check for updates doesnt seem to work properly. > > The default templates definitely get checked for updates, but the cloned > templates never seem to. If i manually click the "Update VM system" on a > cloned template, it will often find updates. > > I ran "qubes-set-update status" in dom0, and both were enabled. > > Running Qubes OS 3.1 I believe its only templates that you have running at the time and connected to the internet that will get the update notice. So I only have sys-net, sys-firewall, usually running at boot. so those two templates will get checked first it seems. so one is fedora and one is debian. if one of them gets and update, I check the clones of them as well. On another note, it would be nice to get popups to desktop or taskbar for template updates, like when there is a dom0 update. I still resort to just keeping the qubes-manager onscreen at all times. (although alsso to look for yellow triangles if any). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/80e4f977-c6af-4065-bf03-eb57e9a167ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Attaching a USB printer scanner to Windows HVM via usbip (a workaround)
On Monday, January 23, 2017 at 3:28:47 AM UTC-5, daltong defourne wrote: > Hi! > I've managed to plug a USB printer/scanner into Windows HVM via usbip (as > workaround to current USB/PCI passthrough woes) > > Sharing with community: > https://github.com/QubesOS/qubes-issues/issues/2597#issuecomment-274347172 > > NB! This thing requires that you have networking between windows HVM and your > usbvm (or whatever the USB controller has been passed through to) can other appvms bet attacked by the usbvm after this setup? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/780d9374-1494-477b-87e8-bd7291d89731%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Chipping/Crackling noise on HDMI
On Sunday, January 22, 2017 at 6:03:16 AM UTC-5, FWM wrote: > Im running a HDMI cable from my GPU to my home theater system, and have set > the VM to use that Audio output. > > Unfortunately im getting a chipping/crackling noise. I never used to get this > noise using the same setup but running windows, so i dont think its the > hardware or cable. > > Any suggestions? There is also a pulseaudio line you can edit in a config file. I've had cracklings in the past, I'll try to google it for you. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/87d1a1a9-4d19-4410-b586-3915b7b18664%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: NVIDIA DRIVER and OPTIMUS
On Monday, January 23, 2017 at 6:28:13 AM UTC-7, nezn...@xy9ce.tk wrote: > > The only way is to use Nouveau. Problem with that is, Nouveau doesn't > > support new-ish GPUs without upgrading to kernels past the current Qubes > > supported kernels. So, nvidia owners are SOL with Qubes atm. > > What "SOL" is means? Btw thx for answer, m8 SOL = Shit out of luck It depends on which gpu you have - if it's supported in kernel 4.8.12-12 then you're good; that's the latest kernel version in the unstable repo. If not, you would need to compile it yourself which is a PITA and I'm not sure how exactly you'd do it. Gray -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/744e676b-0db1-4036-9207-16244a477113%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Linux HVM Cursor lag
On Monday, January 23, 2017 at 1:38:31 PM UTC+1, tech...@tutanota.com wrote: > I wanted to ask everyone using linux HVM's - or even booting a linux live CD > - do you get cursor lag? So far I have seen that in Kali. In fact, the cursor is not only slow, but the entire window moves about when I move the cursor. This has the main effect of moving away things I need to click on when moving the mouse, and the (bonus, I guess) side-effect of driving me crazy. Haven't bothered testing more yet, but will look into it in future. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3f9a6e8e-8c23-4d55-9d45-de7646cce99d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Redshift in dom0?
On Mon, Jan 23, 2017 at 06:52:47AM -0800, Andrew David Wong wrote: > > What's the best way to install something like Redshift in dom0? just install it like any other package in dom0… :) -- cheers, Holger -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170123150159.GC22748%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [qubes-users] Firewall Broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-01-22 12:55, Unman wrote: > On Sun, Jan 22, 2017 at 07:18:13PM +0100, qube...@tutanota.com wrote: >> Qubes 3.2 >> Have created new AppVM and within "firewall rules" restricted access using >> "deny access" to all websites [by leaving it blank] or just a single >> website. Bizarrely however,the firewall lets all traffic thro' >> Any ideas >> > > Do you have the qube connected to a firewall, or directly to sys-net? > Adding to this: If the VM is connected directly to sys-whonix, the same symptoms will occur. This is a known issue. > If the latter, then sys-net (by default) does not implement the Qubes > firewall. > > If the former, open a console in the firewall and look at the relevant > rules : > iptables -L -nv > Are there rules allowing the traffic from the relevant IP in the FORWARD > chain? > > Try changing the netvm for the relevant qube - make sure the iptables > rules change on the firewall. Then try reconnecting. > You can do this on command line using: > qvm-prefs netvm -s none > and > qvm-prefs netvm -s > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYhfryAAoJENtN07w5UDAwbxoP/2EmhcRJUwdgwyHMA/4rajAE w7rUuED0T29SizNRVQeZHgfFP5AYvhks2cY/9KTurvs1rvV6G7UdTOTHkAGcMypQ 9HHxwG8RMlDOTCFFulKd54oXM56+5HDtUFWUTAfx6jrPHl/FGjNSEv1GwTCSO5V8 hkDHoPfdppFI5zn+P0MLgEs4crXo6nNhqwDjn312ydCPnHLAdABj2X1pGeRrdomU HiB4rvElRtImURzV3jd2xi9zM2klF9xOFFyHS6JSWFo26QPifjmauHm3VUjBjCvp pQppmA62s2ztXoljv6CTAOwvR124nMuClxD8NKu1PpnpZ0ZpadoaesUw79tUfYUr Kroj8rThVP1go8vSzY/YyO2d0v3Z8jpR+iDXJ1amyCGLjEEkBXHPlHQNqs8vFmGk Uqiy3GvQGpDaI/LVHNuN2+MmfRKRSZ/1tnjtYvDf1dcl93EGBHKg/cO7XSdxaWF7 OaNUdHcZsylJbcJMNuZ/Z7ZGbhoK8wzBUAFXjTBgrnI1D2XjoGKydq7fqZncvUJG 128ip4MiMGpjvvjPzUYPqWaRvGgxk4dudDiPAW/RmmF5DcJZexIDVGmYz+9rlRoF TZYF4b8oGJ6CvLc0VyKn8KGaceg8igzq7X3x0xvKsg12WQJBTqIvMqgj96un39/z WRiTv5VWsyK7YgMeOo/l =V2SG -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5287f8ed-cce4-c563-13fa-99dabcb51245%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Random screen blackouts Qubes 3.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-01-22 02:43, FWM wrote: > So a problem im having is randomly it looks like the screen saver > will try come on, even though im typing or using the mouse. > > And even if i move the mouse the screen will stay black, and i have > to move mouse to the tool bar and click open windows, which will > remove the blackness only over that window. > > Seems very much like some kind of graphic bug. > > But its also the typo of glitchy thing that ive seen when > computers/GPUs get hot. > > Is this a know issue? Is there a tool i can use to monitor my > system temps? where should i install such tool? in dom0? > > Thanks > Sounds like it might be this (or related to this): https://github.com/QubesOS/qubes-issues/issues/2399 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYhfniAAoJENtN07w5UDAw0MsQAIK6ckZCW+gul6LEhX3TJt9Q kznXB59Ob7DZPSKAG06UzsuK9SF+rVHRiO7SW+BOE6mHeFmRYH6xkykeQa3nXecU 09j2j9JrtO349iFpc48crfLSAMF6qWv8A5fUy4X3NrxjhDtoyl4m85QYrMRjsUql 24m5KfTnL7CreZU2Gl4MX63ma7uGP4FzIBf1aXEPhpqAlc6rfsVnTUNbPDYfr8hx xzRlPPr6egWx+++fco9ZjLuR4iZhDpOtQOGGjv+ZkFS24ZK/4usURN93jHDLPGAU HEY3r1cKFxawtHHT94QzfgEtZjSHnukukcPcbe0cW+cbH1YmyqJE7mm4ggbRzwxc bXy4IYHUo4WoraM4gjkTcOeL8UvToef3TBWWhmvwZgmoR5xNet7NXiKBxrrjRO1M aGbVV++zwIJ8Ep+NJjZvYd9NBmDNd0o6m2sywty5S4dMwAAAbqruTm2RmeAW3xiO sGB7kCitmlpObd5IUfv9awe3N0fvsTA5m817hr3YwvR4Lj0Mnp8otI3a4ZeiYLv2 TECY26BMWl1YzXDMx1JoZjvrf36jRSnCWASm+2i/bDhZSnJOZqXHuICB+x7Qr4w1 sCx3cETUCk89AXgxkjhS5cbCRIO/OnFDAkicOppyW4e0XEdCo1gAjOUXxSCy/AZ5 4tG8ZZ/2+Ip+/yOHEMkN =SlWg -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/739007ce-4cfe-193a-46e9-ae9850baba32%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Linux HVM Cursor lag
Hi, I did post previously on the same topic but wanted to ask again in a more general way as I didn't get any solution. I wanted to ask everyone using linux HVM's - or even booting a linux live CD - do you get cursor lag? Every linux distro that I have tried as an HVM - installed or just booting an ISO - always gets really bad cursor lag. Is that normal??? I have tried on high-end laptops with 12-16GB ram - even with no other VM running. I always get the same lag. Is that the normal expected performance? All other PV vm's work perfectly - even a Windows 7 HVM - just linux HVM's have this lag. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KbAKQ4Q--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to view Youtube in Fullscreen ? (for dummies)
On Thursday, October 27, 2016 at 12:15:53 AM UTC+3, jamie wrote: > does not matter if I use fedora, debian or whonix ... whenever I press > fullscreen on any youtube video the brower freezes.. > > it also does not matter which browser I use firefox, chromium,... > all of them freeze. > > > how to watch youtube videos 'for dummies' in fullscreen ? > how to enable fullscreen mode 'for dummies' in my fedora appVM ? Right click on window border, choose fullscreen The browser window goes fullscreen NOW press the video's fullscreen button The video will now go into fullscreen on a fullscreen window and all will be right with the world. P.S.: If you're running on intel IGFX, it may require some annoying tuning to get youtube working "just right" (without tearing, etc) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5e29411d-de9e-4198-98b8-89819cc51fb0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NetVM without firewall, no PING from outside?
Unman: > I suggest you read the docs: > www.qubes-os.org/doc/firewall has a section on allowing traffic in to > qubes. Thank you for the link. It provided a good foundation. > But this may not be what you want. It reads as if you want to have > sys-net operating as a router. You can do this quite simply by changing > the iptables configuration and using proxy arp to make sure that the > external network sees the qubes behind the router. > Alternatively you could use the netvm as a gateway to the network of > qubes, and make sure that THAT route is propagated on your internal > network. Thank you, it seems like using proxy arp is the way to go for me. That way I can still use a dynamic address for my NetVM. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8cee4116-fa0b-46b1-9c88-d71aadf00b3b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Attaching a USB printer scanner to Windows HVM via usbip (a workaround)
Hi! I've managed to plug a USB printer/scanner into Windows HVM via usbip (as workaround to current USB/PCI passthrough woes) Sharing with community: https://github.com/QubesOS/qubes-issues/issues/2597#issuecomment-274347172 NB! This thing requires that you have networking between windows HVM and your usbvm (or whatever the USB controller has been passed through to) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f56bb866-8565-43e0-b34c-c966e3ed8969%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Lenovo x230 Laptop vs. Lenovo x230t Tablet on Qubes R3.2
It is a decent choice, you can install a better screen from alibaba and the better keyboard from the x220 if you dont like an island style keyboard. On 01/22/2017 06:11 PM, knaoxf...@gmail.com wrote: I'm looking into getting a budget laptop around $100-$250 for Qubes R3.2. I've heard good things about the x220 and x230. Although I have a question that I havent been able to find answered. My question is has anyone installed on the tablet version of those and is there any difficulties with that verse the laptop variant? I've seen that the specs are similiar, but wasn't sure about the periphereals like the keyboard and trackpad. If you have any suggestions for laptops in that price range, that would help. Thank you. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b3e33327-7d7a-249b-b089-25a3d29dc8c2%40gmx.com. For more options, visit https://groups.google.com/d/optout.
