When I run on retrace-stg.aws.fedoraproject.org:
/usr/bin/fasClient -i
I get TB:
Traceback (most recent call last): File "/usr/bin/fasClient", line 905, in <module> users = fas.filter_users(valid_groups=valid_groups, restricted_groups=restricted_groups) File "/usr/bin/fasClient", line 372, in filter_users if group not in self.groups: File "/usr/bin/fasClient", line 252, in _refresh_groups group_data = self.group_data(force_refresh=self.force_refresh) File "/usr/lib/python3.6/site-packages/fedora/client/fas2.py", line 929, in group_data req_params=params, auth=True) File "/usr/lib/python3.6/site-packages/fedora/client/baseclient.py", line 367, in send_request auth_params=auth_params, retries=retries, timeout=timeout) File "/usr/lib/python3.6/site-packages/fedora/client/proxyclient.py", line 386, in send_request timeout=timeout, File "/usr/lib/python3.6/site-packages/requests/api.py", line 116, in post return request('post', url, data=data, json=json, kwargs) File "/usr/lib/python3.6/site-packages/requests/api.py", line 60, in request return session.request(method=method, url=url, kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 533, in request resp = self.send(prep, send_kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 646, in send r = adapter.send(request, kwargs) File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 516, in send raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: HTTPSConnectionPool(host='admin.stg.fedoraproject.org', port=443): Max retries exceeded with url: /accounts/json/fas_client/group_data (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fd61ea079e8>: Failed to establish a new connection: [Errno 110] Connection timed out',))
And indeed,
telnet admin.stg.fedoraproject.org 80
cannot reach it.
I tried to look where it is configured in ansible.git, but I cannot find it.
I would appreciate the help here.
Does the AWS proxy (proxy30) play into this somehow? /accounts seems to be routed to a dead end there, but it’s otherwise accessible.
So admin.stg.fedoraproject.org should be
[smooge@linode01 EL8-mod_qos]$ host admin.stg.fedoraproject.org admin.stg.fedoraproject.org is an alias for stg.fedoraproject.org. stg.fedoraproject.org has address 209.132.181.5
It doesn't touch the proxies at all. I think part of the problem must have been resolved out of this ticket as
[root@retrace-stg ~][STG]# host admin.stg.fedoraproject.org admin.stg.fedoraproject.org is an alias for stg.fedoraproject.org. stg.fedoraproject.org has address 209.132.181.5 [root@retrace-stg ~][STG]# traceroute 209.132.181.5 traceroute to 209.132.181.5 (209.132.181.5), 30 hops max, 60 byte packets 1 216.182.226.220 (216.182.226.220) 22.024 ms 216.182.226.198 (216.182.226.198) 18.339 ms 216.182.226.216 (216.182.226.216) 17.274 ms 2 100.66.8.184 (100.66.8.184) 16.579 ms 100.66.8.160 (100.66.8.160) 51.219 ms 100.66.13.148 (100.66.13.148) 18.762 ms 3 100.66.10.152 (100.66.10.152) 2.058 ms 100.66.10.114 (100.66.10.114) 4.404 ms 100.66.10.172 (100.66.10.172) 14.278 ms 4 100.66.7.101 (100.66.7.101) 14.741 ms 100.66.7.35 (100.66.7.35) 18.105 ms 100.66.7.53 (100.66.7.53) 18.021 ms 5 100.66.5.211 (100.66.5.211) 18.923 ms 100.66.5.229 (100.66.5.229) 12.421 ms 100.66.5.245 (100.66.5.245) 12.591 ms 6 100.65.15.225 (100.65.15.225) 0.847 ms 100.65.15.17 (100.65.15.17) 0.348 ms 100.65.14.145 (100.65.14.145) 1.034 ms 7 52.93.29.59 (52.93.29.59) 0.534 ms 52.93.29.43 (52.93.29.43) 0.809 ms 52.93.29.201 (52.93.29.201) 3.325 ms 8 100.100.8.20 (100.100.8.20) 0.601 ms 100.100.8.114 (100.100.8.114) 0.509 ms 100.100.8.0 (100.100.8.0) 0.689 ms 9 100.91.177.56 (100.91.177.56) 8.073 ms 100.91.177.220 (100.91.177.220) 6.685 ms 100.91.177.114 (100.91.177.114) 6.086 ms 10 100.91.165.48 (100.91.165.48) 6.950 ms 100.91.159.128 (100.91.159.128) 6.262 ms 100.91.165.82 (100.91.165.82) 6.678 ms 11 100.91.164.141 (100.91.164.141) 6.907 ms 100.91.165.115 (100.91.165.115) 6.250 ms 100.91.165.43 (100.91.165.43) 6.996 ms 12 100.91.221.20 (100.91.221.20) 9.863 ms 100.91.198.90 (100.91.198.90) 7.386 ms 100.91.198.44 (100.91.198.44) 6.517 ms 13 100.91.199.33 (100.91.199.33) 6.120 ms 100.91.198.79 (100.91.198.79) 7.189 ms 100.91.199.57 (100.91.199.57) 5.978 ms 14 52.93.128.102 (52.93.128.102) 7.086 ms 54.240.229.152 (54.240.229.152) 6.834 ms 150.222.241.178 (150.222.241.178) 6.400 ms 15 100.91.189.10 (100.91.189.10) 6.394 ms 100.91.217.122 (100.91.217.122) 6.673 ms 6.503 ms 16 * 100.91.217.133 (100.91.217.133) 9.049 ms 52.93.4.37 (52.93.4.37) 12.557 ms 17 100.91.191.132 (100.91.191.132) 6.296 ms 100.91.216.42 (100.91.216.42) 6.525 ms 52.93.4.110 (52.93.4.110) 6.282 ms 18 100.91.191.7 (100.91.191.7) 6.700 ms 208.122.29.37 (208.122.29.37) 6.034 ms 208.122.29.41 (208.122.29.41) 6.265 ms 19 52.93.128.208 (52.93.128.208) 6.641 ms 54.239.45.18 (54.239.45.18) 7.158 ms 52.93.128.208 (52.93.128.208) 7.050 ms 20 100.91.131.115 (100.91.131.115) 6.543 ms 100.91.131.23 (100.91.131.23) 6.505 ms 100.91.131.5 (100.91.131.5) 6.214 ms 21 * 52.93.4.55 (52.93.4.55) 13.142 ms 52.93.4.7 (52.93.4.7) 13.089 ms 22 64.95.160.1 (64.95.160.1) 60.243 ms 52.93.4.104 (52.93.4.104) 6.332 ms 52.93.4.94 (52.93.4.94) 7.035 ms 23 64.95.158.70 (64.95.158.70) 62.064 ms 208.122.29.41 (208.122.29.41) 6.379 ms 208.122.29.37 (208.122.29.37) 6.348 ms 24 border5.ae1-bbnet1.phx010.pnap.net (69.25.168.1) 60.223 ms bbr2.ae7.nym007.pnap.net (64.95.158.74) 6.610 ms 6.339 ms 25 bbr1.ae102.dal.pnap.net (64.95.158.173) 36.343 ms redhatphx-1.phx004.pnap.net (69.25.120.242) 62.859 ms redhat-2.edge1.phx004.pnap.net (69.25.121.26) 62.595 ms 26 bbr1.phx010.pnap.net (64.95.158.169) 60.549 ms transit-199-181-132-209.redhat.com (209.132.181.199) 62.935 ms bbr1.phx010.pnap.net (64.95.158.169) 60.586 ms 27 64.95.160.1 (64.95.160.1) 60.319 ms 60.468 ms 60.463 ms 28 64.95.158.70 (64.95.158.70) 62.214 ms 62.260 ms 62.327 ms 29 border5.ae1-bbnet1.phx010.pnap.net (69.25.168.1) 60.507 ms border5.ae2-bbnet2.phx010.pnap.net (69.25.168.65) 60.348 ms * 30 redhat-2.edge1.phx004.pnap.net (69.25.121.26) 62.937 ms 62.908 ms * [root@retrace-stg ~][STG]# telnet 209.132.181.5 80 Trying 209.132.181.5... Connected to 209.132.181.5. Escape character is '^]'. GET / <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https:///">here</a>.</p> <hr> <address>Apache Server at admin.fedoraproject.org Port 80</address> </body></html> Connection closed by foreign host.
so it can connect. I am checking to see about fas currently and will update the ticket when I get more info.
Metadata Update from @smooge: - Issue assigned to smooge - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: authentication, aws
Timeout and crash still occurring. Looking to see if there is a permission error elsewhere.
@kevin found the problem.
[root@retrace-stg ~][STG]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.5.128.177 proxy01.phx2.fedoraproject.org proxy01 proxy02 proxy03 proxy04 proxy05 proxy06 proxy07 proxy08 proxy09 proxy10 proxy11 proxy12 proxy13 proxy14 proxy30 fedoraproject.org admin.fedoraproject.org admin.stg.fedoraproject.org apps.fedoraproject.org apps.stg.fedoraproject.org 10.5.126.23 infrastructure.fedoraproject.org 10.5.128.175 pkgs.fedoraproject.org 10.5.128.148 memcached01.stg.phx2.fedoraproject.org memcached01 memcached02 memcached03 memcached04 10.5.128.120 db01.stg.phx2.fedoraproject.org db-ask db-koji01 db-github2fedmsg tagger_dbdb-summershum nuancier_db db-notifs db-kerneltest db-pps
Problem is that our playbooks assume that anything in the staging group is in phoenix and gets the staging phoenix hosts file. That doesn't work for this so I have added a specific hosts file for retrace-stg.aws.fedoraproject.org.
fasClient now works.
Metadata Update from @smooge: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.