Re: [qubes-users] Re: Crossover (Office 2016) and Qubes 4rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Dec 12, 2017 at 09:00:23AM -0800, Adrian Rocha wrote: > Hi, > > I am using Crossover on Qubes 3.2. I suppose that it have to work fine in > Qubes 4. > You just have to install it and register on the template VM, like any other > software. After that you can install the Windows apps in the App VM because > they are installed in the user home dir I have Crossover installed in one AppVMs. All you need to do before it, is to make its directories stored on /rw to not vanish after VM restart. Do it by creating /rw/config/qubes-bind-dirs.d/cxoffice.conf: binds+=( '/opt/cxoffice' ) binds+=( '/etc/crossover.conf' ) Then install crossover, and execute /usr/lib/qubes/init/bind-dirs.sh to actually move the files to /rw (just one time operation after install). I use it very rarely, for Excel 2007... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJaMFfZAAoJENuP0xzK19csRHUH/26Eq6lLRvAHOA2BFGh7HqEL ri6ugsnRo86hmS8BQIR8FPgy4iyjrNNJ7fhlvlVkKepi4EiX4dNasA+lD1Vt4idF oGhkQv1D7fZnXEUhb1v33+dkj6kKuy8uN0P1NNGCom8THZ+jw7RPCW+auLDCArBm uv7MAIeuNQTNt70RCu5mrN9xNjuqzIksFhAz3PvFJnCc1SGhL9p+UGgmvmPsmKDd cEae4dNeb5UGOKjVa0BD/ejzy+XBSgLUTSJFhssYqriY0DE1UpH0oo0iSd2iqPpL Tqr5xRi0L7Vlw/VcqDVBNu3XuU4I0ALnF3lNbZRM9T6LQeYeD4ZABDFdUsUznzI= =M/2m -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/20171217030355.GB21185%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Q4rc3 debian-9 template fails to update.
On Saturday, December 16, 2017 at 2:49:19 PM UTC+1, haaber wrote: > >> I freshly installed debian-9 ; when installing packages, apt-get hangs > >> for days(!) with > >> > >> 81% [waiting for headers] ... > >> followed by Err:XX Connection failed. > >> > > > 2) Does restarting all of Qubes, and immediately update debian-9 after full > > startup, make any difference? I.e. I've experienced issues on longer > > running Qubes 4 my self, but mostly my issues are triggered by > > suspend/hibernate or if HDMI plugged TV-screen goes to sleep mode on its > > own (even if laptop screen is not sleeping). It triggers various of weird > > system issues, I'm suspecting it's driver-module/kernel related, but I'm > > not really all that sure. A full system restart however, makes everything > > work fully again. Perhaps you experience something similar, yet different > > at the same time. Either way, quick way to find out whether a full restart > > works or not. > > YES! So I guess things are linked to hilbernation problems when I close > the lid. Is there another cure than full reboot? Bernhard aha, this should narrow it down to possible suspects indeed. Just to be sure, there might still be a possibility that the restart fixed another issue, of an origin we didn't speculate about. Was it a single case issue the restart fixed? Or do you encounter repeatedly issues after hibernation which are fixed with restarts? Just to verify, so we don't jump to conclusions too fast. I'm guessing your issue is pretty much similar to my own, except we experience somewhat different symptoms, originating from the same cause - hibernate/suspend. You can see my github issue rapport here from a few weeks back (I haven't had the time to keep the rapport updated due to emerging deadlines hunting me down, but I plan to return to it eventually. Also it was different back then, the issue I rapported back then has changed somewhat (slightly) between that date and today. I plan to update there soon as well); https://github.com/QubesOS/qubes-issues/issues/3359 Feel free to add your own experiences of the issue if you think it has similar root causes. The symptoms might be different, but the cause/trigger appears to the similar. Possibly it's the admin mechanism that breaks down? I experience issues in the domU windows, like the Qubes coloured panels, or Qubes widgets, general graphical freezes, or entire forced restarts during suspend because it doesn't suspend while in my bag but stays awake when it's supposed to be suspending, etc. Perhaps, your issue is similar, but you get networking issues instead, i.e. when updating. So all this might be somehow related to the admin mechanism, I'm speculating now though, but it seems like a good place to start given the clues so far seems indirectly to point towards it. You can throw a link there back to this thread on github, if you find it useful to do so, if you decide to make a post on the github thread. If you don't plan to post on github, do you mind if I link to this thread instead for extra references? Once I get around to it of course. I think it's a good idea to show more people have this issue (assuming it indeed has a shared trigger/cause), perhaps it can provide extra clues of the overall bug. The problem right now though, is to narrow it down more precisely, so the exact issue can be found. Also, something that changed in recent updates (I'm sitting on current-testing updates), is that it now appears to be enough to only restart all network based VM's (non network based VM's are fine and don't need restart). Basically, sys-net and sys-firewall are messed up. This makes it easier, as it no longer requires a full system restart. Is this the same for you too? -- 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/259fe4c4-8d36-47a1-bfa5-f141c04cb9ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Q4rc3 debian-9 template fails to update.
On Saturday, December 16, 2017 at 10:21:32 AM UTC+1, haaber wrote: > I freshly installed debian-9 ; when installing packages, apt-get hangs > for days(!) with > > 81% [waiting for headers] ... > followed by Err:XX Connection failed. > > Has someone an idea where to look / how to procede? (there is definitely > no other apt* running ). Thank you, Bernhard -- 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/0e095044-29a5-4699-9f79-2d03a3adbcfe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [Newbie] RDP client unable to connect to server through vpn
Gustavo Lapido Loureiro: > I setup a vpn connection following tasket's Qubes-vpn-support. > (https://github.com/tasket/Qubes-vpn-support) > > I was able to connect to the vpn remote server and browse its web server > content with Firefox. > > However, when I try to use Remmina to connect to the remote rdp server, it > times out. > > Is this something being blocked by the firewall? > > I understand that this isn't some purelly Qubes issue, and it probably isn't > an issue after all, just some setting that should be tinkered (firewall?). > > The point is that, with all these qubes I'm kind of lost where to start > debugging, what to change and where. > If you want to tunnel your RDP connection through your VPN connection, then try connecting to the RDP server via its tun0 (private LAN) IP address. Example: openvpn's default subnet IIRC is 10.8.0.0/24 which means that the RDP server on your VPN server is listening on 10.8.0.1:3389. Make sure your server is accepting incoming connections on port 3389. There shouldn't be any issues sending traffic out from Qubes. -- 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/82e8e0f6-d3cc-6133-5e8e-de69549d67ed%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [Newbie] RDP client unable to connect to server through vpn
I setup a vpn connection following tasket's Qubes-vpn-support. (https://github.com/tasket/Qubes-vpn-support) I was able to connect to the vpn remote server and browse its web server content with Firefox. However, when I try to use Remmina to connect to the remote rdp server, it times out. Is this something being blocked by the firewall? I understand that this isn't some purelly Qubes issue, and it probably isn't an issue after all, just some setting that should be tinkered (firewall?). The point is that, with all these qubes I'm kind of lost where to start debugging, what to change and where. -- 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/7aeffc33-f75a-4765-8dda-b84059f92d6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Sat, December 16, 2017 2:25 am, Yuraeitha wrote: > Aight, so the idea of this thread, is to get an overview of where we > stand, that is, how far are we away from archiving GPU Passthrough on > Qubes. If you look at how the "competition" is approaching it, you need GPU hardware capable of virtualization such as Nvidia Grid, Radeon Sky(?), Intel GVT-g and hypervisor support. https://www.nvidia.com/object/grid-technology.html https://www.amd.com/en-us/innovations/software-technologies/sky https://01.org/igvt-g https://code.vmware.com/article-detail/-/asset_publisher/8n011DnrSCHt/content/vsga-datasheet https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-configuring-graphics.pdf Not something I've ever played with, but it seems kind of like IOMMU to me. You could write a software layer to provide slow virtualized GPUs, or use hardware for faster ones. Of these, it seems like Intel's approach is the most open source friendly. XenGT has working code. No idea how hard it would be to integrate with Qubes, though. > I must be tired, I initially wrote 'qubestions' instead of 'questions' > here... aight, so possible questions for the discussion. I like it! Let's rename the FAQ to Frequently Asked Qubestions. -- 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/61a84e9c7dc6a5d9303fdd39f3c25ca9.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to use wifi card with Kali ?
On Fri, December 15, 2017 9:07 pm, axel.schwoerer via qubes-users wrote: > Hello all. > I've installed Kali Linux template on Qubes, and I want to know if it > possible to use the wifi cards computer or to use an external wifi card > (like AWUS036h) ? Short answer is probably. See http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html for some ways you could approach it. Specifics are going to depend on if you need the ability to directly access the NIC to craft packets for example. The ability to directly attach devices in general to a Qube depends on hardware make and model, how well your computer supports it, etc. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2a8306099c189be338d5e6b7c7f8be14.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Atheros AR928X & Q4.0rc3 Passthrough
Getting crashes on domU boot with an assigned Atheros wireless PCIe card
under Qubes 4.0rc3 with both PV and HVM. Any suggestions how to accomplish
it? Some of the posts/threads I find go back to 2010 but I'm still
stumped.
*
dom0 shows:
Dec 16 05:12:14 dom0 kernel: pci :02:00.0: [168c:002a] type 00 class
0x028000
Dec 16 05:12:14 dom0 kernel: pci :02:00.0: reg 0x10: [mem
0xf010-0xf010 64bit]
Dec 16 05:12:14 dom0 kernel: pci :02:00.0: supports D1
Dec 16 05:12:14 dom0 kernel: pci :02:00.0: PME# supported from D0 D1
D3hot
Dec 16 05:12:14 dom0 kernel: pci :02:00.0: disabling ASPM on pre-1.1
PCIe device. You can enable it with 'pcie_aspm=force'
...
Dec 16 05:12:14 dom0 kernel: pci :02:00.0: Signaling PME through PCIe
PME interrupt
...
Dec 16 05:12:16 dom0 kernel: pciback :02:00.0: seizing device
Dec 16 05:12:16 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:12:16 dom0 kernel: Already setup the GSI :17
*
With qvm-prefs personal virt_mode pv (first run in guest-personal.log), I see
[0.00] p2m virtual area at c900, size is 100
[0.00] Remapped 0 page(s)
...
[3.971434] ath9k :00:00.0: Xen PCI mapped GSI17 to IRQ15
[3.971674] ath: phy0: Enable WAR for ASPM D3/L1
[4.397628] BUG: unable to handle kernel paging request at
c90001cd0040
[4.397651] IP: [] iowrite32+0x2e/0x40
[4.397667] PGD 18831067 [4.397671] PUD 18830067
PMD 11ef3067 [4.397683] PTE 8010f0100075
[4.397690]
[4.397696] Oops: 0003 [#1] SMP
...
[4.398003] RIP [] iowrite32+0x2e/0x40
and in dom0
Dec 16 05:14:52 dom0 kernel: xen_pciback: vpci: :02:00.0: assign to
virtual slot 0
Dec 16 05:14:52 dom0 kernel: pciback :02:00.0: registering for 9
...
Dec 16 05:14:56 dom0 kernel: pciback :02:00.0: enabling device (
-> 0002)
Dec 16 05:14:56 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:14:56 dom0 kernel: Already setup the GSI :17
Dec 16 05:14:56 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:14:56 dom0 kernel: Already setup the GSI :17
Dec 16 05:14:56 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:14:56 dom0 kernel: Already setup the GSI :17
Dec 16 05:14:56 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:14:56 dom0 kernel: Already setup the GSI :17
Dec 16 05:14:56 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:14:56 dom0 kernel: Already setup the GSI :17
Dec 16 05:14:56 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:14:56 dom0 kernel: Already setup the GSI :17
Dec 16 05:14:56 dom0 kernel: pciback :02:00.0: Driver tried to write
to a read-only configuration space field at offset 0x92, size 2. This may
be harmless, but if you have problems with your device:
1) see permissive attribute in sysfs
2) report problems to the xen-devel mailing
list along with details of your device
obtained from lspci.
I think that is related to the following code in
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/init.c
if (sc->driver_data & ATH9K_PCI_D3_L1_WAR) {
ah->config.pcie_waen = 0x0040473b;
ath_info(common, "Enable WAR for ASPM D3/L1\n");
}
which I'm guessing is what leads to the configuration space write and crash.
*
Setting qvm-prefs personal virt_mode hvm (second run in
guest-personal.log), I see
Dec 16 05:15:48 dom0 kernel: xen_pciback: vpci: :02:00.0: assign to
virtual slot 0
Dec 16 05:15:48 dom0 kernel: pciback :02:00.0: registering for 11
Dec 16 05:15:49 dom0 kernel: pciback :02:00.0: enabling device (
-> 0002)
Dec 16 05:15:49 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:15:49 dom0 kernel: Already setup the GSI :17
Dec 16 05:15:49 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:15:49 dom0 kernel: Already setup the GSI :17
Dec 16 05:15:49 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:15:49 dom0 kernel: Already setup the GSI :17
Dec 16 05:15:49 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:15:49 dom0 kernel: Already setup the GSI :17
Dec 16 05:15:49 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:15:49 dom0 kernel: Already setup the GSI :17
Dec 16 05:15:49 dom0 kernel: xen: registering gsi 17 triggering 0 polarity 1
Dec 16 05:15:49 dom0 kernel: Already setup the GSI :17
and in hypervisor.log
(XEN) domain_crash called from svm.c:1541
(XEN) Domain 10 (vcpu#0) crashed on cpu#2:
(XEN) --[ Xen-4.8.2 x86_64 debug=n Not tainted ]--
(XEN) CPU:2
(XEN) RIP:0010:[]
(XEN) RFLAGS: 0296 CONTEXT: hvm guest (d10v0)
(XEN) rax: rbx: 97c946eb95c0 rcx: 0005
(XEN) rdx: 0040 rsi: af5580700040 rdi:
Re: [qubes-users] Re: Q4rc3 debian-9 template fails to update.
>> I freshly installed debian-9 ; when installing packages, apt-get hangs >> for days(!) with >> >> 81% [waiting for headers] ... >> followed by Err:XX Connection failed. >> > 2) Does restarting all of Qubes, and immediately update debian-9 after full > startup, make any difference? I.e. I've experienced issues on longer running > Qubes 4 my self, but mostly my issues are triggered by suspend/hibernate or > if HDMI plugged TV-screen goes to sleep mode on its own (even if laptop > screen is not sleeping). It triggers various of weird system issues, I'm > suspecting it's driver-module/kernel related, but I'm not really all that > sure. A full system restart however, makes everything work fully again. > Perhaps you experience something similar, yet different at the same time. > Either way, quick way to find out whether a full restart works or not. YES! So I guess things are linked to hilbernation problems when I close the lid. Is there another cure than full reboot? Bernhard -- 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/bd8bef46-2bd0-9448-5876-7351bdb24976%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4rc3 debian-9 template fails to update.
On Saturday, December 16, 2017 at 10:51:30 AM UTC, Chris Laprise wrote: > On 12/16/2017 04:21 AM, haaber wrote: > > I freshly installed debian-9 ; when installing packages, apt-get hangs > > for days(!) with > > > > 81% [waiting for headers] ... > > followed by Err:XX Connection failed. > > > > Has someone an idea where to look / how to procede? (there is definitely > > no other apt* running ). Thank you, Bernhard > > I just updated a freshly-installed debian-9 on 4.0rc3 two days ago > without connection errors. > > The difference may be that I have been updating my dom0 with > --enablerepo=qubes*testing, and a template having connection errors > suggests a problem with dom0/xen or with whatever is running sys-net. > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 True, I also use current-testing on my Qubes RC-2, fully updated, which has debian-9, and do not experience these update issues either. If only using regular updates, perhaps the issue is indeed fixed in the current-testing releases. Might want to backup first though, just in case current-testing gives rise to other more serious problems. It really does sound like the new backup method for templates yeah, so it's probably revolving around python code and packages related to the admin mechanic, type of updates? -- 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/d681487b-1789-4e10-a600-b29ede2808cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Trying to get my head around a configuration for a VPN-Proxy VM and its firewall?
On 12/15/2017 11:44 PM, vel...@tutamail.com wrote: I have scenario #1 working...I checked DNS leak and was able to get different results depending on the VM I was on. Is this just likely to break due to the bug you reference? The bug only pertains to "Deny except" setting on appVMs causing the VPN to block DNS. Bug isn't triggered if you use "Deny except" on the VPN VM itself. Scenario 2 was supposed to depict 3 separate sys-net, not running at the same time. clarified as follows: Clarrified Scenario #2 a) VMa--sys-vpn--sys-firewall---sys-net(Wireless and ethernet) b) VMb---sys-firewall---sys-net(Wireless and ethernet) c) VMc---sys-firewall---sys-net(Wireless and ethernet) If I want to get on VMa(VPN)...I would need to close all VMs in b) and c), if I wanted to get on VMb, I would need to close all VMs in a) and c), etc...pain in the but! But is this more secure due to multiple seperated sys-net? Qubes treats sys-net as untrusted. IMO here you're not gaining much (if any) security for the extra hassle. Scenario #3 clarified a) VMa--sys-vpn-sys-net(Wireless and ethernet) b) VMb--sys-firewallsys-net(Ethernet only) c) VMc--sys-firewallsys-net(Wireless only) #3 Scenario is insipired by this post(multiple sys-net's): Multiple sys-net: http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html ...is the only benefit of this configuration that I can use VMb and VMc at the same time? or is there better isolation with this config having multiple sys-net's? This assumes all VMs in a) and b) would need to be closed to get on VMa(VPN) There is some merit to separating wifi and ethernet like this as it could help protect an ethernet LAN from malware acquired over wifi, for example. But in this case combining them sometimes in one sys-net with a) may not be a good idea. Instead, if you need to sometimes use the VPN over wifi and sometimes over ethernet, you could easily switch the netvm setting on the VPN VM; then your wifi and ethernet controllers stay in separate VMs. Regarding the firewall rules in sys-vpn: Unfortunately (or fortunately?) my VPN provides a domain name instead of IPs e.g. VPNprovider.Canada.com, the VPN provider requires port 1194(UDP only), with user name/password and a local cert(all set up in the OpenVPN client in sys-vpn). In the sys-vpn VM firewall, I would "allow DNS queries" and "deny network access except": 1) put a rule that allows "*"(Which I believe allows "Any" domain/IP to pass, although it is limited to VPNprovider.Canada.com i.e. the Gateway in OpenVPN client )for "address", 2) port 1195 for "service" and 3) a protocol of "UDP". Wouldn't this block port 80, 443 and all other ports and only allow VPNprovider.Canada.com on port 1195 via UDP only? Only if you're certain that other addresses won't be accessed by sys-vpn. Therefor if VPN goes down all other ports 80, 443 would not be allowed? i.e. a kill switch?...similar to whats on the Qubes instructions except GUI configured? But if no other addresses besides VPNprovider.Canada.com are accessed, why would other _ports_ be accessed? IOW, yes this nails down the ports (because numbers are used for those) but whatever might access other ports might access other addresses. Using the VPN doc or Qubes-vpn-support such access attempts wouldn't succeed. If you look at the firewall script, it restricts output solely to the VPN client (i.e. openvpn) using a special group 'qvpn'. This prevents incidental net access by other programs. And again, putting domain names on the firewall settings tab tends to be an unreliable, weak measure; its not good advice if DNS returns a random selection from a pool of IPs. Its also weak if MITM is in the threat model, allowing an attacker to easily spoof their own addresses and port numbers ...and your worries about sys-net seem to indicate that such a threat applies. So all said and done, its not necessary to add firewall rules if your VPN provider uses a cert and the sys-vpn config isolates the tunnel traffic as VPN doc and Qubes-vpn-support do. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/694442b1-61ff-21c4-93f0-02ba50d356f3%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4rc3 debian-9 template fails to update.
On 12/16/2017 04:21 AM, haaber wrote: I freshly installed debian-9 ; when installing packages, apt-get hangs for days(!) with 81% [waiting for headers] ... followed by Err:XX Connection failed. Has someone an idea where to look / how to procede? (there is definitely no other apt* running ). Thank you, Bernhard I just updated a freshly-installed debian-9 on 4.0rc3 two days ago without connection errors. The difference may be that I have been updating my dom0 with --enablerepo=qubes*testing, and a template having connection errors suggests a problem with dom0/xen or with whatever is running sys-net. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/88064750-3950-c2b0-cfb0-01a26da2c6a6%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Q4rc3 debian-9 template fails to update.
On Saturday, December 16, 2017 at 9:21:32 AM UTC, haaber wrote: > I freshly installed debian-9 ; when installing packages, apt-get hangs > for days(!) with > > 81% [waiting for headers] ... > followed by Err:XX Connection failed. > > Has someone an idea where to look / how to procede? (there is definitely > no other apt* running ). Thank you, Bernhard You might already tried some of these, or maybe it won't be helpful, but either way, here is some suggestions to start with. 1) It's probably not this simple to fix, but then again it's a quick and cheap trial and error test to check and be sure. Try clean old update data. "sudo apt-get clean" in the debian-9 terminal. I'm not sure how to clean old data in dom0 or the sys-firewall, or wherever Qubes 4 new update mechanism keeps its downloaded packages before sending them to the "offline" updating template in question. But perhaps this is something to look further into, atm I don't have too much time to do so. If it keeps hanging on the same %, then perhaps this is a possible suspect, and maybe a cleanup fixes it. 2) Does restarting all of Qubes, and immediately update debian-9 after full startup, make any difference? I.e. I've experienced issues on longer running Qubes 4 my self, but mostly my issues are triggered by suspend/hibernate or if HDMI plugged TV-screen goes to sleep mode on its own (even if laptop screen is not sleeping). It triggers various of weird system issues, I'm suspecting it's driver-module/kernel related, but I'm not really all that sure. A full system restart however, makes everything work fully again. Perhaps you experience something similar, yet different at the same time. Either way, quick way to find out whether a full restart works or not. 3) How about "sudo journalctl --boot" in dom0 and AppVM terminal alike, same time, after you did both a system restart and then following also encounter the update bug. Doing it after a system restart cleans the log and make it easier to read. Aka, easier to scroll down to the last lines that matter, and doing it right after you encounter the issue, makes it a possibility to spot some errors in the log, around the end of it. (I'm sure there are smarter ways to navigate these long scrolling, but none that I'm aware of). Doing this both in the AppVM and dom0, same time, and look for something that looks out of the ordinary. Also executing both commands same time, before looking into the logs details, makes it a bit easier, so you don't have to mess with time-log comparisons. I know these are relative simple approaches, but I can't think of anything deeper atm. If above suggestions are to no prevail, then maybe someone more knowledgeable will drop by with better suggestions. -- 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/81e15892-92a9-40f3-b5fe-7fd46ca29f1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Q4rc3 debian-9 template fails to update.
I freshly installed debian-9 ; when installing packages, apt-get hangs for days(!) with 81% [waiting for headers] ... followed by Err:XX Connection failed. Has someone an idea where to look / how to procede? (there is definitely no other apt* running ). Thank you, Bernhard -- 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/ae8b6bcf-01e7-9cd2-5b7e-c17d08195598%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Release date for qube os 4
On Saturday, December 16, 2017 at 5:30:15 AM UTC, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2017-12-15 19:14, Yuraeitha wrote: > > On Wednesday, December 13, 2017 at 2:05:30 AM UTC, Andrew David > > Wong wrote: On 2017-12-12 17:33, grv wrote: > I see on https://www.qubes-os.org/doc/releases/4.0/schedule/ > that Dec 11 is the last date mentioned to decide if rc3 is > final. Have we taken the decision? > > > > > As far as I know, the decision has not yet been made. Either way, > > the schedule will be updated soon. > > > If I install rc3, would I be able to update to QubeOS 4 in > place (without having to migrate my VMs manually) ? > > > > > We'll announce this as soon as we can. We usually can't say for > > certain whether an in-place upgrade will be possible until very > > close to the stable release. > > > > If we say that it'll be possible based on our current plans, and > > those plans change, users may be inconvenienced (or worse). If we > > refrain from changing our plans because we've already said that an > > in-place upgrade will be possible, that limits our ability to > > improve the final release while it's still in testing. We don't > > want to make promises that we can't keep, but we also don't want > > to lock ourselves into a path that turns out to be sub-optimal. > > That's why we wait to announce things like this until we can be > > reasonably certain. > > > > > > Hey Andrew, Is there any chance if we can get recommendations, as > > for when it is recommendable to re-install between the Qubes > > release candidates? I.e. an extra line in the release schedule > > saying re-install recommended, or something akin to that? I'm just > > pondering thoughts here, whether it's possible or not. > > > >> From what I can gather, release candidates can be seen in two > >> ways. > > > > - 'Updates are so major, that a re-install for the next release > > candidate makes for a more stable and reliable system.' > > > > or > > > > - 'Some systems won't work properly before updates are applied, > > therefore creating an impossible circle if booting, installing, > > reaching the update process, is unreachable.' > > > > When decisions are made in keeping or making a new release > > candidate, it would be greatly appreciated to have a means to know > > if re-install is the former, or the latter, scenario, or maybe > > even sometimes both. This would save a lot of time for many people > > to re-install, or even be worried and stressed about not doing so, > > when not knowing if one should or not. > > > > Is it possible we can include this tiny detail somewhere, i.e. in > > the release schedule, or somewhere else that is a sensible > > location that is easy to find for users? > > > > We've actually already started doing that. :) > > Take a look at our last two release candidate announcements: > > "As a consequence of the partition layout change, it will be necessary > for current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2 > rather than attempting to upgrade in-place." > > https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/ > > "Current users of Qubes 4.0-rc2 can upgrade in-place by downloading > the latest updates from the testing repositories in both dom0 and > TemplateVMs." > > https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/ > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJaNK9ZAAoJENtN07w5UDAw0+oQAMQ8EFQNpMnRIe/yhC1o4v9G > PKta+7YsCjfawTu7oWUdbh8ETKAzqo7BGyqZeZsQzOIlgRLZo4/1C3BCLSsYjUQm > E8kYADe/8i4YGyeXU2SUeGgzSrbZGfvWdE2dMB5oc3uLp0eYB/jtKMIxNdbPRp6B > vmDvTFRgSoUNHq8hgS+p8A8VNB696xPoCx4jzWHjo7NbWubaRGRKsArCHkPjwfMW > x5Skro/DslYjSU+Bx5r61sJLZZT46bFIrqogc5pmZzcvw3M0VnjKZD2H0D5RoOrD > JKuz+2RiZZRkqzNZpS5fOxD392Y0r9D3YlcEM/1+QrMy1xfix8wdik4bDb/49Rxu > +ZgI5yZw2HpDILc2wUcF2Ph+LvS7u8J1VwwkZXdgyjL4CO2DZBO0VMiiUvDwg98Q > 8WuWZDPfkgFE8fsNiStiQwFtqOE/hCvAhJ6qE4pJMujMdbm1mjQJErQH1LCAE9pV > cz2fLHWlPzWp06PqNV9zRFHA4twQUat0IDTd2wikPDG30HzjcE+WVengoKo8iTCs > /EvbfmY6MabDMkisC+y7zgQkZeGIGFTdjvG1SG6asYdklrNvGHfJkOlQw376Fkda > a0+aC3A2qy8pgbh6vC8voTkpuzd7+H/gXET2kyzGdzA9tWKhpqXHtP0RWUpQ7EXC > 1gzCPMVIykmTkIUsK3TL > =VA2a > -END PGP SIGNATURE- Thanks Andrew, this is pretty awesome. It really takes off the pressure to figure out whether to re-install or not. I can only speak for my self, but I'm very grateful for this little piece of information, it removes a lot of worries, especially, and in particular when on busy schedules. Thanks for the link and quotes too, it gives a good and helpful idea as for what to look for in the future releases. -- 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
[qubes-users] Re: qubes won't boot, how to rescue system or save my data?
or what haaber said, who provides further details. -- 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/625c96ad-45e6-412f-86e6-06c597571734%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qubes won't boot, how to rescue system or save my data?
On Saturday, December 16, 2017 at 4:54:30 AM UTC, jer...@openmailbox.org wrote: > i first tried setup for my printer which has USB connected to PC... > using the guide in Using and Managing USB Devices in qubes-os website in > docs.. > enabled sys-sub using the command > sudo qubesctl top.enable qvm.sys-usb > > then the command > sudo qubesctl state.highstate > > computer froze, restarted pc, the keyboard didn't work (in passphrase > encryption part), but if press a button only num lock color appears for a > second, and if i hold a button the num lock button is lighted.. > > i then tried installing new qubes, using manual partition configuration (not > the automatic), i think i didn't delete the partition with my data.. i tried > adding some new partitions.. > > now after installing qubes, after encryption password for disk, entering > password, it was counting number when clicking alt tab, and says unlimited... > > how can i rescue Choice of words and wording, and the scenario and timing, makes it look like you double posted https://groups.google.com/forum/#!topic/qubes-users/6NBcP05CdPc Despite having used two different e-mails. I'm not trying to be mean here, but how come you're not sticking to your original topic? You likely can't make that Qubes setup work after having torn it in half and try to glue it together again, there is simply too many details. Try the advice I offered in the other topic. -- 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/a675fc08-b576-40b5-b5b7-2f843ec4faa8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes won't boot, how to rescue system or save my data?
On 12/14/2017 04:16 PM, jerr...@openmailbox.org wrote: > i first tried setup for my printer which has USB connected to PC... > using the guide in Using and Managing USB Devices in qubes-os website in > docs.. > enabled sys-sub using the command > sudo qubesctl top.enable qvm.sys-usb > > then the command > sudo qubesctl state.highstate > > computer froze, restarted pc, the keyboard didn't work (in passphrase > encryption part), but if press a button only num lock color appears for a > second, and if i hold a button the num lock button is lighted.. > > i then tried installing new qubes, using manual partition configuration (not > the automatic), i think i didn't delete the partition with my data.. i tried > adding some new partitions.. > > now after installing qubes, after encryption password for disk, entering > password, it was counting number when clicking alt tab, and says unlimited... > > how can i rescue I emergency, Iwould rescue data externally: use a luks-enabled linux (tails for example) on a usb drive, then open the discs (cryptsetup luksOpen /dev/XXX and mount it). Inside /var/lib/qubes/ you will find private.img in each appvm. These can be mounted individually & rsync-ed to a rescue disc (I recommend a loopback device that is luks-crypted as well). Bernhard -- 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/d631a153-c537-6dec-9a12-4392f0466d7f%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unable to start VM after renaming in Qubes Manager
> The data is stored in the private.img file in that folder. > > You can either create a new qube, and then attach the file: > qvm-block -A dom0:/var/lib/qubes/appvms/oldname /private.img > then mount /dev/xvdi in , and extract the data from > /mnt/home/user > OR: mount the private.img file in dom0 and qvm-copy the data files to some > qube. > OR: create a new qube, and copy the private.img file to > /var/lib/qubes/appvms/new Thank you I used the last option and it worked just fine. -- 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/20171216080902.8BAA54EB275%40mta-1.openmailbox.org. For more options, visit https://groups.google.com/d/optout.
