[Spacewalk-list] Antwort: advice about organizing channels and repositories

Mon Dec 4 07:08:57 UTC 2017

Hi!

I have a little bit "complex" layout.
Based on the problem that I have to keep all my Servers on same Patchlevel 
throughout the month.

As example for the CentOS 6-part

Base-Channel CentOS6 
--- childchannel CentOS 6.9
--- childchannel CentOS 6.9 Updates

Clone Of Base-Channel CentOS6
--- clone of childchannel CentOS 6
--- clone of childchannel CentOS 6 Updates - Months 01-04-07-10
--- clone of childchannel CentOS 6 Updates - Months 02-05-08-11
--- clone of childchannel CentOS 6 Updates - Months 03-06-09-12

There is no Server connected to Base-Channel and below, this is wehre I do 
my Reposync on daily base in it

All my Servers are subscribed to the Clone of Base-Channel, CentOS 6 the 
"clone of Childchannel CentOS6" and the papropiate Updates-Channel 
I do a clone by date + Channelsync every start of the Month and switch my 
Servers from e.g subchannel 02-05-08-11 to 03-06-09-12 and so on....

With this one I have the benefit to keep the Servers on the same Level for 
the full month, end even could keep them at least 3 Months "old" :-)

cheers
Matthias

------------------------------------------------------------------------------------
METZLER 
Informationstechnologie

Matthias Gruber 
IT-Infrastruktur & -Betrieb

B. Metzler seel. Sohn & Co.
Kommanditgesellschaft auf Aktien
Untermainanlage 1
60329 Frankfurt am Main
Telefon (0 69) 21 04 - 43 30
Telefax (0 69) 21 04 - 40 40
MGruber at metzler.com
www.metzler.com

Von:    Nicole Beck <nskyrca at syr.edu>
An:     "'spacewalk-list at redhat.com'" <spacewalk-list at redhat.com>
Datum:  01.12.2017 16:00
Betreff:        [Spacewalk-list] advice about organizing channels and 
repositories
Gesendet von:   spacewalk-list-bounces at redhat.com

Hi,
I’m new to spacewalk, and I’m not sure how to organize the channels.  If, 
for example, you are running CentOS 6.7 without spacewalk, and you run 
“yum update”, you will end up at CentOS 6.9.  If I add spacewalk, what is 
the best way to do that?  Do I make a centos67-base with a 
centos67-updates child, then a centos69-base with a centos69-update child, 
using the respective repositories (which I think are a vault.centos.org 
and http://mirror.centos.org/centos-6/6.9/os/x86_64/)? But then do I have 
to change which channel my server is subscribed to from the centos67 to 
centos69? Or should I make a centos6 channel with the child 
centos6-updates channel using the repositories for latest minor version (
http://mirror.centos.org/centos-6/6/os/x86_64/ )? Is this advisable?

Is there documentation for best practices for setting up/organizing 
channels? 

Thanks for your advice!
Nicole

Nicole Beck
Information Technology Analyst
Information Technolgy Services – Core Infrustructure Services - Unix
315.506.9744
nskyrca at syr.edu
215 Machinery Hall, Syracuse, NY 13244
syracuse.edu
Syracuse University

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

Persönlich haftende Gesellschafter: Harald Illy, Michael Klaus, Friedrich von Metzler, Emmerich Müller, Gerhard Wiesheu
Vorsitzender des Aufsichtsrates: Dr. Christoph Schücking
Sitz der Gesellschaft: Frankfurt am Main, Handelsregisternummer: HRB 27 515

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfänger sein, so bitten wir Sie höflich, dies unverzüglich dem Absender mitzuteilen und die Nachricht zu löschen. Es ist unzulässig, die Nachricht unbefugt weiterzuleiten oder zu kopieren. Da wir nicht die Echtheit oder Vollständigkeit der in dieser Nachricht enthaltenen Informationen garantieren oder zusichern können, sind die vorstehenden Ausführungen rechtlich nicht bindend. Eine Haftung hierfür wird ausgeschlossen.
This message is confidential. If you are not the intended recipient, we kindly ask you to inform the sender and delete the information. Any unauthorised dissemination or copying hereof is prohibited. As we cannot guarantee or assure the genuineness or completeness of the information contained in this message, the statements set forth above are not legally binding. Accordingly we cannot accept any liability for their contents.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20171204/a0f0cb7c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20171204/a0f0cb7c/attachment.sig>