Red Hat Network Chat Log

March 21, 2002


15.04.23 <moderator> Ok, let's give this another try -- welcome to the Red Hat Network Q&A session

15.04.59 <moderator> We're going to have the RHN team field your questions regarding the Red Hat Network service

15.05.23 <moderator> To start, I'd like the RHN folks to introduce themselves -- gdk?

15.05.37 <gdk> Hi, I'm Greg DeKoenigsberg, and I'm the web engineering manager for RHN.

15.05.55 <moderator> Chip?

15.06.21 <chip> Hullo, I'm Chip Turner, and I'm a Web Engineer on RHN.

15.07.03 <moderator> Any other RHN people out there that don't want to lurk? :-)

15.07.22 <gdk> Let 'em lurk. ;-)

15.07.56 <moderator> Ok, let's get started. If you have a question about RHN (and not about how you can't install X or whatever) msg moderator, and we'll get started...

15.09.15 <moderator> <misato> asks: does rhn have a capability for 3rd party sets of applications that are distributable? and how would it be done?

15.09.35 <gdk> Sure do.

15.10.09 <gdk> RHN can enable third parties to build their own channels to distribute previate packages within their own organization.

15.10.49 <gdk> We're also working on a mechanism to allow third parties to work with us to distribute their own packages publically as well.

15.11.50 <gdk> Distribution of packages within a private organization is associated with the RHN Proxy Server product.

15.12.03 <gdk> You can read more about that at redhat.com, somewhere there's a whitepaper, heh. Next Q?

15.12.15 <moderator> rizen asks: What is this "Red Hat Network"?

15.12.53 <gdk> To start with, RHN is a service that allows you to register your systems with us and keep them updated with the latest packages.

15.13.39 <gdk> But it's also an expanding infrastructure that will allow you to subscribe to ISV software channels, sign up for monitoring services, and more.

15.13.49 <gdk> Take a look at rhn.redhat.com.

15.14.04 <gdk> Subscription is free for one Red Hat system. Next Q?

15.14.27 <moderator> odysseus asks: what counter messures do you have in place in the event of a "break-in", i.e. like the apache.org attack that could have come to apache packages being released with backdoors built in.. isnt auto updates going to open up problems like this?

15.14.55 <gdk> Chip?

15.16.05 <chip> That's a very valid question. RHN offers two main layers of security to protect subscribed systems. The first is tight checking of SSL certificates. The up2date client will not talk to a server that does not have a certificate issued by Red Hat. This helps ensure you're talking to OUR servers, and not subject to a man in the middle attack. (more)

15.17.28 <chip> However, as you suggest, that doesn't help if our servers are compromised. Every package served by RHN is signed with an official GPG key (the same key that signs packages on the FTP site). This key is not in our colocation facility -- it exists in our main offices, and only three people in the company have access to it. So, even if our servers were compromised, since the up2date client validates GPG keys, it would refuse to install any package

15.17.28 <chip> that was not properly signed. (more)

15.18.21 <chip> For third party questions as discussed earlier, you would sign the packages with your own key, and tell the up2date clients on your servers to accept that key in addition to ours. No package is installed without a valid signature. (done)

15.18.26 <moderator> sarnold_ asks: (is RHN) basically an attempt to model debian's apt ?

15.19.08 * gdk smiles.

15.19.55 <chip> Apt is a useful tool for debian systems, but it serves a slightly different purpose than RHN. There is some common functionality, though. For instance, you can say "up2date gnumeric" and RHN will download the latest gnumeric, solve dependencies, and install the package, much like apt-get will do. (more)

15.20.41 <chip> For individual users and admins, say, 10 or fewer systems, logging into each box and using apt is an effective solution.

15.21.22 <moderator> Jag|Work asks: Now I just want to know about how selective I can be in updating packages. And do these channels require the client to subscribe to them or can I select groups of clients to be channel members right from the server?

15.21.30 <chip> But if you have 100, or even 1,000 systems, you need something else. This is where RHN, and the RHN website in particular, come in. Through the website you can see exactly what updates which servers need, and apply them at will. (done)

15.21.59 * moderator apologies for stomping on Chip's toes... :-)

15.22.22 * chip apologies to Mr Moderator for not indicating he wasn't done :)

15.23.01 <gdk> You can be as selective as you'd like to be in updating packages...

15.23.17 <gdk> ...both from the client side, selecting the packages to be updated in the up2date client...

15.23.41 <gdk> ...or on the web side, bringing up the server and indicating none, one, several, or all outdated packages to be updated.

15.24.21 <gdk> As far as channels go, you are perfectly free to subscribe or unsubscribe from channels for each system directly from the web interface.

15.24.31 <gdk> Next Q?

15.24.36 <moderator> opcenter_ asks: How does RHN compare to Ximian's RedCarpet service?

15.25.50 <gdk> It's a similar offering in many ways, but there are some notables differences...

15.26.09 <gdk> ...one being that we have a highly scalable centralized management interface...

15.26.47 <gdk> ...another being that since we are based on the distro, we have a better view on the full dependency pciture for a system or a set of systems...

15.27.30 <gdk> ...and we're going to moving beyond simple package updates quickly in the near future.

15.27.36 <gdk> Next Q?

15.27.49 <moderator> Speare asks: I'm wondering, as many folks have mentioned, what plans there may be for optional Red Hat channels to cover Rawhide, Gnomehide, Xhide, Betas, and other auxilliary packages? If so, what's the timescale, ballpark?

15.28.00 * gdk hrms.

15.28.12 <gdk> This is an obvious use of RHN, as everyone who uses it knows.

15.28.41 * chip hrms too.

15.28.56 <gdk> I feel comfortable telling you that we use these sorts of channels extensively inside Red Hat, but there are certain caveats to releasing some of these things outside of the castle walls, so to speak.

15.29.39 <gdk> Let me just say that we're working on ways to make both beta channels and 3rd party channels more consumable in the near future. Again, it's so obviously important that we'd have to be insane not to be working on it. :-)

15.29.47 <gdk> Next Q?

15.30.17 <moderator> lemonade asks: so the up2date client is like updater for windows, the client upload what program has been installed on the system and the server retrive it? so basicaly the server will know what all the program we've installed in our server, and how about our privacy?

15.32.32 <chip> Privacy is very important to us. When you register a system, one of the questions it asks is if you want to send package listings up -- it's completely optional. We have a comprehensive privacy policy governing this, available at https://rhn.redhat.com/help/security.pxt for more details. Obviously the central management features become somewhat limited if you don't send the package manifest up, but the up2date client program itself works just fine. (more)

15.33.10 <chip> Windows' update functions basically by downloading data from the central server; up2date does the same for its main functionality. (more)

15.33.43 <chip> For corporations concerned about privacy, we offer the RHN Satellite (aka RHN-in-a-box) that can operate without any connection to our servers whatsoever, but that's a different topic :) (done)

15.33.53 <moderator> odysseus asks: I know it says on the rhn site that security patchs will be released asap.. do you have a team monitoring bugtraq etc.. 24/7?

15.34.37 <gdk> Yes. :-)

15.34.40 <gdk> ALso...

15.35.10 <gdk> ...we're proactive in hunting down issues as well; the recent zlib vulnerability was discovered by Owen Taylor of RH. Next Q?

15.35.19 <moderator> bewmIES asks: WRT key signing, why not have them generate a signging key which you sign with your RHN key and just build a web of trust (instead of having the end-user import all these keys)?

15.37.09 <chip> We've considered this issue. In practice, it is very hard to build up a comprehensive public key infrastructure. Right now, we rely on the end user explicitly specifying which keys he wants used. In the future we may explore other alternatives, but we want to move slowly when it comes to issues of such magnitude, and not risk our users' systems. (done)

15.37.16 <moderator> ananke asks: what kind of information does rhn store about our systems, more precisely, does it store the machine's ip? what i'm concerned about is the security of our systems, in case if they haven't been updated in awhile, yet they were registered with rhn. if rhn's database would contain any information that would allow attackers get the list of packages installed on our systems, it would be quite dangerous.

15.40.00 <chip> You're correct, the same data used to alert customers that they have security issues is the same data a hostile attacker could use to acquire targets. It is an option you choose to allow or disallow when you register, though. You can choose to send neither packages, hardware information, nor network information when you run rhn_register. You can also delete your registered profiles at any time (and once deleted, the data is gone from our tables

15.40.00 <chip> completely). (more)

15.40.58 <chip> Also, yes, we do store IP information when you register, if you do not tell rhn_register to withold it, but it is for reporting purposes only. (done)

15.41.08 <moderator> hunter asks: How soon will we be able to subscribe/unsubscribe using just the client, without using the website?

15.42.32 <gdk> For now, we're trusting a sensible UI on the website to manage subscription issues.

15.42.41 <gdk> Next Q?

15.42.43 <moderator> wal asks: will rhn be expanded in the near future to cover RPM based distros, or even any other linux based distro?

15.42.56 * gdk smiles knowingly.

15.43.45 <gdk> That's one of those questions that is best answered by stating the capabilities of RHN itself:

15.44.11 <gdk> It is designed to handle any RPM-based distribution. And I'll leave it at that. Next Q?

15.44.18 <moderator> Orasis asks: Hello, I am Justin Chapweske of Onion Networks, and the inventor of Swarmcast. When might we see peer-to-peer content distribution capabilities added to the Redhat Network? Is Redhat interested in collaborating on building a peer-to-peer CDN for open source and public domain content?

15.45.51 <gdk> Sure, we discuss it all the time, but it's not in the short-term roadmap.

15.46.10 <gdk> For now, we need to concentrate on doing what we do well, which is centralized maintenance.

15.46.19 <gdk> Next Q?

15.46.20 <moderator> Speare asks: Some people get anxious when the RHN is described with languages like "register your systems with us." I understand the architecture, but newcomers don't. How can we address the concerns that up2date sounds like "spyware" at first blush, making newcomers more comfortable with the value of having a push-style updating scheme?

15.46.42 <gdk> That's a good question.

15.47.11 <gdk> To be honest, though, a lot of customers have a pressing need for this kind of solution, and one of the good things about being Red Hat is that we have a certain credibility.

15.48.24 <gdk> There are a lot of customers who are willing to trust is with what is, clearly, quite sensitive data -- and for enterprises who simply can't afford to trust their info to a third party, we do have a solution called the Satellite Server that replicates the full function of RHN inside a local network. But that

15.48.28 <gdk> (oops)

15.48.35 <gdk> that's definitely an enterprise-class solution.

15.48.41 <gdk> Next Q?

15.48.47 <moderator> zaph asks: going back to selection, will it be possible to select just one (or a few) updates to apply to a range of machines at once?

15.49.01 <gdk> It's already possible with the RHN Workgroup service.

15.49.33 <gdk> You can apply one or more packages or errata to one or more systems or groups of systems.

15.50.02 <gdk> Take a look at https://rhn.redhat.com/feature_comparison.pxt for more info. Next Q?

15.50.05 <moderator> Edgan asks: How redudant/fail-over/load-balancing is rhn? Any single points of failure like the database?

15.52.05 <chip> Every server involved in providing RHN service has at least one on-site failover (sometimes more than one). We also use this in times of high activity to load balance across systems. We also have offsite redudancy in case of disaster. (done)

15.52.41 <moderator> opcenter_ asks: Does a customer actually have to purchase a RedHat distro to register on RHN and use the service or is it available for those who just download the ISO's or install over the internet (without purchasing anything)?

15.53.47 <gdk> Creating an account with RHN is free. Registering one system and receiving updates for 6.2 and 7.x is free as well...

15.55.06 <gdk> Purchasing RHN subscriptions is required to keep more than one system updated. Purchased entitlements also give priority service during times of high load...

15.55.31 <gdk> ...and the ability to download ISOs directly from RHN. We expect this feature to be popular around release time. :-)

15.55.42 <gdk> Again, take a look at https://rhn.redhat.com/feature_comparison.pxt for more info. Next Q?

15.55.45 <moderator> KP asks: Will there ever be a web tool to delete RHN accounts? Currently we have to call Customer support, and that is not a quick/easy task...

15.57.25 <gdk> Interaction with customer support is a necessary step to make sure that your account is properly closed and any refunds due you are handled properly. Next Q?

15.57.32 <moderator> ananke asks: what about localized up2date servers? is there a way to have one central server download all the updates, and the rest of the machines on the local network use this particular machine to fetch the packages? it would cut down on the total bandwith used for the given organization.

15.58.26 <gdk> That's called the RHN Proxy Server, and we're working on finalizing and making that product available.

15.58.36 <gdk> Next Q?

15.58.52 <moderator> odysseus asks: ive not had much time to really look into rhn, but Im guessing the clients/server deamons etc.. for this will all be opensource?

16.00.08 <gdk> The client is fully open source, but we don't open source the servers.

16.00.41 <gdk> Just like we don't open source the internal build system or any of the tools that allow us to provide services.

16.00.47 <gdk> Next Q?

16.01.00 <moderator> graf25 asks: I had one computer running up2date on a free rhn account, but when I reinstalled the system, I could no longer use it. Does this mean that "one system free" is really "one installation free"? 16.01.54 <gdk> Nah. What happened is that the system received a new systemid when you registered it, and RHN was still trying to update the old one...

16.02.22 <gdk> ...just go to the web site, remove the old profile, and entitle the new one to service.

16.03.02 <moderator> Ok, I see we're past our 16:00 end time. Thanks to everyone for coming and asking some really good questions!



'Ask The Experts' Interviews

Greg DeKoenigsberg
Red Hat Network Questions Answered