If I want to use a SUSE image (SuSe SLE11 SP3) in an OpenStack public cloud offering, what are the licensing/validation requirements for running that image? and what is the process associated with validation and updating the image?
I’m not sure if I need consistent public network connectivity for the license to validate itself against a SuSe license server on boot each time or if I need a licensing server that sits on that network for my virtual machines to validate against.
AFAICT there’s no “licensing server” involved. You’d only need connectivity to fetch upgrades from SUSE - which will then check your registration and license status, on the SUSE server. As to the currently valid licensing options, this may vary significantly depending on site licenses etc, so I believe this is beyond the scope of this forum. Do you have a current SUSE sales contact at hand? I’m sure they’d be happy to assist in determining the available options…
Thanks for the quick response. There is a sales contact that exist for our company somewhere but as we are a pretty large company (100K+ employees) and our license info is hard to track down. In the mean time I have done some reading on the Subscription
Management Tool manual and think I have the authentication process down. I think it is
1 - Install SMT from Novell/Suse Customer Center with appropriate subscription list for my clients
2 - SMT mirrors the appropriate updates/repos from N/SCC
3 - Build client image with requrl and reqcert parameters set in the kernel
4 - Every time authentication/update needed, they point to local SMT to process that job
I even found this diagram
My question now is can I do the authentication/updates without the SMT and point those machines to the N/SCC? The SMT manual shows the requrl and reqcert being set in examples
My question now is can I do the authentication/updates without the SMT and point those machines to the N/SCC?
actually, that is the standard way of doing things when you only have a few machines SMT typically enters the picture if you have more than a few machines, either to reduce network traffic by mirroring the SUSE repositories, or to be able to control update installation by manually enabling patches via a local testing/production repository setup within SMT.
You can simply use YaST to register the machine to NCC/SCC (the according dialog will even be presented during install, but can be called later as well). No specific configuration is required for this.
I was just coming back to report I think I found my solution HERE. I plan on using a cloud init script and upon launch of each VM run
suse_register -a email=joe@example.com -a regcode-sles=4adab769abc68 -a regcode-oes=30a74ebb94fa
as the root user which should authenticate me against my SCC account. Now it is just a matter of getting in contact with the right person in our Software Right’s Management team who has access .
SMT typically enters the picture if you have more than a few machines, either to reduce network traffic by mirroring the SUSE repositories, or to be able to control update installation by manually enabling patches via a local testing/production repository setup within SMT.
.