[Spacewalk-list] SLES best practices

[Flores, Javier (D4\INF\IT ID)]

Hi Chris

If I execute 'zypper info XYZ' on a system connected to Suse, I see a line with "Support Level: Level 3". On systems registered to Spacewalk this information is not there (Support Level: unknown) and thus zypper gives you that "warning". 

I don't know if you can get Spacewalk to sync this information but it never bothered me much. The RPM packages are the same and from Suse and that's what matters.

Regards,
Javier


-----Ursprüngliche Nachricht-----
Von: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] Im Auftrag von Will, Chris
Gesendet: Dienstag, 19. Januar 2016 14:37
An: spacewalk-list at redhat.com
Betreff: Re: [Spacewalk-list] SLES best practices

How do you setup your channels and repositories?  I am able to download and sync the rpms from SUSE but get the following messages when trying to do a zypper update from spacewalk.

slxmfdev2:~ # zypper up -D
Refreshing service 'spacewalk'.
Loading repository data...
Reading installed packages...


The following packages are going to be upgraded:
  augeas-lenses binutils gdb glibc glibc-32bit glibc-i18ndata glibc-locale glibc-locale-32bit gtk2 gtk2-32bit gtk2-lang
  inst-source-utils kernel-default kernel-default-base kernel-default-man ksh libaugeas0 libgcc_s1 libgcc_s1-32bit libgcrypt11
  libgcrypt11-32bit libgomp1 libicu libstdc++6 libstdc++6-32bit nscd openssh postfix release-notes-sles rpcbind s390-tools
  spacewalk-check spacewalk-client-setup spacewalk-client-tools suseRegisterInfo timezone usbutils xorg-x11-Xvnc
  zypp-plugin-spacewalk

The following packages are not supported by their vendor:
  augeas-lenses binutils gdb glibc glibc-32bit glibc-i18ndata glibc-locale glibc-locale-32bit gtk2 gtk2-32bit gtk2-lang
  inst-source-utils kernel-default kernel-default-base kernel-default-man ksh libaugeas0 libgcc_s1 libgcc_s1-32bit libgcrypt11
  libgcrypt11-32bit libgomp1 libicu libstdc++6 libstdc++6-32bit nscd openssh postfix release-notes-sles rpcbind s390-tools
  spacewalk-check spacewalk-client-setup spacewalk-client-tools suseRegisterInfo timezone usbutils xorg-x11-Xvnc
  zypp-plugin-spacewalk

Chris Will

-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Flores, Javier (D4\INF\IT ID)
Sent: Wednesday, January 13, 2016 6:40 AM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] SLES best practices

Hi Klaas,

I have been using one base channel for every major release (sles11, sles12) and child channels per service pack (sles11-sp3-pool, sles11-sp3-updates, sles11-sp4-pool, sles11-sp4-updates etc.)

To update from SLES 11 SP3 to SLES 11 SP4 I have simply added the SP4 channels to a SP3 system and then executed "zipper dup". After finishing I unsubscribe the system from the SP3 channels.

With SLES 11 I have had systems attached to channels of different service packs and no problems. But that was just because I forgot to unsubscribe from the old channels. I don't know if it's safe with SLES 12 and modules like web-scripting which have a different life cycle than the service packs.

Regards,
Javier



-----Ursprüngliche Nachricht-----
Von: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] Im Auftrag von Klaas Demter
Gesendet: Mittwoch, 13. Januar 2016 10:33
An: spacewalk-list at redhat.com
Betreff: [Spacewalk-list] SLES best practices

Hi,
I have a couple of questions regarding sles handling in spacewalk. What is a better solution and how can I more easily upgrade the machines connected to my spacewalk:
- create one base channel for a major Release (sles12) and child channels for GA/SP1/...
- create one base channel for each release (sles12-ga)

Can I safely have a sles12 sp1 system with the ga channels attached to it (ga-updates/ga-pool) or could this lead to inconsistency in that system? I guess the question is could a ga-update somehow be considered newer than a package in sp1 by zypper or could GA include packages dropped in newer service packs?

Does a simple zypper update suffice to update from one release to the next one once I change the subscribed channels in spacewalk or does zypper migrate do more than alter repositories and update packages?

Thanks in advance.

Greetings,
Klaas Demter

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.


_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list