[1381] in SIPB bug reports
"bloom-beacon" will soon be the WRONG host to read news from
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed Oct 24 20:24:48 1990
Date: Wed, 24 Oct 90 20:23:53 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: cfyi@ATHENA.MIT.EDU, sipb@ATHENA.MIT.EDU, docsourc@ATHENA.MIT.EDU
Cc: usenet@ATHENA.MIT.EDU, bug-sipb@ATHENA.MIT.EDU
(This message is being sent to cfyi because consultants are going to
have to help users who encounter the problem discussed below; to sipb
because it's a sipb-related issue; and to docsourc because the
documentation staff is going to have to update their documentation
based on the problem discussed below. The CC to usenet is because
it's usenet related, and the CC to bug-sipb is because of the changes
to the sipb locker described in the *** IMPORTANT NOTE *** section.)
SIPB will soon be acquiring a new machine (a DECstation 3100) to act
as our main NetNews server. It will NOT be named bloom-beacon.
As a result, any documentation which refers to bloom-beacon.mit.edu
as a NetNews server will have to be changed, and any users who have
personal configurations that depend on the news server being
bloom-beacon are going to have problems after the cut-over to the new
server.
The CNAME "news.mit.edu" currently points to bloom-beacon.mit.edu.
After the cut-over, it will be changed to point to the new news
server. Therefore, I am currently in the process of changing things
in the sipb locker so that all of the clients that refer to
bloom-beacon refer to news instead (if all goes as planned, that
should only require modifications to one file in the locker).
However, that change will not affect some people's configurations;
for example, people who use gnus and have (setq gnus-nntp-server
"bloom-beacon") in their .emacs files.
I would recommend the following:
1. People with personal customizations should change all references to
bloom-beacon to refer to news instead. I don't think there are
going to be a really large number of people with this problem, so I
am not putting a lot of effort into publicizing this.
*** IMPORTANT NOTE ***: I have modified the version of gnus in the
sipb locker so that after the volume is released tonight, it will
default to using news.mit.edu if there is no gnus-nntp-server set
(and will set the return address and organization properly as
well). Therefore, the way to fix this problem with respect to gnus
is for the user to REMOVE the line that sets gnus-nntp-server from
his/her .emacs file. The line that changes the load-path will,
however, have to remain. Furthermore, if the user's .newsrc file
is named .newsrc-bloom-beacon.mit.edu, rather than .newsrc, they
will have to rename it to .newsrc-news.mit.edu (and rename
.newsrc-bloom-beacon.mit.edu.el, if it exists, to
.newsrc-news.mit.edu.el).
2. If there is any consulting material (e.g. stock answers) that
refers to bloom-beacon, it should be fixed to refer to news, or, in
the case of gnus, to not tell users to set the server explicitly at
all.
3. A stock answer should be prepared to answer the question, "Why
won't bloom-beacon let me read news?" This stock answer will not
be needed until the cut-over, but consulting should *have it ready
when the cut-over occurs*, because there are going to be people
asking questions. The stock answer should simply tell people to
update their customizations to point to the new location, since (if
all goes well) the only possible cause of problems by the time the
cut-over occurs will be personal customizations.
4. All Project Athena documentation that refers to bloom-beacon should
be fixed to refer to news, or, in the case of gnus, to not tell
users to set the server explicitly at all.
We do not know yet exactly when the cut-over will take place. I will
send out appropriate notifications when we know more.
Please let me (or "usenet") know if you have any questions.
jik
