[qubes-users] Re: qubes-template-debian-7 missing?
Looks indeed like it is missing from http://yum.qubes-os.org/r3.1/templates-itl/rpm/ but is present in 3.0 at http://yum.qubes-os.org/r3.0/templates-itl/rpm/ Docs probably need updating if this was deliberate. A shame as Debian 7 still gets 'long term support' security updates so would still be good to keep around for a while longer. -- 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/af994b6f-e551-47f6-b636-a986c1313582%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes-template-debian-7 missing?
Hi, I'm trying to install the Debian 7 (Wheezy) template on Qubes 3.1. Per https://www.qubes-os.org/doc/templates/debian I run: sudo qubes-dom0-update qubes-template-debian-7 The result I get is No Match for argument qubes-template-debian7 Nothing to download Has the template disappeared? My /etc/yum.repos.d/qubes-templates.repo shows both [qubes-templates-itl] and [qubes-templates-community] as being enabled. Thanks Mig -- 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/02196ef6-d6bd-4846-bd85-3b817641fd1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM
On Monday, October 17, 2016 at 11:43:26 AM UTC-4, Robert Mittendorf wrote: > > The data copied to that VM (i.e. the pdf file or whatever you opened) > > must be considered leaked if the VM gets compromised via e.g. drive-by > > exploits. > > Agreed, it's limited to that data, but nevertheless an unexpected > > potential impact. And depending on your data it can be critical. > Well, that is why it is a distinct DispVM. If I open a legit PDF from my > mail client in a DispVM (say dispvm1) and I open a non-legit URL in a > DispVM, this will not be the same dispVM and thereby not leak the PDFs > data. If the PDF itself is malicious, I most likely will not care about > the leak. Only exception: A legit PDF gets infected and is then mailed > to me. Usually that would allow the attacker to leak the PDF from the > system it was send from in the first place. > > From a usability point of view you'll also get annoyed if you cannot > > print in dispVMs just because your firewall rules allowing > > connectivity to your printer aren't inherited, but those to allowing > > connectivity to the internet suddenly are in place. > agreed, basically. > > > > Btw inheriting netVMs makes a lot of sense if you imagine one Tor > > proxy VM and one directly connected one. So a dispVM from a Tor > > connected VM would spawn a direct internet connection in your case... > > Currently it fortunately does not. > agreed. > > Well, I was actually suprised that there is more than 1 DispVM. Do the > child-DispVMs use the fedora-23-dvm template as well? oh yes thats a good point. thats another reason I liked to create dispvm menu entries in the applications list,to also inherit that vm's window border color that they are launched from. To remind me what level trust it is. -- 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/257d4379-fcc6-46d8-b93a-7f4b5f555e66%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 3.2 - Missing prompt: 'Edit Applications' - Problem creating Whonix Disposable vm (dvm)
On Saturday, October 15, 2016 at 5:49:28 AM UTC-4, qer...@tutanota.com wrote: > I am following this guide: > > > > > https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461 > > I have created the whonix-ws dvm template but am unable to create a usable > dvm like in the aforementioned guide, primarily because there is no 'edit > applications' prompt and I have not been able to discover the new way of > editing applications. Is there a way to edit applications like in 3.1 or must > a different process be followed to create whonix-ws dvm for tor browsing? > > > -- > > > Securely sent with Tutanota. Claim your encrypted mailbox today! > > > https://tutanota.com I'm not sure this is what you mean, but to edit start menu items, you hit alt + f3 in xfce. -- 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/36f8582f-4bf5-48ad-806a-68b38ae5ad82%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 3.1 Installer Hangs on Creating default DisposableVM
On Tuesday, October 18, 2016 at 11:27:00 PM UTC-4, ad...@roughshod.net wrote: > Oops, subject should read 3.2 not 3.1 Have you tried to install without creating any default vms? I believe that is an option, then you can try to set up your vms manually afterwards. -- 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/ee3dd119-6d33-4109-b7e9-d44f65828521%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 - Missing prompt: 'Edit Applications' - Problem creating Whonix Disposable vm (dvm)
qer...@tutanota.com: > > I am following this guide: > > > > > https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm/2461 > > > > I have created the whonix-ws dvm template but am unable to create a usable > dvm like in the aforementioned guide, primarily because there is no 'edit > applications' prompt and I have not been able to discover the new way of > editing applications. Is there a way to edit applications like in 3.1 or must > a different process be followed to create whonix-ws dvm for tor browsing? Hi, Might this be a KDE/XFCE difference? I'm using KDE with Qubes 3.2 and the "Edit Applications..." option is present for me. Cheers, -Jeremy -- 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/72c4ca1e-6a6f-89ca-694c-7875bdfe1e72%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] philosofy on qubes and other environment
pleom...@gmail.com: > philosofy of qubes is that you are safe when your app is isolatet.This is > wrong just keep app in sandboxes or jails and what wrong can be happen? Thanks for the spamfest. Looks like my null-routed email address list finally has someone other than Drew in it. Next time you feel tempted to send a ridiculous number of 1-line emails to a mailing list, please don't. There are those of us who actually have useful things to be doing. Cheers, -Jeremy -- 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/eb16d477-fcd5-117e-d26d-24d29a0e079e%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] swappiness, caches
> Interesting that the Wiki page for swappiness (this kernel parameter is > officially more famous than I am) recommends setting it to at least 1. > > https://en.wikipedia.org/wiki/Swappiness I'm going to stick with vm.swappiness=0 for a few days just to see if any reliability problems or app failures do pop up, out of curiosity. I think a setting of 1 (or at least <10) is probably best for the long run, letting some very infrequently used stuff creep off to swap. -- 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/87ef6832599ed40108b3708ea2ee3580.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] swappiness, caches
> Interesting, sounds reasonable. > > Running with absolutely 0 swap however can lead to unexpected problems > from my experience: Interesting that the Wiki page for swappiness (this kernel parameter is officially more famous and I am) recommends setting it to at least 1. https://en.wikipedia.org/wiki/Swappiness More on the vm.swapiness parameter. It's a bit more subtle than I thought. Some references: 1) http://askubuntu.com/questions/103915/how-do-i-configure-swappiness This page describes it as being how prone Linux is to start swapping out processes. At 0, nothing will be swapped until memory is fully exhausted; at 100, swapping out of processes will begin almost immediately. It indicates the default setting of 60 means swapping will start when memory is around "half" full. So a setting of zero doesn't prevent swapping, it just puts it off until there is no memory available. This is the old-school Unix behaviour I'm used to, and probably best for VM. 2) http://unix.stackexchange.com/questions/88693/why-is-swappiness-set-to-60-by-default This page talks about it in relation to choosing pages with backing store (programs, libraries, cached/mem-mapped data files, already-swapped data) vs. "anonymous" pages of allocated memory. Cached files have a weight of 200-vm.swappiness, and anonymous pages a weight of vm.swapiness. That may be saying the same thing as #1 but in a different; possibly more prescise way, since a setting of 100 gives a 50/50 weight for new page acquisition betreen swap and cache. 3) http://www.cloudibee.com/linux-performance-tuning-vm-swappiness/ This one talks about it as a balance between "swapping and freeing cache," which is the same, I think. - Any anonymous page is going to need to be written to swap before being given to the VM needing memory. (As well as a read when the page is used in the future.) And writes are usually more expensive than reads to start with. A cached file/program/library doesn't need to be written, the page can be discarded and re-used immediately since it can be retrieved from the backing file/program/library when needed in the future. Having a swap/anon page swapped and retrieved has a cost of 1w+1r Having a file/prog page discarded and later retrieved has a cost of 1r. So swapping has a r/w cost of at least 2x that of stealing from the file-backed cache. (Writes are usually a bit more costly than reads, as well.) Obviously the nature of your machine (server/desktop) affects things. That 60 default setting means file-backed cached pages have a weight of 200-60, or 140, while the anonymous/to-be-swapped pages have a weight of 60, a 70%/30% balance in favour of resuing file-backed cached pages versus swapping something out to get free pages. Not a bad compromise for running on bare hardware, or a server; but not appropriate/necessary for a VM. With vm.swappiness set to 0 and the same swap space as before, swap can get used when needed; and as much as before, but not until memory is exhausted. And when the free memory is exhausted, that also implies that all of the cache has also been re-allocated as assigned memory as well. Since the VM's really shouldn't be caching in the first place (double-caching in both dom0 and the VM has to be slower than just one level of cache). I'm still looking around for options to disable file caching, but having vm.swappiness low at least gives any running program priority over the memory being used as cache. The qmemman load balancer won't consider the memory used for a VM's cache as part of it's "required" memory (but it does include swapped out stuff, giving it reasonable chance of getting back into memory without thrashing), so with low vm.swapiness a VM will not be given extra memory to maintain any significant level of cache, unless there's free memory around to be doled out between VM's overall. I can't help but think the original intent was for vm.swappiness=0 behaviour. Once vm.swappiness is >0, then some level swapping will occur resulting in free pages for the VM, and Linux will then go and use these pages for additional (and unnecessary) cache space; an all-around waste of disk-access, CPU time, memory. Running with vm.swappiness=0 seems to work in practice so far. I'm still amazed at the difference in memory/performance I'm seeing. Zero swap on a system that used to have 40M-ish swapped on all VM's and in dom0. And smaller VM's, allowing more to be started. I'm surprised that this hasn't been a default, or at least some similar tuning done by default. In the source code, the 350M "dom0 memory boost" is mentioned as being specifically to give dom0 free memory (that will inherently be used as cache) beyond its actual needs (used memory+used swap). So there is intent to let dom0 do the file caching. But not a similar effort to prevent unnecessary caching in the VM's. Also, it's worth verifying the benefitting from a low vm.swappiness in dom0 itself. Swapping can
[qubes-users] Re: проблемы с установкой usb wi-fi адаптера rtl8188eus
среда, 19 октября 2016 г., 14:32:36 UTC+3 пользователь Connor Page написал: > контроллер usb должен быть в той же виртуальной машине. > please use English on this mailing list. я просто хочу установить rtl8188eu в templateVM fedora-22. дохожу до команды в терминале : sudo make install и мне выдает ошибку , что у меня нет прав чтоб создать простой файл... и что файловая система доступна только для чтения. Что мне делать? -- 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/46aa57a8-a91a-4e22-a431-17d1588853df%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] swappiness, caches
On 10/19/2016 05:54 PM, johnyju...@sigaint.org wrote: It always seemed a bit "off" to me that there should be any swap usage or significant buffers/caches inside VM's. dom0 already caches the virtual .img files, so having the kernel inside each VM also buffering/caching files and metadata is really just a waste of CPU and disk space. More importantly, swap activity is a major performance killer on bare hardware; even more so on a virtual machine. There's a case to let some stuff swap out (unused x-servers in sys-net/sys-firewall, etc.) but the default is way too aggressive for good performance, IMHO. The kernel has a "vm.swappiness" (0 to 100) parameter that controls the balance between grabbing a new free page from the cache or swapping a page out to re-use. The default is 60, which leans towards swapping instead of cache use. Not ideal. In dom0 and all my VM's, I tried changing the swappiness factor to see what the effect would be: # echo 0 >/proc/sys/vm/swappiness or $ sudo sysctl -w vm.swappiness=0 To empty existing swap space, I did a "swapoff -av && swapon -av" Performance is noticeably better, with no swapping happening in any of the VM's, nor in dom0. And memory usage reported by the Vm's seems to be smaller; a heavy browsing session used to crank a VM up to 1.5G; now it seems to be more like 800M. So I can run more VM's, get more done. (I'm not sure why this is, but firefox seems to be less of a memory pig with this change. Maybe with the former aggressive swapping out, Firefox thought free memory was a bit cheaper than it is, and was more aggressive in its own use, or more lax in freeing things up. With a more realistic picture of the memory situation, by changing vm.swappiness to 0, it doesn't seem to be quite the pig it was.) You can set the parameter permanently by adding "vm.swappiness=0" to /etc/sysctl.conf in dom0 and your templates. Poking around 'net, I see a few comments where 0 swappiness is best for guest VM's. I wonder if a little higher might not be bad, for the case of an unused X server or whatever, being able to swap out. I might play a bit with different settings in different VM's. It would be nice to disable caching in the VM's, but that seems to be a difficult thing to do in Linux. So far I've found that the system is pretty good about keeping the VM size to the minimum/startup size, and giving up buffers/cache when needed. (buffers/cache aren't included in the 'memory-used' calculation when mem-balancing between VM's, which keeps the buffers/cache under control a bit, I think. Excessive cache use is not given weight and rewarded by additional memory in the balancing. Any real memory needs from an existing or new VM would effectively take priority over buffer space, in the memory balancing allocations.) Real quick and dirty way of checking your swap usage across VM's (I might add this info to the VM manager for fun, since it's pretty critical performance information; will submit any changes): $ sudo xenstore-ls -f /local/domain | awk '/meminfo/ { print $12-$14, $1 }' The # reported in the path is the domid, which you can see with "qvm-ls -i" I'd be interested in hearing others' thoughts on this. Related reading: https://www.xenproject.org/directory/directory/research/118-geiger-monitoring-the-buffer-cache-in-a-virtual-machine-envrionement.html http://www.sersc.org/journals/IJCA/vol6_no1/12.pdf Interesting, sounds reasonable. Running with absolutely 0 swap however can lead to unexpected problems from my experience: Some applications (e.g. firefox downloads the last time I tested it) use memory-mapped files of arbitrary size assuming swapping is enabled, i.e. you'll store the entire files in memory without swapping. If however the files are getting too large (say you download a multi Gig file via firefox), your memory will run out and the application will report an error (firefox will cancel the download due to a write error). Most applications work though and reducing the swap size to an absolute minimum certainly helps to improve speed. -- 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/2efe4523-86f1-02a9-4a7a-313bc1a0733a%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] swappiness, caches
It always seemed a bit "off" to me that there should be any swap usage or significant buffers/caches inside VM's. dom0 already caches the virtual .img files, so having the kernel inside each VM also buffering/caching files and metadata is really just a waste of CPU and disk space. More importantly, swap activity is a major performance killer on bare hardware; even more so on a virtual machine. There's a case to let some stuff swap out (unused x-servers in sys-net/sys-firewall, etc.) but the default is way too aggressive for good performance, IMHO. The kernel has a "vm.swappiness" (0 to 100) parameter that controls the balance between grabbing a new free page from the cache or swapping a page out to re-use. The default is 60, which leans towards swapping instead of cache use. Not ideal. In dom0 and all my VM's, I tried changing the swappiness factor to see what the effect would be: # echo 0 >/proc/sys/vm/swappiness or $ sudo sysctl -w vm.swappiness=0 To empty existing swap space, I did a "swapoff -av && swapon -av" Performance is noticeably better, with no swapping happening in any of the VM's, nor in dom0. And memory usage reported by the Vm's seems to be smaller; a heavy browsing session used to crank a VM up to 1.5G; now it seems to be more like 800M. So I can run more VM's, get more done. (I'm not sure why this is, but firefox seems to be less of a memory pig with this change. Maybe with the former aggressive swapping out, Firefox thought free memory was a bit cheaper than it is, and was more aggressive in its own use, or more lax in freeing things up. With a more realistic picture of the memory situation, by changing vm.swappiness to 0, it doesn't seem to be quite the pig it was.) You can set the parameter permanently by adding "vm.swappiness=0" to /etc/sysctl.conf in dom0 and your templates. Poking around 'net, I see a few comments where 0 swappiness is best for guest VM's. I wonder if a little higher might not be bad, for the case of an unused X server or whatever, being able to swap out. I might play a bit with different settings in different VM's. It would be nice to disable caching in the VM's, but that seems to be a difficult thing to do in Linux. So far I've found that the system is pretty good about keeping the VM size to the minimum/startup size, and giving up buffers/cache when needed. (buffers/cache aren't included in the 'memory-used' calculation when mem-balancing between VM's, which keeps the buffers/cache under control a bit, I think. Excessive cache use is not given weight and rewarded by additional memory in the balancing. Any real memory needs from an existing or new VM would effectively take priority over buffer space, in the memory balancing allocations.) Real quick and dirty way of checking your swap usage across VM's (I might add this info to the VM manager for fun, since it's pretty critical performance information; will submit any changes): $ sudo xenstore-ls -f /local/domain | awk '/meminfo/ { print $12-$14, $1 }' The # reported in the path is the domid, which you can see with "qvm-ls -i" I'd be interested in hearing others' thoughts on this. Related reading: https://www.xenproject.org/directory/directory/research/118-geiger-monitoring-the-buffer-cache-in-a-virtual-machine-envrionement.html http://www.sersc.org/journals/IJCA/vol6_no1/12.pdf Cheers JJ -- 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/7cc1093b43c2e02d8712b9d67d6341fe.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
[qubes-users] проблемы с установкой usb wi-fi адаптера rtl8188eus
контроллер usb должен быть в той же виртуальной машине. please use English on this mailing list. -- 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/0848d9f3-95bf-446b-b95c-9ac520843ef4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] super-bag
я ввел команду на удаление template debian 9, а вместо него удалились все другие VM, а дебиан 9 остался невредим!что делать??? -- 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/2a4a67a6-607b-411f-8978-138dee724559%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.