Join Log in
Score:-1
Myan avatar Server

Yum to packages.microsoft.com failed on Centos 7

ir flag
Myan

You can say i'm beginner in using Centos. Our regional want to use packages.microsoft.com as repository. We have open the firewall to the packages.microsoft.com. Tracepath is no issue, but when we are doing yum update it is still failed. I try doing openssl to packages.microsoft.com, but only CONNECTED, it didn't get the Certificate.

Can anybody have similar problem? Or anybody know how to solve it?

Here is the error:

[root@abcde01 network-scripts]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.gbnetwork.com
 * extras: mirrors.gbnetwork.com
 * updates: mirrors.gbnetwork.com
base                                                                                    | 3.6 kB  00:00:00
extras                                                                                  | 2.9 kB  00:00:00
https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: [Errno 12] Timeout on https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')
Trying other mirror.
https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: [Errno 12] Timeout on https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')
Trying other mirror.
https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: [Errno 12] Timeout on https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')
Trying other mirror.
https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: [Errno 12] Timeout on https://packages.microsoft.com/centos/7/prod/repodata/repomd.xml: (28, 'Operation timed out after 30001 milliseconds with 0 out of 0 bytes received')
Trying other mirror.

[root@abcde01 network-scripts]# openssl s_client -connect packages.microsoft.com:443
CONNECTED(00000003)



[root@ieleaisiq01 network-scripts]# curl -vk https://packages.microsoft.com
* About to connect() to packages.microsoft.com port 443 (#0)
*   Trying 52.230.121.169...
* Connected to packages.microsoft.com (52.230.121.169) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb

Add more detail :

We have sure to open to all CDn IP Address used by packages.microsoft.com. When we are doing tracepath, it is already go to public :

[root@abcde01]# tracepath packages.microsoft.com -p 443
 1?: [LOCALHOST]                                         pmtu 1500
 1:  gateway                                               0.166ms asymm 64
 1:  gateway                                               0.080ms asymm 64
 2:  100.64.96.0                                           0.171ms
 3:  10.1.22.2                                             0.518ms
 4:  10.1.22.9                                             0.496ms
 5:  10.1.22.17                                            0.561ms
 6:  10.1.22.17                                            0.554ms pmtu 1476
 6:  192.168.1.99                                         20.473ms
 7:  10.1.22.41                                           20.216ms
 8:  203.115.193.250                                      23.265ms
 9:  cbj-br1.arc.net.my                                   17.568ms
10:  203.115.224.98                                       23.552ms
11:  microsoft-1.myix.my                                  23.661ms
12:  ae28-0.icr02.kul01.ntwk.msn.net                      38.018ms
13:  be-102-0.ibr01.kul01.ntwk.msn.net                    28.477ms asymm 17
14:  be-7-0.ibr02.sg3.ntwk.msn.net                        29.007ms asymm 16
15:  ae102-0.icr02.sg3.ntwk.msn.net                       28.548ms
16:  no reply
17:  no reply
18:  no reply
^C

Appreciate for your help.

Thanks.

116
1 + 0
ssl
yum
Score:3
HBruijn avatar Server
in flag
HBruijn

We have open the firewall to the packages.microsoft.com

That is probably where you went wrong.

When a hostname is used in a firewall rule usually it will effected with the (single) IP-address to hostname resolves to at the moment the rule gets added.

Like many download sites packages.microsoft.com appears to be load balanced and/or uses a CDN or something and is not tied to a single IP-address.

When your yum tries to connect to packages.microsoft.com ; it will most likely resolve to a different IP-address than the one that was resolved and used in your firewall and the connection will be blocked.

+ 5
fr flag
Tomek
I would add a suggestion to check IP address presented by curl in question against firewall rules. This should immediately confirm or reject this answer.
0
Reply
Myan avatar
ir flag
Myan
Hi @Tomek, we have confirm the block IP Address used by CDN. we are not allowed only one IP, but more than 210 IP Address block from Microsoft documentation. When we are doing tracepath, it can reach the Microsoft public IP address.
0
Reply
fr flag
Tomek
It's probably about time to disclose your firewall rules... BTW, what MTU do you use on your network, on the Internet connection and do you block ICMP?
0
Reply
Myan avatar
ir flag
Myan
Hi @Tomek, we use MTU 1500. yes for ICMP is blocked. Do we need to open this ICMP ?
0
Reply
fr flag
Tomek
HTTP(S) connections use much larger packets than the tracepath. And different networks along the route can support different maximum packet sizes. To help cope with that IPv4 packets are either broken by the routers or ICMP is used to signal sender that it needs to send smaller packets. If ICMP is blocked the latter breaks. For IPv6 there is no option to break packets along the path, so ICMP there MUST work. It is less of a problem for IPv4 but still can be. You can experiment with ping's `-M do` and `-s` options to see if that might be a case.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.