[sles-beta] Question concerning SUSEConnect subscription register process

urs.frey at post.ch urs.frey at post.ch
Thu Jul 10 03:53:06 MDT 2014


Hi Will

>The SCC team are currently working on duplicate detection, de-duplication, 
>product updates and migration from NCC-registered systems to SCC.  These will 
>give registration operations an 'at most once' semantic.
>
>There is "deregister" API already, but it's not exposed in the SUSEConnect 
>CLI, yet.
Thank you for this most welcome announcement

In my place here, servers get set up using autoyast by operations team. In about 5% of all cases, the operations team does get a wrong setup order.
(Project people coming from Microsoft world, not knowing about the Linux functional (pattern) setup.
So a server might get set up as web server instead getting set up as proxy server. Or if there is no function at all, base pattern gets set up.
So the operations team does a second setup. On my SMT I get the two different UIDs for the same server with the same IP and hostname.

For me it would be most helpful if I could use a kind of autoyast tag to deregister versus my SMT if already existing.
Of course I cannot put an existing UID string into my autoinst.xml profile, because at setup time nobody will go and check the SMT manually before creating the autoinst.xml profile.

But all my servers do have a defined hostname, IP, hardware model, MAC.
So if the UID gets created out of such parameters there would be a way to check versus the SMT if a registration already exists and one could either use the same UID when re-installing, or deregister.

I can imagine MAC does probably not get used when generating the registration UID.
This can simply be proven because when changing the motherboard with its NICs in a HP Proliant server, the MAC changes, but the SLES registration UID afterwards stays the same.

Maybe you can see now what the idea behind is:
Reducing manual work on SMT and / or NCC / SCC and having a proper registration base where each SLES installation is registered once.

Of course you will also have to deal with sites, where the server gets set up using DHCP and then being transferred to its final network segment.

Best regards

Urs Frey                                              
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX     : ++41 (0)58 667 30 07 
E-Mail:   urs.frey at post.ch

-----Ursprüngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Will Stephenson
Gesendet: Tuesday, July 08, 2014 12:47 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] Question concerning SUSEConnect subscription register process

On Monday 07 Jul 2014 10:37:48 urs.frey at post.ch wrote:
> Upon registering a new installation against NCC / SMT a unique installation
> UID gets created The registration against a subscription gets done by this
> UID.
> 
> On a second installation of the very same server again a new UID gets
> created. Now in my subscription register list I have two registrations but
> only one server So I have to clean up my subscription registrations
> manually and regularly, else there might be to many subscriptions "eaten"
> by non-existing servers.
> 
> In the operations team, there very often installations get redone,
> interrupted etc. Wrong orders, customers not satisfied after installation,
> etc. So I miss a mechanism where I can de-register a server node first upon
> re-installation Something like SUSEConnect unregister `hostname`

The SCC team are currently working on duplicate detection, de-duplication, 
product updates and migration from NCC-registered systems to SCC.  These will 
give registration operations an 'at most once' semantic.

There is "deregister" API already, but it's not exposed in the SUSEConnect 
CLI, yet.

Will 
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta


More information about the sles-beta mailing list