so here's my sob story... a bit more detail this time..
if I do an up2date -u --nosig everything works fine... sometimes...
the exception seems to be when a new package is available for a package I have installed, but the new package has a new dependency that I have NOT met previously...
Also, I have the problem when I use up2date <packagename> to install a package I do NOT already have, and that package has dependencies that I don't already have...
If I figure out what rpm's I need to meet the dependencies before I do it (I can use up2date to get them if they don't have dependencies of their own) then all is well...
emptying out /var/spool/up2date does me no good either, btw, tho I do it anyway out of habit now...
to clarify further, the only problem I've run into is the issue of up2date bonking at the dependency checking phase... other than that, up2date seems to be working fine, at least for me...
hope that helps!
-jbm sends
p.s. - is there gonna be a channel on RHN for Fedora Core when the general release is done? I blew $500 of my employers money a month ago to buy enterprise entitlements for RH9, and it feels like I've wasted the money if I can't keep them up on the latest release...
I know they want me to buy RHEL, but I just can justify that for mail gateways and dns servers...
maybe they could add a rawhide channel to RHN?
On Wed, 2003-10-29 at 11:16, Josh McKenna wrote:
if I do an up2date -u --nosig everything works fine... sometimes... the exception seems to be when a new package is available for a package I have installed, but the new package has a new dependency that I have NOT met previously...
I think I just described my fix to someone else on the list, but in case you missed it... I keep a local FTP/HTTP mirror of both the base distro (severn3/FC-0.95) and rawhide. Rawhide gets updated via rsync roughly nightly. I use the same cron job as the rsync update to also do a yum-arch to rewrite the yum repo headers. (The yum headers for the base distro obviously only needed to be written once since they don't change.)
My clients use yum to point to both of those sources, "base" and "rawhide". As a result, up2date works perfectly here -- well, at least as far as this issue goes.
p.s. - is there gonna be a channel on RHN for Fedora Core when the general release is done? I blew $500 of my employers money a month ago to buy enterprise entitlements for RH9, and it feels like I've wasted the money if I can't keep them up on the latest release...
I know there are Red Hat employees on this list, but to save their valuable time, and not to assume any kind of mantle, I think the answer to your question is probably a resounding "no." RHN is a paid service and RH is pretty smart to conserve their bandwidth for their paying customers. FC customers will largely be the "freebie" base. There's no reason why their current rawhide support has to stop (i.e. the yum repo[s]), but I would imagine keeping rawhide out of RHN allows them to do some fairly fancy netfilter footwork, to ensure that RHN customers always trump us freeloaders. (No bitterness intended, I fully agree with them if this is the case.)
Remember that your entitlements still get you patch support and enterprise-type management options that you simply don't have with Fedora Core. "Keeping [systems] up on the latest release" is not why you pay for entitlements; they give you support and/or management options you don't have otherwise.
I know they want me to buy RHEL, but I just can justify that for mail gateways and dns servers...
Then Fedora Core, along with the increasing number of yum/apt repositories, might serve you fine. Keep in mind the point of the Fedora Project, and its origins -- over time, it's probably reasonable to think Fedora Core relases could happen even faster than those under the Red Hat Linux banner. A review of the project site at http://fedora.redhat.com might be useful.
Of course, only you can weigh the security repercussions of your decisions on your company's IT infrastructure. If you feel comfortable, given its mission and timetables, with using Fedora Core (or an older EOL Red Hat Linux product) in the capacities you describe, that's your prerogative. Remember that in terms of "free-of-cost" distros, Fedora Core and Red Hat Linux 9 are only two of many alternatives for someone who is a skilled and security-educated administrator.
The entire foregoing is my $0.02 and is subject to your personal rate of exchange. :-)
maybe they could add a rawhide channel to RHN?
See above, best of luck, and cheers.
--- "Paul W. Frields" paul@frields.com wrote:
On Wed, 2003-10-29 at 11:16, Josh McKenna wrote:
p.s. - is there gonna be a channel on RHN for
Fedora Core
when the general release is done? I blew $500 of
my
employers money a month ago to buy enterprise
entitlements
for RH9, and it feels like I've wasted the money
if I can't
keep them up on the latest release...
I know there are Red Hat employees on this list, but to save their valuable time, and not to assume any kind of mantle, I think the answer to your question is probably a resounding "no." RHN is a paid service and RH is pretty smart to conserve their bandwidth for their paying customers.
RHN isn't totally a paid service; up through RH 9 a demo service was allowed (with the "price" being the filling out of surveys every 60 days). Of course, the paying customers got more bandwidth.
If there is are no Fedora plans for a Fedora RHN, then rhn_applet and rhn_register should have not even made it to the first beta, let alone the third.
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
On Wed, 2003-10-29 at 13:47, James J. Ramsey wrote:
p.s. - is there gonna be a channel on RHN for
Fedora Core
when the general release is done? I blew $500 of
my
employers money a month ago to buy enterprise
entitlements
for RH9, and it feels like I've wasted the money
if I can't
keep them up on the latest release...
I know there are Red Hat employees on this list, but to save their valuable time, and not to assume any kind of mantle, I think the answer to your question is probably a resounding "no." RHN is a paid service and RH is pretty smart to conserve their bandwidth for their paying customers.
RHN isn't totally a paid service; up through RH 9 a demo service was allowed (with the "price" being the filling out of surveys every 60 days). Of course, the paying customers got more bandwidth.
If there is are no Fedora plans for a Fedora RHN, then rhn_applet and rhn_register should have not even made it to the first beta, let alone the third.
First let me say that I got just a little muddled there. I actually use a Demo account for some RHL 9 boxes I have, also, and that should have occurred to me as I was writing. Nevertheless, rhn_applet as part of the overall up2date package isn't only useful for RHN enabled boxes. It works fine for clients on a local, isolated network I have at work, where I have to SneakerNet updates to a yum repo I use there; I simply remove the serverURL value and they get instant up2date goodness.
As for rhn_register, since it also is part of the overall up2date package, there's no real reason for it to "go away" in FC just because those folks might not be using it. After all, the FC distro is the basis for RHEL, and it would take an unnecessary effort to remove it especially from FC.
James J. Ramsey said:
If there is are no Fedora plans for a Fedora RHN, then rhn_applet and rhn_register should have not even made it to the first beta, let alone the third.
rhn_applet can (and as shipped it Test 3 does, IIRC) look at yum repositories for updates.
Looking in the archives gives the indication that at least for the first FC release it was planned to have a RHN channel for errata. I don't know if that has changed or not.
On Wed, 2003-10-29 at 14:24, William Hooper wrote:
Looking in the archives gives the indication that at least for the first FC release it was planned to have a RHN channel for errata. I don't know if that has changed or not.
It might be interesting here to note that RHN had channels for FC-0.93 and FC-0.94 (under one name or another), but none for FC-0.95 -- this was obviated by the availability of the HTTP rawhide yum repo. In any case, I would call all this conjecture moot because as long as one can rsync the updates and create the yum headers oneself, there's no point in expecting Red Hat to fill that need. Certainly many other intrepid and charitable folks already have and will continue to do so. Once again, they've given us all the tools we need to take up the banner, so to speak.
--- "Paul W. Frields" paul@frields.com wrote:
On Wed, 2003-10-29 at 14:24, William Hooper wrote:
Looking in the archives gives the indication that
at least for the first
FC release it was planned to have a RHN channel
for errata. I don't know
if that has changed or not.
It might be interesting here to note that RHN had channels for FC-0.93 and FC-0.94 (under one name or another), but none for FC-0.95 -- this was obviated by the availability of the HTTP rawhide yum repo.
Rawhide is good for updating betas, but terrible as a repository for stable updates. I hope there is at least some way of getting ordinary straight-up security updates, whether via RHN or a YUM channel.
What I wonder is how come the blue checkmark in the RHN applet never turns red when updates are available?
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
On Wed, 2003-10-29 at 16:32, James J. Ramsey wrote:
Rawhide is good for updating betas, but terrible as a repository for stable updates. I hope there is at least some way of getting ordinary straight-up security updates, whether via RHN or a YUM channel.
Like I mentioned, you should expect the fedora.us site and many others to carry this sort of thing, probably Red Hat too for that matter. It may not be part of RHN though; just a yum repository (and/or apt).
What I wonder is how come the blue checkmark in the RHN applet never turns red when updates are available?
Must be a local configuration problem on your end; mine works fine on my net-connected testing box. Have you checked your /etc/sysconfig/rhn/sources? Check the archive for hints if necessary. Cheers,
--- "Paul W. Frields" paul@frields.com wrote:
On Wed, 2003-10-29 at 16:32, James J. Ramsey wrote:
What I wonder is how come the blue checkmark in
the
RHN applet never turns red when updates are
available?
Must be a local configuration problem on your end; mine works fine on my net-connected testing box. Have you checked your /etc/sysconfig/rhn/sources? Check the archive for hints if necessary.
FWIW, there's only one line in /etc/sysconfig/rhn/sources that isn't a comment:
yum rawhide http://ftp.redhat.com/pub/redhat/linux/rawhide/
(That's all on one line.)
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
On Wed, 2003-10-29 at 18:08, James J. Ramsey wrote:
What I wonder is how come the blue checkmark in
the
RHN applet never turns red when updates are
available?
Must be a local configuration problem on your end; mine works fine on my net-connected testing box. Have you checked your /etc/sysconfig/rhn/sources? Check the archive for hints if necessary.
FWIW, there's only one line in /etc/sysconfig/rhn/sources that isn't a comment:
yum rawhide http://ftp.redhat.com/pub/redhat/linux/rawhide/
Same as mine. There is a designated check-in interval in /etc/sysconfig/rhn/rhnsd, usually 240 (minutes)... mine was working this morning per usual. Perhaps someone else has some ideas. I would take this to fedora-list instead as it doesn't seem to be bug related. Good luck and cheers.
On Thu, Oct 30, 2003 at 10:08:32AM -0500, Paul W. Frields wrote:
On Wed, 2003-10-29 at 18:08, James J. Ramsey wrote:
What I wonder is how come the blue checkmark in
the
RHN applet never turns red when updates are
available?
Must be a local configuration problem on your end; mine works fine on my net-connected testing box. Have you checked your /etc/sysconfig/rhn/sources? Check the archive for hints if necessary.
FWIW, there's only one line in /etc/sysconfig/rhn/sources that isn't a comment:
yum rawhide http://ftp.redhat.com/pub/redhat/linux/rawhide/
Same as mine. There is a designated check-in interval in /etc/sysconfig/rhn/rhnsd, usually 240 (minutes)... mine was working this morning per usual. Perhaps someone else has some ideas. I would take this to fedora-list instead as it doesn't seem to be bug related. Good luck and cheers.
Well I have seen this behaviour too, I need to investigate it because sometimes it just work as it should and other time the check seems to miss some updates. I need to debug this, I think this was already reported on bugzilla.
Daniel
--- "Paul W. Frields" paul@frields.com wrote:
On Wed, 2003-10-29 at 18:08, James J. Ramsey wrote: Same as mine. There is a designated check-in interval in /etc/sysconfig/rhn/rhnsd, usually 240 (minutes)... mine was working this morning per usual.
My RHN applet is working now. Go figure.
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
I used up2date yesterday and it had to update about 20 packages.
During it installation of kernel-source up2date died because it could not install the package. The problem now is, that all packages that where to be installed after kernel-source are de-installed!
Now, on my system openoffice and, of course, kernel-source are missing! There were another 10 packages that might not be there, but unfortunately I updated in a console window so there is no scrollback buffer available to find out what other packages are missing.
I can live with this happening during the test-phase of fedora, but I think this is a showstopper for production!
Michael
I've entered a bug in bugzilla. ID is 108691
michael-ring@t-online.de (Michael Ring) writes:
Now, on my system openoffice and, of course, kernel-source are missing! There were another 10 packages that might not be there, but unfortunately I updated in a console window so there is no scrollback buffer available to find out what other packages are missing.
Just a side note: You can look at /var/log/rpmpkgs Or one of its rotated logs to see what was installed before.
On Fri, Oct 31, 2003 at 09:22:50AM +0100, Michael Ring wrote:
I used up2date yesterday and it had to update about 20 packages.
During it installation of kernel-source up2date died because it could not install the package. The problem now is, that all packages that where to be installed after kernel-source are de-installed!
Now, on my system openoffice and, of course, kernel-source are missing! There were another 10 packages that might not be there, but unfortunately I updated in a console window so there is no scrollback buffer available to find out what other packages are missing.
/var/log/rpmpkgs* tell you what packages you used to have installed.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Fri, 2003-10-31 at 03:22, Michael Ring wrote:
I used up2date yesterday and it had to update about 20 packages. During it installation of kernel-source up2date died because it could not install the package. The problem now is, that all packages that where to be installed after kernel-source are de-installed!
[...snip...]
I've entered a bug in bugzilla. ID is 108691
This looks closely related to my bug #108652, rather than the one it was marked as duplicating in bugzilla. I added a comment in the hopes that someone will see that this (and many of the other up2date problems that keep reappearing on the list) could be taken care of by simply adding an extra modicum of sanity checking during the process.
On Fri, 31 Oct 2003, Paul W. Frields wrote:
On Fri, 2003-10-31 at 03:22, Michael Ring wrote:
I used up2date yesterday and it had to update about 20 packages. During it installation of kernel-source up2date died because it could not install the package. The problem now is, that all packages that where to be installed after kernel-source are de-installed!
[...snip...]
I've entered a bug in bugzilla. ID is 108691
This looks closely related to my bug #108652, rather than the one it was marked as duplicating in bugzilla. I added a comment in the hopes that someone will see that this (and many of the other up2date problems that keep reappearing on the list) could be taken care of by simply adding an extra modicum of sanity checking during the process.
Looks like all these issues are due to the mirrors (including ftp.redhat.com) not having a consistant yum repository (i.e headers/header.info not in sysc with the *.rpm files available on the mirror .)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107972
The correct fix - I think, is to change the process with which ftp.redhat.com is updated.
I suspect there is a local machine where rawhide rpms are updated - and header.info is re-generated for. But somehow header.info is rsynced to ftp.redhat.com - but not all the rpm packages. (perhaps i386/header packages are rsynced every 3 hours - but not the s390x - which get rsynced once every day?) - thus resulting in inconistancy on the ftp site.
This inconsistancy gets propagated to all mirrors.
Satish
On Fri, 2003-10-31 at 11:54, Satish Balay wrote:
I used up2date yesterday and it had to update about 20 packages. During it installation of kernel-source up2date died because it could not install the package. The problem now is, that all packages that where to be installed after kernel-source are de-installed!
[...snip...]
I've entered a bug in bugzilla. ID is 108691
This looks closely related to my bug #108652, rather than the one it was marked as duplicating in bugzilla. I added a comment in the hopes that someone will see that this (and many of the other up2date problems that keep reappearing on the list) could be taken care of by simply adding an extra modicum of sanity checking during the process.
Looks like all these issues are due to the mirrors (including ftp.redhat.com) not having a consistant yum repository (i.e headers/header.info not in sysc with the *.rpm files available on the mirror .)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107972
The correct fix - I think, is to change the process with which ftp.redhat.com is updated.
While I completely agree that the proximate cause is on the server side, this doesn't help the casual user who suddenly ends up with a broken box, where packages are suddenly missing and the dependency tree is now broken. Fixing the client to use a little bit of common sense to avoid disaster is also a good idea, especially since it involves a minimum of fuss.
--- "Paul W. Frields" paul@frields.com wrote:
The correct fix - I think, is to change the
process with which
ftp.redhat.com is updated.
While I completely agree that the proximate cause is on the server side, this doesn't help the casual user who suddenly ends up with a broken box, where packages are suddenly missing and the dependency tree is now broken. Fixing the client to use a little bit of common sense to avoid disaster is also a good idea, especially since it involves a minimum of fuss.
I agree. up2date needs to do enough sanity checking so that if it gets bogus RPMS, headers, etc., it can do something intelligent like tell the user that something is wrong at the server end--so that they can complain to Red Hat sooner. :) Having up2date mysteriously hang and/or spew inscrutable tracebacks (that only appear if one launches up2date from a terminal) just makes problems harder to resolve.
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/