Can't get to https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-for-lustre/epel-7-x86_64/

[Danesh Manoharan]

guys, need some advise. I'm unable to access
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
from my organization's network. Outside the network is fine. The network/security team
has confirmed that the url has been white listed. Who can I contact to verify we are not
on your blacklist?

[Rick Stevens]

On 9/26/18 12:54 PM, Danesh Manoharan wrote:
>  guys, need some advise. I'm unable to access
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> from my organization's network. Outside the network is fine. The network/security team
> has confirmed that the url has been white listed. Who can I contact to verify we are not
> on your blacklist?
>  
You didn't specify what kind of error you're receiving (timeout, no such
host, whatever). I doubt you're blacklisted. If you are, you need to
tell us what your IP address is. Blacklisting is generally done via IP
address...not domain names.

From inside your network try getting the IP address of the site and
verify that it matches what I show below:

	[root@prophead ~]# host copr-be.cloud.fedoraproject.org
	copr-be.cloud.fedoraproject.org has address 209.132.184.48

I've seen DNS issues inside corporate networks cause things like this.
If the DNS doesn't resolve correctly, try adding a line to your
/etc/hosts file:

	209.132.184.48	copr-be.cloud.fedoraproject.org

to bypass your faulty DNS entry.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks(a)alldigital.com -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-                 IGNORE that man behind the keyboard!               -
-                                                - The Wizard of OS  -
----------------------------------------------------------------------

[Joe Zeff]

On 09/26/2018 01:54 PM, Danesh Manoharan wrote:
>  guys, need some advise. I'm unable to
> accesshttps://copr-be.cloud.fedoraproject.org/results/managerforlustre/ma...
>  from my organization's network. Outside the network is fine. The network/security
> team has confirmed that the url has been white listed. Who can I contact to verify we are
> not on your blacklist? 
Two questions: first, have you tried pinging 
copr-be.cloud.fedoraproject.org to make sure it's reachable from your 
network and second, what does your browser report as the reason it 
couldn't display the page?

[Danesh Manoharan]

1. pings don't come back. Think icmp is turned off.
2. On a machine inside.
[root@testmachine001 ~] #wget 
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
--2018-09-26 21:34:23--  (try:20) 
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... failed: Connection
timed out.
Giving up.
3. On a machine outside.
[root@testmachine ~]# wget
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
--2018-09-27 06:25:26-- 
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... connected.
ERROR: certificate common name “copr.fedorainfracloud.org” doesn’t match requested host
name “copr-be.cloud.fedoraproject.org”.
To connect to copr-be.cloud.fedoraproject.org insecurely, use ‘--no-check-certificate’.

I suspect we might have gotten blacklisted, maybe? We've been running a large lustre
install with IML which tells it's hosts to pull from the repo.

[Rick Stevens]

On 9/26/18 3:30 PM, Danesh Manoharan wrote:
>  1. pings don't come back. Think icmp is turned off.
>  2. On a machine inside.
>  [root@testmachine001 ~] #wget 
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
>  --2018-09-26 21:34:23--  (try:20) 
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
>  Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... failed: Connection
> timed out.
>  Giving up.
>  3. On a machine outside.
>  [root@testmachine ~]# wget
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
>  --2018-09-27 06:25:26-- 
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
>  Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
>  Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... connected.
>  ERROR: certificate common name “copr.fedorainfracloud.org” doesn’t match requested host
> name “copr-be.cloud.fedoraproject.org”.
>  To connect to copr-be.cloud.fedoraproject.org insecurely, use ‘--no-check-certificate’.
>  
>  I suspect we might have gotten blacklisted, maybe? We've been running a large lustre
> install with IML which tells it's hosts to pull from the repo.
>  
Hmmm, well, I see three possibilities:

	a) Your corporate firewall doesn't allow https:// (port 443)
	connections (unlikely)

	b) You're using a proxy or a browser that doesn't like the fact
	that the domain requested doesn't match the domain the SSL cert
	was generated for and just tosses the traffic out quietly. You
	could try the wget using that "--no-check-certificate" option
	and see if that buys you anything. That's just a wild stab in
	the dark, though.

	c) You really are blacklisted, but again I think that's fairly
	unlikely. The owners of the website would need to know your
	public IP to determine if you're blacklisted or not and you'd
	need to contact them directly I'd think--not this list. The
	website in question IS run by RedHat and the email contact for
	tech questions (according to whois) is "noc(a)redhat.com".

In regards to b) above, it is interesting that SSL cert is generated for
copr.fedorainfracloud.org. That, in turn, is an alias for
copr-fe.cloud.fedoraproject.org with an IP of 209.132.184.54. And your
request is for copr-be.cloud.fedoraproject.org with an IP of
209.132.184.48. Dunno if a redirect occurs or what (doesn't appear so
from the wget output), but if so, you may need to make sure your
firewall allows both IPs (209.132.184.48 and 209.132.184.54).

That's subtle ("copr-fe...." versus "copr-be...."), but
interesting. I'd
also have expected them to use wildcard SSL certs for
"*.fedoraproject.org" to handle this. For my part, I've always tried to
use SSL certs generated for actual the TLD of actual machine names--not
aliases. I think some servers and client libraries don't handle that
well, but I've been mistaken before (quite often, in fact).
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks(a)alldigital.com -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-   I haven't lost my mind.  It's backed up on tape somewhere, but   -
-                       probably not recoverable.                    -
----------------------------------------------------------------------

[Samuel Sieb]

On 9/26/18 3:30 PM, Danesh Manoharan wrote:
>  3. On a machine outside.
>  [root@testmachine ~]# wget
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
>  --2018-09-27 06:25:26-- 
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
>  Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
>  Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... connected.
>  ERROR: certificate common name “copr.fedorainfracloud.org” doesn’t match requested host
> name “copr-be.cloud.fedoraproject.org”.
>  To connect to copr-be.cloud.fedoraproject.org insecurely, use ‘--no-check-certificate’.
This might be a problem.  If your work uses a proxy, it might block 
something like this.

[Ed Greshko]

On 9/27/18 7:22 AM, Samuel Sieb wrote:
>  On 9/26/18 3:30 PM, Danesh Manoharan wrote:
> > 3. On a machine outside.
> > [root@testmachine ~]# wget
> >
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> > --2018-09-27 06:25:26-- 
> >
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> > Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
> > Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... connected.
> > ERROR: certificate common name “copr.fedorainfracloud.org” doesn’t match requested
> > host name “copr-be.cloud.fedoraproject.org”.
> > To connect to copr-be.cloud.fedoraproject.org insecurely, use
> > ‘--no-check-certificate’.
>
>  This might be a problem.  If your work uses a proxy, it might block something like
>  this. 
Well, he said "On a machine outside" which I took to mean not in the office.

FWIW,

[egreshko@meimei tmp]$ wget
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
--2018-09-27 07:24:19-- 
https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
Resolving copr-be.cloud.fedoraproject.org (copr-be.cloud.fedoraproject.org)...
209.132.184.48
Connecting to copr-be.cloud.fedoraproject.org
(copr-be.cloud.fedoraproject.org)|209.132.184.48|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 75982 (74K) [text/html]
Saving to: ‘index.html’

index.html           100%[=====================>]  74.20K   458KB/s    in 0.2s   

2018-09-27 07:24:20 (458 KB/s) - ‘index.html’ saved [75982/75982]

Just to be complete I would also do

telnet 209.132.184.48 443        as well as
telnet copr-be.cloud.fedoraproject.org 443

Both at work and outside of work.

-- 
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them, then tell them what you told them."

[Samuel Sieb]

On 9/26/18 4:29 PM, Ed Greshko wrote:
>  On 9/27/18 7:22 AM, Samuel Sieb wrote:
> > On 9/26/18 3:30 PM, Danesh Manoharan wrote:
> >> 3. On a machine outside.
> >> [root@testmachine ~]# wget
> >>
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> >> --2018-09-27 06:25:26--
> >>
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> >> Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
> >> Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443... connected.
> >> ERROR: certificate common name “copr.fedorainfracloud.org” doesn’t match
> requested
> >> host name “copr-be.cloud.fedoraproject.org”.
> >> To connect to copr-be.cloud.fedoraproject.org insecurely, use
> >> ‘--no-check-certificate’.
> >
> > This might be a problem.  If your work uses a proxy, it might block something like
> > this.
>  
>  Well, he said "On a machine outside" which I took to mean not in the office.
Yes, that was my point.  It worked outside, but gave a certificate 
warning.  If they have a proxy like where I work and it detects that, it 
might completely block the connection.

[Ed Greshko]

On 9/27/18 10:03 AM, Samuel Sieb wrote:
>  On 9/26/18 4:29 PM, Ed Greshko wrote:
> > On 9/27/18 7:22 AM, Samuel Sieb wrote:
> >> On 9/26/18 3:30 PM, Danesh Manoharan wrote:
> >>> 3. On a machine outside.
> >>> [root@testmachine ~]# wget
> >>>
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> >>>
> >>> --2018-09-27 06:25:26--
> >>>
> https://copr-be.cloud.fedoraproject.org/results/managerforlustre/manager-...
> >>>
> >>> Resolving copr-be.cloud.fedoraproject.org... 209.132.184.48
> >>> Connecting to copr-be.cloud.fedoraproject.org|209.132.184.48|:443...
> connected.
> >>> ERROR: certificate common name “copr.fedorainfracloud.org” doesn’t match
> requested
> >>> host name “copr-be.cloud.fedoraproject.org”.
> >>> To connect to copr-be.cloud.fedoraproject.org insecurely, use
> >>> ‘--no-check-certificate’.
> >>
> >> This might be a problem.  If your work uses a proxy, it might block something
> like
> >> this.
> >
> > Well, he said "On a machine outside" which I took to mean not in the
> office.
>
>  Yes, that was my point.  It worked outside, but gave a certificate warning.  If
>  they have a proxy like where I work and it detects that, it might completely block
>  the connection.
>  
I see your point.  I suppose I was confused since, like I showed, I am certainly
outside of his company (or any other) and I don't get a "certificate
warning".
So, I am left to wonder why he gets one and I don't. 


-- 
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them, then tell them what you told them."

[Joe Zeff]

On 09/26/2018 04:30 PM, Danesh Manoharan wrote:
>  1. pings don't come back. Think icmp is turned off. 
Try traceroute, to see how far the pings get before they die.  It's 
unlikely, but there might be some server you're going through that's 
blocking the pings.

[Ed Greshko]

On 9/27/18 7:41 AM, Joe Zeff wrote:
>  On 09/26/2018 04:30 PM, Danesh Manoharan wrote:
> > 1. pings don't come back. Think icmp is turned off.
>
>  Try traceroute, to see how far the pings get before they die.  It's unlikely, but
>  there might be some server you're going through that's blocking the pings.
>  
Actually, I would do "sudo traceroute -T -O info --sport=443 209.132.184.48"  
Since
everything is working fine for me I'll include my results.

[egreshko@meimei ~]$ sudo traceroute -T -O info --sport=443 209.132.184.48
traceroute to 209.132.184.48 (209.132.184.48), 30 hops max, 60 byte packets
 1  wifi.greshko.com (192.168.1.1)  0.293 ms  0.324 ms  0.348 ms
 2  211.75.128.254 (211.75.128.254)  7.016 ms  7.124 ms  6.740 ms
 3  tpdt-3308.hinet.net (168.95.211.46)  6.459 ms  6.590 ms  6.768 ms
 4  tpdt-3022.hinet.net (220.128.27.94)  7.610 ms  7.107 ms  7.118 ms
 5  r4101-s2.tp.hinet.net (220.128.14.97)  6.795 ms  6.346 ms  6.805 ms
 6  r4001-s2.tp.hinet.net (220.128.30.249)  33.731 ms  6.754 ms  6.900 ms
 7  r11-pa.us.hinet.net (202.39.91.37)  132.211 ms  132.026 ms  132.103 ms
 8  sl-mst50-pa-.sprintlink.net (144.223.179.25)  138.562 ms  138.723 ms  138.496 ms
 9  144.232.15.56 (144.232.15.56)  142.652 ms  142.509 ms  140.486 ms
10  144.232.15.245 (144.232.15.245)  147.554 ms  143.141 ms  143.772 ms
11  144.232.8.194 (144.232.8.194)  137.500 ms  137.660 ms  137.585 ms
12  be3144.ccr22.sjc01.atlas.cogentco.com (154.54.5.101)  153.119 ms  153.147 ms 
152.758 ms
13  be3177.ccr42.lax01.atlas.cogentco.com (154.54.40.145)  141.021 ms  140.908 ms 
140.029 ms
14  be2932.ccr32.phx01.atlas.cogentco.com (154.54.45.161)  152.725 ms  152.245 ms 
152.488 ms
15  be3439.agr22.phx01.atlas.cogentco.com (154.54.85.94)  152.828 ms  152.292 ms 
152.358 ms
16  te0-0-1-0.nr12.b019174-0.phx01.atlas.cogentco.com (154.24.53.154)  153.313 ms 
153.229 ms  153.384 ms
17  38.88.238.30 (38.88.238.30)  152.848 ms  152.670 ms  152.917 ms
18  unused (66.187.228.248)  157.501 ms  161.845 ms  156.674 ms
19  * * *
20  * * *
21  instance-48.cloud.fedoraproject.org (209.132.184.48)  155.346 ms  152.908 ms 
153.157 ms
22  * instance-48.cloud.fedoraproject.org (209.132.184.48) <ack>  153.086 ms
instance-48.cloud.fedoraproject.org (209.132.184.48) <syn,ack>  153.010 ms

The final <syn,ack> confirms connection.




-- 
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them, then tell them what you told them."

[Todd Zullinger]

Danesh Manoharan wrote:
>  I suspect we might have gotten blacklisted, maybe? We've
>  been running a large lustre install with IML which tells
>  it's hosts to pull from the repo. 
I would try asking in #fedora-buildsys on irc.freenode.net
or send a message to the copr mailing list at
copr-devel(a)lists.fedorahosted.org.

I have seen someone else whose IP's were blacklisted by the
copr systems recently, so that's certinly a possiblity.

-- 
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If everything seems to be going well, you have obviously overlooked
something.