Freezing repos with Azure SLES PAYG licenses

Hi,
When using SLES with PAYG licenses, we can use the Azure/SuSE’s SMT server to have access to repositories. However these always contain new patches.
What most enterprises need is freezed repositories - when patching the whole environment takes 2 months, we need to ensure that first and last server will receive the same set of patches.
What is the best solution for this?
Can we for example run our own SMT server which would sync from the Azure SMT? Or we would need our own licenses from SuSE for that?
We could probably mirror the SMT repos with wget, but then we would need to set-up the VMs with that local repository and not those automatically pulled by the Azure/SMT whatever cloud zypper service on each zypper run.

[QUOTE=ux3adidas;58345]Hi,
When using SLES with PAYG licenses, we can use the Azure/SuSE’s SMT server to have access to repositories. However these always contain new patches.
What most enterprises need is freezed repositories - when patching the whole environment takes 2 months, we need to ensure that first and last server will receive the same set of patches.
What is the best solution for this?
Can we for example run our own SMT server which would sync from the Azure SMT? Or we would need our own licenses from SuSE for that?
We could probably mirror the SMT repos with wget, but then we would need to set-up the VMs with that local repository and not those automatically pulled by the Azure/SMT whatever cloud zypper service on each zypper run.[/QUOTE]

Chaining of update servers is not supported. You can run your own update servers in your own account, but those will then have to be registered against SCC (SUSE Customer Center) and thus you need an entitlement. This pushes you into the BYOS model. There is no way to convert an on-demand instance into a BYOS instance, thus you’d have to re-build your infrastructure, which is probably not an option.

You can use the ‘–download-only’ option with zypper to get the packages that are available at that given day. Then you can create a repo from this and distribute it to all the other servers that are suppossed to get the same package version. Not very pretty but this can certainly be automated.

Last but not least, and most likely the most convenient option is to use SUSE Manager (SUMa) [1] . With SUMa you can manage on-demand instances [2]. You obtain a SUMa entitlement from SUSE and get the appropriate number of lif-cycle-management license and you’re all set. With SUMa you then control when the updated packages go out and you can ensure that all managed systems have the same level of packages. We have arrived at version 4.0 for SUMa but the way on-demand instances get managed is still the same as in [2]

[1] https://www.suse.com/products/suse-manager/
[2] https://www.suse.com/c/suse-manager-3-0-arrives-public-cloud-long-last/

Thanks for you answer. We have found option “zypper patch --date”. Do you think it should work for this purpose?