Thanks Alex. The only problem is that we do not select the servers where we download maintenance from. We select an IBM server to place the order (either eccgw01.boulder.ibm.com or eccgw02.rochester.ibm.com), then you order is automatically placed in one of the download servers (the ones in IBM Software Electronic Delivery Servers Change <https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change>), and the download happens automatically.
Anyway, thanks again for your inputs, they helped a lot! ------------------------------------------------------------------------------------------------------------------------------- *Lucas Rosolen* [email protected] linkedin.com/in/lrosolen/ <https://www.linkedin.com/in/lrosolen> Em ter., 8 de abr. de 2025 às 10:18, Alexander Huemer < [email protected]> escreveu: > On Tue, Apr 08, 2025 at 09:33:47AM +0200, Lucas Rosalen wrote: > > We have a strange behavior when attempting to download maintenance use > SMPE > > Receive Order. > > > > As indicated here ( > > > https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change > ), > > our firewall has been opened for: > > deliverycb-mul.dhe.ibm.com - 129.35.224.118 > > deliverycb-mul.dhe.ibm.com - 170.225.126.48 > > > > However the download fails. > > > > When we ping deliverycb-mul.dhe.ibm.com, it resolves to 170.225.119.154, > > not to the IPs above. > > We tried ping/nslookup deliverycb-mul.dhe.ibm.com from several clients, > > from our own laptops in different networks, but they all resolve the > same. > > In DNS on the public internet, deliverycb-mul.dhe.ibm.com is a CNAME to > deliverycb-mul.dublindata.ibm.com., which in turn resolves to > 170.225.119.154 currently. > > > We have a case opened with IBM, but they say don't support DNS > resolution. > > Well, that is a contradiction in itself, for a number of reasons. > * The website at [1] clearly states the FQDNs (they call them hostnames > there). > * Apparently the webserver that feels responsible for > deliverycb-mul.dhe.ibm.com has a vhost set up for that FQDN only, not > for the IP address. if you punch, let's say https://170.225.119.154/ > into your browser, you are being served a certificate that is valid > for the FQDN only, not for the IP address. Your browser is going to > warn you about that condition, will allow you to continue though, as a > match is not enforced. > > If they do not support DNS resolution, why are there DNS entries for the > servers? Why are the web servers configured so that they only accept > requests targeted at those FQDNs? > Anyways... Provided DNS wouldn't be there at all and you still wanted to > download from those servers. You could either instruct your download > program to talk to that specific IP, e.g. > > $ curl --connect-to 170.225.119.154:443 https://deliverycb-mul.dhe.ibm.com > > Or you can associate the IP address with the FQDN in /etc/hosts or > whatever the equivalent on Windows is. > > What really happened here is that they changed the IP adddresses of > their servers for some unknown reason and neglected to drive appropriate > customer communication and also neglected to update the documentation > that you pointed to. > > Assuming that no funny business is happening here, you can just update > your firewall rules to allow traffic to the 'new' IP address and be done > with it. Modern firewalls can also whitelist DNS entries... > > The whole thing does not smell strange, the 'new' IP address is owned by > IBM. I wouldn't worry too much about this. > > -Alex > > [1] > https://www.ssllabs.com/ssltest/analyze.html?d=deliverycb-bld.dhe.ibm.com > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
