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...
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/1cf98b11146bb54cb5306f379df34df1%40riseup.net.
