[qubes-users] Updating WiFi Drivers

[flaviosanchez]

Hello. How do I make changes to this path "/usr/lib/modules/(uname 
-r)/kernel/drivers/net/wireless"? I would like to place lwfinger's compiled 
driver (https://github.com/lwfinger/rtl8188eu) in that directory to get my NIC 
card to work properly.

-- 
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/c36cca0e-0db2-4648-9eed-863fa102a121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Anyone disabled the Intel ME yet?

[filtration]

cooloutac:
> On Sunday, September 24, 2017 at 8:24:44 PM UTC-4, cooloutac wrote:
>> On Thursday, September 21, 2017 at 12:08:41 PM UTC-4, Hugo Costa wrote:
>>> On Thursday, 21 September 2017 07:23:01 UTC+1, Alex  wrote:
 Replying to this thread to report that somebody DID ACTUALLY find an
 exploitable vulnerability in the latest IME 11+, and they will be
 sharing nothing less that this UNSIGNED CODE EXECUTION vuln at blackhat
 europe 2017.

 Abstract here:
 https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668

 Title is pretty scary, but we'll see if it's actually that dangerous

 -- 
 Alex
>>>
>>> Was going to post the same. 2 Russian researchers that a couple weeks ago 
>>> found out a way to clean some modules on Intel ME now have found a 
>>> significative exploit that allows them to actually run code on a piece of 
>>> hardware with direct access to the network. The scary thing is - it's 
>>> impossible to detect.
>>
>> and thats prolly just what we know about lol.
> 
> I feel like cause I live in nyc that you just expect this type of stuff from 
> your friends and neighbors hahaha.  maybe not the same means but the same 
> ends.  but ya hardware level stuff is scary,  cause that means real security 
> means alot of money, so poor people are screwed.
> 

My motherboard has a "Disable ME" jumper. Not good enough for many of
you, I know.

As far as AMT, apparently the entry is through Intel NICs. I hoped to
mitigate it by using a third party NIC. The Intel device stayed lit
(amber, not green) on power off, my new one is completely off when
powered off.

-- 
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/c6467dfa-2bb1-e0ec-8b3a-f433d228332a%40posteo.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anyone disabled the Intel ME yet?

[cooloutac]

On Sunday, September 24, 2017 at 8:24:44 PM UTC-4, cooloutac wrote:
> On Thursday, September 21, 2017 at 12:08:41 PM UTC-4, Hugo Costa wrote:
> > On Thursday, 21 September 2017 07:23:01 UTC+1, Alex  wrote:
> > > Replying to this thread to report that somebody DID ACTUALLY find an
> > > exploitable vulnerability in the latest IME 11+, and they will be
> > > sharing nothing less that this UNSIGNED CODE EXECUTION vuln at blackhat
> > > europe 2017.
> > > 
> > > Abstract here:
> > > https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668
> > > 
> > > Title is pretty scary, but we'll see if it's actually that dangerous...
> > > 
> > > -- 
> > > Alex
> > 
> > Was going to post the same. 2 Russian researchers that a couple weeks ago 
> > found out a way to clean some modules on Intel ME now have found a 
> > significative exploit that allows them to actually run code on a piece of 
> > hardware with direct access to the network. The scary thing is - it's 
> > impossible to detect.
> 
> and thats prolly just what we know about lol.

I feel like cause I live in nyc that you just expect this type of stuff from 
your friends and neighbors hahaha.  maybe not the same means but the same ends. 
 but ya hardware level stuff is scary,  cause that means real security means 
alot of money, so poor people are screwed.

-- 
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/758bb5df-6fa7-4b27-8aa8-ae4ef2bf52d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anyone disabled the Intel ME yet?

[cooloutac]

On Thursday, September 21, 2017 at 12:08:41 PM UTC-4, Hugo Costa wrote:
> On Thursday, 21 September 2017 07:23:01 UTC+1, Alex  wrote:
> > Replying to this thread to report that somebody DID ACTUALLY find an
> > exploitable vulnerability in the latest IME 11+, and they will be
> > sharing nothing less that this UNSIGNED CODE EXECUTION vuln at blackhat
> > europe 2017.
> > 
> > Abstract here:
> > https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668
> > 
> > Title is pretty scary, but we'll see if it's actually that dangerous...
> > 
> > -- 
> > Alex
> 
> Was going to post the same. 2 Russian researchers that a couple weeks ago 
> found out a way to clean some modules on Intel ME now have found a 
> significative exploit that allows them to actually run code on a piece of 
> hardware with direct access to the network. The scary thing is - it's 
> impossible to detect.

and thats prolly just what we know about lol.

-- 
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/c993f589-1ef2-40d3-823e-88f6de5313ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix

[cooloutac]

On Sunday, September 24, 2017 at 3:59:28 PM UTC-4, Person wrote:
> It seems that the VMs have already been replaced. Which is good considering 
> that then I don't need to delete the old templates. 
> 
> However, the system didn't automatically give me an anon-Whonix or sys-Whonix 
> templates, so I tried making some for myself. (I'm not sure if there is a 
> easier or better way to get the templates, if there is, please inform me.) 
> 
> I tried to download Tor Browser on Whonix-ws, and it doesn't work. My 
> internet connectivity and Whonix VMs are working fine, but there is an error 
> because "Tor could not connect to the Tor control port". 
> 
> Specifically, the error I saw was this: http://imgur.com/eQWNgcf.

whonix already comes with tor browser.

-- 
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/44cf4a24-b70a-4c40-aa27-d75ed6bf8e24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix

[Person]

It seems that the VMs have already been replaced. Which is good considering 
that then I don't need to delete the old templates. 

However, the system didn't automatically give me an anon-Whonix or sys-Whonix 
templates, so I tried making some for myself. (I'm not sure if there is a 
easier or better way to get the templates, if there is, please inform me.) 

I tried to download Tor Browser on Whonix-ws, and it doesn't work. My internet 
connectivity and Whonix VMs are working fine, but there is an error because 
"Tor could not connect to the Tor control port". 

Specifically, the error I saw was this: http://imgur.com/eQWNgcf. 

-- 
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/b3019cc1-547c-499c-bbf4-42811c05755d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uninstall or reinstall Whonix

[cooloutac]

On Saturday, September 23, 2017 at 10:31:08 PM UTC-4, Person wrote:
> You were correct (thank you so much!). Apparently I set the Update VM to 
> "none" in the Global Settings, so it didn't work. Now installing Whonix works 
> fine.
> 
> However, uninstalling the old templates still does not work. The dom0 
> terminal only replies with "No match for argument: qubes-template-whonix-gw" 
> and "Error: No packages marked for removal". Although I assume as I am 
> already starting to reinstall Whonix, the old templates won't matter as much.

https://www.qubes-os.org/doc/remove-vm-manually/  try these steps.

-- 
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/8b40f460-1fcf-4f27-be27-041a5ad3a596%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to recover Qubes when keyboard / mice is dysfunctional due to USB qube setup issues?

[cooloutac]

On Sunday, September 24, 2017 at 12:23:23 PM UTC-4, cooloutac wrote:
> On Sunday, September 24, 2017 at 9:25:24 AM UTC-4, Patrick Schleizer wrote:
> > Quote from https://www.qubes-os.org/doc/usb/
> > 
> > > Caution: By assigning a USB controller to a USB qube, it will no
> > longer be available to dom0. This can make your system unusable if, for
> > example, you have only one USB controller, and you are running Qubes off
> > of a USB drive.
> > 
> > How can one recover from such a situation if there is no PS2
> > keyboard/mice available?
> > 
> > I guess... Unless there is a better way...? Boot the system using from
> > an external disk using a USB recovery operating system... Then modify
> > the local disk (with broken Qubes)... Then do what?
> > 
> > Cheers,
> > Patrick
> 
> ya that. exactly.

that would be the only way I would know of.

-- 
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/f03bd62f-c453-4e2a-85f6-6f27ee6f3af4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to recover Qubes when keyboard / mice is dysfunctional due to USB qube setup issues?

[cooloutac]

On Sunday, September 24, 2017 at 9:25:24 AM UTC-4, Patrick Schleizer wrote:
> Quote from https://www.qubes-os.org/doc/usb/
> 
> > Caution: By assigning a USB controller to a USB qube, it will no
> longer be available to dom0. This can make your system unusable if, for
> example, you have only one USB controller, and you are running Qubes off
> of a USB drive.
> 
> How can one recover from such a situation if there is no PS2
> keyboard/mice available?
> 
> I guess... Unless there is a better way...? Boot the system using from
> an external disk using a USB recovery operating system... Then modify
> the local disk (with broken Qubes)... Then do what?
> 
> Cheers,
> Patrick

ya that. exactly.

-- 
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/e92fd8ca-2bd3-48ef-8db4-89562883ea36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Has anyone tried to activate SELINUX in Fedora 25?

[cooloutac]

On Sunday, September 24, 2017 at 12:17:33 PM UTC-4, cooloutac wrote:
> On Sunday, September 24, 2017 at 12:16:34 PM UTC-4, cooloutac wrote:
> > On Thursday, September 21, 2017 at 4:40:42 AM UTC-4, pels wrote:
> > > On Wednesday, September 20, 2017 at 2:54:31 PM UTC+2, cooloutac wrote:
> > > > On Wednesday, September 20, 2017 at 4:41:58 AM UTC-4, pels wrote:
> > > > > I'd like to activate SELINUX(enforcing) in VMs (f25 and f25-minimal), 
> > > > > but fails:
> > > > > 
> > > > > [1.510532] audit: type=1404 audit(1505894636.317:2): enforcing=1 
> > > > > old_enforcing=0 auid=4294967295 ses=4294967295
> > > > > [1.601491] audit: type=1403 audit(1505894636.408:3): policy 
> > > > > loaded auid=4294967295 ses=4294967295
> > > > > [1.605815] systemd[1]: Successfully loaded SELinux policy in 
> > > > > 95.611ms.
> > > > > [1.617897] systemd[1]: Failed to mount tmpfs at /run: Permission 
> > > > > denied
> > > > > [.[0;1;31m!!.[0m] Failed to mount API filesystems, freezing.
> > > > > [1.621206] systemd[1]: Freezing execution.
> > > > > 
> > > > > I had it enabled  in fedora 24 but after upgrading failed
> > > > > I create a new template (f25 and f25-minimal) with same effect.
> > > > > 
> > > > > I have tried to reset SELinux to its initial state:
> > > > > yum remove selinux-policy
> > > > > rm -rf /etc/selinux
> > > > > yum install selinux-policy-targeted
> > > > > fixfiles -f -F relabel
> > > > > reboot
> > > > > 
> > > > > Any ideas?
> > > > > 
> > > > > Thank you very much
> > > > > 
> > > > > Best Regards
> > > >   
> > > >   Is this a vm, if so do we really care if systemd is running in it?   
> > > > You sure thats selinux?  what does sestatus say? 
> > > > 
> > > > When googling this error seems people have same issue when running 
> > > > docker.  And you have to set seccomp to unconfined.
> > > 
> > > Thank you cooloutac
> > > 
> > > -Is this a vm
> > > It happens in Templates and VMs.
> > > 
> > > -Is this a vm, if so do we really care if systemd is running in it?
> > > The problem is when i enable SELINUX VMs/templates doesn't "boot" or fail 
> > > to start. 
> > > If I disable SELINUX, the templates/VMs start whithout problems and 
> > > systemd is activated.
> > > 
> > > -You sure thats selinux?
> > > Yes i'm pretty sure, it's exactly the same config that i had in fedora24.
> > > In dom0
> > > qvm-prefs -s fedora-25 kernelopts "nopat security=selinux selinux=1"
> > > and in VMs/Templats
> > > /etc/selinux/config
> > > 
> > > SELINUX=enforcing 
> > > SELINUXTYPE=targeted
> > > 
> > > Default selinux config
> > > 
> > > -what does sestatus say?
> > > I can't execute anything in template/VMs 
> > > in dom0:
> > > qvm-run fedora-25 --nogui -pass-io -u root "sestatus"
> > > Error(fedora-25): Domain 'fedora-25':qreexec not connected
> > > 
> > > -When googling this error seems people have same issue when running 
> > > docker.  And you have to set seccomp to unconfined
> > > 
> > > Yes, i've read it, but i don't know how disable seccomp and the 
> > > consequences...
> > > 
> > > 
> > > Could you make me a big favour and try to activate SELINUX?
> > > 
> > > Thank you very much
> > > 
> > > Best regards
> > 
> > Probably only useful in the template vm.  But still not sure how beneficial 
> > it would be was my point though.  Its probably not compatible with qubes, 
> > sounds like it breaks qrexec, maybe not worth the headache man.
> 
> If they exploiting xen already I don't think it really matters at that point. 
>  But i'm far from an expert.

I'm sorry for spam,  but wanted to add an alternative option is use multiple 
template vms for installing diff untrusted software,  of course this requires 
more resources,  but Qubes in general requires more resources and specific 
capable hardware for best compatibility.

-- 
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/14d2a72a-cd51-43d8-87e9-cc8b14fee790%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Has anyone tried to activate SELINUX in Fedora 25?

[cooloutac]

On Sunday, September 24, 2017 at 12:16:34 PM UTC-4, cooloutac wrote:
> On Thursday, September 21, 2017 at 4:40:42 AM UTC-4, pels wrote:
> > On Wednesday, September 20, 2017 at 2:54:31 PM UTC+2, cooloutac wrote:
> > > On Wednesday, September 20, 2017 at 4:41:58 AM UTC-4, pels wrote:
> > > > I'd like to activate SELINUX(enforcing) in VMs (f25 and f25-minimal), 
> > > > but fails:
> > > > 
> > > > [1.510532] audit: type=1404 audit(1505894636.317:2): enforcing=1 
> > > > old_enforcing=0 auid=4294967295 ses=4294967295
> > > > [1.601491] audit: type=1403 audit(1505894636.408:3): policy loaded 
> > > > auid=4294967295 ses=4294967295
> > > > [1.605815] systemd[1]: Successfully loaded SELinux policy in 
> > > > 95.611ms.
> > > > [1.617897] systemd[1]: Failed to mount tmpfs at /run: Permission 
> > > > denied
> > > > [.[0;1;31m!!.[0m] Failed to mount API filesystems, freezing.
> > > > [1.621206] systemd[1]: Freezing execution.
> > > > 
> > > > I had it enabled  in fedora 24 but after upgrading failed
> > > > I create a new template (f25 and f25-minimal) with same effect.
> > > > 
> > > > I have tried to reset SELinux to its initial state:
> > > > yum remove selinux-policy
> > > > rm -rf /etc/selinux
> > > > yum install selinux-policy-targeted
> > > > fixfiles -f -F relabel
> > > > reboot
> > > > 
> > > > Any ideas?
> > > > 
> > > > Thank you very much
> > > > 
> > > > Best Regards
> > >   
> > >   Is this a vm, if so do we really care if systemd is running in it?   
> > > You sure thats selinux?  what does sestatus say? 
> > > 
> > > When googling this error seems people have same issue when running 
> > > docker.  And you have to set seccomp to unconfined.
> > 
> > Thank you cooloutac
> > 
> > -Is this a vm
> > It happens in Templates and VMs.
> > 
> > -Is this a vm, if so do we really care if systemd is running in it?
> > The problem is when i enable SELINUX VMs/templates doesn't "boot" or fail 
> > to start. 
> > If I disable SELINUX, the templates/VMs start whithout problems and systemd 
> > is activated.
> > 
> > -You sure thats selinux?
> > Yes i'm pretty sure, it's exactly the same config that i had in fedora24.
> > In dom0
> > qvm-prefs -s fedora-25 kernelopts "nopat security=selinux selinux=1"
> > and in VMs/Templats
> > /etc/selinux/config
> > 
> > SELINUX=enforcing 
> > SELINUXTYPE=targeted
> > 
> > Default selinux config
> > 
> > -what does sestatus say?
> > I can't execute anything in template/VMs 
> > in dom0:
> > qvm-run fedora-25 --nogui -pass-io -u root "sestatus"
> > Error(fedora-25): Domain 'fedora-25':qreexec not connected
> > 
> > -When googling this error seems people have same issue when running docker. 
> >  And you have to set seccomp to unconfined
> > 
> > Yes, i've read it, but i don't know how disable seccomp and the 
> > consequences...
> > 
> > 
> > Could you make me a big favour and try to activate SELINUX?
> > 
> > Thank you very much
> > 
> > Best regards
> 
> Probably only useful in the template vm.  But still not sure how beneficial 
> it would be was my point though.  Its probably not compatible with qubes, 
> sounds like it breaks qrexec, maybe not worth the headache man.

If they exploiting xen already I don't think it really matters at that point.  
But i'm far from an expert.

-- 
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/68aa364e-53ad-4dad-b33b-0d957851c57e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Painless USB attach/detach

[Sean Hunter]

> On 24 Sep 2017, at 14:26, Yethal  wrote:
> 
> W dniu niedziela, 24 września 2017 15:03:45 UTC+2 użytkownik Sean Hunter 
> napisał:
>> Yeah. Grep | cut -f1 from that script is similar to the awk line I use 
>> except that I also only print the first match (if there are multiple 
>> matches) whereas that script will print all of them which I think will cause 
>> problems if you have a device attached multiple timex. 
>> 
>> Sent from my phone. Sorry if brief. 
>> 
>>> On 24 Sep 2017, at 13:44, Yethal  wrote:
>>> 
>>> W dniu niedziela, 24 września 2017 13:45:19 UTC+2 użytkownik Sean Hunter 
>>> napisał:
 
 [sean@dom0 ~]# qvm-usb
 BACKEND:DEVID DESCRIPTIONUSED BY
 fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
 p:1-1 QEMU_QEMU_USB_Tablet_42
 sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
 sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  
 sys-usb:1-6   0489_e076  
 vault:1-1 QEMU_QEMU_USB_Tablet_42
 
> 
> For that to happen I'd have to have more than one device greppable using the 
> same keyword (or regex) right?
> 

Yes that’s the case for the touchpad on my laptop for instance as you can see 
above. It’s built-in but usb-attached apparently.  Any case both my script and 
the other one are about the sane for most practical use cases I would think. No 
reason to switch if its working well. 

Cheers,

Sean


-- 
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/E4F5C397-361F-4A18-AAB9-21BD7CD724BE%40uncarved.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Painless USB attach/detach

[Yethal]

W dniu niedziela, 24 września 2017 15:03:45 UTC+2 użytkownik Sean Hunter 
napisał:
> Yeah. Grep | cut -f1 from that script is similar to the awk line I use except 
> that I also only print the first match (if there are multiple matches) 
> whereas that script will print all of them which I think will cause problems 
> if you have a device attached multiple timex. 
> 
> Sent from my phone. Sorry if brief. 
> 
> > On 24 Sep 2017, at 13:44, Yethal  wrote:
> > 
> > W dniu niedziela, 24 września 2017 13:45:19 UTC+2 użytkownik Sean Hunter 
> > napisał:
> >> Hey there,
> >> 
> >> I was trying out attaching usb devices to qubes and thought this might be 
> >> useful to other people. If you have a device with a complicated 
> >> description (eg a Yubikey) it can be a pain to figure out what device ID 
> >> it's being attached to in sys-usb so you can use qvm-usb attach to send it 
> >> to an AppVM.
> >> [sean@dom0 ~]# qvm-usb
> >> BACKEND:DEVID DESCRIPTIONUSED BY
> >> fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
> >> p:1-1 QEMU_QEMU_USB_Tablet_42
> >> sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
> >> sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  
> >> sys-usb:1-6   0489_e076  
> >> vault:1-1 QEMU_QEMU_USB_Tablet_42
> >> 
> >> Typing qvm-usb, looking down for where my Yubikey is, then looking accross 
> >> for the sys-usb:1-3 next to it, then typing qvm-usb attach somevm 
> >> sys-usb:1-3 will get pretty old pretty fast.
> >> 
> >> Luckily, unix is awesome. I have created a couple of small shell functions 
> >> which search the output of qvm-usb on the description and attach or 
> >> detach. Thus:
> >> [sean@dom0 ~]# usb-attach somevm Yubi
> >> [sean@dom0 ~]# qvm-usb
> >> BACKEND:DEVID DESCRIPTIONUSED BY
> >> fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
> >> p:1-1 QEMU_QEMU_USB_Tablet_42
> >> sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
> >> sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  somevm
> >> sys-usb:1-6   0489_e076  
> >> vault:1-1 QEMU_QEMU_USB_Tablet_42
> >> 
> >> ...and likewise...
> >> [sean@dom0 ~]# usb-detach somevm Yubi
> >> 
> >> If you like them you could put them (or something similar) in your 
> >> ~/.bashrc in your dom0.
> >> 
> >> Here they are:
> >> function usb-attach() {
> >>qvm-usb attach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
> >> }
> >> 
> >> function usb-detach() {
> >>qvm-usb detach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
> >> }
> >> 
> >> 
> >> Cheers,
> >> 
> >> Sean
> > 
> > Great job! I use Micah Lee's script adapted to fit my usb devices
> > https://micahflee.com/2016/12/qubes-tip-making-yubikey-openpgp-smart-cards-slightly-more-usable/
> > 
> > -- 
> > 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/25a26bb2-70d3-43dc-823b-8ff0ddaa734f%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

For that to happen I'd have to have more than one device greppable using the 
same keyword (or regex) right?

-- 
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/80edc1f7-acd8-4b9c-9ffd-de3218ad49e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to recover Qubes when keyboard / mice is dysfunctional due to USB qube setup issues?

[Patrick Schleizer]

Quote from https://www.qubes-os.org/doc/usb/

> Caution: By assigning a USB controller to a USB qube, it will no
longer be available to dom0. This can make your system unusable if, for
example, you have only one USB controller, and you are running Qubes off
of a USB drive.

How can one recover from such a situation if there is no PS2
keyboard/mice available?

I guess... Unless there is a better way...? Boot the system using from
an external disk using a USB recovery operating system... Then modify
the local disk (with broken Qubes)... Then do what?

Cheers,
Patrick

-- 
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/60e93375-e4dc-78ce-80e5-2414c263874b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Privacy in Qubes

[cooloutac]

On Friday, September 22, 2017 at 9:39:31 PM UTC-4, Person wrote:
> These are all very good tips, but to be honest, I'm not actually doing 
> anything too serious on Qubes so tracking is not that bad (but privacy is 
> still valuable). 
> 
> How would changing the web user agent fare? I tried it, and I believe it 
> works well, but I am not sure what happens to the tracking. Of course, adding 
> another OS in a Qubes VM would work well too, but it takes much more effort.

Tracking and privacy go hand in hand.   I would Just use tor browser.  Not sure 
how safe or maintained alot of addons are.

I don't think adding another os in the vm would help.  I would use multiple 
whonix vms for diff identities if need be.  You can even make it your 
disposable vm.

-- 
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/2f587ab9-3857-4985-9f79-7aac44412623%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Painless USB attach/detach

[Sean Hunter]

Yeah. Grep | cut -f1 from that script is similar to the awk line I use except 
that I also only print the first match (if there are multiple matches) whereas 
that script will print all of them which I think will cause problems if you 
have a device attached multiple timex. 

Sent from my phone. Sorry if brief. 

> On 24 Sep 2017, at 13:44, Yethal  wrote:
> 
> W dniu niedziela, 24 września 2017 13:45:19 UTC+2 użytkownik Sean Hunter 
> napisał:
>> Hey there,
>> 
>> I was trying out attaching usb devices to qubes and thought this might be 
>> useful to other people. If you have a device with a complicated description 
>> (eg a Yubikey) it can be a pain to figure out what device ID it's being 
>> attached to in sys-usb so you can use qvm-usb attach to send it to an AppVM.
>> [sean@dom0 ~]# qvm-usb
>> BACKEND:DEVID DESCRIPTIONUSED BY
>> fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
>> p:1-1 QEMU_QEMU_USB_Tablet_42
>> sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
>> sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  
>> sys-usb:1-6   0489_e076  
>> vault:1-1 QEMU_QEMU_USB_Tablet_42
>> 
>> Typing qvm-usb, looking down for where my Yubikey is, then looking accross 
>> for the sys-usb:1-3 next to it, then typing qvm-usb attach somevm 
>> sys-usb:1-3 will get pretty old pretty fast.
>> 
>> Luckily, unix is awesome. I have created a couple of small shell functions 
>> which search the output of qvm-usb on the description and attach or detach. 
>> Thus:
>> [sean@dom0 ~]# usb-attach somevm Yubi
>> [sean@dom0 ~]# qvm-usb
>> BACKEND:DEVID DESCRIPTIONUSED BY
>> fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
>> p:1-1 QEMU_QEMU_USB_Tablet_42
>> sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
>> sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  somevm
>> sys-usb:1-6   0489_e076  
>> vault:1-1 QEMU_QEMU_USB_Tablet_42
>> 
>> ...and likewise...
>> [sean@dom0 ~]# usb-detach somevm Yubi
>> 
>> If you like them you could put them (or something similar) in your ~/.bashrc 
>> in your dom0.
>> 
>> Here they are:
>> function usb-attach() {
>>qvm-usb attach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
>> }
>> 
>> function usb-detach() {
>>qvm-usb detach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
>> }
>> 
>> 
>> Cheers,
>> 
>> Sean
> 
> Great job! I use Micah Lee's script adapted to fit my usb devices
> https://micahflee.com/2016/12/qubes-tip-making-yubikey-openpgp-smart-cards-slightly-more-usable/
> 
> -- 
> 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/25a26bb2-70d3-43dc-823b-8ff0ddaa734f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/408D4BFD-3AD7-4803-8ACE-998D5959989E%40uncarved.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Painless USB attach/detach

[Sean Hunter]

Hey there,
I was trying out attaching usb devices to qubes and thought this might be useful to other people. If you have a device with a complicated description (eg a Yubikey) it can be a pain to figure out what device ID it's being attached to in sys-usb so you can use qvm-usb attach to send it to an AppVM.
[sean@dom0 ~]# qvm-usb
BACKEND:DEVID DESCRIPTIONUSED BY
fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
p:1-1 QEMU_QEMU_USB_Tablet_42
sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  
sys-usb:1-6   0489_e076  
vault:1-1 QEMU_QEMU_USB_Tablet_42
Typing qvm-usb, looking down for where my Yubikey is, then looking accross for the sys-usb:1-3 next to it, then typing qvm-usb attach somevm sys-usb:1-3 will get pretty old pretty fast.
Luckily, unix is awesome. I have created a couple of small shell functions which search the output of qvm-usb on the description and attach or detach. Thus:
[sean@dom0 ~]# usb-attach somevm Yubi
[sean@dom0 ~]# qvm-usb
BACKEND:DEVID DESCRIPTIONUSED BY
fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
p:1-1 QEMU_QEMU_USB_Tablet_42
sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  somevm
sys-usb:1-6   0489_e076  
vault:1-1 QEMU_QEMU_USB_Tablet_42
...and likewise...
[sean@dom0 ~]# usb-detach somevm Yubi
If you like them you could put them (or something similar) in your ~/.bashrc in your dom0.
Here they are:
function usb-attach() {
qvm-usb attach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
}

function usb-detach() {
qvm-usb detach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
}

Cheers,
Sean





-- 
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/20170924114417.GG3033%40uncarved.com.
For more options, visit https://groups.google.com/d/optout.
Hey there,

I was trying out attaching usb devices to qubes and thought this might
be useful to other people.  If you have a device with a complicated
description (eg a Yubikey) it can be a pain to figure out what device ID
it's being attached to in sys-usb so you can use `qvm-usb attach` to
send it to an AppVM.  

```
[sean@dom0 ~]# qvm-usb
BACKEND:DEVID DESCRIPTIONUSED BY
fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
p:1-1 QEMU_QEMU_USB_Tablet_42
sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  
sys-usb:1-6   0489_e076  
vault:1-1 QEMU_QEMU_USB_Tablet_42
```

Typing `qvm-usb`, looking down for  where my Yubikey is, then looking
accross for the `sys-usb:1-3` next to it, then typing `qvm-usb attach
somevm sys-usb:1-3` will get pretty old pretty fast.

Luckily, unix is awesome.  I have created a couple of small shell
functions which search the output of qvm-usb on the description
and attach or detach.  Thus:


```
[sean@dom0 ~]# usb-attach somevm Yubi
[sean@dom0 ~]# qvm-usb
BACKEND:DEVID DESCRIPTIONUSED BY
fedora-25:1-1 QEMU_QEMU_USB_Tablet_42
p:1-1 QEMU_QEMU_USB_Tablet_42
sys-firewall:1-1  QEMU_QEMU_USB_Tablet_42
sys-usb:1-3   Yubico_Yubikey_4_OTP+U2F+CCID  somevm
sys-usb:1-6   0489_e076  
vault:1-1 QEMU_QEMU_USB_Tablet_42
```

...and likewise...

```
[sean@dom0 ~]# usb-detach somevm Yubi


If you like them you could put them (or something similar) in your
`~/.bashrc` in your dom0.

Here they are:

```
function usb-attach() {
qvm-usb attach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
}

function usb-detach() {
qvm-usb detach "${1}" $( qvm-usb | awk "/${2}/"'{print $1;exit}' )
}

```

Cheers,

Sean



signature.asc
Description: PGP signature

Re: [qubes-users] Pointer lock API

[yuraeitha]

On Sunday, September 24, 2017 at 11:15:28 AM UTC, Leo Gaspard wrote:
> On 09/24/2017 04:50 AM, Nagaev Boris wrote:
> > Hey!
> > 
> > I noticed that Quake3 almost works in Qubes 3.2, but has one annoying
> > issue: the pointer is unmanageable. It looks like the pointer has the
> > "memory" about its previous position: e.g. when I move it left, the
> > game continues moving right. I tried `openarena` tool from the Debian
> > template and also web version of Quake on http://www.quakejs.com/ both
> > have the same issue. Performance of both native and web versions is
> > amazing, the only problem is the mouse.
> > 
> > I think it works incorrectly because it tries to lock the pointer
> > (probably to move it to the screen center) but Qubes doesn't allow
> > AppVMs to manage pointer. X11 has function `XWarpPointer` that moves
> > the pointer. Probably the game uses this function, though I don't know
> > how to check this.
> > 
> > Can Qubes add Pointer lock support for AppVM, please?
> 
> Disclaimer: I haven't tried yet to do this.
> 
> In addition to using the tablet input mode, as Alex advises, you may
> have luck plugging in a USB mouse and passing it through to the VM (if
> you run in non-seamless mode).
> 
> HTH,
> Leo

Sounds to me like a good suggestion, and it will more depend on the guest-OS 
whether it supports USB-mouse, making Qubes support irrelevant. 

Having said that, it would be amazing to sometime in the near future have 
touch-screen support for Qubes and AppVM's. 
If non-touch screens don't disappear with Virtual/Augmented reality spreading 
like wildfire in the coming years, then traditional mouse most certainly is 
going to go away eventually.

With all these new hand movement, brain-wave thought control of software, 
gyroscope finger sensor ring and control. It's hard to see it being a good idea 
not to focus development on these new technologies, which might come to market 
very fast, once the big mobile/laptop developers decide to unleash it.

At which point, we'll be sourly left behind this revolution, which has the 
potential to make software use considerably more convenient, fast and smooth.

It's a bit of a problem, few programmers seem to take anything else but 
keyboard/mouse seriously. Though of course, its hard to program for something 
that hasn't reached mainstream yet, or at best only prototypes or exotic 
commercial releases in the wild.

But considering how long it takes to make touch-screen work properly in the 
Linux community, I do fear for the future once new input methods become 
mainstream. 

I love the Linux community. But if there is anything I dislike, it's the 
conservative, reactive, kind of thinking that takes president. There are so few 
visionaries, proactive, kind of thinkers around in the Linux community in 
general. Though to be fair, Qubes is quite revolutionary and visionary, but I'm 
not talking about Qubes, but rather the desktop environments and their lack of 
proper working input support.

It hardly makes sense for Qubes to implement it, if the desktop environments 
don't support it properly to begin with. In a sense, it makes sense Qubes 
developers don't work on something, which is outside their scope. The problem 
here, is those who are supposed to be responsible for it, the desktop 
environment developers, especially the conservative ones who dislike change and 
don't care about users who have different needs than their own. 

Those are the problem, in my opinion. Albeit can't complain if I don't donate 
to them, but I don't want to donate unless they do a good job either, to which 
many desktop developers most certainly don't. It's a bad never ending circle. 

-- 
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/4d18d712-6890-4335-9f52-40a98fd3ddf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Salt vcpus bug in 4.0rc1

[yuraeitha]

On Sunday, September 24, 2017 at 10:53:12 AM UTC, Sean Hunter wrote:
> Hi there,
> 
> I think changes to remove vcpu option etc from qvm-create in 4.0 haven't been 
> synced into the saltstack modules yet.
> 
> If I create an x.top file like this
> base:
>   dom0:
>   - x   
> 
> ...and an x.sls file like this
> x:
>   qvm.present:
>- name: x
>- template: fedora-25
>- label: blue
>- mem: 4096
>- vcpus: 4
>   
> 
> ...and then try to create the vm by doing
> $ sudo qubesctl top.enable x
> $ sudo qubesctl state.highstate
> 
> ...I get this error output, saying that it doesn't understand the vcpus 
> option.
> [ERROR   ] /usr/bin/qvm-check x 
> == stderr ==
> /usr/bin/qvm-create --template fedora-25 --label blue --vcpus 4 x 
> usage: qvm-create [-h] [--verbose] [--quiet] [--class CLS]
>   [--property NAME=VALUE] [--pool VOLUME_NAME=POOL_NAME]
>   [-P POOL_NAME] [--template VALUE] [--label VALUE]
>   [--help-classes]
>   [--root-copy-from FILENAME | --root-move-from FILENAME]
>   [VMNAME]
> qvm-create: error: unrecognized arguments: --vcpus x
> == stderr ==
> /usr/bin/qvm-check x 
> usage: qvm-check [-h] [--verbose] [--quiet] [--all] [--exclude EXCLUDE]
>  [--running] [--paused] [--template]
>  [VMNAME [VMNAME ...]]
> qvm-check: error: no such domain: 'x'
>  [0;31mlocal: [0;0m
>  [0;31m-- [0;0m
>  [0;31m  ID: x [0;0m
>  [0;31mFunction: qvm.present [0;0m
>  [0;31m  Result: False [0;0m
>  [0;31m Comment: /usr/bin/qvm-check x 
>   == stderr ==
>   /usr/bin/qvm-create --template fedora-25 --label blue --vcpus 4 
> x 
>   usage: qvm-create [-h] [--verbose] [--quiet] [--class CLS]
> [--property NAME=VALUE] [--pool 
> VOLUME_NAME=POOL_NAME]
> [-P POOL_NAME] [--template VALUE] [--label 
> VALUE]
> [--help-classes]
> [--root-copy-from FILENAME | --root-move-from 
> FILENAME]
> [VMNAME]
>   qvm-create: error: unrecognized arguments: --vcpus x
>   == stderr ==
>   /usr/bin/qvm-check x 
>   usage: qvm-check [-h] [--verbose] [--quiet] [--all] [--exclude 
> EXCLUDE]
>[--running] [--paused] [--template]
>[VMNAME [VMNAME ...]]
>   qvm-check: error: no such domain: 'x' None [0;0m
>  [0;31m Started: 11:28:23.389119 [0;0m
>  [0;31mDuration: 1446.122 ms [0;0m
>  [0;31m Changes:[0;0m
> 
> ...
> 
> Summary for local
>  [0;0m
>  [0;32mSucceeded: 7 [0;0m
>  [0;31mFailed:1 [0;0m
>  [0;36m
> Total states run: 8 [0;0m
>  [0;36mTotal run time:   3.415 s [0;0m
> DOM0 configuration failed, not continuing
> 
> Removing that line makes it work. I searched on github and the qubes-devel 
> list but didn't find anything. Should I just go ahead and make a new bug on 
> github? I may have a dig through the code to see if I can fix it myself, 
> although I'm new to both qubes and salt, so not making any promises. :)
> 
> Cheers,
> 
> Sean

It might actually be better to post this on Qubes-Devel, you'll much easier get 
directly involved with the developers there, as they only occasionally drop by 
Qubes-Users due to having a lot of work. Reading a lot of different forums and 
threads takes a lot of time, so it's easier for both them and you to throw this 
topic over there in a centralized developer forum. There is a wait delay for 
accepting threads/replies, but it probably isn't a problem with something like 
this which is developer related, and therefore on-topic over there.

Said as a fellow normal user, welcome to the Qubes community! Always great to 
see new faces in this amazing project they are making (:

-- 
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/6211bf55-2b14-4fb5-89cd-393f76aed380%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Salt vcpus bug in 4.0rc1

[Sean Hunter]

Hi there,
I think changes to remove vcpu option etc from qvm-create in 4.0 haven't been synced into the saltstack modules yet.
If I create an x.top file like this
base:
  dom0:
  - x   
...and an x.sls file like this
x:
  qvm.present:
   - name: x
   - template: fedora-25
   - label: blue
   - mem: 4096
   - vcpus: 4
  
...and then try to create the vm by doing
$ sudo qubesctl top.enable x
$ sudo qubesctl state.highstate
...I get this error output, saying that it doesn't understand the vcpus option.
[ERROR   ] /usr/bin/qvm-check x 
== stderr ==
/usr/bin/qvm-create --template fedora-25 --label blue --vcpus 4 x 
usage: qvm-create [-h] [--verbose] [--quiet] [--class CLS]
  [--property NAME=VALUE] [--pool VOLUME_NAME=POOL_NAME]
  [-P POOL_NAME] [--template VALUE] [--label VALUE]
  [--help-classes]
  [--root-copy-from FILENAME | --root-move-from FILENAME]
  [VMNAME]
qvm-create: error: unrecognized arguments: --vcpus x
== stderr ==
/usr/bin/qvm-check x 
usage: qvm-check [-h] [--verbose] [--quiet] [--all] [--exclude EXCLUDE]
 [--running] [--paused] [--template]
 [VMNAME [VMNAME ...]]
qvm-check: error: no such domain: 'x'
 [0;31mlocal: [0;0m
 [0;31m-- [0;0m
 [0;31m  ID: x [0;0m
 [0;31mFunction: qvm.present [0;0m
 [0;31m  Result: False [0;0m
 [0;31m Comment: /usr/bin/qvm-check x 
  == stderr ==
  /usr/bin/qvm-create --template fedora-25 --label blue --vcpus 4 x 
  usage: qvm-create [-h] [--verbose] [--quiet] [--class CLS]
[--property NAME=VALUE] [--pool VOLUME_NAME=POOL_NAME]
[-P POOL_NAME] [--template VALUE] [--label VALUE]
[--help-classes]
[--root-copy-from FILENAME | --root-move-from FILENAME]
[VMNAME]
  qvm-create: error: unrecognized arguments: --vcpus x
  == stderr ==
  /usr/bin/qvm-check x 
  usage: qvm-check [-h] [--verbose] [--quiet] [--all] [--exclude EXCLUDE]
   [--running] [--paused] [--template]
   [VMNAME [VMNAME ...]]
  qvm-check: error: no such domain: 'x' None [0;0m
 [0;31m Started: 11:28:23.389119 [0;0m
 [0;31mDuration: 1446.122 ms [0;0m
 [0;31m Changes:[0;0m

...

Summary for local
 [0;0m
 [0;32mSucceeded: 7 [0;0m
 [0;31mFailed:1 [0;0m
 [0;36m
Total states run: 8 [0;0m
 [0;36mTotal run time:   3.415 s [0;0m
DOM0 configuration failed, not continuing
Removing that line makes it work. I searched on github and the qubes-devel list but didn't find anything. Should I just go ahead and make a new bug on github? I may have a dig through the code to see if I can fix it myself, although I'm new to both qubes and salt, so not making any promises. :)
Cheers,
Sean





-- 
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/20170924105206.GA2404%40uncarved.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[qubes-users] Re: Some HVM systems don't pickup IP from DHCP

[yuraeitha]

On Thursday, November 5, 2015 at 4:00:22 AM UTC, Pete Howell wrote:
> I've noticed on several installs, that the system would not pickup an IP 
> address and had to have one hardcoded.  Does anyone know why this happens?

I had a similar issue when I installed Android 7.1 on Qubes OS, it did not 
pickup the ethernet connection, but rather kept seeking a wireless connection.
I tried to bind the template of which the Android 7.1 was installed on, to 
Sys-Net, instead of Sys-Firewall, and it instantly solved the issues. 

I'm not too much into as to why and how this works, perhaps it just bypasses 
the Qubes internal DHCP? Though, if putting another firewall up next to the 
Qubes default firewall, it should be possible to maintain the overall security, 
however, without the ability to send files from/to Android 7.1, or whatever 
else is hosted with HVM. I suspect? 

-- 
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/fc72eba8-40c8-408d-aab9-a730119ef547%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: how to make a docker host templatevm

[yuraeitha]

On Sunday, September 24, 2017 at 10:12:03 AM UTC, pixel fairy wrote:
> On Sunday, September 24, 2017 at 3:02:50 AM UTC-7, yura...@gmail.com wrote:
> 
> > This looks exciting, I definitely will have a look at it when Qubes 4.0-RC2 
> > has been released, with more up-to-date templates.
> 
> i wrote it for Qubes 3.2. Ill do it again on 4.0-rc2 if it works on my laptop.

Cheers!
Wish I could contribute somehow, feels a bit wrong to just leech like this. But 
at the very least, it is greatly appreciated when you guys make these 
life-quality increasing pieces work.

-- 
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/0c315012-e565-4cbf-912f-2eaaef944b99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Screen freezing and input problems in AppVMs

[yuraeitha]

On Sunday, September 24, 2017 at 8:52:32 AM UTC, Michael Strasser wrote:
> Hi!
> 
> I've been experiencing some strange issues recently, which I can't
> really pin down on anything in particular.
> 
> * I've been getting a frozen screen after random periods of time when
> I've been using two different monitors. Usually the only solution is to
> kill my machine.
> 
> * Sometimes (again when using multiple screens) just mouse input and
> keyboard input from my laptop stop working, although mouse input from my
> USB mouse keeps working.
> 
> * My laptop monitor has input "freezes" all the time (i.e. after about
> 4-7 keypresses there is a delay of about 1 second until the input is
> processed), but I do not experience the same on my second monitor and I
> only experience them in AppVMs, not in dom0.
> 
> * I can no longer put applications into fullscreen mode on my laptop
> monitor - no input is recognized and the app "freezes" until I quit
> fullscreen mode (at which point the input made in fullscreen mode is
> delivered to/visible in the application) - fullscreen mode works fine on
> my second monitor.
> 
> I'm using Qubes 3.2 with i3, but I experienced the same problems with xfce.
> 
> At first I thought this was a hardware issue, but I just tried booting
> Ubuntu 16.04 from a USB stick and couldn't reproduce any of the issues.
> I also just noticed that input "freezing" just happens in AppVMs, not in
> dom0.
> 
> I have no idea what is causing these issues, I've been using Qubes OS
> since April and everything was fine, until about 1 1/2 months ago when
> these problems started to arise. I also couldn't find any connection to
> work load or anything performance related that would explain the issues.
> I also tried changing the kernel version of one of the AppVMs from
> 4.9.45-21 to 4.9.35-20 and 4.9.35-19 but nothing changed.
> 
> Does anyone have any tips or has experienced something similar?
> 
> 
> I'm using Qubes 3.2, kernel version 4.9.45-21 with i3 on a Lenovo X250.
> 
> 
> Best regards

I've experienced many of the symptoms you describe, including the full-screen 
issue. Actually, it looks like we've had the exact same issue down to last 
detail by the looks of your post. I only partly solved mine, I'm not entirely 
sure to what extent it was solved as i didn't run benchmark tests on this 
machine, though I can more or less do what I did before now.

I've had my issue since the last couple of days/weeks? It's uncertain when it 
started, since it only appears when multiple of VM's are running, and stops 
when closing a few VM's. 

It is definitely not RAM related as I multiple of times made sure I had enough, 
however it seems it might be Processor related? Also it gets significantly 
worse if trying to stream movies like Youtube. It seems like the Qubes Manager 
doesn't record CPU useage correctly, or perhaps there is something wrong with 
the kernel, or something else entirely. 

I felt a significant performance increase back to normal, when I moved from 
kernel 4.9.35 to 4.9.45. I made no difference between Dom0/Templates/AppVM 
kernels, I upgraded all of it to the 4.9.45 kernel. 

I've suspected codec issues if the decoder of video can't handle it, but it 
doesn't seem to be restricted to video only, albeit a more smooth video decoder 
definitely would help on the issue.

Another thing that seems strange, is that I feel a slight hit on performance 
when getting back up from hibernation/suspend, as well as when returning 
AppVM's from a backup upon complete delete of the entire drive and reinstalling 
Qubes/Dom0/Templates on the drive (same machine). 

Albeit they felt small, and it might just have been my imagination. But while 
it isn't proof and may simply be a coincidence, my issues that look pretty much 
identical to yours, started when I re-installed Qubes/Dom0/Templates, and 
restored all AppVM's from the backup I made.

A few days ago, I made a brand new AppVM for my Youtube'ing just to see if it 
would speed up without freezing or lag. I used the exact same template too as 
before. And sure enough, it was much, much faster than my old AppVm of which I 
had restored from my backup around when my issues started.

Perhaps you made similar changes recently and got similar issues for that 
reason? or perhaps it's something else entirely, it's all anecdotal and 
speculation at this point of time. 

-- 
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/f09eb1e9-1096-4da4-9de3-3a8ca1d75c50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: how to make a docker host templatevm

[yuraeitha]

On Friday, September 22, 2017 at 9:47:59 AM UTC, pixel fairy wrote:
> heres how to make a docker host templatevm. have fun.
> 
> https://gist.github.com/xahare/6b47526354a92f290aecd17e12108353
> 
> Should this be added to the qubes docs?

This looks exciting, I definitely will have a look at it when Qubes 4.0-RC2 has 
been released, with more up-to-date templates. 

Thanks for sharing.

-- 
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/69c9a29a-5af9-4419-89bc-1062a9613dfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Is it damaging to increase each 2GB VM storage beyond the drive limit?

[yuraeitha]

Heya, 

TL:DR 
Is there anything wrong with pushing VM partitions beyond the physical drive 
size, as long as data doesn't exceed the physical drive size (which it can't 
for obvious reasons). Corruption? Backup size? Privacy? or just no code 
available yet to tailor VM sizes to unique drive sizes?

- - - - 

These 4 questions above reflect the confusement to which this thread seeks to 
solve and find answers to. They might not be all be the reasons, or perhaps 
there is another reason altogether. 

Root of the question that either makes the question trivial, or very important:
On one hand, it might just be that there hasn't been any code made yet for this 
otherwise trivial exercise to change the virtual partition sizes. On the other 
hand, it also gives the impression that Qubes is discouraging making virtual 
partitions too big compared to the drive, for a good reason which hasn't been 
easily explained to the masses. 

Afterthought: 
The latter hand scenario is worrying, considering the very small 2GB home 
folder partition size, when the technology of virtual partitions doesn't appear 
to have an actual hard limit, as long as data doesn't exceed the soft limit. 
Hence, should one be careful here? or is there really just another less serious 
reason for the 2GB home folder partition size out-of-the-box? For example Why 
isn't it just set to say, 100GB, or even 10.000GB by default, if virtual 
partition sizes doesn't matter and most keep track of disk usage in Dom0 anyway?

I'm asking, since I'm considering to simply give each of my AppVM's the size of 
my physical drive, and just keep track of the used drive space with Dom0/XFCE4. 

If there are any reasons to be careful? or perhaps one should follow hard to 
find guidelines to virtual partition sizes? 

It would be really appreciated to find a solid answer, or even just the best 
answer available.


Cheers, 
Yuraeitha  

-- 
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/63e0f090-7cc5-45fe-865f-80077ef1431d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Screen freezing and input problems in AppVMs

[Michael Strasser]

Hi!

I've been experiencing some strange issues recently, which I can't
really pin down on anything in particular.

* I've been getting a frozen screen after random periods of time when
I've been using two different monitors. Usually the only solution is to
kill my machine.

* Sometimes (again when using multiple screens) just mouse input and
keyboard input from my laptop stop working, although mouse input from my
USB mouse keeps working.

* My laptop monitor has input "freezes" all the time (i.e. after about
4-7 keypresses there is a delay of about 1 second until the input is
processed), but I do not experience the same on my second monitor and I
only experience them in AppVMs, not in dom0.

* I can no longer put applications into fullscreen mode on my laptop
monitor - no input is recognized and the app "freezes" until I quit
fullscreen mode (at which point the input made in fullscreen mode is
delivered to/visible in the application) - fullscreen mode works fine on
my second monitor.

I'm using Qubes 3.2 with i3, but I experienced the same problems with xfce.

At first I thought this was a hardware issue, but I just tried booting
Ubuntu 16.04 from a USB stick and couldn't reproduce any of the issues.
I also just noticed that input "freezing" just happens in AppVMs, not in
dom0.

I have no idea what is causing these issues, I've been using Qubes OS
since April and everything was fine, until about 1 1/2 months ago when
these problems started to arise. I also couldn't find any connection to
work load or anything performance related that would explain the issues.
I also tried changing the kernel version of one of the AppVMs from
4.9.45-21 to 4.9.35-20 and 4.9.35-19 but nothing changed.

Does anyone have any tips or has experienced something similar?


I'm using Qubes 3.2, kernel version 4.9.45-21 with i3 on a Lenovo X250.


Best regards

-- 
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/5aa2a729-4398-040d-3c9c-b150464a06aa%40gmx.at.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Pointer lock API

[Alex]

On 09/24/2017 04:50 AM, Nagaev Boris wrote:
> Hey!
> 
> I noticed that Quake3 almost works in Qubes 3.2, but has one
> annoying issue: the pointer is unmanageable. It looks like the
> pointer has the "memory" about its previous position: e.g. when I
> move it left, the game continues moving right. I tried `openarena`
> tool from the Debian template and also web version of Quake on
> http://www.quakejs.com/ both have the same issue. Performance of both
> native and web versions is amazing, the only problem is the mouse.
> 
> I think it works incorrectly because it tries to lock the pointer 
> (probably to move it to the screen center) but Qubes doesn't allow 
> AppVMs to manage pointer. X11 has function `XWarpPointer` that moves 
> the pointer. Probably the game uses this function, though I don't
> know how to check this.
> 
> Can Qubes add Pointer lock support for AppVM, please?
> 
It may not be a pointer lock issue, but rather a problem with input
type. Did you try starting the VM with a different mouse input type? The
default seems to be Mouse, while Tablet may solve your problems, like it
did (even if not 100% because of inbuilt android pointer acceleration)
for my Android appVM.

The mouse input type setting cannot be configured via standard Qubes
tools, either the qubes.xml or the manager. You can try by creating a
copy of "appvmname.conf" with a name different from the original (or
Qubes will overwrite it) that you can find in dom0 at
/var/lib/qubes/appvms/appvmname/appvmname.conf.

In the copy find the "devices" element and add "" - this will override the default mouse input. Start the VM
with this conf instead of the default one with qvm-start and check.

It would be a great security concern to let single appVMs manage the
pointer, even if in good faith (misclicks can produce disasters) and
without mentioning the big development problem. The mouse "resource"
will have to be "shared" among potentially several
mouse-management-enabled appvms: who shall win if two appvms decide to
lock the mouse in two separate rectangles?

-- 
Alex

-- 
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/9e149873-19ab-90ac-ddd8-ee4e90418eed%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature