Fedora-21 template unable to connect to any repos

[Noah Vesely]

Recently upgraded to R3-rc1 and I'm currently having the problem that I'm unable to update my Fedora template using the standard mechanisms. I am using qubes-core-vm-3.0.9-1.fc21.x86_64.

[user@fedora-21]/etc/yum.repos.d% sudo yum update
Loaded plugins: langpacks, post-transaction-actions, yum-qubes-hooks
http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: [Errno 12] Timeout on http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds')
Trying other mirror.
http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: [Errno 12] Timeout on http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds')
Trying other mirror.
http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: [Errno 12] Timeout on http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds')
Trying other mirror.
... ad nauseam

It also cannot connect to the fedora repos, not just the Qubes ones. My Debian template is doing just fine. I usually use a VPN, but disabling it has no effect in this circumstance; the problem persists with the standard TemplateVM -> FirewallVM -> NetVM topology.

Just to go through the standard things, I'm just using the default repositories, the updates proxy is running in my netVM:

[user@net ~]$ systemctl status qubes-updates-proxy.service
● qubes-updates-proxy.service - Qubes updates proxy (tinyproxy)
   Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; enabled)
   Active: active (running) since Mon 2015-07-20 14:34:52 PDT; 7h ago
  Process: 423 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start (code=exited, status=0/SUCCESS)
  Process: 409 ExecStartPre=/usr/bin/install -d --owner tinyproxy --group tinyproxy /var/run/tinyproxy (code=exited, status=0/SUCCESS)
 Main PID: 452 (tinyproxy)
   CGroup: /system.slice/qubes-updates-proxy.service
           ├─ 452 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           ├─ 463 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           ├─ 464 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           ├─2940 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           ├─2941 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           ├─2942 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           ├─2943 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....
           └─2980 /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates....

, and in Qubes VM Manager I have allowed access to the VM update manager. One thing I could not figure out is if the updates-proxy-setup service was running in my fedora-21 VM by a different name or if it no longer exists. I could not find anything with a similar name that might indicate it was the same service running wtih a different name.

Here is a dump of IPtables -vnL for my net, firewall, and fedora-21 VMs.

[user@net ~]$ sudo iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
 3802  258K ACCEPT     tcp  --  vif+   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8082
    0     0 DROP       udp  --  vif+   *       0.0.0.0/0            0.0.0.0/0            udp dpt:68
12275   20M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    1    40 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
    9   596 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
  541 86500 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
 234K  203M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DROP       all  --  vif+   vif+    0.0.0.0/0            0.0.0.0/0          
 8537  550K ACCEPT     all  --  vif+   *       0.0.0.0/0            0.0.0.0/0          
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 15364 packets, 7502K bytes)
 pkts bytes target     prot opt in     out     source               destination

[user@firewall]~% sudo iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 DROP       udp  --  vif+   *       0.0.0.0/0            0.0.0.0/0            udp dpt:68
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
  350  125K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  vif0.0 *       0.0.0.0/0            0.0.0.0/0          
    0     0 DROP       all  --  vif+   vif+    0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     tcp  --  *      *       10.137.2.3           10.137.255.254       tcp dpt:8082
    0     0 REJECT     all  --  *      *       10.137.2.3           0.0.0.0/0            reject-with icmp-host-prohibited
   14   861 ACCEPT     udp  --  *      *       10.137.2.19          10.137.1.1           udp dpt:53
    0     0 ACCEPT     udp  --  *      *       10.137.2.19          10.137.1.254         udp dpt:53
    0     0 ACCEPT     tcp  --  *      *       10.137.2.19          10.137.1.1           tcp dpt:53
    0     0 ACCEPT     tcp  --  *      *       10.137.2.19          10.137.1.254         tcp dpt:53
    0     0 ACCEPT     icmp --  *      *       10.137.2.19          0.0.0.0/0          
    0     0 DROP       tcp  --  *      *       10.137.2.19          10.137.255.254       tcp dpt:8082
    8   544 ACCEPT     all  --  *      *       10.137.2.19          0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination  

[user@fedora-21 system]$ sudo iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       udp  --  vif+   *       0.0.0.0/0            0.0.0.0/0            udp dpt:68
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DROP       all  --  vif+   vif+    0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  vif+   *       0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 198 packets, 11880 bytes)
 pkts bytes target     prot opt in     out     source               destination

Hopefully someone more knowledgeable than me can explain what's going on.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I've seen a similar problem. It was because tinyproxy loaded
/etc/resolv.conf only at startup, which may happen before DHCP client
obtains actual DNS configuration. In such a case tinyproxy will use
invalid DNS servers, so all connections fails at this stage.
Restarting that service should fix the problem.

- --
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 v1

iQEcBAEBCAAGBQJVsWI5AAoJENuP0xzK19csMeYH/2VD93GcYOsla0yAWEUJ/Dt8
YVY+YHYrec5Qfm7bqSGm6IZuuFqZOyXsghHFfNi3I1CL0CHQvaN7ZRDsuoi+BVsw
D+q46sLukB+Il/gv0ieMyIaQpHv2NmWkEWv5jO8R0IfgqX4g1/RwTLAccnWvaBNe
QOT1hUu3NXHwnbKleDQCjx1YjrSDUgFKGhSlEWEDEKD/pWs4AOQFVPNWx7AV2ifF
hMR/ZiqwTQipGtkDZBb/J8Vc5lOZeQ82EONP4DNyXe46an6NRebO2sOHxkTe8B19
5oBJDi4BatRSDI4A3BvtKl+dhDlqrYVYo+aLsbtH9nbdprFOovyXhENhyfI80KI=
=9SUX
-----END PGP SIGNATURE-----

[Noah Vesely]

After starting fedora-21 VM, I tried `# systemctl restart qubes-updates-proxy.service` in NetVM with no luck.

[conp...@gmail.com]

why do you have the proxy in netvm and not firewallvm?

[Danny Fullerton]

On 07/23/2015 07:07 PM, Noah Vesely wrote:
> After starting fedora-21 VM, I tried `# systemctl restart
> qubes-updates-proxy.service` in NetVM with no luck.

Try this ```sudo service qubes-updates-proxy restart```

--
Danny Fullerton
Mantor Organization

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jul 24, 2015 at 05:01:24AM -0700, conp...@gmail.com wrote:
> why do you have the proxy in netvm and not firewallvm?

This is where update proxy is running by default. Details here:
https://www.qubes-os.org/doc/SoftwareUpdateVM/#updates-proxy

- --
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 v1

iQEcBAEBCAAGBQJVskVtAAoJENuP0xzK19cs2l8H/R0r0VXuWiILB4/gQ8Xuv+r7
UNtgEo8UzGB331TpZFenFGZRcLCymbsL12O0/GvjCeZE8tB7qDEH1XDgVr4EKXFf
NH6RlUB45RCN9Rz89AwuDkmnKYYPnE39LPgVOkZKZzzcXHUoRckO08N0b7N4TE6X
psMjbckjmebGGm5v32/IvdMggijYRa93D+ismTpxAH/IOC/F69N9Gn+JpVLSW3KB
uXh8U4Ba+DMXw5d6xa3R6PSMJ903htJWwUaLiuKHJA69KqyuNPsgH77Nlxzct4Rl
ENdgRVe0TZLtj+vqfaUoMhzu9sYB6pOxNPhsTb3vBP2mbEtyx6a+e65oLjyzUBI=
=Djjn
-----END PGP SIGNATURE-----

[Noah Vesely]

Try this ```sudo service qubes-updates-proxy restart```

Fedora has switched to systemd and `service` is a SysV utility. Maybe it still works for a lot of things, but the usage of systemctl (and other systemd utilities) should be preferred.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jul 23, 2015 at 04:07:51PM -0700, Noah Vesely wrote:
> After starting fedora-21 VM, I tried `# systemctl restart
> qubes-updates-proxy.service` in NetVM with no luck.

Check `journalctl -b` in netvm for possible proxy errors. Can you access
the repository from netvm directly (for example wget on URL printed in
error message)?

- --
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 v1

iQEcBAEBCAAGBQJVsr7vAAoJENuP0xzK19csIY8H/388PlPegFeV4tNo9POEP8JO
c9RH3aMt1+GKqkA0siClmVhrg8W8C2m71YwHzIuTKmHaa6fh1LnjVH60i2V639W2
hGR67P/7FBOMta1wFUl1d4ZOT9hrKDNvKkS9n8NIuEW76MEp60I0ME8mJ9gJ+h1G
m/CN2RrB3y0vGV5iPYoHapUIYQwxcSs96OcTeGwmo9qFIXp9hb4uMbRIzwj5WeqW
fXiOo0BL4/j0BlAv90qDj5+vs2Nwa7U2NhCapfbceLfUmOQjSYV4VBK5DB3bjTgZ
WsKsYzKS02ghzLfm/ahWuADu5hgJJ+L+3Aua4cTojLUXSp/Zsu90JeTDM4eNu5Q=
=erdk
-----END PGP SIGNATURE-----

[Unman]

But service redirects to systemctl, so neither the suggestion nor your
"correction" is much help.

I've seen the same behaviour myself - set an update VM with 21 as default
UpdateVM, and neither the PR-QBS-SERVICESs rule nor INPUT to 8082 are
set, and tinyproxy isnt running.

Interestingly, status shows this:
inactive (dead)
start condition failed
none of the trigger conditions were met.

Using systemctl wont start the service.
But if I manually run the Service Exec commands then everything works as
expected. I havent had time to debug this, so that's what I do when I
want to trigger an update.

unman

[Noah Vesely]

Check `journalctl -b` in netvm for possible proxy errors.

The journalctl log going back is totally clean (i.e., it starts up fine every time w/o errors).
 

Can you access the repository from netvm directly (for example wget on URL printed in
error message)?

Yes. I should have mentioned this earlier, but I can even download the repodata xml from the fedora-21.

I notice that when I stop the process by hitting ctrl+c a few times, I was seeing the curl error 56 after the first few times, which indicates a failure to receive network data (not very descriptive, I know), CURLE_RECV_ERROR. I don't know if this is just a result of yum shutting itself down or actually related to my problem as you don't see these errors if you allow yum to run through normally--you just get the timeout er

    [user@fedora-21]~% sudo yum update

    Loaded plugins: langpacks, post-transaction-actions, yum-qubes-hooks

    Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-21&arch=x86_64 error was
    12: Timeout on https://mirrors.fedoraproject.org/metalink?repo=fedora-21&arch=x86_64: (28, 'Connection timed out after 30001 milliseconds')

    http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: [Errno 12] Timeout on http://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: (28, 'Connection timed out after 30001 milliseconds')
    Trying other mirror.

    ^Chttp://yum.qubes-os.org/r3.0/current/vm/fc21/repodata/repomd.xml: [Errno 14] curl#56 - "Network error recv()"
    Trying other mirror.
    ^Chttp://yum.qubes-os.org/r3.0/current-testing/vm/fc21/repodata/repomd.xml: [Errno 14] curl#56 - "Network error recv()"
    Trying other mirror.
   
   
     One of the configured repositories failed (Qubes OS Repository for VM (updates-testing)),
     and yum doesn't have enough cached data to continue. At this point the only
     safe thing yum can do is fail. There are a few ways to work "fix" this:
   
         1. Contact the upstream for the repository and get them to fix the problem.
   
         2. Reconfigure the baseurl/etc. for the repository, to point to a working
            upstream. This is most often useful if you are using a newer
            distribution release than is supported by the repository (and the
            packages for the previous distribution release still work).
   
         3. Disable the repository, so yum won't use it by default. Yum will then
            just ignore the repository until you permanently enable it again or use
            --enablerepo for temporary usage:
   
                yum-config-manager --disable qubes-vm-r3.0-current-testing
   
         4. Configure the failing repository to be skipped, if it is unavailable.
            Note that yum will try to contact the repo. when it runs most commands,
            so will have to try and fail each time (and thus. yum will be be much
            slower). If it is a very temporary problem though, this is often a nice
            compromise:
   
                yum-config-manager --save --setopt=qubes-vm-r3.0-current-testing.skip_if_unavailable=true
   
    failure: repodata/repomd.xml from qubes-vm-r3.0-current-testing: [Errno 256] No more mirrors to try.
    http://yum.qubes-os.org/r3.0/current-testing/vm/fc21/repodata/repomd.xml: [Errno 14] curl#56 - "Network error recv()"