[qubes-users] express card USB controller

2016-07-07 Thread Franz
I need an additional USB controller that can be assigned to a VM different
from sys-usb.

Since I have an express card slot, should something like this work?
https://www.thinkpenguin.com/gnu-linux/usb-30-expresscard-34mm

Or do you know something that works?

Best
Fran

-- 
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/CAPzH-qDaqd01qqFt6ADXMKDnT-kMEg5sMK3eHW-YEy%3DHERJpZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Bridged NAT Win App VM

2016-07-07 Thread Iestyn Best
On Thursday, June 23, 2016 at 10:43:43 AM UTC+10, Drew White wrote:
> I have been working on getting my bridging perfect, just using iptables on 
> the NetVM.
> 
> I have not got it working perfectly, there are still some things wrong with 
> other things that I have to find a way to work around it.
> Once it's working perfectly, I'll put it up somwhere.
> 
> 
> On Saturday, 18 June 2016 05:56:50 UTC+10, qubes qna  wrote:
> 
> Dear users, what's the current status of bridging support?  is there any 
> active development?  At this time it seems it's beta and experimental at this 
> time.
> 
> We want to run a windows VM in bridged mode to join an ActiveDirectory domain.
> 
> Has any else ran a Windows AppVM in an activedirectory domain?  and if so how?

I would be interested to know what you have achieved so far. It may help with a 
problem I have at the moment.

Thank you for all the work you have been doing.

-- 
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/96f79e02-2b2d-4815-b62a-1f33289b9da9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] SCCM Task Sequence in HVMTemplate

2016-07-07 Thread Iestyn Best
Hi,

I have just reinstalled Qubes using the 3.2-rc1 and I am trying to install my 
company SOE into a VM but I have had no luck so far.

Our company uses SCCM to deploy the image.

So far I have tried:
 * Using PXE boot using iPXE but I am not sure what to chain to
 * Using a boot ISO with the SCCM task sequence but as the VM is in a different 
network, it cannot get DHCP. Also, the static IP options via MDT are bugged and 
I cannot set a static IP.
 * I tried turning off the sys-net vm and assigning the physical nic to the 
HVMTemplate but when I boot the ISO it does not recognise the NIC.
 * Tried creating a bridge with the sys-net vm but had no luck as the details 
are old.

I am looking to see if anyone has any suggestions they could provide to help me 
get the SOE installed via the network deployment capability. If I could PXE 
boot would probable be the best, but I assume just getting the DHCP and network 
access to pass through (possibly via temporary bridge) would achieve what I am 
looking to do.

Regards,
Iestyn Best

-- 
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/1ccc5b1b-cfc1-433c-abbd-f646ddd56d5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Networking

2016-07-07 Thread Drew White
The networking REALLY needs to be up at 1Gbps.
This slow speed is just horrific when you are managing servers.

Takes forever to upload a 4 GB iso.

And to copy a file from the network to local, or vice-versa, takes way too long.

-- 
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/c0927481-f528-4627-aebf-627f40b1e878%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes Version from CLI

2016-07-07 Thread Drew White
On Thursday, 7 July 2016 18:27:40 UTC+10, Andrew David Wong  wrote:

> It's on hold until we can find a GNOME/GTK developer:
> 
> https://www.qubes-os.org/join/#tocAnchor-1-1-5

Ahh, well, the things I build for my own use in Qubes aren't built using the 
normal GTK and all that.

I know how to program in many different languages, but what I build to be 
reliable are not in those languages because I'm not 100% in those areas.

I can make my way through things, but they are not my best areas.


I don't have all these skills. 

yes > Python
yes > Shell scripting
yes > System configuration (basic services, startup scripts etc)
yes > Git, make
?   > (Optional) networking, firewalling
?   > (Optional) X11 protocol (raw)
yes > (Optional) GUI frameworks (Gtk, Qt)
may > (Optional) kernel and/or hypervisor debugging skills
no  > (Optional) low level stuff (UEFI, PCI communication, including IOMMU, 
networking down to ethernet layer, Xen backend/frontend interfaces)
no  > (Optional) libvirt internals
nvr > (Optional) salt stack
umm > (Optional) advanced desktop environment configuration, including writing 
plugins (KDE, Gnome)



-- 
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/abf109e4-7363-47ba-88eb-0b0224d7fb0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] issues in 3.2

2016-07-07 Thread Drew White
On Friday, 8 July 2016 09:50:21 UTC+10, Iestyn Best  wrote:
> On Thursday, July 7, 2016 at 11:00:45 AM UTC+10, Drew White wrote:
> > On Thursday, 7 July 2016 00:57:06 UTC+10, Andrew David Wong  wrote:
> > > I'm not a coder, so I don't know. If you know the task to be an easy
> > > one, why not help us out by contributing the patch yourself?
> > 
> > If I was to make a patch for it, it would involve me fixing all the bugs in 
> > it, basically rewriting the whole thing by going through line by line of 
> > the whole code to find where things are going wrong.
> > 
> > Since you have already been talking about rewriting the whole thing anyway, 
> > I don't see the point in doing that.
> > 
> > I personally have already altered things that are annoyances in the qvm 
> > tools and other things to fix what I find to be very very very annoying, 
> > and which are things that if I couldn't change, I wouldn't be using Qubes, 
> > yet I was told they couldn't be changed because other things worked off it, 
> > and yet those things with exactly the same change made, worked fine. one 
> > line of code in tools after one area changed in one tool. Took me 5 minutes 
> > to make the change, but made everything so much cleaner in the menu system. 
> > The next thing is the Windows Main Menu reader, and fixing that up.
> 
> Hi Drew,
> 
> Glad to see you are getting Qubes to work the way you like/need.
> 
> Just curious, have you provided patches to the Qubes team with those changes?
> 
> I would be interested in seeing if your fixes could come through in the main 
> release.
> 
> Regards,
> Iestyn Best

No, I have not provided them because I was told it would never be changed, and 
they would not  change it because they had things that worked using the way it 
was. So they will not change it no matter what, because I proposed it to them 
before.

I'll be happy to provide the small things that I have done to change things for 
more easy menu, but in 3.2 we need the real menu back, not that THING they call 
a menu that isn't.

-- 
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/1409eef0-4922-45cd-9c64-1771cdd55b2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: r-10 All-in-One Qubes PC (New at Crowd Supply)

2016-07-07 Thread Iestyn Best
It would be good to find out some of that information.

It is also good to see other people trying to support and promote Qubes-OS.

-- 
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/25ecba52-d7f3-45b4-b001-39c7cb436206%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Networking Disabled - cannot enable NetworkManager Applet [sys-firewall]

2016-07-07 Thread jefferson_plague
Hello all,

I realised I had been making a mistake when following the "whonix 12 to 13" 
guide. I deleted my post so that I could probe some other issues before 
returning with a revised and updated reply. However I found my other issues to 
be resolved. 

The meta packages problem is resolved. However each boot up the sys-firewall 
NetworkManager issue returns. Hoping this is not a risk to security or 
function. Everything else at this time seems in order

-- 
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/d7955f14-f5e6-4c80-9383-8e8b59fffc1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Networking Disabled - cannot enable NetworkManager Applet [sys-firewall]

2016-07-07 Thread Qubed One
Qubed One:
> jefferson_pla...@hotmail.com:
>> Hello Andrew 
>>
>>> This is the NetworkManager applet running in sys-firewall. Normally,
>>> sys-firewall is connected to sys-net for network access, and the
>>> NetworkManager applet only runs in sys-net. (The situation can be
>>> different if you're running things like VPN VMs, but we'll set those
>>> aside here.)
>>>
>>> In short: the NetworkManager applet shouldn't be visible in
>>> sys-firewall in the first place, but it's not a big problem (just a
>>> confusing one). There's normally a script that hides it, but in your
>>> case, that's not working for some reason.
>>
>> My set up is standard with the only change from fresh installation being the 
>> updating of templates and dom0. Is this difference of NetworkManager 
>> appearing an indication of any loss of function or security?
>>
>>> So, are you still having problems updating dom0 and your templates? If 
>>> so, can you explain the problems? 
>>
>> There were issues with dom0. The link below give the solution:
>> https://groups.google.com/forum/#!searchin/qubes-users/errno$2014$20curl$2337/qubes-users/zMETrlPMqng/GcwIPcZ8BQAJ
>>
>> The whonix templates were difficult. I was able to update them however I 
>> still get a whonixcheck error for the whonix gateway. It reads "WARNING: 
>> Whonix Meta Packages Test Result: Whonix-Gateway detected, but the meta 
>> package qubes-whonix-gateway is not installed. Did you accidentally 
>> uninstall it?"
>>
>> I followed the steps from this discussion:
>> https://groups.google.com/forum/#!searchin/qubes-users/meta$20package$20qubes-whonix-gateway$20is$20not$20installed/qubes-users/P2BTCOPcTnU/xHXxMEzLPwAJ
>>
>> This did not work:
>> "sudo apt-get install qubes-whonix-workstation" on WS template
>> "sudo apt-get install qubes-whonix-gateway" on GW template. 
>>
>> Another similar command to the two above worked. However the autoremove 
>> command did not work. I was root and met the requirements it seemed to need. 
>>
>> The sanity check from here did not work, returning 1 instead of 0. The 
>> command was not recognised:
>> https://www.google.com/url?q=https%3A%2F%2Fwww.whonix.org%2Fwiki%2FUpgrading_Whonix_12_to_Whonix_13=D=1=AFQjCNGFl1_nVVp9x0MIL9am3BnI9-vOlA
>>
>> I would like to learn how to fix this meta package error. From what I have 
>> read here it would be a risk to my security to bypass this issue.
>> https://www.whonix.org/wiki/Whonix_Debian_Packages#What_is_the_disadvantage_of_removing_a_meta_package.3F
> 
> 
> These steps worked for me (sorry, can't find the source that directed me
> here. It mentioned something about upgrading Whonix from 12 to 13
> without realizing it.):
> 
> https://www.whonix.org/wiki/Upgrading_Whonix_12_to_Whonix_13


Sorry again, it appears you've already tried that. I need to read more
thoroughly before replying...


>> Thank you for providing some sources. Are there any that I can learn to 
>> better navigate qubes and use basic code? I will keep looking through the 
>> documentation. Aside for running an update on a VM is there anyway to check 
>> if the VM (or dom0) is up to date?
>>
> 

-- 
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/37148fc2-d147-96b7-a9cd-f295e14fe44d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Networking Disabled - cannot enable NetworkManager Applet [sys-firewall]

2016-07-07 Thread Qubed One
jefferson_pla...@hotmail.com:
> Hello Andrew 
> 
>> This is the NetworkManager applet running in sys-firewall. Normally,
>> sys-firewall is connected to sys-net for network access, and the
>> NetworkManager applet only runs in sys-net. (The situation can be
>> different if you're running things like VPN VMs, but we'll set those
>> aside here.)
>>
>> In short: the NetworkManager applet shouldn't be visible in
>> sys-firewall in the first place, but it's not a big problem (just a
>> confusing one). There's normally a script that hides it, but in your
>> case, that's not working for some reason.
> 
> My set up is standard with the only change from fresh installation being the 
> updating of templates and dom0. Is this difference of NetworkManager 
> appearing an indication of any loss of function or security?
> 
>> So, are you still having problems updating dom0 and your templates? If 
>> so, can you explain the problems? 
> 
> There were issues with dom0. The link below give the solution:
> https://groups.google.com/forum/#!searchin/qubes-users/errno$2014$20curl$2337/qubes-users/zMETrlPMqng/GcwIPcZ8BQAJ
> 
> The whonix templates were difficult. I was able to update them however I 
> still get a whonixcheck error for the whonix gateway. It reads "WARNING: 
> Whonix Meta Packages Test Result: Whonix-Gateway detected, but the meta 
> package qubes-whonix-gateway is not installed. Did you accidentally uninstall 
> it?"
> 
> I followed the steps from this discussion:
> https://groups.google.com/forum/#!searchin/qubes-users/meta$20package$20qubes-whonix-gateway$20is$20not$20installed/qubes-users/P2BTCOPcTnU/xHXxMEzLPwAJ
> 
> This did not work:
> "sudo apt-get install qubes-whonix-workstation" on WS template
> "sudo apt-get install qubes-whonix-gateway" on GW template. 
> 
> Another similar command to the two above worked. However the autoremove 
> command did not work. I was root and met the requirements it seemed to need. 
> 
> The sanity check from here did not work, returning 1 instead of 0. The 
> command was not recognised:
> https://www.google.com/url?q=https%3A%2F%2Fwww.whonix.org%2Fwiki%2FUpgrading_Whonix_12_to_Whonix_13=D=1=AFQjCNGFl1_nVVp9x0MIL9am3BnI9-vOlA
> 
> I would like to learn how to fix this meta package error. From what I have 
> read here it would be a risk to my security to bypass this issue.
> https://www.whonix.org/wiki/Whonix_Debian_Packages#What_is_the_disadvantage_of_removing_a_meta_package.3F


These steps worked for me (sorry, can't find the source that directed me
here. It mentioned something about upgrading Whonix from 12 to 13
without realizing it.):

https://www.whonix.org/wiki/Upgrading_Whonix_12_to_Whonix_13


> Thank you for providing some sources. Are there any that I can learn to 
> better navigate qubes and use basic code? I will keep looking through the 
> documentation. Aside for running an update on a VM is there anyway to check 
> if the VM (or dom0) is up to date?
> 

-- 
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/7448bbb6-f675-ba08-d008-48073bb2c5cd%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Problem with chrony package installing on Qubes Release 3.2-rc1

2016-07-07 Thread R.B.

On 07/06/2016 04:52 PM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-06 04:40, Jeral A wrote:

Hi!

I'm having problem during the Qubes Release 3.2-rc1 installation.
During the installation process error message displays, informing
me that the "chrony" package won't be installed. Here is the whole
error message text: You have specified that the package 'chrony'
should be installed. This package does not exist. Would you like to
ignore this package and continue with installation?

If I press "Yes", then the installation process continues, but
after the system runs first time, another error message appears:
https://i.imgur.com/n1d7HOm.jpg

After that the system starts normally, but I can't find any
preinstalled VMs (sys-net, sys-firewall, work, personal etc).


Had a similar effect during my second install. At the time I had backups 
of VM's waiting to get re-installed, so I didn't take note of which vm's 
where missing at the time. I did see the chrony error.
What I did different in relation to the first install, was setting 
timezone and keyboard. At the first install, I adjusted the settings 
_after_ the install. Could be the two issues below are related?


Maybe a fresh install with default settings?



https://github.com/QubesOS/qubes-issues/issues/2110
https://github.com/QubesOS/qubes-issues/issues/2147



Regards,

RB

--
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/152dd4b1-11b4-e632-fb77-3e024c866eec%40reboli.nl.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Possible to give global access to second harddrive?

2016-07-07 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-07 08:27, Fredrik wrote:
> I have a seccond harddrive I only plan to use for media and
> downloading. What is the easiest or preferred way to give all or
> some of my VMs acces to it?
> 
> setting  up a share would mean opening the firewall and that seams
> like bad idé sins dom0 is the only VM that can see it for now.
> 

This is my personally preferred method:

https://www.qubes-os.org/doc/secondary-storage/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXfsjFAAoJENtN07w5UDAwg6IP/2Zl1gdrm/kvKqLhjIpK3AT8
4b2+pUwP9peumZ0wFf3Ap6x4GfXYSZUCOeQCMPgpJh4MGiBPTcfGju8u86XY2BtV
lpXR4Al0YZnUzcWBSwG/BEvUgt34UHEkbMoZYvA4WlC7QxkXbGuRyENYC3gZcFG9
udENlj8t9unW/ibYcsXUKBynVweYw3fzP0x4ILrfIMjefPZCWvD+CDjVmA1HKXOZ
yMt9z03PpXpSolS7DQdY5iAn/7W34d5mH65KAO9Q0/JrfG6pkEOBCkaNc0Lf6X5E
uVtZ4DCd0vdUnhUZbfyfB9ucYkHOkVpeQA+gQzpJ5daefqwtqXZQT5pd8oNOenPd
sFe1VitQ1kKSwwPFg4AfA//e1OnATpbri8MCmTMAiw5hBC9uuZCykBpvSBzrghH1
VFEKveBeBPvtsErG7AapIYpw8r7flpib2Jt7S/c17mjTM1CiD3F2JWWMAHLD6yaM
L2LSz1/09dfYe8TJS4gHhf/1xyh1sB8khjtdvVMa0S9nAPs3CaaX3ZaO8VApxs3f
BPVhu9+dlTurZbk0xFejuA3asm0d3035MBkJGYBufzge75O389jTUcFkpxcGYrrU
Pgzv9vdABhwJ0RltiGRvtu/pC8csUdbVObgTbpnKAaBlyKAZ3mSWMo7uEvXEp2jP
e2WQfk2EiaXEzYgV88CB
=RldU
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fff77803-e3f8-d3ea-8491-9a102f36bcca%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Networking Disabled - cannot enable NetworkManager Applet [sys-firewall]

2016-07-07 Thread jefferson_plague
Hello Andrew 

> This is the NetworkManager applet running in sys-firewall. Normally,
> sys-firewall is connected to sys-net for network access, and the
> NetworkManager applet only runs in sys-net. (The situation can be
> different if you're running things like VPN VMs, but we'll set those
> aside here.)
> 
> In short: the NetworkManager applet shouldn't be visible in
> sys-firewall in the first place, but it's not a big problem (just a
> confusing one). There's normally a script that hides it, but in your
> case, that's not working for some reason.

My set up is standard with the only change from fresh installation being the 
updating of templates and dom0. Is this difference of NetworkManager appearing 
an indication of any loss of function or security?

>So, are you still having problems updating dom0 and your templates? If 
>so, can you explain the problems? 

There were issues with dom0. The link below give the solution:
https://groups.google.com/forum/#!searchin/qubes-users/errno$2014$20curl$2337/qubes-users/zMETrlPMqng/GcwIPcZ8BQAJ

The whonix templates were difficult. I was able to update them however I still 
get a whonixcheck error for the whonix gateway. It reads "WARNING: Whonix Meta 
Packages Test Result: Whonix-Gateway detected, but the meta package 
qubes-whonix-gateway is not installed. Did you accidentally uninstall it?"

I followed the steps from this discussion:
https://groups.google.com/forum/#!searchin/qubes-users/meta$20package$20qubes-whonix-gateway$20is$20not$20installed/qubes-users/P2BTCOPcTnU/xHXxMEzLPwAJ

This did not work:
"sudo apt-get install qubes-whonix-workstation" on WS template
"sudo apt-get install qubes-whonix-gateway" on GW template. 

Another similar command to the two above worked. However the autoremove command 
did not work. I was root and met the requirements it seemed to need. 

The sanity check from here did not work, returning 1 instead of 0. The command 
was not recognised:
https://www.google.com/url?q=https%3A%2F%2Fwww.whonix.org%2Fwiki%2FUpgrading_Whonix_12_to_Whonix_13=D=1=AFQjCNGFl1_nVVp9x0MIL9am3BnI9-vOlA

I would like to learn how to fix this meta package error. From what I have read 
here it would be a risk to my security to bypass this issue.
https://www.whonix.org/wiki/Whonix_Debian_Packages#What_is_the_disadvantage_of_removing_a_meta_package.3F

Thank you for providing some sources. Are there any that I can learn to better 
navigate qubes and use basic code? I will keep looking through the 
documentation. Aside for running an update on a VM is there anyway to check if 
the VM (or dom0) is up to date?

-- 
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/e23a296a-8af4-4c08-bc3f-b458b20b5137%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Connection via a proxyVM with a VPN client, VM's have no acces to LAN devices

2016-07-07 Thread Fredrik
How do I I set up access to my LAN devices? In this case my NAS that is located 
on my 192.168.1.1/24 network. The VM's are of course NAT in this case 
10.137.4/24.

My proxy-vm is connected to the default sys-firewall if i switch to sys-net I 
can access my nas for a minute or so then it stops working. I could  see it 
stop working at the same time since I pinged the NAS from 3 VM's.

What am I doing wrong?

-- 
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/9e43e5ba-e7bb-4cd9-999a-c3cb07ac5087%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Xen exploit talk at Black Hat

2016-07-07 Thread J.M. Porup
https://www.blackhat.com/us-16/briefings.html#ouroboros-tearing-xen-hypervisor-with-the-snake

Ouroboros: Tearing Xen Hypervisor with the Snake


The Xen Project has been a widely used virtualization platform powering
some of the largest clouds in production today.

Sitting directly on the hardware below any operating systems, the Xen
hypervisor is responsible for the management of CPU/MMU and guest
operating systems.

Guest operating systems cound be controled to run in PV mode using
paravirtualization technologies or HVM mode using hardware-assisted
virtualization technologies.

Compare to HVM mode, PV mode guest OS kernel could recognize the
existence of hypervisor and, thus, work normally via hypervisor
inferfaces which are called hypercalls. While performing priviledged
operations, PV mode guest OS would submit requests via hypercalls then
the hypervisor do these operations for it after verifying its requests.

Inspired by Ouroboros, an ancient symbol with a snake bitting its tail,
our team has found a critical verification bypass bug in Xen hypervisor
and that will be used to tear the hypervisor a hole. With sepecific
exploition vectors and payloads, malicious PV guest OS could control not
only the hypervisor but also all other guest operating systems running
on current platform.

by Shangcong Luan of Alibaba

https://www.blackhat.com/us-16/speakers/Shangcong-Luan.html

-- 
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/20160707194929.GI1114%40fedora-21-dvm.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Chris Laprise



On 07/07/2016 12:45 PM, Duncan Guthrie wrote:


On 7 July 2016 16:53:35 BST, Chris Laprise  wrote:

On 07/07/2016 10:40 AM, Duncan Guthrie wrote:

On 7 July 2016 03:28:48 BST, Chris Laprise 

wrote:

On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:

I'm not so adamant about wanting gpu passthrough on qubes,  cause

imo,  gaming online usually means all security is out the window.

Plus

I feel as though gpu is much bigger attack surface for side channel
attacks then net card.  I could be wrong because I have no clue

about

low level stuff, but I feel it would somehow undermine purpose of

using

qubes.  Maybe I'm wrong.

I think this is wrong because many kinds of apps rely on GPUs now:
Media
decoding and creation, 3D design and printing (I would love to have
even
just SketchUp on Qubes!), and any other responsive 3D interface that
app
designers want to offer. This even includes web pages,

crypto-currency,

and many scientific apps. GPUs are now general processing engines

that

embody MOST of a typical computer's processing power.

This is not about games.


I think this is wrong. Most heavy computer users work in offices and

do word processing and spreadsheets, the 'average' casual use is
generally web browsing and light media consumption.

Qubes works fine for using Libreoffice, web applications and social

media, and programming e.g. in Python. Graphics designers can use GIMP
or InkScape, or any of the Windows programs that they commonly use.

It is true that you won't be able to use 3D applications like

SketchUp, but I do not think such tasks constitute most of the average
workload as you say. Perhaps they make up most of your workload, but I
don't think that you speak for everyone here. I have found Qubes works
for me, and people I know do similar tasks on their computers.

Furthermore, there is no getting around the fact that visual

rendering

is integral to security. The GPU can see any private info that you

can,

and if compromised can take steps to trick users into sabotaging

their

own privacy and security. Like the CPU, the GPU must be accepted as

a

core component of trust, and protected as such... at least any GPU

that

operates the admin and trusted domains.

It is fortunate that we at least have a trend of integrated GPUs (in
APUs) where the GPU is manufactured into the same package as the
(implicitly) trusted CPU. For the time being, this is a boost to

Qubes'

compatibility and security even if the GPUs are under-utilized.

For Qubes to either 1) give up on GPU support, or 2) relegate them

to

untrusted status would be an _irretrievable_ error in judgment. It
would
make the OS a 21st century terminal application, because the lions
share
of the power expected by PC users would be missing (as it is
currently).

Chris


I dispute this argument. Dropping "GPU support" (I am not sure where

you get this impression) is hardly going to make Qubes a terminal
application. You can use anything that uses 2D graphics, and can play
music and movies, and do word processing, and email, and software
development, and... The list goes on. Qubes is about security, and
allowing such high level access for the GPU is a terrible compromise.

I am not proposing that domUs have direct access to graphics systems
operating in dom0. GPU access needs to be properly virtualized, and
thankfully some groundwork by Intel (and probably others) has been laid

for it. Alternately, a specification for well-behaving discrete
graphics
could make graphics passthrough a realistic option for many people.

Marek has already stated that any domU used for primary graphics (as
unrealistic as that may be, given the state of passthrough
compatibility) will be a trusted one, and that the purpose of such an
implementation would be to facilitate the use of Linux graphics drivers

while the rest of the OS slims down and experiments with microkernel
admin and storage vms.

The current state is, of course, one of trusting the GPU. That poses a
problem for those who want both discrete graphics and anti-tampering
(AEM) but otherwise? I don't see the compromise you mention.


What are you suggesting then? You are criticising Qubes for not having good GPU 
support, but recognise that you can't have good security when GPU has access to 
hardware? I am sorry but I don't understand your point fully, and would 
appreciate it if you could elaborate further. What is your solution, do you 
want there to be virtualised domains for GPU? If I remember correctly, this is 
a feature being worked on.


Qubes doesn't have good GPU support; It is a work in progress on many 
fronts.


I mentioned that it could go in the direction of GPU virtualization or 
better passthrough support, or both. In either case, there would still 
be a protected primary graphics card that would at least render dom0 and 
other trusted domains. But with the former, the primary graphics can 
also safely process requests 

[qubes-users] Re: Qubes Screenshot Tool with imgurl auto upload available. [beta]

2016-07-07 Thread JPL
Works really well. Thanks. Another job made a hell of a lot easier.

On Saturday, July 2, 2016 at 9:57:07 PM UTC+1, Eva Star wrote:
> Okey. I released tool that can automatically capture 
> fullscreen/windows/regions and upload it to AppVM and imgurl automaticaly.
> 
> 
> Now it is in beta state and tested only with Qubes 3.2rc1, but I think it 
> will work with other Qubes starting from R3.0 or R3.1 (where qvm-run is 
> available)
> 
> 
> Full description and download you can find here: 
> 
> 
> https://github.com/evadogstar/qvm-screenshot-tool
> 
>  
> Test it and I hope you will be happy with it as I am :) Because screenshots 
> is one weak side of Qubes (before this tool done ;) 
> 
> 
> Plans: 
> * add editor for images at AppVM to blur some arias on image... (suggest are 
> welcome)
> * multiple selections -> one screenshots -> upload it
> * delayed screenshots
> * maybe uploading any existed image from dom0 to imgurl after selecting it on 
> dialog
> 
> 
> Enjoy but remember that is only beta

-- 
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/b2e8a60b-7124-451b-a17a-702ee78c258f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Duncan Guthrie


On 7 July 2016 16:53:35 BST, Chris Laprise  wrote:
>On 07/07/2016 10:40 AM, Duncan Guthrie wrote:
>>
>> On 7 July 2016 03:28:48 BST, Chris Laprise 
>wrote:
>>> On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:
 I'm not so adamant about wanting gpu passthrough on qubes,  cause
>>> imo,  gaming online usually means all security is out the window. 
>Plus
>>> I feel as though gpu is much bigger attack surface for side channel
>>> attacks then net card.  I could be wrong because I have no clue
>about
>>> low level stuff, but I feel it would somehow undermine purpose of
>using
>>> qubes.  Maybe I'm wrong.
>>>
>>> I think this is wrong because many kinds of apps rely on GPUs now:
>>> Media
>>> decoding and creation, 3D design and printing (I would love to have
>>> even
>>> just SketchUp on Qubes!), and any other responsive 3D interface that
>>> app
>>> designers want to offer. This even includes web pages,
>crypto-currency,
>>>
>>> and many scientific apps. GPUs are now general processing engines
>that
>>> embody MOST of a typical computer's processing power.
>>>
>>> This is not about games.
>>>
>> I think this is wrong. Most heavy computer users work in offices and
>do word processing and spreadsheets, the 'average' casual use is
>generally web browsing and light media consumption.
>> Qubes works fine for using Libreoffice, web applications and social
>media, and programming e.g. in Python. Graphics designers can use GIMP
>or InkScape, or any of the Windows programs that they commonly use.
>> It is true that you won't be able to use 3D applications like
>SketchUp, but I do not think such tasks constitute most of the average
>workload as you say. Perhaps they make up most of your workload, but I
>don't think that you speak for everyone here. I have found Qubes works
>for me, and people I know do similar tasks on their computers.
>>
>>> Furthermore, there is no getting around the fact that visual
>rendering
>>> is integral to security. The GPU can see any private info that you
>can,
>>>
>>> and if compromised can take steps to trick users into sabotaging
>their
>>> own privacy and security. Like the CPU, the GPU must be accepted as
>a
>>> core component of trust, and protected as such... at least any GPU
>that
>>>
>>> operates the admin and trusted domains.
>>>
>>> It is fortunate that we at least have a trend of integrated GPUs (in
>>> APUs) where the GPU is manufactured into the same package as the
>>> (implicitly) trusted CPU. For the time being, this is a boost to
>Qubes'
>>>
>>> compatibility and security even if the GPUs are under-utilized.
>>>
>>> For Qubes to either 1) give up on GPU support, or 2) relegate them
>to
>>> untrusted status would be an _irretrievable_ error in judgment. It
>>> would
>>> make the OS a 21st century terminal application, because the lions
>>> share
>>> of the power expected by PC users would be missing (as it is
>>> currently).
>>>
>>> Chris
>>>
>> I dispute this argument. Dropping "GPU support" (I am not sure where
>you get this impression) is hardly going to make Qubes a terminal
>application. You can use anything that uses 2D graphics, and can play
>music and movies, and do word processing, and email, and software
>development, and... The list goes on. Qubes is about security, and
>allowing such high level access for the GPU is a terrible compromise.
>
>I am not proposing that domUs have direct access to graphics systems 
>operating in dom0. GPU access needs to be properly virtualized, and 
>thankfully some groundwork by Intel (and probably others) has been laid
>
>for it. Alternately, a specification for well-behaving discrete
>graphics 
>could make graphics passthrough a realistic option for many people.
>
>Marek has already stated that any domU used for primary graphics (as 
>unrealistic as that may be, given the state of passthrough 
>compatibility) will be a trusted one, and that the purpose of such an 
>implementation would be to facilitate the use of Linux graphics drivers
>
>while the rest of the OS slims down and experiments with microkernel 
>admin and storage vms.
>
>The current state is, of course, one of trusting the GPU. That poses a 
>problem for those who want both discrete graphics and anti-tampering 
>(AEM) but otherwise? I don't see the compromise you mention.
>

What are you suggesting then? You are criticising Qubes for not having good GPU 
support, but recognise that you can't have good security when GPU has access to 
hardware? I am sorry but I don't understand your point fully, and would 
appreciate it if you could elaborate further. What is your solution, do you 
want there to be virtualised domains for GPU? If I remember correctly, this is 
a feature being worked on.

>Defining personal computing and what most people want as a list of 
>traditional activities--instead of using examples of innovative apps
>and 
>the kind of directions app developers can go--is a mistake that leads 
>projects into 

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Chris Laprise

On 07/07/2016 10:40 AM, Duncan Guthrie wrote:


On 7 July 2016 03:28:48 BST, Chris Laprise  wrote:

On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:

I'm not so adamant about wanting gpu passthrough on qubes,  cause

imo,  gaming online usually means all security is out the window.  Plus
I feel as though gpu is much bigger attack surface for side channel
attacks then net card.  I could be wrong because I have no clue about
low level stuff, but I feel it would somehow undermine purpose of using
qubes.  Maybe I'm wrong.

I think this is wrong because many kinds of apps rely on GPUs now:
Media
decoding and creation, 3D design and printing (I would love to have
even
just SketchUp on Qubes!), and any other responsive 3D interface that
app
designers want to offer. This even includes web pages, crypto-currency,

and many scientific apps. GPUs are now general processing engines that
embody MOST of a typical computer's processing power.

This is not about games.


I think this is wrong. Most heavy computer users work in offices and do word 
processing and spreadsheets, the 'average' casual use is generally web browsing 
and light media consumption.
Qubes works fine for using Libreoffice, web applications and social media, and 
programming e.g. in Python. Graphics designers can use GIMP or InkScape, or any 
of the Windows programs that they commonly use.
It is true that you won't be able to use 3D applications like SketchUp, but I 
do not think such tasks constitute most of the average workload as you say. 
Perhaps they make up most of your workload, but I don't think that you speak 
for everyone here. I have found Qubes works for me, and people I know do 
similar tasks on their computers.


Furthermore, there is no getting around the fact that visual rendering
is integral to security. The GPU can see any private info that you can,

and if compromised can take steps to trick users into sabotaging their
own privacy and security. Like the CPU, the GPU must be accepted as a
core component of trust, and protected as such... at least any GPU that

operates the admin and trusted domains.

It is fortunate that we at least have a trend of integrated GPUs (in
APUs) where the GPU is manufactured into the same package as the
(implicitly) trusted CPU. For the time being, this is a boost to Qubes'

compatibility and security even if the GPUs are under-utilized.

For Qubes to either 1) give up on GPU support, or 2) relegate them to
untrusted status would be an _irretrievable_ error in judgment. It
would
make the OS a 21st century terminal application, because the lions
share
of the power expected by PC users would be missing (as it is
currently).

Chris


I dispute this argument. Dropping "GPU support" (I am not sure where you get 
this impression) is hardly going to make Qubes a terminal application. You can use 
anything that uses 2D graphics, and can play music and movies, and do word processing, 
and email, and software development, and... The list goes on. Qubes is about security, 
and allowing such high level access for the GPU is a terrible compromise.


I am not proposing that domUs have direct access to graphics systems 
operating in dom0. GPU access needs to be properly virtualized, and 
thankfully some groundwork by Intel (and probably others) has been laid 
for it. Alternately, a specification for well-behaving discrete graphics 
could make graphics passthrough a realistic option for many people.


Marek has already stated that any domU used for primary graphics (as 
unrealistic as that may be, given the state of passthrough 
compatibility) will be a trusted one, and that the purpose of such an 
implementation would be to facilitate the use of Linux graphics drivers 
while the rest of the OS slims down and experiments with microkernel 
admin and storage vms.


The current state is, of course, one of trusting the GPU. That poses a 
problem for those who want both discrete graphics and anti-tampering 
(AEM) but otherwise? I don't see the compromise you mention.


Defining personal computing and what most people want as a list of 
traditional activities--instead of using examples of innovative apps and 
the kind of directions app developers can go--is a mistake that leads 
projects into an unbearable surfeit of unsupported corner cases. And 
seriously-- if that's what it would come to then just develop a 
convenient firmware verification and re-flashing system and run TAILS on 
the hardware; it would save considerable time and effort.


An accurate view of use cases would hardly stop at office software and 
playing music because almost everyone has make-or-break corner cases. 
Teleconferencing and 3D printing, for example, are now SMB and home user 
activities that benefit from GPUs, which become more necessary due to 
the extra CPU overhead of domain isolation.


As for suggesting server-based processing of large jobs to Qubes 
users... I'm not even sure where to start with that one.


Chris



[qubes-users] Possible to give global access to second harddrive?

2016-07-07 Thread Fredrik
I have a seccond harddrive I only plan to use for media and downloading. What 
is the easiest or preferred way to give all or some of my VMs acces to it?

setting  up a share would mean opening the firewall and that seams like bad idé 
sins dom0 is the only VM that can see it for now.  

-- 
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/411e703e-1a7f-466d-a72c-1a67c9e44b47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Duncan Guthrie


On 7 July 2016 03:28:48 BST, Chris Laprise  wrote:
>On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:
>> I'm not so adamant about wanting gpu passthrough on qubes,  cause
>imo,  gaming online usually means all security is out the window.  Plus
>I feel as though gpu is much bigger attack surface for side channel
>attacks then net card.  I could be wrong because I have no clue about
>low level stuff, but I feel it would somehow undermine purpose of using
>qubes.  Maybe I'm wrong.
>
>I think this is wrong because many kinds of apps rely on GPUs now:
>Media 
>decoding and creation, 3D design and printing (I would love to have
>even 
>just SketchUp on Qubes!), and any other responsive 3D interface that
>app 
>designers want to offer. This even includes web pages, crypto-currency,
>
>and many scientific apps. GPUs are now general processing engines that 
>embody MOST of a typical computer's processing power.
>
>This is not about games.
>
I think this is wrong. Most heavy computer users work in offices and do word 
processing and spreadsheets, the 'average' casual use is generally web browsing 
and light media consumption.
Qubes works fine for using Libreoffice, web applications and social media, and 
programming e.g. in Python. Graphics designers can use GIMP or InkScape, or any 
of the Windows programs that they commonly use.
It is true that you won't be able to use 3D applications like SketchUp, but I 
do not think such tasks constitute most of the average workload as you say. 
Perhaps they make up most of your workload, but I don't think that you speak 
for everyone here. I have found Qubes works for me, and people I know do 
similar tasks on their computers.

>Furthermore, there is no getting around the fact that visual rendering 
>is integral to security. The GPU can see any private info that you can,
>
>and if compromised can take steps to trick users into sabotaging their 
>own privacy and security. Like the CPU, the GPU must be accepted as a 
>core component of trust, and protected as such... at least any GPU that
>
>operates the admin and trusted domains.
>
>It is fortunate that we at least have a trend of integrated GPUs (in 
>APUs) where the GPU is manufactured into the same package as the 
>(implicitly) trusted CPU. For the time being, this is a boost to Qubes'
>
>compatibility and security even if the GPUs are under-utilized.
>
>For Qubes to either 1) give up on GPU support, or 2) relegate them to 
>untrusted status would be an _irretrievable_ error in judgment. It
>would 
>make the OS a 21st century terminal application, because the lions
>share 
>of the power expected by PC users would be missing (as it is
>currently).
>
>Chris
>

I dispute this argument. Dropping "GPU support" (I am not sure where you get 
this impression) is hardly going to make Qubes a terminal application. You can 
use anything that uses 2D graphics, and can play music and movies, and do word 
processing, and email, and software development, and... The list goes on. Qubes 
is about security, and allowing such high level access for the GPU is a 
terrible compromise.

>> Plus as a gamer myself,  I always want the most fps the machine can
>dish,  and that's definitely not by running games in a vm.
>>
>> I have a separate machine for sensitive and daily tasks running
>qubes.  Most people use consoles for gaming now anyways.  Hardware
>industry has been dying for a decade and I never had any reason or
>thought I would ever build a custom pc again,  until qubes!  :)
>>
If you are doing something really heavy like statistical work you often would 
use a dedicated server for this. As far as I know connecting to such servers 
would be possible using Qubes. At any rate you could always use Qubes for 
personal use and then have a dedicated work computer for stats, 3D development, 
etc.

These are just my own observations.
Hope it helps, 
D.

-- 
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/8BF8CE0E-1077-441A-B41C-1D7CE520EF64%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Problem with chrony package installing on Qubes Release 3.2-rc1

2016-07-07 Thread Jeral
And is it possible to install the default VMs (sys-net, sys-firewall etc) 
manually by running some script?

-- 
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/3866f4db-ceaa-4b72-8538-19c309ef2fcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.1 crashing, no warning, no error message (Lenovo X230)

2016-07-07 Thread Chris Laprise

On 07/07/2016 06:49 AM, Andreas Rasmussen wrote:


On 07/07/2016 05:32 AM, Chris Laprise wrote:

On 07/06/2016 01:28 PM, Andreas Rasmussen wrote:

Hi!

I bought a Lenovo x230 and installed Qubes 3.1 early may. It has worked
like a charm, but in the last two or three weeks the computer has been
shutting down without warning or error message. It has happened five
times with no apparent pattern. It has both happened with both many and
few VM's open.

The crash goes like this: The screen freezes for 3-5 seconds, then the
computer reboots. I get no error message. The reboot looks like a normal
boot.

I have tried to look in the logfiles, but I'm not sure I'm looking the
right places. So for starters: Can anyone tell me what files to look in?
/var/log/messages only seem to have information about the session after
the crash, same goes for boot.log.

(My computer skills are limited, so please bare with me)

best,

Andreas

Logitech mice are known to trigger this bug.

Chris
.


Where do I read more on this? Thanks for the input!



https://github.com/QubesOS/qubes-issues/issues/1689

Chris

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bc8b377e-8d90-5594-27d7-94d2e9b4261e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.1 crashing, no warning, no error message (Lenovo X230)

2016-07-07 Thread Andreas Rasmussen


On 07/07/2016 05:32 AM, Chris Laprise wrote:
> On 07/06/2016 01:28 PM, Andreas Rasmussen wrote:
>> Hi!
>>
>> I bought a Lenovo x230 and installed Qubes 3.1 early may. It has worked
>> like a charm, but in the last two or three weeks the computer has been
>> shutting down without warning or error message. It has happened five
>> times with no apparent pattern. It has both happened with both many and
>> few VM's open.
>>
>> The crash goes like this: The screen freezes for 3-5 seconds, then the
>> computer reboots. I get no error message. The reboot looks like a normal
>> boot.
>>
>> I have tried to look in the logfiles, but I'm not sure I'm looking the
>> right places. So for starters: Can anyone tell me what files to look in?
>> /var/log/messages only seem to have information about the session after
>> the crash, same goes for boot.log.
>>
>> (My computer skills are limited, so please bare with me)
>>
>> best,
>>
>> Andreas
> 
> Logitech mice are known to trigger this bug.
> 
> Chris
> .
> 

Where do I read more on this? Thanks for the input!

-- 
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/44b9d32a-3fff-9c34-a54b-d847e9a6c6fd%40andreas-rasmussen.dk.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes Version from CLI

2016-07-07 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-06 23:00, Drew White wrote:
> On Thursday, 7 July 2016 13:50:45 UTC+10, Andrew David Wong
> wrote:
>> It's the only way that I'm aware of, and it seems to be a
>> standard way of storing version information:
>> 
>> $ ls /etc/ | grep release fedora-release@ os-release 
>> qubes-release redhat-release@ system-release@ system-release-cpe
> 
> Well that's fair enough then.
> 
> Any idea when your new Qubes-Manager is meant to be coming out to
> test?
> 

It's on hold until we can find a GNOME/GTK developer:

https://www.qubes-os.org/join/#tocAnchor-1-1-5

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXfhJzAAoJENtN07w5UDAwRpsQAJ07v7cKl5sywv47dyr0xYmL
KVjRTk/Hpk2HRldMuzWxHr6/jDMNeoM5/yaFgFtpDcOzvloGVyHm83Cd7Z6M6+ww
YTCi4Ljta8nojcjiSxc1L26ckd2bCNGTEU6bKgX+NBLg6YS67nXUO1EsVI+OIC6Z
5YhS+KV2/OOaWe/lwR66sTM8tqn8D+bjY+1Z6tpIENDO6YJc/NVgic2OJ3InL97s
bWxPpOLkVk3LI6a0SMcPCRFm1nRG7IuiOW2EFt5qFi9X/Az4I9m+e41sZYCoPFZE
ak+8TPYhN4uZdcLRCjTnD2G9Bbxx4M7C7e3QzCMznejZ/8G5c/LnrUGzv80QeWKb
NwmLHEFC5hRnwI1TOw4pxOp5NSEKWA3nqjIetH42gC4n2PN47xHLz9X3ymXAesam
apxAwSAbedsx6CJ3kshl9lvdrsLNiG2Ol3q650ZsP4X4Btm766mmi33zs6MvYPK/
aR07vVtiU1hCNkjV13JcA9leZC3KK6iLioos3iwqTKvBQsNbHYZXzevAUbOoq74C
tMVZY4dWXQ312iuF6D4qdrxsMK3cWy+jX24ULYxJ5kTgkN+UOcVRiqeuW4kRjfec
9wGqbEDssIt/k3JylVYUwVBjii5lRYwRaJ165M4G4HpNOEjhKkhLCPqMw7NkkwNB
XwZuKa+KmvtlUAzd1xFi
=YGdo
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7e38af5f-5deb-10c8-5a26-bcf960d7e9e7%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: newbie question about port forwarding and remote connection

2016-07-07 Thread Nicola Schwendener
Hi Eva, 
thank you very much for your time and your answer:
> > ... this is the most important question: you mean I cannot attach a second 
> > disk to my HVM windows? or I cannot attach automatically on startup?
> >
> Yes, you can not attach it to windowsHVM by default. You can enable this 
> option, but (currently) it can lead to data loss.
> 
> But you can attach your other disks to any other unix based AppVMs and 
> download files, then move files to WindowsHVM without any troubles.
I think I cannot understand... I've a bunch of disks in raid (almost 4TB) that 
are currently a second disk in a Windows environment. These data are documents, 
photo (>100'000), videos (>10'000), music  
when you say:
> But you can attach your other disks to any other unix based AppVMs and 
> download files, then move files to WindowsHVM without any troubles.
you mean I've to copy or to move from the data disk mounted on a Linux appVM to 
a "temporary" folder in windows, edit (or do whatever I want) and then move 
back to the linux appvm and back to the data disk? 
I imagine doing that for a bunch of files are ok... but If, for example, I need 
to work with lightroom or other tools that collect, organize all files, is 
impossible.

best regads
Nick

-- 
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/dea90c77-b95d-420e-ab0b-0984cccacbb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] newbie question about port forwarding and remote connection

2016-07-07 Thread Nicola Schwendener
Hi Andrew,
thank you very much for your reply... I understood the templateVM in a linux 
environment, but my doubts are on a windows template hvm. Windows normally 
changes many files during normal operations (open documents, ...) normally in 
the programdata folder. in a normal hvm I guess these files will be updated, in 
a template-hvm no... is it correct? then how can works third party services in 
a template-hvm? do they interact with the user? 
thank you very much.
best regards
Nick

-- 
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/4249dc8c-7fdf-4711-bdf4-794d5712ae9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.