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&arch=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: > https://github.com/QubesOS/qubes-doc/pull/603/files#diff-50cf93c6cf4fa87fc6b6612d706874a1 > may be useful, but possibly also in need of correction. I remember when you made that writeup based on my original issue, but I didn't see it in the current Qubes Docs. I had gone through my original post and tried those settings again before posting here. Once we figure out why my current R4.0.x isn't working that doc could be re-included on the Qubes site. sysad.andes: > Also, besides what's listed in all the docs, make sure you have > qubes-input-proxy installed in whatever template is behind the VM you want to > handle updates for your templates Is qubes-input-proxy the same as this? https://github.com/QubesOS/qubes-app-linux-input-proxy That seems to be a USB device proxy. Is that what you were referring to, or is there something else? -- 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/ec0329a4d728eafc68ab120b200b19ae%40riseup.net.
