[qubes-users] Re: qubes-template-debian-7 missing?

2016-10-19 Thread miguel . jacq
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?

2016-10-19 Thread miguel . jacq
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

2016-10-19 Thread raahelps
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)

2016-10-19 Thread raahelps
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

2016-10-19 Thread raahelps
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)

2016-10-19 Thread Jeremy Rand
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

2016-10-19 Thread Jeremy Rand
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

2016-10-19 Thread johnyjukya
> 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

2016-10-19 Thread johnyjukya
> 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

2016-10-19 Thread volodatrahorenko
среда, 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

2016-10-19 Thread David Hobach

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

2016-10-19 Thread johnyjukya
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

2016-10-19 Thread Connor Page
контроллер 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

2016-10-19 Thread volodatrahorenko
я ввел команду на удаление 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.