We are happy to announce that a new SUSE update infrastructure is in place in Microsoft Azure. The update infrastructure operated and maintained by SUSE provides updates to instances launched from SUSE released SUSE Linux Enterprise Server on demand images in Microsoft Azure.
Those using the latest images, released on 2014-11-06 or thereafter, will automatically connect to the new infrastructure. Those that have running instances started from images released prior to this date need to switch the instances to the new infrastructure. To switch a running instance follow these simple steps:
zypper --no-refresh --non-interactive in instanceInfraUpgrade.noarch.rpm
instanceInfraUpgrade
rm instanceInfraUpgrade.noarch.rpm
After the update to the new infrastructure “zypper lr” will point to repositories starting with “SMT”
The old infrastructure server will be disabled on June 30, 2015.
– July 29, 2015 –
I added the ‘–no-refresh’ option to the zypper command to prevent zypper from trying to refresh the repositories. The old update infrastructure was removed on June 30th, as announced. Anyone trying to follow the procedure that still has the old update infrastructure configured will run into issues if the ‘–no-refresh’ option is not used.
The legacy infrastructure server is now offline. If you are experiencing any issues receiving updates, please check the procedure outlined above, for migrating to the new infrastructure, or start a new instance.
Hello, a question about this new update infrastructure (OK not so new now).
Is this service hosted in the Azure DC for each region? We are operating from the North Europe (Dublin) region, and deploying the new SLES 11 SP4 images. Are there now SLES update servers deployed into North Europe for this purpose?
We found that the SLES image has the registercloudguest script which executes when a new VM is deploying. This script tries to connect to SMT servers from /etc/regionserverclnt.cfg file by https protocol:
cat /etc/regionserverclnt.cfg
[server]
api = regionInfo
certLocation = /var/lib/regionService/certs
regionsrv = 104.45.154.114,104.45.31.195,191.237.254.253,23.100.36.229,23.101.26.184
We are wondering where these IP addresses are hosted? We can see they are registered to Microsoft (via whois) but they are not listed in the published Microsoft range for North Europe.
We need to conform to company IT Security policies, and so we need to understand where these servers are hosted, who is managing them.
Those IP addresses are our geodistributed region servers. regionsrvclnt will request from (at least) one of the region servers, and it will respond with information about your local SMT servers, which, yes, run in each region.
The IP addresses of all our servers are available via the pint command line tool; e.g. :
$ pint microsoft servers
will return a list of the IP addresses for both the region servers and all SMT servers; you probably want
$ pint microsoft servers --regionserver
$ pint microsoft servers --smt --region 'North Europe'[/CODE]
in order to give you the global region servers (same as the list in the config file) and your region-local SMT servers.
Just for reference, here's the current output:
[CODE]$ pint microsoft servers --regionserver
<?xml version='1.0' encoding='UTF-8'?>
<servers>
<server ip="23.101.26.184" name="" region="Southeast Asia" type="regionserver"/>
<server ip="191.237.254.253" name="" region="Brazil South" type="regionserver"/>
<server ip="104.45.31.195" name="" region="West Europe" type="regionserver"/>
<server ip="104.45.154.114" name="" region="East US" type="regionserver"/>
<server ip="23.100.36.229" name="" region="West US" type="regionserver"/>
</servers>
$ pint microsoft servers --smt --region 'North Europe'
<?xml version='1.0' encoding='UTF-8'?>
<servers>
<server ip="104.45.85.11" name="smt-azure.susecloud.net" region="North Europe" type="smt"/>
<server ip="104.45.85.45" name="smt-azure.susecloud.net" region="North Europe" type="smt"/>
</servers>
I realize this is from 3 years ago, but is this still the current update infrastructure?
I have inherited a few servers that are SLES 11 SP2 and I am getting the following error for all repositories that use “default-ec2-update.susecloud.net”. I think the update script has not been run on the affected servers, would it still work or have there been additional changes, etc?
[QUOTE=rjschwei;24920]We are happy to announce that a new SUSE update infrastructure is in place in Microsoft Azure. The update infrastructure operated and maintained by SUSE provides updates to instances launched from SUSE released SUSE Linux Enterprise Server on demand images in Microsoft Azure.
Those using the latest images, released on 2014-11-06 or thereafter, will automatically connect to the new infrastructure. Those that have running instances started from images released prior to this date need to switch the instances to the new infrastructure. To switch a running instance follow these simple steps:
zypper --no-refresh --non-interactive in instanceInfraUpgrade.noarch.rpm
instanceInfraUpgrade
rm instanceInfraUpgrade.noarch.rpm
After the update to the new infrastructure “zypper lr” will point to repositories starting with “SMT”
The old infrastructure server will be disabled on June 30, 2015.
– July 29, 2015 –
I added the ‘–no-refresh’ option to the zypper command to prevent zypper from trying to refresh the repositories. The old update infrastructure was removed on June 30th, as announced. Anyone trying to follow the procedure that still has the old update infrastructure configured will run into issues if the ‘–no-refresh’ option is not used.[/QUOTE]
I realize this is from 3 years ago, but is this still the current update infrastructure?
I have inherited a few servers that are SLES 11 SP2 and I am getting the following error for all repositories that use “default-ec2-update.susecloud.net”. I think the update script has not been run on the affected servers, would it still work or have there been additional changes, etc?
Repository ‘tmp_instance_infrastructure_upgrade’ priority has been set to 1.
Retrieving repository ‘tmp_instance_infrastructure_upgrade’ metadata [done]
Building repository ‘tmp_instance_infrastructure_upgrade’ cache [done]
Specified repositories have been refreshed.
Loading repository data…
Reading installed packages…
‘python-argparse’ is already installed.
No update candidate for ‘python-argparse-1.2.1-2.5.65.x86_64’. The highest available version is already installed.
Resolving package dependencies…
Problem: nothing provides python-m2crypto needed by cloud-regionsrv-client-6.3.8-22.2.x86_64
Solution 1: do not install cloud-regionsrv-client-6.3.8-22.2.x86_64
Solution 2: break cloud-regionsrv-client-6.3.8-22.2.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c): c
Removing repository ‘tmp_instance_infrastructure_upgrade’ [done]
Repository ‘tmp_instance_infrastructure_upgrade’ has been removed.
How do I fix this? is this infraupgrade still viable?