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&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?
>
> I tried a few more things, but have not yet been successful to get the
> TemplateVMs to update via the proxy.
>
> As Dom0 will update, and it is working through sys-firewall (the system
> default for Dom0 UpdateVM), I tried changing sys-net to sys-firewall in
> qubes.UpdatesProxy. The result was the same. I could not update
> TemplateVMs. I reverted that change.
>
> I removed my changes to TinyProxy in /etc/tinyproxy.conf from the
> fedora-30 template. Instead I made the changes to the Upstream proxy in
> sys-net in /rw/config/rc.local as per the document draft linked by
> @awokd
> ~~~
> echo "Upstream 10.0.0.1:8080" >>
> /etc/tinyproxy/tinyproxy-updates.conf
> ~~~
> Instead of timing out, I immediately got [Proxy CONNECT aborted] errors
> from Fedora templates when attempting to update. When I switch this back
> to:
> ~~~
> echo "Upstream 10.0.0.1:8080" >> /etc/tinyproxy/tinyproxy.conf
> ~~~
> the updates still fail to connect, but they take several minutes to time
> out with [Operation timed out after 30000 milliseconds with 0 out of 0
> bytes received]
>
> As I can update via Dom0, I downloaded a fresh copy of Fedora 32.
> $ sudo qubes-dom0-update qubes-template-fedora-32
>
> When attempting to update fedora-32 TemplateVM I still get this (with
> Upstream proxy set in tinyproxy-updates.conf):
> ---
> [user@fedora-32 ~]$ sudo dnf update
> Fedora 32 openh264 (From Cisco) - x86_64 0.0 B/s | 0 B
> 00:02
> Errors during downloading metadata for repository
> 'fedora-cisco-openh264':
> - Curl error (56): Failure when receiving data from the peer for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64
> [Proxy CONNECT aborted]
> Error: Failed to download metadata for repo 'fedora-cisco-openh264':
> Cannot prepare internal mirrorlist: Curl error (56): Failure when
> receiving data from the peer for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64
> [Proxy CONNECT aborted]
> Fedora Modular 32 - x86_64 0.0 B/s | 0 B
> 00:02
> Errors during downloading metadata for repository 'fedora-modular':
> - Curl error (56): Failure when receiving data from the peer for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64
> [Proxy CONNECT aborted]
> Error: Failed to download metadata for repo 'fedora-modular': Cannot
> prepare internal mirrorlist: Curl error (56): Failure when receiving
> data from the peer for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64
> [Proxy CONNECT aborted]
> ---
>
> Or this (with Upstream proxy set in tinyproxy.conf)
> ---
> [user@fedora-32 ~]$ sudo dnf update
> Fedora 32 openh264 (From Cisco) - x86_64 0.0 B/s | 0 B
> 06:00
> Errors during downloading metadata for repository
> 'fedora-cisco-openh264':
> - Curl error (28): Timeout was reached for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64
> [Operation timed out after 30000 milliseconds with 0 out of 0 bytes
> received]
> - Curl error (28): Timeout was reached for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64
> [Operation timed out after 30001 milliseconds with 0 out of 0 bytes
> received]
> Error: Failed to download metadata for repo 'fedora-cisco-openh264':
> Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached
> for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-32&arch=x86_64
> [Operation timed out after 30001 milliseconds with 0 out of 0 bytes
> received]
> Fedora Modular 32 - x86_64 0.0 B/s | 0 B
> 06:00
> Errors during downloading metadata for repository 'fedora-modular':
> - Curl error (28): Timeout was reached for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64
> [Operation timed out after 30001 milliseconds with 0 out of 0 bytes
> received]
> - Curl error (28): Timeout was reached for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-32&arch=x86_64
> [Operation timed out after 30000 milliseconds with 0 out of 0 bytes
> received]
> 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-32&arch=x86_64
> [Operation timed out after 30000 milliseconds with 0 out of 0 bytes
> received]
> ---
>
> I hope this additional info might help to lead toward some more
> suggestions...
SUCCESS!
I figured it out. I can download updates via my corporate proxy! The act
of writing everything out helped me to catch something.
I noticed that in @awokd's writeup you have this:
~~~
echo "Upstream 10.0.0.1:8080" >>
/etc/tinyproxy/tinyproxy-updates.conf
~~~
You were missing "http" in the Upstream line. This works:
~~~
echo "Upstream http 010.0.0.1:8080" >>
/etc/tinyproxy/tinyproxy-updates.conf
~~~
If you make this small change, the instructions on that old document are
working on a fresh, clean install of R4.0.3, behind a corporate HTTP
Squid proxy. You may want to consider resubmitting it for inclusion in
the Docs.
Thanks all for the assistance!
--
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/53ac801617c5d1b133e2abba2a512690%40riseup.net.
