Re: [qubes-users] Re: DisposableVM Help
I appreciate your help. 'qvm-run dispvm=fedora-32-dvm-template --service qubes.StartApp+xterm' results in the error: unrecognized arguments: qubes.StartApp+xterm. I don't know if I am communicating this correctly, but I am trying to create a fedora-32-dvm, that is also itself a DVMTemplate (has the 'template_for_dvms' flag set), like I currently have for my debian-10-dvm and whonix-15-dvm. Is this not the proper way to run DVM's? I currently have a menu item for 'fedora-32-dvm-template', but opening any application from the menu, like Firefox for example, opens the DVMTemplate, not a DispVM. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0563ba9f-7354-4b38-aef7-97791bbf804co%40googlegroups.com.
Re: [qubes-users] Re: DisposableVM Help
On Fri, Jul 17, 2020 at 12:14:07PM -0700, Robert Spigler wrote: > According to the documentation, I try: > > 'qvm-prefs fedora-32-dvm template_for_dispvms True' > > error: no such domain: 'fedora-32-dvm' > > Tried 'qvm-prefs fedora-32 template_for_dispvms True' > > error: no such property: 'template_for_dispvms' > > > Following 'Creating a New DisposableVM Template' further down the page: > > 'qvm-create --template fedora-32 --label red fedora-32-dvm-template' > 'qvm-prefs fedora-32-dvm-template template_for_dispvms True' > 'qvm-features fedora-32-dvm-template appmenus-dispvm 1' > > This creates a domain titled 'fedora-32-dvm-template' like I describe in my > original post, with the disposable_vm_template flag set, but it is not a > DisposableVM itself, which is what I am attempting. > Hi Robert I'm sorry my previous post wasn't clear enough. A DisposableVM is based on a DisposableVM Template. You have created a DisposableVM Template. You can use it to spawn disposableVMs. You can do this by hand: qvm-run dispvm=fedora-32-dvm-template --service qubes.StartApp+xterm Setting the qvm-features as you have done *should* create menu items that will spawn disposableVMs that use that template. If you wanted to create disposableVMs based on a qube that uses the fedora-32 template, that is what you have done. If that is *not* what you were attempting, please explain exactly what it is you want. (If you think that your fedora-32-dvm-template should itself be a DisposableVM , please re-read the glossary, and the page on disposableVMs: *this* attempt is based on a misunderstanding of how disposableVMs are created in Qubes 4.) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200718012701.GA30460%40thirdeyesecurity.org.
[qubes-users] Re: How to create application shortcuts for Flatpak apps?
On 2020-07-16 13:56, Alex Lu wrote: I have a couple AppVMs with flatpak apps installed on them (with a -- user flag) and I can't figure out how to do it. There is guide explaining how to do it, but it expects you to have flatpak apps installed in TemplateVM. Is it possible to do? This might help: https://github.com/QubesOS/qubes-issues/issues/2766#issuecomment-603925759 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e50b3969-ba2f-1129-aab8-6b143112eeb7%40gmx.de.
Re: [qubes-users] A Little Help Understanding Bitcoin
If I look at my watching only wallet at the bottom right of the Electrum window there is a red icon indicating network status. I expected this icon to be green since this wallet is supposed to be watching, no? In your watching-only electrum you should see it green. You probably have some configuration error. Does firefox work fine on this VM? I just changed the template my Electrum qube is based on from a fedora-31-minimal template to a fedora-31 template and my watching only wallets' network status has now turned green and I can see my transactions. In additiona, if someone could confirm to me that what I am doing is correct. I created a new transaction on the receiving tab of the watching only wallet and then used the QR code generated by this to receive bitcoin, but I have not received anything. Am I just impatient or was I not supposed to do this in my watching only wallet? Not sure if this is related to my above question of the network status not being green. I am a complete Bitcoin noob. Any help with this will be very much appreciated. Yes, if your electrum can't connect it won't show your balance. If you know what address did you sent, try some block explorer: - https://www.blockchain.com/btc/address/ Would anybody have an idea what a minimal template might be missing in this particular usecase? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3a7e0baa-637c-6aed-7ac3-4e8412559fca%40ak47.co.za.
Re: [qubes-users] A Little Help Understanding Bitcoin
On 2020-07-17 14:02, Qubes wrote: > I created a offline and watching only (Electrum) bitcoin wallet as > describes in the Qubes docs, > https://www.qubes-os.org/doc/split-bitcoin/, but I wanted to find out of > I did something wrong or if what I am seeing is in fact correct. > > If I look at my watching only wallet at the bottom right of the Electrum > window there is a red icon indicating network status. I expected this > icon to be green since this wallet is supposed to be watching, no? > > The watching only wallet uses sys-whonix as its netVM. In your watching-only electrum you should see it green. You probably have some configuration error. Does firefox work fine on this VM? > > In additiona, if someone could confirm to me that what I am doing is > correct. I created a new transaction on the receiving tab of the > watching only wallet and then used the QR code generated by this to > receive bitcoin, but I have not received anything. Am I just impatient > or was I not supposed to do this in my watching only wallet? Not sure if > this is related to my above question of the network status not being green. > > I am a complete Bitcoin noob. Any help with this will be very much > appreciated. > Yes, if your electrum can't connect it won't show your balance. If you know what address did you sent, try some block explorer: - https://www.blockchain.com/btc/address/ -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7fc46704-abfa-1ec0-7805-084c2acd6cb5%40riseup.net.
Re: [qubes-users] File syncing between Qubes
Michael Haynes schrieb am Do., 16. Juli 2020, 22:18: > This got me wondering: > > *Question: Is there a simple way to setup a dedicated "server" VM* > *using WebDAV to allow qubes to [automatically / periodically] exchange > encrypted data even without Internet access? If so, what are the security > implications of doing this? If not, what are some alternative ways of > automating data transfers between qubes?* > You could look into sshfs which is able to mount a remote filesystem over ssh. 799 > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2sy7GcrKWe2Ldu2v49Dsem0QWORE5w-KPn4NQ%3DxOUYWBQ%40mail.gmail.com.
Re: [qubes-users] Re: DisposableVM Help
According to the documentation, I try: 'qvm-prefs fedora-32-dvm template_for_dispvms True' error: no such domain: 'fedora-32-dvm' Tried 'qvm-prefs fedora-32 template_for_dispvms True' error: no such property: 'template_for_dispvms' Following 'Creating a New DisposableVM Template' further down the page: 'qvm-create --template fedora-32 --label red fedora-32-dvm-template' 'qvm-prefs fedora-32-dvm-template template_for_dispvms True' 'qvm-features fedora-32-dvm-template appmenus-dispvm 1' This creates a domain titled 'fedora-32-dvm-template' like I describe in my original post, with the disposable_vm_template flag set, but it is not a disposableVM itself, which is what I am attempting. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9a7a9a4a-b300-4500-b213-0d935e0f82e8o%40googlegroups.com.
[qubes-users] Re: Does qubes protect against all firmware viruses ?
Btw isn't there same problem with multi session dvd as with usb flashdisk? You can write there additional data. Unless you use read only CD mechanic, but i didn't see it anywhere... On Tuesday, June 9, 2020 at 5:18:10 PM UTC+2, Catacombs wrote: > > > > On Tuesday, June 9, 2020 at 9:39:26 AM UTC-5, Catacombs wrote: >> >> >> >> On Monday, June 8, 2020 at 1:00:17 PM UTC-5, tomas.s...@gmail.com wrote: >>> >>> I understand, that Qubes compartmentalizes OS and parts of OS don't have >>> access to other parts of the OS. So even if you had virus in your firmware >>> of a network card, it wouldn't matter. I know firmware viruses are rare, >>> but still better safe than sorry. I am looking for safe OS to do online >>> banking from. If i use live usb of QUBES, does that protect me against all >>> firmware viruses ? I wonder. Even there is like 0.2% chance of being >>> infected with it. Also i can't disable all my disks in BIOS, could that be >>> problem ? I mean if i use live-usb and don't boot my main OS, when usb is >>> plugged in. So my main OS can't compromise Qubes. And even if disks were >>> enabled and i boot up Qubes from live usb, i am not sure if it could get >>> infected, because these viruses has to be loaded somehow right ? But if >>> they are passively on the disk and you launch 2nd OS from live-usb, not >>> sure if it could get infected like this. I wanted to dedicate my old pc for >>> online banking, but Qubes doesn't work there. >>> >> >> You might rather look at those webpages which talk about "Threat Model." >> Who you might be contending with. There is, of course, the possibility >> that what you are referring to is the fact Intel main processors have >> modems which might allow Intel to change the firmware code without your >> knowing it. I have been told, by someone who is much more knowledgeable >> about these things, that there are no instances of Intel ever having done >> that. There are some possible problems with USB Keyboards. >> >> You might ask your bank. I suspect in any case, what you might be more >> interested in is reading about VPN's. Some more expensive that others. >> As someone said, don't trust a free VPN, they have to make their money >> somewhere, still I use the free version of ProtonVPN. >> >> Hardware that is produced with the goal of no Firmware intrusion includes >> - https://puri.sm/ the qubes certified hardware, >> https://www.qubes-os.org/doc/certified-hardware/, notice the Hardware >> Compatibility List, https://www.qubes-os.org/hcl/ >> >> I guess that is off the subject. >> >> If you use a VPN- My bank checks the IP of the address the login comes >> from. If the VPN server is say in New York, a thousand miles away, it will >> not let me login. Bank reasons I should have told them I was traveling. >> You might find difficulty using Tor, or Whonix to login to your bank. >> > > I should mention, using a credit card can insulate you from risk. The big > risk of using a bank account is allowing someone to have the checking > account number itself, the one on the bottom of all your checks. > > Puppy Linux has a number of Live versions which actually do not have a > root, but whose security in the case of a bank account is derived from > loading a new fresh version of OS at each re-boot. If one completely power > downs the computer after each bank session, and does not save the partition > each time, then. No way can software get in around you. Installing a VPN > to use with one of the distros of Puppy Linux can be problematic though. > Puppy Linux has a friendly forum. I think you might start with Easy OS, > create a multi-save DVD. Boot then do your banking, power down. > > Not perfect. If you are a geek type, then use Qubes. No doubt Qubes is > superior in several ways. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3f336a42-3770-404e-8431-b126fbee9017o%40googlegroups.com.
[qubes-users] Deleting a user created template VM, using dom0
Greetings, I created a template a while back for emails using thunderbird and I recently tried to delete it via the qubes manager. So, the VM was deleted and no longer appears in the qubes manager window, yet an icon still remains in the qubes VM drop down menu with the same name as the VM deleted but the icon has changed from a lock to a square and the only application associated with the vm is a firefox browser. Also, I can't access the VMs terminal or settings application, nor do I remember if the VM was set to auto back-up. It's most likely an artifact from the VM, and I am assuming I can use dom0 to delete the artifact but I don't know the command. Could some one help with the code to delete an appVM from the qubes VM drop down menu using dom0. Thanks, -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0f864b70-d96a-ff88-fffa-be11d75c077e%40gmail.com.
[qubes-users] Qubes possibly not detecting ethernet PCI (Dell Inspiron 5593)
Hi all, I ran into an issue while configuring my disposable sysVMs: It turns out my sys-net is set to PVH by default instead of HVM, which allows for PCI passthrough. This led me to look around, and it turns out there are no devices attached to my sys-net despite there being an ethernet jack in my laptop. Using qvm-pci in dom0 revealed that there are no network interfaces, but three "Unknown", two "PCI bridge" one "ISA bridge" and one "Communication controller", all from Intel Corporation. Is it possible that one of these is my ethernet interface? - If so, how would I go about figuring out which one and restoring it? Or do I just test them one by one? - If not, how would I get Qubes to look for my missing ethernet? Thanks in advance -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4c14638a-1b3a-42e1-97f9-43838cbef311o%40googlegroups.com.
Re: [qubes-users] Security advantages of static DVMs for sys-VMs?
On Thursday, 16 July 2020 20:48:52 UTC+8, unman wrote: > > 54th - static disposableVMS are neither unstable nor hard to use. They > are as stable as a normal sys-VM and transparent in use. > Unman, you're right. I was being overly cautious and, to be frank, scared of making my OS more complicated, but it's worth it. Peter Funk wrote: > Throwing everything away will also delete any evidence that > something bad might have happened to this part of your digital > life and will make later analysis of the events harder. Logs aren't really a concern for me, but it's still something that I should look at for DispVMs. Thanks -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/712c3816-31a9-4437-9c61-cd93f9284ebco%40googlegroups.com.
Re: [qubes-users] Re: Fw: qubes arch template
On Thu, Jul 16, 2020 at 05:16:57PM +0200, Fr??d??ric Pierret wrote: > > > On 2020-07-16 16:51, fargubz wrote: > > Hi Frederic, > > > > Having the https://github.com/QubesOS/qubes-issues/issues/5503 issue. > > Hi, please don't ask directly to any member of the Qubes OS project > (including me :)). Ask to the list directly for which I CC it. > > > What is the step to fix this? > > I'm pretty sure any person who built Archlinux could help you (which is not > my case). > > > Best regards! > > > > fargubz > > > > Regards, > I *have* built the template and do not have this problem. Are you sure that is your issue? If so, there's clearly something majorly wrong with your arch building environment. I suggest you clean it out, and start again. 1. Run ./setup and make sure that only arch is selected. 2. Run `make clean-rpms` 3. Confirm that chroot-vm-archlinux is not present. Delete (using sudo) if it is. 4. Confirm that qubes-src/linux-template-builder/prepared_images/archlinux.img is not present. Delete (using sudo) if it is. 5. `make qubes-vm` and `make template` Alternatively I provide pre-built templates, and Arch packages at https://qubes.3isec.org Download an arch template, confirm the signature, copy it in to dom0 and install it using `dnf install` unman -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200717140811.GA27865%40thirdeyesecurity.org.
[qubes-users] A Little Help Understanding Bitcoin
I created a offline and watching only (Electrum) bitcoin wallet as describes in the Qubes docs, https://www.qubes-os.org/doc/split-bitcoin/, but I wanted to find out of I did something wrong or if what I am seeing is in fact correct. If I look at my watching only wallet at the bottom right of the Electrum window there is a red icon indicating network status. I expected this icon to be green since this wallet is supposed to be watching, no? The watching only wallet uses sys-whonix as its netVM. In additiona, if someone could confirm to me that what I am doing is correct. I created a new transaction on the receiving tab of the watching only wallet and then used the QR code generated by this to receive bitcoin, but I have not received anything. Am I just impatient or was I not supposed to do this in my watching only wallet? Not sure if this is related to my above question of the network status not being green. I am a complete Bitcoin noob. Any help with this will be very much appreciated. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/37272a2c-e713-59ba-79f7-f93ca82d6522%40ak47.co.za.
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
On 2020-07-17 06:55, pr0xy wrote: > On 2020-07-17 02:55, pr0xy wrote: >> On 2020-07-16 12:34, unman wrote: >>> On Wed, Jul 15, 2020 at 11:41:57PM -0700, pr0xy wrote: On 2020-07-15 09:28, pr0xy wrote: > I have been running R3.2 for about as long as I can. Time to upgrade to > R4.0.x > > Original 2017 thread where I got this working in R3.2: > https://groups.google.com/d/msg/qubes-users/K_etKdhnqLA/KyJ16z8JCwAJ > > It appears that some of the R3.2 tweaks I used to get Qubes to work > nicely with my corporate proxy are no longer valid in 4.0.x. To > summarize, my company network has a very restrictive proxy that forces > internet traffic through an HTTP/HTTPS proxy like: > > proxy.example.com:8080 > > In R4.0.x how and where would I set this proxy for the Qubes Updates > Proxy? sys-net? sys-firewall? TemplateVMs? If I understand the documentation correctly... https://qubes-os.org/doc/software-update-domu/#updates-proxy we have TinyProxy running in sys-net, and this proxy is used for TemplateVM updates. In the default R4.0.3 install, sys-net is based on a Fedora 30 template. In the fedora-30 templateVM I tried editing /etc/tinyproxy/tinyproxy.conf to add the IP of my company's HTTP proxy as the upstream proxy Upstream http 10.0.0.1:8080 That does not seem to work. >>> >>> It would be helpful if you said in what way it does not seem to work. >>> >>> Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy, >>> to make sure which qube is acting as the proxy. >>> Check in a template if you are using sources with http:// or https:// - >>> look in /etc/yum.repos.d or /etc/apt/sources.list as appropriate >>> Confirm that you have DNS resolving in whichever qube is acting as >>> proxy. >>> >>> Report back. >> >> unman: >>> It would be helpful if you said in what way it does not seem to work. >> >> I am unable to update TemplateVMs. Due to the proxy issue they cannot >> access updates so I get an error like this: >> >> fedora-30: >> --- >> [user@fedora-30 ~]$ sudo dnf update >> Fedora Modular 30 - x86_64 0.0 B/s | 0 B >> 06:00 >> Error: Failed to download metadata for repo 'fedora-modular': Cannot >> prepare internal mirrorlist: Curl error (28): Timeout was reached for >> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-30=x86_64 >> [Operation timed out after 30001 milliseconds with 0 out of 0 bytes >> received] >> --- >> >> debian-10: >> --- >> user@debian-10:~$ sudo apt update >> Err:1 https://deb.qubes-os.org/r4.0/vm buster InRelease >> >> Reading from proxy failed - select (115: Operation now in progress) >> [IP: 127.0.0.1 8082] >> Err:2 https://deb.debian.org/debian buster InRelease >> >> Reading from proxy failed - select (115: Operation now in progress) >> [IP: 127.0.0.1 8082] >> Err:3 https://deb.debian.org/debian-security buster/updates InRelease >> Reading from proxy failed - select (115: Operation now in progress) >> [IP: 127.0.0.1 8082] >> Reading package lists... Done >> Building dependency tree >> Reading state information... Done >> All packages are up to date. >> W: Failed to fetch https://deb.debian.org/debian/dists/buster/InRelease >> Reading from proxy failed - select (115: Operation now in progress) [IP: >> 127.0.0.1 8082] >> W: Failed to fetch >> https://deb.debian.org/debian-security/dists/buster/updates/InRelease >> Reading from proxy failed - select (115: Operation now in progress) [IP: >> 127.0.0.1 8082] >> W: Failed to fetch >> https://deb.qubes-os.org/r4.0/vm/dists/buster/InRelease Reading from >> proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1 >> 8082] >> W: Some index files failed to download. They have been ignored, or old >> ones used instead. >> --- >> >> I found that I am able to update Dom0. It is using sys-firewall as >> UpdateVM to download updates. >> sys-firewall is based on fedora-30, and the Upstream proxy is set in >> TinyProxy. This seems to work. >> >>> Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy >> >> In /etc/qubes-rpc/policy/qubes.UpdatesProxy it shows sys-net is being >> used for non-Whonix TemplateVMs: >> --- >> # Default rule for all TemplateVMs - direct the connection to sys-net >> $type:TemplateVM $default allow,target=sys-net >> >> $anyvm $anyvm deny >> --- >> >>> Check in a template if you are using sources with http:// or https:// - >>> look in /etc/yum.repos.d or /etc/apt/sources.list as appropriate >> >> The fedora-modular.repo has all the http:// lines commented out. Other >> repo files also appear to be using https:// as well. >> debian-10 is also using https:// in sources.list >> >>> Confirm that you have DNS resolving in whichever qube is acting as proxy. >> >> DNS appears to be working from both sys-net and sys-firewall qubes. >> cat /etc/resolve.conf from sys-net shows the company DNS servers. I can
Re: [qubes-users] Qubes in a corporate network behind HTTP proxy [R4.0.x]
On 2020-07-17 02:55, pr0xy wrote: > On 2020-07-16 12:34, unman wrote: >> On Wed, Jul 15, 2020 at 11:41:57PM -0700, pr0xy wrote: >>> On 2020-07-15 09:28, pr0xy wrote: >>> > I have been running R3.2 for about as long as I can. Time to upgrade to >>> > R4.0.x >>> > >>> > Original 2017 thread where I got this working in R3.2: >>> > https://groups.google.com/d/msg/qubes-users/K_etKdhnqLA/KyJ16z8JCwAJ >>> > >>> > It appears that some of the R3.2 tweaks I used to get Qubes to work >>> > nicely with my corporate proxy are no longer valid in 4.0.x. To >>> > summarize, my company network has a very restrictive proxy that forces >>> > internet traffic through an HTTP/HTTPS proxy like: >>> > >>> > proxy.example.com:8080 >>> > >>> > In R4.0.x how and where would I set this proxy for the Qubes Updates >>> > Proxy? sys-net? sys-firewall? TemplateVMs? >>> >>> If I understand the documentation correctly... >>> https://qubes-os.org/doc/software-update-domu/#updates-proxy >>> we have TinyProxy running in sys-net, and this proxy is used for >>> TemplateVM updates. >>> >>> In the default R4.0.3 install, sys-net is based on a Fedora 30 template. >>> In the fedora-30 templateVM I tried editing >>> /etc/tinyproxy/tinyproxy.conf to add the IP of my company's HTTP proxy >>> as the upstream proxy >>> >>> Upstream http 10.0.0.1:8080 >>> >>> That does not seem to work. >> >> It would be helpful if you said in what way it does not seem to work. >> >> Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy, >> to make sure which qube is acting as the proxy. >> Check in a template if you are using sources with http:// or https:// - >> look in /etc/yum.repos.d or /etc/apt/sources.list as appropriate >> Confirm that you have DNS resolving in whichever qube is acting as >> proxy. >> >> Report back. > > unman: >> It would be helpful if you said in what way it does not seem to work. > > I am unable to update TemplateVMs. Due to the proxy issue they cannot > access updates so I get an error like this: > > fedora-30: > --- > [user@fedora-30 ~]$ sudo dnf update > Fedora Modular 30 - x86_64 0.0 B/s | 0 B > 06:00 > Error: Failed to download metadata for repo 'fedora-modular': Cannot > prepare internal mirrorlist: Curl error (28): Timeout was reached for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-30=x86_64 > [Operation timed out after 30001 milliseconds with 0 out of 0 bytes > received] > --- > > debian-10: > --- > user@debian-10:~$ sudo apt update > Err:1 https://deb.qubes-os.org/r4.0/vm buster InRelease > > Reading from proxy failed - select (115: Operation now in progress) > [IP: 127.0.0.1 8082] > Err:2 https://deb.debian.org/debian buster InRelease > > Reading from proxy failed - select (115: Operation now in progress) > [IP: 127.0.0.1 8082] > Err:3 https://deb.debian.org/debian-security buster/updates InRelease > Reading from proxy failed - select (115: Operation now in progress) > [IP: 127.0.0.1 8082] > Reading package lists... Done > Building dependency tree > Reading state information... Done > All packages are up to date. > W: Failed to fetch https://deb.debian.org/debian/dists/buster/InRelease > Reading from proxy failed - select (115: Operation now in progress) [IP: > 127.0.0.1 8082] > W: Failed to fetch > https://deb.debian.org/debian-security/dists/buster/updates/InRelease > Reading from proxy failed - select (115: Operation now in progress) [IP: > 127.0.0.1 8082] > W: Failed to fetch > https://deb.qubes-os.org/r4.0/vm/dists/buster/InRelease Reading from > proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1 > 8082] > W: Some index files failed to download. They have been ignored, or old > ones used instead. > --- > > I found that I am able to update Dom0. It is using sys-firewall as > UpdateVM to download updates. > sys-firewall is based on fedora-30, and the Upstream proxy is set in > TinyProxy. This seems to work. > >> Check in dom0, the contents of /etc/qubes-rpc/policy/qubes.UpdatesProxy > > In /etc/qubes-rpc/policy/qubes.UpdatesProxy it shows sys-net is being > used for non-Whonix TemplateVMs: > --- > # Default rule for all TemplateVMs - direct the connection to sys-net > $type:TemplateVM $default allow,target=sys-net > > $anyvm $anyvm deny > --- > >> Check in a template if you are using sources with http:// or https:// - look >> in /etc/yum.repos.d or /etc/apt/sources.list as appropriate > > The fedora-modular.repo has all the http:// lines commented out. Other > repo files also appear to be using https:// as well. > debian-10 is also using https:// in sources.list > >> Confirm that you have DNS resolving in whichever qube is acting as proxy. > > DNS appears to be working from both sys-net and sys-firewall qubes. > cat /etc/resolve.conf from sys-net shows the company DNS servers. I can > ping these from sys-firewall. > > awokd: >>
