Well, the headline says it all, but that would make for a very short blog, thus let me expand a little bit.
Way back when, when GCE was very young and Google and SUSE worked together to bring SUSE Linux Enterprise Server as an on-demand image to GCE a verification mechanism was needed to verify access to the SUSE operated update infrastructure within GCE. This verification mechanism was based on the public IP address of the instance requesting access to the update infrastructure and served it’s purpose well for many years.
Fast forward and today we have many users that are interested to run their instances without a public IP address which is an obvious problem if a verification scheme is based on the public IP address from a known pool of addresses. Well, this problem is now resolved. Working with Google the verification mechanism now takes advantage of new capabilities in GCE and uses a token mechanism to verify that the requesting instance should gain access to the update infrastructure. The traffic still has to originate from within GCE, i.e. a routing of GCE -> Private Data Center -> GCE does not work, but setting up a NAT in GCE and sending the traffic through it just works, whether the instance behind the NAT has a public GCE assigned IP or not. There are some version conditions, of course, and I’ll get to those in a minute.
The verification part has two components, on the server side of the update infrastructure we’ve rolled out the necessary changes and the update infrastructure has been ready to go for about a week. On the client side, the instance, it is necessary that the following or later versions of packages are installed on the system.
On SLES and SLES For SAP
cloud-regionsrv-client version 7.0.6 or later
cloud-regionsrv-client-plugin-gce version 1.0.0 or later
regionServiceClientConfigGCE version 2.1.2 or later
On SLES For SAP
regionServiceClientConfigSAPGCE version 1.0.1 or later
These versions are pre-installed on SLES 12 SP3 and SLES 12 SP3 For SAP on-demand images and thus an instance fired up from those images will just get the repos as expected. For those running SLES 12 SP2 or SLES 12 SP1 instances, it is time to move forward. However, the packages are in the update repositories and can be installed via “zypper up“. Those running SLES 12 SP1 For SAP and SLES 12 SP2 For SAP you have some time before migration is in order and the package versions you need are also available in the update repositories, thus a “zypper up” will do the trick for you as well.
And that’s really all there is to it, it just works…