[rhn-users] Various RHN config options

[inode0]

On 6/19/07, jef e <jef_umd at umd.umich.edu> wrote:
> inode0 wrote:
>
> > As far as I know they have no "pushing" capabilities. In addition to
> > what you get with RHN hosted a proxy server does support custom
> > channels for making non-RHEL packages available to your users via
> > up2date/yum and managing those packages within the RHN framework. This
> > has worked well for us until recently.
>
> We have very few packages that we build ourselves in our current Debian
> environment, but making our own repository has been helpful. Knowing
> that we could do the same with the proxy is good to know.
>
> I've not had to do this yet, but does the basic Hosted RHN let you push
> out updates to systems, or at least schedule automatic updating of them?
> (Rather than logging in to each one and doing 'up2date -u'?)

Yes you can schedule updates from the RHN hosted interface. Whether
they will get picked up or not is another story. We honestly have not
had very good luck with things scheduled via RHN actually working as
one would expect, however I can't help but think our experience is
unusual. If everyone had the problems we've had I can't really imagine
anyone would use the scheduling features at all.

If our users want errata applied automatically I now tell them to run
up2date -u from cron once a day since that seems to be the only
reliable option we have at the moment.

This is not a push, and I think the design choice here is a good one.
You schedule the action and then it sits queued on RHN until the
machine checks in and picks it up. This allows more flexible network
and firewall setups to work without making special arrangements.

> > Normal management of machines and users is still all done via RHN at Red
> > Hat.
>
> Thats what I figured, despite sales person saying the opposite. :-)
>
>
> > One other often missed feature of a proxy server at an edu is the
> > included site subscription which to me is worth more than anything
> > else, but this must be weighed against your needs and inclination to
> > support systems not owned by your university. Some perhaps aren't even
> > allowed to do this by local regulations.
>
> We don't wish to get into the Redhat support game at the moment (we are
> stretched pretty thin as it is), so the site license is definitely not
> on our radar. :)

Well, support was a bad word. More like be ok with your users using
your proxy with their personal equipment as you would see fit to
allow.

> For us, even the Department license is overkill at 500 subscriptions --
> however, it does include a proxy server. If we take into account the
> cost of the number of individual subs. that we need plus the cost of
> adding a proxy server, the Department license isn't that much more
> expensive, even if we do have 'wasted' subscriptions. (Thus my questions
> about the proxy's usefulness - just trying to get a feel for what we
> might get out of it that isn't really mentioned in RH's literature and
> such.)

The site subscription with a proxy (and I have no idea if the same is
true in your arrangement) does not cover university equipment.

I will say emphatically that our users are very happy with the proxy
server's performance over the past years. The speed difference during
large updates is very obvious. We also use it for network installs and
users really like that (although that could of course be done
elsewhere too).

John