grep -l smt-ec2.susecloud.net /etc/zypp/repos.d/*
on all your running on demand instances in Amazon EC2 returns something you can be done reading, thanks for visiting. The information that follows does not effect you in any way. However, if you still have on demand instances that produce no output when the above grep is used then you should pay close attention to what comes next.
Way back when we all experienced Shellshock a new update infrastructure was put in place in AWS EC2. This update infrastructure is set up in an HA configuration and ever since updates for client instances have been very smooth sailing. With the ripples of Shellshock still fresh, in May 2015 we introduced the SUSE Image Life Cycle for Public Cloud Deployments which is intended to help those that create instances to avoid inadvertently launching instances from images that contain known vulnerabilities or from images that no longer receive updates.
In the spirit of the life cycle and in collaboration with Amazon a very large number of old images were initially set to be un-discoverable and were only launchable from the command line if the ami-id was already known and provided. As a second step these images move(d) from un-discoverable to private, i.e. they will no longer be able to be used. Everyone running an instance that was originally created from one of these images received an e-mail from Amazon about these changes. We are now approaching the time, May 18, 2016, where not only old images move to the bitbucket and shall never be launched again, but also where the update infrastructure that backs up those old images and instances launched from them will be decommissioned. The effect of this on running instances that are still connected to the old update infrastructure is that any “zypper” command will fail. However, the instances will continue to run. That the “zypper” command fails only makes it more apparent that these instances do not receive any updates. Instances of the SLES 11 SP2 and SLES 11 SP3 variety that have not migrated to the new update infrastructure and have not migrated to SLES 11 SP4 have not received any updates or security fixes in a while and thus the situation does not really change, other than that the situation of not getting updates is now more apparent. So, if you are running in a completely sealed VPC you may not care about this fancy update stuff anyway and you can happily continue to run the instance that you have as is. If however, you are running anything that is public facing then you should really migrate to the new update infrastructure and to SLES 11 SP4 to pick up the latest security fixes. That way your services will not DROWN in the murky field of security issues.
While all of this will probably get more exciting as the deadline approaches, that’s human nature apparently, consider this as a little reminder that procrastination leads to panic and a final appeal to those that have not transitioned to do so as soon as possible. Once transitioned to the “new” update infrastructure you should also move forward to use the latest service pack for SUSE Linux Enterprise Server, SLES 11 SP4 or SLES 12 SP1 . This will then get you fully up to date.
For those that are interested in some historical analysis, pint can help and you will be able to trace the history of every image we have released in Amazon EC2, meaning when the image was published, what image replaced it and when an image was deprecated and finally deleted. This implies that if you have a work load that is stateless or easy to configure and setup you can use pint to look up the image that you used as a base for your instance and trace it forward to find the image that is considered it’s successor.
With this, keep in mind that 2 months pass quickly and that once things get turned off on May 18, after an 18 months transition period there is no going back. Thus, if you still have some of your long running work loads connected to the old update infrastructure,
grep smt-ec2.susecloud.net /etc/zypp/repos.d/*
for on demand instances returns nothing, it is time to catch up and move to the not so new but more robust update infrastructure.