We’ve been running NCC, and need to convert to SCC for SLES12. Our SMT server is behind a firewall to the internet. What hosts and ports are needed for us to properly connect and get updates via the SCC method? We don’t have access now, but will need it soon, so I want to pester our FW people only once.
Do we just need http/https access to updates.suse.com, or is there more to it than that, like adding host scc.suse.com or other ports?
jdtrudel,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:
Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.suse.com/faq.php
If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…
Good luck!
Your SUSE Forums Team
http://forums.suse.com
[QUOTE=jdtrudel;37640]We’ve been running NCC, and need to convert to SCC for SLES12. Our SMT server is behind a firewall to the internet. What hosts and ports are needed for us to properly connect and get updates via the SCC method? We don’t have access now, but will need it soon, so I want to pester our FW people only once.
Do we just need http/https access to updates.suse.com, or is there more to it than that, like adding host scc.suse.com or other ports?[/QUOTE]
Hi!
I’m facing the same problem now. Did you managed to get SMT working from behind the firewall?
As per for now I know that login.microfocus.com and www.suse.com are necessary too, but other addresses it is reffering too are, whole bunch of cloud addresses from aws…
marcin
On 03/08/18 19:14, marcinstec wrote:
[color=blue]
I’m facing the same problem now. Did you managed to get SMT working from
behind the firewall?
As per for now I know that login.microfocus.com and www.suse.com are
necessary too, but other addresses it is reffering too are, whole bunch
of cloud addresses from aws…[/color]
For SLES12+ (SUSE-only) SMT it’s https access to scc.suse.com and
updates.suse.com where the latter is backed by a content delivery
network so IP names/addresses could change.
I don’t believe either login.microfocus.com or www.suse.com are required
from the SMT server (unless you’re logging in as a user and using a web
browser to connect to the SUSE Customer Center).
Simon
SUSE Knowledge Partner
[QUOTE=smflood;53837]On 03/08/18 19:14, marcinstec wrote:
…
For SLES12+ (SUSE-only) SMT it’s https access to scc.suse.com and
updates.suse.com where the latter is backed by a content delivery
network so IP names/addresses could change.
I don’t believe either login.microfocus.com or www.suse.com are required
from the SMT server (unless you’re logging in as a user and using a web
browser to connect to the SUSE Customer Center).
…
[/QUOTE]
Hi! Thanks for getting back to me.
I’m still struggling with it. The customer is very strict about firewall and outgoing traffic. I have to declare IPs/URLs I’m about to access otherwise everything is blocked.
I have checked the addresses mentioned by registration process"
https://scc.suse.com/connect
https://updates.suse.com
Both are accesible, however the output differs compared to the results I get from “unprotected” test machine - target machine get’s them crippled (ie looks like no css loaded)
And offcourse testing the credentials on target box fails.
The other thing that conserns me, is this “content delivery network” you mentioned, which obviously has to be accessible too. My unprotected test machine is happily mirroring some data from 68.232.34.211:https which is not even registered in DNS and according to whois, belongs to… verizon.
So concluding: running SMT behind really restricted firewall sucks.
Hey SuSE?!? How about reasonable list od IP’s and URLs SMT is accessing while registration AND mirroring process so I can make my security guys happy with the whiltelist of allowed sites ?
[QUOTE=marcinstec;54167]Hi! Thanks for getting back to me.
I’m still struggling with it. The customer is very strict about firewall and outgoing traffic. I have to declare IPs/URLs I’m about to access otherwise everything is blocked.
I have checked the addresses mentioned by registration process"
https://scc.suse.com/connect
https://updates.suse.com
Both are accesible, however the output differs compared to the results I get from “unprotected” test machine - target machine get’s them crippled (ie looks like no css loaded)
And offcourse testing the credentials on target box fails.
The other thing that conserns me, is this “content delivery network” you mentioned, which obviously has to be accessible too. My unprotected test machine is happily mirroring some data from 68.232.34.211:https which is not even registered in DNS and according to whois, belongs to… verizon.
So concluding: running SMT behind really restricted firewall sucks.
Hey SuSE?!? How about reasonable list od IP’s and URLs SMT is accessing while registration AND mirroring process so I can make my security guys happy with the whiltelist of allowed sites ?[/QUOTE]
Maybe setting it up as a “disconnected” SMT would make the security guys even more happy?
https://www.suse.com/documentation/sles-12/book_smt/data/smt_disconnected.html
If not then please open a SR to get an “official” answer, these forums are mainly used by users/customers/partners etc, SUSE don’t officially monitor these forums.
Thomas
Hi marcinstec,
[QUOTE=marcinstec;54167]
Hey SuSE?!? How about reasonable list od IP’s and URLs SMT is accessing while registration AND mirroring process so I can make my security guys happy with the whiltelist of allowed sites ?[/QUOTE]
the more typical use case for such environments is running SMT behind an HTTPS proxy. This offers the added bonus of using credentials to open rule sets selectively for requesters (like SMT) that might need a broader range of accesses.
Looking at our update server’s entries in our proxy log, I see connects to scc.suse.com and updates.suse.com, both https (port 443) - every other access is for channels not hosted at SUSE. These typically are no “web page” accesses, but API calls and RPM downloads, so there’s nothing to compare via the “looks” in a browser window.
Regarding the impact of CDNs: Of course, the actual IP addresses used for “updates.suse.com” may differ widely, pointing to according servers of some CDN. Thus IP filtering would be a pain and constant source of trouble.
Regards,
J