Re: Channel configuration questions (newbie)

Jonathan -

        Responses inlined, hopefully they'll be useful.

On Sat, 01 Feb 2003, Jonathan S. Shapiro wrote:

> I've been rolling my own update process for our lab for some time. I'm
> looking at switching to Current, and I have a couple of (hopefully
> simple) naive questions:
> 
> 0. We mirror updates from RedHat regularly, and I plan to continue that
> practice. It is not clear (to me) from the installation instructions
> whether we need to rebuild some sort of server-side RPM database after
> adding newly available updates. (nrh-update looks like it does) Do we?
        You will need to issue an "update" type command to the Current
server so it known about the new RPM's; in the 1.4.x series, you
currently have to shut down the Apache server to do so.  This will
change in the 1.5.x series.

> 1. In Brian's Article, he mentioned that there is no need to maintain
> distinct "channels" for different architectures. Is this accurate?
        Each channel represents a single distinct arch/release
combination.  For example, if you want to use Current to distribute the
7.3 release for an x86 (i386) and for a sparc (Red Hat does not support
sparc, but work with me for a moment), you would need to set up two
channels.  However, if you only have i386, i586, and i686 machines, you
only need the i386 channel, as the client can determine the best
compatible arch for a given machine.

> I understand that the i386 packages will run on later architectures just
> fine, but getting the kernel and lib RPMs right really does help. If all
> of the RPMs land in one channel (i.e. one set of directories), is the
> up2date client smart enough to sort them out? (Pardon ignorance here --
> I don't subscribe under up2date, so I never looked at how channels are
> specified in the UI).
        As above, yes, the client is able to sort out the differences
between i386, i586, i686, and other compatible arches.

> 2. We have one or two machines with oddball hardware (e.g. Toshiba
> Tablet PC) where support hasn't made it into the "official" kernels and
> we have build locally enhanced RPMs. We could do locally enhanced
> package upgrades a la "red carpet", but in a (probably vain) effort to
> minimize divergence from the "standard" packages, I've gotten into the
> habit of installing those only on machines where they are really needed.
> Is there a way to distinguish between clients and choose channels based
> on the previously recorded machine info, or should I create a new
> pseudo-channel specifically for those machines?
        At the present time, there is no support for channel parenting
in the server, which would be one way of addressing this issue.  I'm
not sure right off-hand about simply creating multiple channels and
subscribing different machines to them; this is another way of solving
this issue, but I'm going to have to ask Hunter to weigh in on the
possibilities of setting this up with the present release(s) of Current.

> 3. If I go the pseudo-channel route, the obvious thing to do would be to
> try configuring the directories such that the Toshiba config would look
> like:
> 
> 	...
> 	rpm_dirs = /somewhere/redhat-8.0/Toshiba-RPMS
> 		/somewhere/redhat-8.0/rh8.0-updates
> 		/somewhere/redhat-8.0/rh8.0-baseline-rpms
> 
> while the "normal" machines would just use:
> 
> 	...
> 	rpm_dirs = /somewhere/redhat-8.0/rh8.0-updates
> 		/somewhere/redhat-8.0/rh8.0-baseline-rpms
> 
> The idea here would be to override the rh8.0-updates directory by
> putting replacements in the Toshiba-specific directory. Is there a
> defined search order rule that determines which directory "wins" if two
> RPMs in different directories have the same version number, or should I
> resolve this by making "red carpet" style intermediate versions (I know
> how to do this if need be).
        This is definitely the channel parenting idea you're talking
about, which we're not yet able to support.  Channel parenting will
likely come about in the 1.7 devel series; again, Hunter will be able to
give more information on the actual roadmap plan.

> Current looks like very nice work, by the way!
        Thanks for the vote of confidence.  :)

-- 
Thank you,
John Berninger

Systems Administrator		[email protected]
Department of Mathematics	Box 8205, Harrelson Hall
NC State University		Raleigh, NC 27695
Phone:  (919)515-6315		Fax:	(919)515-3798

GPG Key ID: A8C1D45C
        Fingerprint: B1BB 90CB 5314 3113 CF22  66AE 822D 42A8 A8C1 D45C
--