Re: [CentOS] how to move forward/undo/revert/fix re: a failed CentOS 5.5 to SL 5.5 migration ... [SOLVED?]
On Wed, Jan 26, 2011 at 11:25 AM, Larry Vaden vaden@texoma.net wrote:
For various reasons which seemingly fail the necessary/sufficient tests with the benefit of hindsight, I attempted to migrate a shell machine which is the beach front from which I work (not a production server) from CentOS 5.5 to Scientific Linux 5.5 yesterday.
Karanbir is quoted on this list as having said something like:
"All that you should need to do is install centos-release, remove redhat-release rpms and just yum update the machine, which should bring in all packages changed by CentOS ( since they will have a slightly higher E-V-R )."
In other words, is there a get out of jail card based on Karanbir's stanza which will return the machine to a consistent state without a fresh install?
With apologies for replying to my own post, the final solution (possibly regarded as draconian and puerile by others) which seemed to work to return to a consistent state was to download Oracle R5U6 and invoke 'rpm -ivh' following some rpm which must be set aside in order to avoid "can not coexist." (e.g., bind vs. bind97 et al).
My thoughts are that it would work as well once CentOS and Scientific Linux R5U6 are released.
It was necessary to pay special attention to the output of
updatedb; locate .rpm | egrep ".rpmnew$|.rpmorig$|.rpmsave$"
No data was lost, but I watch some Dennis Miller, and like him at the end of a rant, "I could be wrong about that" :)
kind regards/ldv
Larry Vaden wrote on 01/30/2011 08:41 PM: ...
With apologies for replying to my own post, the final solution (possibly regarded as draconian and puerile by others) which seemed to work to return to a consistent state was to download Oracle R5U6 and invoke 'rpm -ivh' following some rpm which must be set aside in order to avoid "can not coexist." (e.g., bind vs. bind97 et al).
So, out of morbid curiosity, and because it seems to have been my post on the SL list you quoted that helped get you into this state, was anything other than the replacement process actually broken?
It is completely unsurprising that the kernel RPMS failed to install over the like versions, but I would have expected things to work with the CentOS kernels on the SL/CentOS mixed system. The replacement process was only suggested as something for those really paranoid about not having all the packages from the same distro to try, and I certainly would not have endorsed throwing Oracle into the mix. For the record, if I really wanted to replace the kernels, my process would have been something like:
1. Boot from an older <OldOS> kernel. 2. Remove the newer <OldOS> kernel[s]. 3. Install the latest <NewOS> kernel with yum. 4. Reboot to the <NewOS> kernel. 5. Remove the remaining <OldOS> kernel, or perhaps better leave for a fallback.
By the way, my initial post in the SL thread started: "The procedure (untested by me) should be similar to the procedure on the CentOS Wiki for migration from RHEL to CentOS...".
Caveat Emptor! :-)
Will be interesting to see how you fare with your three-way hybrid when CentOS 5.6 hits the mirrors.
Good luck, Phil
On Tue, Feb 1, 2011 at 1:26 PM, Phil Schaffner Philip.R.Schaffner@nasa.gov wrote:
So, out of morbid curiosity, and because it seems to have been my post on the SL list you quoted that helped get you into this state, was anything other than the replacement process actually broken?
Actually, it was Karanbir's statement that led me to believe it would be possible to have a real choice ...
As far as answering your question, other than BIND, the truth is "I don't know."
I certainly would not have endorsed throwing Oracle into the mix.
There's an old saying that goes like "make chicken salad with the chickens you've got."
Will be interesting to see how you fare with your three-way hybrid when CentOS 5.6 hits the mirrors.
Feel free to pen a stanza which I will run on the system to determine the actual DNA head count and thus whether it is a hybrid ...
At the risk of irritating folks further with the great-grandmother of the situation, RH and downstreams need to get serious about BIND, et al.
e.g. (and not the best one by far, just the one that led me down the path (yikes, www.yahoo is here in rural north Texas on a leaf node)),
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/5.6_Technical_Notes/index.html#bind says, in part:
"* The host/dig/nslookup utilities queried only servers from resolv.conf. With this update, the utilities query the servers specified on command line instead of in resolv.conf and the issue is resolved. ( BZ#561299)"
AFAIK, that's the status of the clones at this time. Still unexplained is why
'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers.
kind regards/ldv
Larry Vaden ha scritto:
AFAIK, that's the status of the clones at this time. Still unexplained is why
'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers.
For what I know OpenDNS (208.67.222.222, 208.67.220.220) does some more "caching" and puts on play some more distribution algorithms on it's own, that's why it doesn't give the same answers that other dns do. I remember there where issues also about www.google.com not giving the "official" google server but their own cache.
Regards Lorenzo
On Wed, Feb 2, 2011 at 3:04 AM, Lorenzo Quatrini lorenzo.quatrini@gmail.com wrote:
Larry Vaden ha scritto:
AFAIK, that's the status of the clones at this time. Still unexplained is why
'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers.
For what I know OpenDNS (208.67.222.222, 208.67.220.220) does some more "caching" and puts on play some more distribution algorithms on it's own, that's why it doesn't give the same answers that other dns do. I remember there where issues also about www.google.com not giving the "official" google server but their own cache.
That doesn't explain the observed behavior of dig/host/nslookup. Nor does IMHO the official release notes, which are quoted again for focus:
"* The host/dig/nslookup utilities queried only servers from resolv.conf. With this update, the utilities query the servers specified on command line instead of in resolv.conf and the issue is resolved. ( BZ#561299)"
The official release notes imply that the argument on the command line was ignored and the contents of /etc/resolv.conf were used instead which should lead to consistent results between the two invocations.
That wouldn't cause the observed behavior; the practice of backporting may be at play here. I'll check with the author's release notes for when/if this has ever been a "feature" in the stock isc.org code as well as BZ and report back to the list.
On Wednesday, February 02, 2011 09:31:43 am Larry Vaden wrote:
"* The host/dig/nslookup utilities queried only servers from resolv.conf. With this update, the utilities query the servers specified on command line instead of in resolv.conf and the issue is resolved. ( BZ#561299)"
The official release notes imply that the argument on the command line was ignored and the contents of /etc/resolv.conf were used instead which should lead to consistent results between the two invocations.
I think the release notes do not reflect the actual bug, in this case. The bug text is:
"I have noticed that release 5.4 (Final) appears to ignore the server option when using host or nslookup if the host in question is not available.
The commands should return no server available as they have in the past but instead decide to query the servers specified in resolv.conf and return results from that."
As both of the servers you gave in the message provided results, the queries given do not trigger the actual bug; that is, if the server referenced is not available or does not return a result, *then* it went to the servers in resolv.conf rather than the previous behavior.
Fault lies in the writer of the release note bullet point, which does not accurately describe the bug actually fixed.
And that explains why 'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers, as I know OpenDNS does fairly aggressive caching that semi-ignores $TTL, and google (8.8.8.8 is a google DNS server) probably does too.
On Wed, Feb 2, 2011 at 1:41 PM, Lamar Owen lowen@pari.edu wrote:
On Wednesday, February 02, 2011 09:31:43 am Larry Vaden wrote:
"* The host/dig/nslookup utilities queried only servers from resolv.conf. With this update, the utilities query the servers specified on command line instead of in resolv.conf and the issue is resolved. ( BZ#561299)"
The official release notes imply that the argument on the command line was ignored and the contents of /etc/resolv.conf were used instead which should lead to consistent results between the two invocations.
Genau.
I think the release notes do not reflect the actual bug, in this case. The bug text is:
"I have noticed that release 5.4 (Final) appears to ignore the server option when using host or nslookup if the host in question is not available.
The commands should return no server available as they have in the past but instead decide to query the servers specified in resolv.conf and return results from that."
As both of the servers you gave in the message provided results, the queries given do not trigger the actual bug; that is, if the server referenced is not available or does not return a result, *then* it went to the servers in resolv.conf rather than the previous behavior.
Fault lies in the writer of the release note bullet point, which does not accurately describe the bug actually fixed.
And that explains why 'host www.yahoo.com 208.67.220.220' and 'host www.yahoo.com 8.8.8.8' got completely different answers, as I know OpenDNS does fairly aggressive caching that semi-ignores $TTL, and google (8.8.8.8 is a google DNS server) probably does too.
I think your analysis is spot on.
kind regards/ldv
-
Lamar Owen -
Larry Vaden -
Lorenzo Quatrini -
Phil Schaffner