[3554] in SIPB_Linux_Development
Re: ypbind lossage
daemon@ATHENA.MIT.EDU (Angie Kelic)
Sat Sep 29 15:35:06 2001
Message-Id: <200109291934.PAA22622@quickstation-zocalo.mit.edu>
To: John Hawkinson <jhawk@MIT.EDU>
cc: linux-dev@MIT.EDU, sipb-office@MIT.EDU
In-reply-to: Your message of "Sat, 29 Sep 2001 14:19:16 EDT."
<200109291819.OAA14242@coleco-sidewinder.mit.edu>
Date: Sat, 29 Sep 2001 15:34:55 -0400
From: Angie Kelic <sly@MIT.EDU>
This is cc'd to sipb-office for users that call reporting an
inability to update the sipb linux installer to 9.0 because
rpms like ypbind generate a conflict. If you are reading
this on sipb-office please read between the parts marked OFFICE,
you'll be happier that way ...
I discovered this problem -- if it is the one that I think you
are referring to. This problem happens because the sipb installer
generated rpm file does not contain epoch numbers.
I think you are severely lacking in your description below, since
people will not see a ypbind problem UNTIL they try to update and
the update is running. There is no way they will see a ypbind
problem unless they already have cluster info. I would like you
to better explain your third papragraph.
OFFICE START READING HERE
The sipb installer does not install a release-rpms file that contains
epoch numbers, this means the update gets confused about what versions
certain programs are. There are a few fairly easy things you could tell
a user to do.
1. Telling people to update to 8.4.26 should work.
or
2. Simply tell them to copy the 8.4.25 control list out of afs
/afs/athena.mit.edu/system/rhlinux/control/list-8.4.25 to
/var/athena/release-rpms -- they should then have a release rpms
list with epoch numbers and will be able to update to 9.0 if they
so desire, or to go to 8.4.26.
OFFICE STOP READING HERE
Again, I think you are seriously confused if you think someone can
see the update related ypbind problem without already having something
that gives the machine hesiod info. (A machine without hesiod info
or cluster.local info won't start an update so shouldn't get far
enough for that update to generate an error.)
Please in the future when reporting problems, clearly explain the
problem and try not to exaggerate the situation.
Thanks.
>It would be good if someone could document what goes on to sipb-office
>so that people who field phone calls are not fully clueless.
>
>It would be good if there was a "canned" solution that could be run,
>like "run this script in the linux locker," if the solution is at
>all complicated.
>
>ghudson suggests that it is as easy as updating to 8.4.26 first,
>and then to 9.0, but that this requires manual kludgery for
>users who have no cluster information. I think expecting
>people to type in a cluster.local file over the phone
>is expecting too much.
>
>
>In general, I think linux-dev has done a shoddy job of telling
>people who answer phones what to say. Perhaps folks could be
>a bit more proactive.
>
>--jhawk
