Kindly provide me solution for this,
linux-lhb2:~ # zypper up
Refreshing service ‘SUSE_Linux_Enterprise_Server_12_SP1_x86_64’.
Problem retrieving the repository index file for service ‘SUSE_Linux_Enterprise_Server_12_SP1_x86_64’:
Download (curl) error for ‘https://scc.suse.com/access/services/1311/repo/repoindex.xml?cookies=0&credentials=SUSE_Linux_Ent erprise_Server_12_SP1_x86_64’:
Error code: Connection failed
Error message: Failed to connect to scc.suse.com port 443: Connection refused
Error message: Failed to connect to scc.suse.com port 443: Connection refused
I have right now verified that the SCC is technically reachable, as you can check by accessing https://scc.suse.com via browser.
Have you tried running “curl -v https://scc.suse.com” right from the command line? This should indicate that curl is contacting your proxy (“* Establish HTTP proxy tunnel to scc.suse.com:443”) - if it’s not, you’ll have to re-check your proxy settings (which may be overridden by local curl configuration).
Something on your side may be blocking this URL from being allowed to
connect. I can get there from here (laptop) though I then get an ‘Access
denied’ error because I do not have credentials, so that’s expected, and
since it’s an application layer (layer seven) error, it implies that the
layer four stuff (‘Connection refused’ error is layer four) is working
properly.
You can test easily with this command:
netcat -zv scc.suse.com 443
#You may need to use the 'nc' command depending on your distro:
nc -zv scc.suse.com 443
From my system the following output is returned showing that the server
side is working, and that my client can reach it:
Connection to scc.suse.com 443 port [tcp/https] succeeded!
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 08/06/16 12:44, arulramasamy wrote:
[color=blue]
Kindly provide me solution for this,
linux-lhb2:~ # zypper up
Refreshing service ‘SUSE_Linux_Enterprise_Server_12_SP1_x86_64’.
Problem retrieving the repository index file for service
‘SUSE_Linux_Enterprise_Server_12_SP1_x86_64’:
Download (curl) error for
‘https://scc.suse.com/access/services/1311/repo/repoindex.xml?cookies=0&credentials=SUSE_Linux_Ent
erprise_Server_12_SP1_x86_64’:
Error code: Connection failed
Error message: Failed to connect to scc.suse.com port 443: Connection
refused
Check if the URI is valid and accessible.
I have modified proxy also.[/color]
Other than echoing the advice of ab and jmozden can I also ask you to
say what you’ve done in relation to your proxy comment above.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
My proxy are working fine. Error is only what i defined before. Kindly help on that.[/QUOTE]
“working fine” in terms of “the suggested curl test works and shows the proxy is contacted”, from within the same console session you’re trying to run “zypper up” from?
On 06/08/2016 08:14 AM, arulramasamy wrote:[color=blue]
Hi ab,
I have tried ur comment, But I shows below error,
linux-lhb2:~ # netcat -zv scc.suse.com 443
netcat: connect to scc.suse.com port 443 (tcp) failed: Connection
refused
linux-lhb2:~ # nc -zv scc.suse.com 443
nc: connect to scc.suse.com port 443 (tcp) failed: Connection refused[/color]
Yes, this is because your system is not able to get out to that service.
You’ll need to check with your network folks to figure out why as,
clearly, it is accessible from other places. Perhaps you can tell us the
IP address resolved in your case, just in case you are hitting a different
box than we are. If the same as we hit, though, then your network folks
are blocking the connection. Whether or not your proxy is configured
correctly does not change that.
The IP address I see for this DNS entry, and the only one I get back, is
130.57.66.27
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
you’re right - even if curl falls back to http_proxy if no https_proxy is given, it slipped by my eye that the environment contains an entry for https_proxy, with empty value (or all blanks) - that may well be the root cause and should be checked in the curl config as well.
