SIPB Office Manual^{†}

The Student Information Processing Board

March 22, 1998

†If you are willing to maintain a section of this:

1. Mail mkgray and lorianne.

2. Write something at the beginning of the printed section saying so.

3. Do it. It lives in /afs/sipb/project/doc/office manual. Use RCS!

Feel free to write new sections.

Contents

1 General Information 3 1.1 What is the SIPB? . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 A Brief History of the SIPB . . . . . . . . . . . . . . . . . . . 4

2 Membership 6 2.1 Responsibilities of Members . . . . . . . . . . . . . . . . . . . 6 2.2 How to become a SIPB member . . . . . . . . . . . . . . . . . 7

2.2.1 Becoming a Prospective . . . . . . . . . . . . . . . . . 7 2.2.2 Being a Prospective . . . . . . . . . . . . . . . . . . . 7 2.2.3 Membership Elections . . . . . . . . . . . . . . . . . . 8

2.3 Frequently Asked Questions (FAQ) List for SIPB . . . . . . . 10 2.4 Prospectives: Questions and Answers . . . . . . . . . . . . . . 14 2.5 Office Maintenance . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.1 Toner Cartridges . . . . . . . . . . . . . . . . . . . . . 20 2.5.2 Recycling . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.3 General Office Cleanliness . . . . . . . . . . . . . . . . 21 2.5.4 The Fridge . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Office Machines and Guest Accounts 22 3.1 Etiquette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Guest Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Normal . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.2 Temporary (sipbn) accounts . . . . . . . . . . . . . . 26

3.3 Mailings lists for SIPB services . . . . . . . . . . . . . . . . . 27 3.3.1 sipb mailing lists . . . . . . . . . . . . . . . . . . . . . 27 3.3.2 usenet, usenet-grunge . . . . . . . . . . . . . . . . . . 27 3.3.3 charon-maintainers . . . . . . . . . . . . . . . . . . . . 28 3.3.4 rtfm-maintainers . . . . . . . . . . . . . . . . . . . . . 28 3.3.5 linux-dev, linux-help, linux-athena . . . . . . . . . . . 28 3.3.6 bug-sipb, bug-outland . . . . . . . . . . . . . . . . . . 29 3.3.7 webmaster . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.8 sipb-gnu . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.9 sipb-afsreq . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 MITVMA and Bitnet accounts . . . . . . . . . . . . . . . . . 30 3.4.1 Athena ↔ Bitnet . . . . . . . . . . . . . . . . . . . . . 30 3.4.2 How to give out a VMA account . . . . . . . . . . . . 30

4 Hardware 32 4.1 Machine-Specific Software . . . . . . . . . . . . . . . . . . . . 32 4.2 SIPB Terminals and Supplies . . . . . . . . . . . . . . . . . . 32

5 Chores 35 5.1 SIPB AFS Backups . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Webster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 [Re]Starting the Webster Server . . . . . . . . . . . . . 42 5.3 Buying Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3.1 Requisitions . . . . . . . . . . . . . . . . . . . . . . . . 43

6 Projects 44

6.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.1.1 SIPB-Written Documents . . . . . . . . . . . . . . . . 44 6.1.2 How to Make More Documentation . . . . . . . . . . . 45 6.1.3 On Line Help . . . . . . . . . . . . . . . . . . . . . . . 45

6.2 Maintaining SIPB software . . . . . . . . . . . . . . . . . . . 46 6.2.1 XScreenSaver . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 1

General Information

(This lives in /afs/sipb/project/doc/office manual)

1.1 What is the SIPB?

The Student Information Processing Board (SIPB) is a service organization whose function is to provide easy access to computer facilities at MIT and assistance to those who use them. We provide services to the MIT computing community to aid in work productivity, computer use education, and entertainment. In short, we strive to aid the MIT computing community in whatever (legal) endeavor users may wish of the available computer resources.

There is, however, another side to the SIPB: we are also one of MIT’s many student activities. The Board is composed of MIT students.^{1} Expertise in computers is not assumed or required for membership, although the majority of members acquire some in time. Members will also find themselves acquiring a lot of other skills and knowledge too diverse to list here. This is not as dreary as it may sound; we generally have a very good time.

1An “associate membership” category is provided for non-students who are interested in involving themselves in our activities.

1.2 A Brief History of the SIPB

SIPB started in 1969, when it was in 39-541. Within a year or two, it relocated to 39-200. From there it moved to 11-205. There it stayed for a while, until its move to its present location to W20-557 in the summer of 1989.

From the very very very beginning, SIPB has had meetings on Monday at 7:30. That’s an international constant to which the world can synchronize. SIPB meetings have even happened with a grand total of 2 prospective members showing up during Christmas break.

SIPB has changed in the more than two decades since its founding, but a look at the 1978 SIPB Office Manual reveals striking similarities:

1. What is the SIPB?

First and foremost, the Student Information Processing Board (SIPB) is a service organization whose function is to provide easy access to computer facilities at MIT, and assistance to those who use them. We provide funding from our yearly budget to members of the MIT community who would like to use a computer to assist them with a project. Such projects may be related to class work or UROP (Undergraduate Research Opportunities Program) study, or may be of only personal interest. It is our job to assess the value of a given user’s proposal, and to provide funding based on that evaluation.

There is, however, another side to the SIPB: we are also one of MIT’s many student activiites. The membership of the Board is composed entirely of MIT students (Footnote: An “associate membership” mechanism is provided for those who do not fall into this category, but are still interested in involving themselves in our activities.) No knowledge of, or interest in computers is assumed or required for membership, although the majority of members acquire a little of both in time. We generally have a very good time.

Since 1975, SIPB has gone on to other things such as:

Around 1988, SIPB supported dialup service to athena. Athena has taken over this now.

SIPB supported LaTEX on athena because athena didn’t do so at the time. Athena has taken that over too, although SIPB continues to provide support for it.

SIPB also brought discuss to athena (SIPB wrote it, actually). It was modeled after forum on multics. Athena also took over this.

The first SIPB chair was Edward Fox (now a professor at Virginia Tech). Chairs over the past ten years have been:

1984 — 1985 Jon Rochlis (jon@mit.edu) 1985 — 1986 Bill Saphir (wcs@mit.edu) 1986 — 1988 Ken Raeburn (raeburn@mit.edu) 1988 — 1989 Stan Zanarotti (srz@mit.edu) 1989 — 1990 Rob French (rfrench@mit.edu) 1990 — 1991 Andrew (Rhu) Greene (amgreene@mit.edu) 1991 — 1992 Juliet Bourne (jcbourne@mit.edu) 1992 Chee Chew (web@mit.edu) 1992 — 1993 Derek Atkins (warlord@mit.edu) 1993 — 1994 Matt Gray (mkgray@mit.edu) 1994 — 1995 Jessie Stickgold-Sarah (sorokin@mit.edu) 1995 — 1996 Greg Hudson (ghudson@mit.edu) 1996 Eric Mumpower (nocturne@mit.edu) 1996 — Present Yonah Schmeidler (yonah@mit.edu)

Membership

2.1 Responsibilities of Members

The members of the Board are expected to uphold the policies of the SIPB, and are responsible for the proper management of its yearly budget. This general statement encompasses many actual duties. SIPB members are expected to contribute some of their time and abilities towards furthering the goals of the Board. This usually entails attending the weekly meetings (Monday nights at 19:30, one of the few true universal constants), occasionally devoting irregular stretches of time (as necessary) to complete vital tasks. Some members are responsible for particular aspects of the SIPB’s day-to-day existence.

The most basic, day-to-day task of a SIPB member is the assistance of users of the computer facilities at MIT. This includes answering questions, giving programming assistance, performing administrative tasks, directing users to other sources of information, and geneally trying to cut through some of the red tape associated with computing at MIT. This does not mean that every SIPB member is expected to be a highly experienced computer hacker, but rather that every member is expected to know the basic steps of helping a user, including what to do when the user needs more help than the member can give.

2.2 How to become a SIPB member

The most effective way of becoming a SIPB member is to become a prospective and hang around the office helping out so much (see below) that the members forget you aren’t a member and proclaim, “WHAT? You’re not a members? We’ll have to fix that!”

The full, official procedure for Granting Membership is described in the By-Laws Article III section 3 amended by Section 1 of Amendment III. That document is currently available in /afs/sipb/admin/text/bylaws.

2.2.1 Becoming a Prospective

Becoming a prospective is easy. Show up in the office and express interest in SIPB and in becoming a Prospective. Then ask any member (this means you need to find out who in the office is a member) to add you to the prospective members list.

2.2.2 Being a Prospective

A prospective has virtually all the rights, priviledges and responsibilities of a member. The main differences are that they cannot have a key to the office, they are not to be given the root password to any of the SIPB machines, and they do not get a vote in elections. They also may not be added to certain sipb mailing lists, although there is a mailing list (sipb-prospectives) devoted to prospectives.

A prospective is expected to:

• Learn as much about the SIPB as they can tolerate. Good ways to do this are hanging out at the office, reading SIPB documents, looking through the office and learning where resources are kept, and just plain talking to people.

• Learn who the currently active SIPB members and the current prospectives are. Becoming familiar with the expertise of these members is also useful when being helpful and answering users’ questions (see below).

• Attend SIPB meetings. Attendance at at least 4 meetings is required, and thus a one month “probationary” period as a prospective is required before nomination for membership. In general, very few prospectives are membered in only 4 weeks. The only technical exception to the 4-meeting rule are non-student, associate member prospectives, but in practice everyone has a minimum “probationary period.”

• Help out with SIPB functions as much as possible. This includes projects such as documentation writing, programming, teaching SIPB courses over IAP, as well as day to day functions such as answering phones and questions, cleaning parts of the office (it almost always needs this), and keeping the documentation rack supplied. The prospective need not do all these duties, of course, but is expected to help SIPB within reasonable bounds.

2.2.3 Membership Elections

Before The Elections Meeting:

1. The prospective should have followed the above instructions about how to become a prospective and how to be a prospective.

2. At a meeting at least 1 week before the election meeting, a member must move to nominate the prospective for membership, and the motion must carry a majority of full members present at that meeting.

3. An announcement of the nomination must be made to all members at least 4 days preceeding the election meeting.

4. Someone, anyone, everyone should read the By-Laws Article III section 3.

At the Meeting:

1. Introduce the nominees

2. Open the floor for questions

3. Ask “The Question”

4. Kick out nonmembers

5. Open private discussion

6. Pass out ballots (get someone else to pass out ballots, tally, etc. Traditionally a nonstudent)

7. Apply formula to results

8. Let the herd in and announce results!

2.3 Frequently Asked Questions (FAQ) List for SIPB

Q. What is a prospective?

A. A prospective is someone who has an interest in becoming a member of SIPB. In other words, it is someone who is interested in helping the computer-user community of MIT.

Q. What is the SIPB?

A. According to the Bylaws, SIPB is a General Committee of the Undergraduate Association of M.I.T. The full name of this committee is the Student Information Processing Board.

Q. What is the purpose of SIPB?

A. According to Article II, Section I of the Bylaws, the principal purpose of the SIPB is to provide the M.I.T. community with improved access to computational facilities. Primarily, this will be focused on students who do not readily have access to other computers on which to further some desirable purpose. The secondary purposes of the Board include: serving as a spokesman for undergraduates to the Faculty and Administration in computer-related topics, functioning as an information center for undergraduates interested in the various computers known to the SIPB and in other topics in computer science or computing at M.I.T., as well as conducting, managing, and supporting experiments run by students to advance the techniques of organization, planning, and administration of access to computers.

Less formally, we try to help out anyone who uses computers at M.I.T. We do this by answering questions, providing services, and writing cool software.

Q. How should a prospective act?

A. It is a common saying that prospectives get membered about the time when everybody thinks they are members anyway. So, I guess this means that you should act just like a SIPB member. This means that you should answer the phone, try to answer questions, and eat a lot of Chinese food.

Q. Can I log in?

A. Yes. You are a prospective member, so go right ahead.

Q. What about the message that tells me not to log in?

A. If you receive the message telling you that only SIPB members and prospectives can login to office machines, then you should ask a SIPB member to add you to the members and prospectives list.

Q. What does that message mean? A. The machines in the SIPB office are not public workstations. They

are here for the use or SIPB members and prospectives. The message is just our not so subtle way of making sure that people understand that. Just get yourself added to the members and prospectives list, and you need never read it again.

Q. Should I log out if a SIPB member wants to use the machine? A. No. But remember that while logged in in the office, you should be

doing member-like things: answering the phone, handling walk-ins, developing software, harassing warlord, writing documentation, etc.

Q. What is the meaning of FTGOS? A. FTGOS stands for ”Furthering The Goals Of SIPB”. Q. Is there a place for communication between prospectives? A. Yes, there is a mailing list called sipb-prospectives. This list has

contains both some members and some prospectives. The use of this list varies over time.

Q. Can I get on the sipb mailing list? A. You can get on the general sipb list, which is a question and answer

forum. However, you cannot get on sipb-members, sipb-staff, or other such lists.

Q. How do I go about starting a project for the SIPB? A. Just Do It. Speak up during a meeting. If anyone mentions a project

they are working on, volunteer to help if the topic interests you (and if you need help, don’t be afraid to ask.)

Q. How do I get a copy of the minutes? A. The minutes exist in world-readable form in the directory /afs/sipb.mit.edu/admin/minutes. Q. What are the main things that SIPB does? A. SIPB provides many services beyond answering questions for users.

These services include maintaining NetNews, providing space for multiple discuss meetings, running servers for IRC, hearts, and mboggle, and many others.

Q. How can I learn about News administration? A. Ask us in person for this one. Q. What is the difference between associate members and active mem-

bers?

A. According to the Bylaws, ”Full membership in the SIPB is open to all students of the M.I.T. community; associate membership is open to anyone.”

So, simply put, active members are students; associate members are mostly old folks. Most, but not all, associate members were at one time active members.

Q. These Bylaws you keep mentioning, where can I find them?

A. Well, unless someone has viciously ripped them down, they are posted on the bulletin board by quiche. (Don’t know which machine is quiche? I suggest you find out.) Take some time to read them. They may answer many of your questions even better than this FAQ. There is also a copy in /afs/sipb/admin/text/bylaws.

Q. How do I become a prospective member?

A. If you’re reading this, you probably are already a prospective member. So, now, to make it official, get yourself added to the members and prospectives list, and come to a meeting to get your name in the minutes.

Q. Why do I want my name in the minutes?

A. So that SIPB members have an official record to show how long you’ve been hanging around. It is important to have this information when nominating prospectives for membership.

Q. How do I become a member?

A. First, you get nominated, then you get elected. If all goes well, you will then be a member of the SIPB.

Q. How do I get nominated?

A. First and foremost, show up at meetings. When you have attended four, you are eligible for nomination. Additionally, get to know the membership. People need to get to know you to nominate you. When you are in the office, make a point of introducing yourself and getting to know people. Finally, get involved in SIPB projects. Nothing is more likely to get you nominated than showing yourself to be a useful and productive member. Once you have been nominated, there will be an election at the next meeting at which quorum is present. You will be asked questions, the membership will consider your nomination, and hopefully, you will be elected.

Q. When are the meetings?

A. Meetings happen every Monday night at 7:30pm in the SIPB office. Q. Do I need to know C? A. No, you don’t need to know C. (perl is nice, though) In fact, you

don’t need to know anything in particular. Much more important is a desire to learn things and help other people learn things that you know.

Q. Can I answer the phone?

A. Yes, in fact you are encouraged to answer it. Try to be courteous and to help the caller as much as you can. If you can’t answer their questions, then see if anyone else in the office can. For many prospectives, a typical conversation may proceed... ”Hello, SIPB.” -”Can you help me with ¡blah¿”

”No, but one second and I’ll see if anyone in the office might be able to” All the better if you can answer the question, but you’re not expected to.

Q. How do I get a CokeComm account?

A. Talk to or email the Coke Pusher. For more information on what is involved with having a CokeComm account, read the poster on the Coke fridge in the back of the room.

Q. What about zephyr?

A. Yes, sipb members do use zephyr. For a long time, messages were sent to instance ’sipb’, but more recently, there has been a move to the class ’sipb’ for the more social and random conversation, saving the more public instance for more technical discussion. So, if you subscribe to Message,sipb,* and sipb,*,* you can be in on all of the conversation between sipb members on zephyr. We discuss everything from bugs in our code to where we’re eating dinner tonight. So, do it.

Q. Where can I find out more?

A. Just ask someone. Anybody in the office, member or prospective, will be happy to answer your questions. There is also more information in the office manual. The most online recent version is currently in /afs/sipb/project/doc/office_manual; read whatever sections you’re interested in! If you have more in-depths questions about what SIPB members do, try the file prospectives.tex.

2.4 Prospectives: Questions and Answers

The following questions were asked by a prospective, and the answers were written by abbe@mit.edu and svalente@mit.edu (each section is marked appropriately). I have rearranged and edited a few things, but the text remains essentially the same as the original questions and answers. As a prospective, you may find that this elucidates some of the less trivial/obvious aspects of SIPB; it may give you a better idea of what SIPB is all about.

Question: I don’t understand what SIPB members/prospects are expected to do.

(svalente) SIPB provides services to the MIT computing community. We do it because it’s fun to help people. It’s fun to feel useful. SIPB prospectives are expected to help people. The two most common ways are answering questions on the phone and in person, and maintaining a program in the SIPB locker. You are free to come up with new ways to be helpful. A good question to ask anyone (member, prospective, random person crossing Mass Ave, yourself) is “How can I help?”

(abbe) There’s no rule that says you have to be working hard at learning something or writing some program whenever you come into the office. A lot of prospectives come into the office as a place to log in instead of in a cluster, to read mail, send zephyrs, etc. It’s generally a good thing to sit in the office and try to answer questions when people ask them, too, but you don’t have to answer them, or know the answers. If you’re totally unwilling to ever try to help a user who comes into the office, even when you do know how to help them, people probably would think this is bad, though.

Question: It is very noisy in the office and not possible to study the manuals for any reasonable undistracted length of time.

(abbe) Sitting in the office and studying manuals is certainly not the only thing you can do. Especially if you’re like me, and don’t learn much from staring at a manual, or necessarily find it very interesting. Knowing C is also not necessary. It’s a useful programming language, but SIPB is not “Student group-of-people-who-like-to-read-manuals board” or “Student C-programmers-incorporated Board.” There are a number of things SIPB tries to do, which are our purpose for existing. Basically, SIPB members want to improve computing at MIT by helping users, providing them with services that might not be available to them otherwise, and providing useful documentation on computing. (I’m missing lots of other specific examples…) For example, SIPB gave out accounts on old crufty systems back before athena existed. SIPB offered a machine you could dial up into from a modem before athena had dialup servers.

Prospectives aren’t expected to be experts on anything when they become prospectives. (And members aren’t expected to be experts on everything when they become members…) Nor are they expected to do all their learning in the SIPB office. If you want to find out how to program in C, you certainly don’t have to pick up SIPB’s copy of K&R, sit at a SIPB machine and read it, and write code. If, however, you wanted to learn about running linux on a PC and doing athena things on it, it might be useful to try asking one of the SIPB members who built most of athena for quiche-lorraine, the PC in the SIPB office which runs linux. The office is a resource, not an obligation.

(svalente) True. SIPB is a student activity a/k/a a social group. More and more often, I find myself thinking: “I’m bored, I’ll go hang out in the SIPB office.” I know that I can find some friends to talk to and some bad music to listen to in the office. It’s not really meant for quiet study.

Question: Once I know C what should I write in it?

(svalente) Whatever you feel like. Most SIPB members have never written any programs in the SIPB locker. The few that have used this method:

1) realize there’s something you’d like to see on athena. It has to interest you personally. Don’t write something because other people are interested in it. 2) write it. (This step may take longer than you think.) 3) if it’s useful to other people, install it in the SIPB locker. (If you don’t yet know how to accomplish this step, don’t worry. It’s peanuts compared to the first two steps.)

Programs written through this method include discuss, nawm, and xzwrite. Question: What is the difference between a SIPB member/prospect

doing a project upon his own initiative and doing a SIPB project?

(abbe) I’ll make an analogy that might help. It’s along the same lines as the difference between doing an assignment in your high school physics class, and doing random physics problems in your physics textbook because you think they’re fun. Your teacher isn’t likely to count the random physics problems as part of your physics assignment, even if they were harder, or you found them interesting, or whatever. Nor will they let the random problems replace the ones you were asked to do.

Now, SIPB projects are not an assignment, of course. But the other difference is that a project you do on your own is something you thought was necessary, and you’re responsible for. If you wrote a program, you’d keep it in your own homedirectory, etc. You wouldn’t need anyone to think it was a good idea besides you. A SIPB project, on the other hand, is often something related to a service SIPB already provides, or wants to provide. It’s approved or suggested by SIPB in some way.

Hence, it’s a SIPB project to offer to put information about the IAP classes SIPB is sponsoring into xmosaic, like mwhitson did. It would also be a SIPB service to say to some SIPB members, “Hey, there’s this program that I’ve seen elsewhere that I have the source to that isn’t on athena, and I think it would be cool if SIPB supported it. I’d like to compile it and maintain it.” Then you could offer to do it at a meeting, and if people though it was cool for SIPB to support it, you could work on it as a SIPB project. It would not be a SIPB project to teach a class on “Introduction to Scheme” or “A Warmup for 6.001” or “How to Type” because SIPB didn’t decide that we wanted to teach a class on those things, or that they were necessarily relevant to the kinds of things SIPB wants to support. They would be your classes, not SIPB classes. This doesn’t mean that we wouldn’t want to sponsor a class on these topics, just that you didn’t try to get us to sponsor it. (Also, classes tend to be taught by people who have already showed to SIPB members that they know the subject they’re teaching on.)

Question: Whenever I enter the office the people are talking in gibberish and I do not want to be rude to stop them in the middle of their work to ask them what it means.

(abbe) Being a prospective means that you are interested in what goes on in the office, and that it IS your place to ask things, either about a conversation that’s going on, or at random. If you do want to know what people are talking about, it is perfectly reasonable to ask. If it’s none of your business, someone will tell you that. Or if they explain and you’re totally lost, you can say you’re lost. If they were talking about something important that they need to keep talking about, then they’ll say “Ask me later.” if they have time to explain it then, great. You’ll learn something. Listening to a conversation is a contribution, even if you know nothing about it, or aren’t an expert … because YOU learn.

(svalente) I felt like that before I knew most of the members. It’s not easy to jump into a conversation you don’t understand with people you don’t know. You don’t have to. However, jumping into the conversation may be the best way to get to know the people and understand the topics.

Also, people talking in gibberish are generally not working. Generally, they’re flaming about some topic that interests them, which may or may not turn out to interest you.

For example, say you walk into the SIPB office and hear the following comment: “Whoever wrote the AFS to NFS translator should be disemboweled!” Say you don’t know what an “AFS to NFS translator” is, or what “disemboweled” means. Simply ask me (yes, I was the one making that statement) “what does disemboweled mean?” and I will happily waste hours of your time explaining what the “AFS to NFS translator” is and why I hate it. And you will probably never speak to me again, but that’s besides the point.

Question: People seem to be working on private, secret projects and I do not feel it is my place to intrude to ask anything.

(svalente) It’s certainly not easy to intrude, but it generally is your place to do so.

(abbe) As for people who seem to be working on private, secret projects — If i’m working on something at my machine, typing away, and you ask me what I’m doing, I would say something similar. If, for example, I were writing top secret code for the CIA and I’d be shot if anyone knew about it (which i don’t think is the case for anyone around here), I would tell you to go away. If I was sending mail to my best friend at another college, I would say that, and you probably wouldn’t be interested. If I was working on something for a SIPB project, or something you would find interesting, I would probably say that. Or if I were working on it, and I was in the middle of getting something done and wanted to finish my train of thought, I might say that, too, and ask you to wait. None of these things are bad … and a lot of them might result in you finding something out. But you don’t have to do anything like that. If you don’t want to learn by asking people about random things, you don’t have to. You can decide what you do want to learn, and work on learning it.

Question: I probably would not have the expertise to contribute anything worthwhile.

(svalente) SIPB members generally believe they’re experts, but don’t let that fool you. :-)

Question: Where is the vast amount of information you guys know written down? Which locker? Which public directory?

(abbe) Last time I checked, most people don’t take everything in their minds and write it down somewhere. If they want to share specific things with people, and people always ask for them, writing them down might be a good thing, but in general, knowledge is knowledge. It doesn’t need to be stored on-line, or in a book. It might be more useful that way, but if every person who knew the same things tried to write them down, we’d have a hell of a lot of duplication going around. It’s not like I’m intentionally keeping a secret from you by not having a file in my public directory stating everything I can remember about my childhood, or every neat thing I remember learning in 8.02, or every UNIX command I know how to use and how it’s used.

Question: How do you write a C program that digitizes microphone input on the Suns and outputs it in modified form? How do you go about obtaining the answer to that question? If from someone else in the office, where did he/she get it from (recursively)? Or is the collective body of knowledge known by SIPB members undocumented and transferred down the generations of members by word of mouth, like before they had writing…

(abbe) If you want to write a C program that digitizes microphone input on the Suns and outputs in in modified form, there is some knowledge you need. First, you need to know how to program in C. There are a lot of ways to learn how to do that, some of them could involve SIPB members, and lots more of them have no reason to. Your choice. You might want to find out how sun digitized sound is stored, what format, etc. You might want to start from scratch and read lots of books. You might be able to get help from SIPB members, who have seen information about Sun sound in other places, maybe read books on it, or whatever. It’s not a requirement that each member learn how to do each thing that might be imaginable or possible with a computer; I don’t know of anyone who has thought about this. But someone else might. The way to learn is to ask around. You might be more likely to find someone in SIPB who knows about it than to find someone randomly sitting next you in class who knows about it, but we don’t guarantee knowledge. Asking where someone got a particular piece of knowledge and where it’s stored is rather pointless. Like, where did you learn how to read? How do I go about learning to read? There are a lot of answers to that question. Or, “How do I learn to do research on something?” You just try. You ask other people where to start.

Question: Are members expected to dedicate their lives to the goals of SIPB, even at the expense of performance in class and the awareness of their own existence? What are these goals, anyway…

(abbe) I tried to give you a general idea of the goals of SIPB before. Of course people aren’t expected to dedicate their lives to SIPB. They aren’t even expected to dedicate n hours a week to it. It’s your own choice. If you don’t seem to want to devote anything at all to SIPB, it’s likely that you probably won’t become a member anyway. And if you don’t have time to devote for a while, you might become inactive if you are already a member, or wait a while to be considered for membership if you’re a prospective. You’d still be a member or a prospective, you just would not be considered someone who’s currently doing much with SIPB. As for “at the expense of performance in class”, there are a decent number of people in SIPB who think that doing things for SIPB and other random computer things are more fun than their classes, and let this take a toll on their classes. This is a bad thing, though. It’s not a requirement for membership in SIPB, and most SIPB members try to encourage each other to go home and tool when they need to.

Question: Is this supposed to be fun? I suppose it can be, but knowing where to find the information can be difficult.

(abbe) If you don’t enjoy helping people or learning about things, then there’s not much SIPB can do about it. Don’t try to be a prospective if you don’t enjoy what you’re doing, maybe you’re making the wrong decision.

I hope that this answers some of your questions; and I hope the length of it hasn’t kept you from reading it. I don’t claim to represent the opinions of all of SIPB, or to know everything about SIPB, but this is about how I see it.

(svalente) I consider the SIPB office to be one of the fun places on campus to kill some time. But then again, I’m weird.

Hope this helped. We are, after all, here to help.

2.5 Office Maintenance

2.5.1 Toner Cartridges

The HP toner cartridges should not be thrown away. They should be recycled. To recycle them, put them in a box and slap a UPS label on it. The UPS label can be found in one of three ways:

1) Look in the manual inside the box. There is one there. 2) If there is no manual inside the box, then look in the office drawer (where the machine room keycard is kept) and take one from there. 3) If there are none there or you can’t find them, then call HP at 1-800-752-0900 Ext. 1872 and talk to the nice lady there. She will send you some labels.

After you have slapped the label on, call UPS and ask them to come pick up. Or check with the Campus Activities Complex. They might be able to work it into their UPS stuff.

2.5.2 Recycling

There are several trash bags at the back of the office devoted to different types of (non-soda can) recyclables. These may be recycled by taking them to Bexley dormitory: on Tuesday night, leave the stuff near Bexley (opposite from Mass Ave), and make sure you put them in the special bins near the curbside (take the stuff out of the bags).

The latest guidelines from abbe:

Jet-A-Way will no longer accept any recyclables left for pickups in plastic bags. All items need to be placed in the bins at curbside. Jet-A-Way has generously agreed to supply each house with 2-3 very large plastic barrels which will be kept near the pickup area. This way, if you plan to transport your recyclables to the pickup site in a plastic bag, you can empty the contents of the bag into the barrel.

Glass (clear and colored), aluminum, tin and plastics (#1 & #2 only) can be mixed together. These items need to be rinsed first.

Newspaper and white paper can be mixed and put either in brown paper bags or wrapped in twine.

The empty deposit soda cans should be sorted by maker (Coca Cola or whatever) into cardboard flats, and then taken down to La Verde’s. A set of five flats should be six dollars of deposit refund. The current Coke Comm is rewarding people who do this with a free can of soda for every five flats.

2.5.3 General Office Cleanliness

When you are done with your can of soda, rinse it out and put it in the cardboard soda flats at the back of the office. When you are done with your food, throw the wrappings away. Remember, do not throw out anything dangerously sharp into the trash.

In case of major disaster, there is a SIPB bucket, sponges, and cleanser on the refridgerator at the back of the room.

2.5.4 The Fridge

Officially, anything not maintained by Cokecomm may be thrown out of the fridge. Unofficially, anything not named and dated may be thrown out, especially if it starts smelling bad (at which time it should definitely be thrown out).

The last fridge cleaning occurred in February of 1994, at which time the inside and door front of the fridge were thoroughly scrubbed with bleachbased cleanser. If you clean the fridge out, do not forget to empty the water-collection tray located beneath it. Feel free to use the gloves, sponges, bucket and cleanser located on the fridge.

Office Machines and Guest Accounts

3.1 Etiquette

SIPB tends to have various machines which are useful because they are fast or unique in some way. They are usually set up so that they can be shared by members. This is considered a privilege, and an earned one at that — being a SIPB member carries responsibilities as well as benefits.

Please be polite about sharing machines. Among members, the person sitting in front of a machine has some amount of priority — it is inappropriate to log in remotely and then use up all of the swap space on a machine thus blowing away the X server — remember that the person in the office is there answering questions in person and on the phone, and is thus doing something productive.

This is not to say remote usage is not helpful; for example, using the various sipb machines to compile all versions of a given program for the SIPB locker is a reasonable thing to do. Just don’t be annoying about it.

3.2 Guest Accounts

There are two types of guests accounts. In a normal guest account, we sponser a user to have an account (usually placed in the sipb afs cell), and we make a request to athena accounts to create all the data necessary to support the account. The home directory will reside on a sipb machine.

3.2.1 Normal

These guest accounts are given to people who are doing work which we feel helps out in the goals of SIPB. These accounts are temporary, generally a term or a year, and each accounts’s existance re-evaluated at the end that term or year.

The policy with these accounts was determined at the 11/25/91 meeting:

SIPB-sponsored Athena account policy There are concerns which prevent the SIPB from sponsoring

guest accounts for anyone who asks for them. These concerns include:

• Licensing. Some software available on Athena are licensed to the MIT community, and there are therefore some legal problems with giving people who are not currently members of the MIT community access to them.

• Policy. Clearly, Athena/IS believes that deactivating accounts is a necessary thing, and giving deactivated accounts back to anyone who asks might be considered a subversion of that policy.

• Resources. The amount of resources available for Athena accounts is limited. Large-scale granting of guest accounts might tax both Athena’s resources and the SIPB’s.

• Nepotism. The SIPB does not wish to become known as an organization that uses grease to make life better for its friends, while not serving the user community as a whole, as its charter intended.

Furthermore, much of the functionality obtained through an Athena account is available on public-access systems that can legitimately give out accounts to anyone who asks and is willing to pay the (usually not very high) fees.

Therefore, the SIPB chooses to restrict account sponsorship to two classes of people:

• SIPB members.

• Individuals who will use their accounts to further the goals of the SIPB (FTGOS).

SIPB members are entitled to sponsored accounts if for no other reason than because ”membership has its privileges.” Furthermore, SIPB members are elected only when the membership feels that they will be a worthwhile addition to the SIPB and help to FTGOS. Therefore, sponsoring accounts for members is considered a worthwhile investment.

Unfortunately, what is and is not ”FTGOS” is currently somewhat undetermined. The mechanism for creating guest accounts currently leaves that decision to the discretion of the member sponsoring the account, although the SIPB Executive Committee (EC) may choose to override a member’s decision to sponsor an account.

When a SIPB member wishes to sponsor an account for a non-member, he or she (the ”or she” is assumed from this point forward) should contact the EC through E-mail to the sipb-ec mailing list or through some other channel, providing the following information:

1. The full real name of the sponsoree, including middle initial.

2. The social security number, MIT ID or some other 9-digit number which may be used by the sponsoree when he registers for his account.

3. The desired username for the account.

4. The address to which E-mail should be forwarded, if it should not be left on an Athena post office.

5. The FTGOS purpose(s) for which the account will be used.

6. If possible, a date after which the account will no longer be needed.

Note that if the account being sponsored is the reactivation of a deactivated Athena account, items 1 and 2 are not necessary, and the username provided in item 3 is the username of the deactivated account.

The sponsor should then wait at least three full business days after the message has been delivered to the EC. In that time, any SIPB member may choose to respond to the sponsorship request, asking for more details about the purpose of the account or questioning the sufficiency of the reasons given.

If someone questions the account, the sponsor can argue with him, or bring it up at a meeting, or whatever. Among other things, the EC has the authority to request that the sponsor or sponsoree come to a meeting and justify the need for the account. The final decision about whether or not to grant the account is left to the EC.

When/if the account has been approved, the sponsor should send E-mail to ”accounts” with the information from items 1, 2, 3, 4 and 6 above. If no expiration date was specified, then the date given should be registration day of the term following the term following the current term (e.g. an account sponsored in November should expire by default around the beginning of the following September). The message should be carbon-copied to the EC. Furthermore, if a home directory in the SIPB AFS cell is necessary, the message should be carbon-copied to the sipb-afsreq mailing list.

When an account is about to expire, the sponsoree must ask the sponsor to responsor it, once again stating how it will be used to FTGOS, or he must find a new sponsor for the account.

The Secretary of the SIPB will be responsible for keeping records of currently sponsored guest accounts, including their expiration dates, as well as for sending out notices when accounts are about to expire (if Athena doesn’t start doing so).

Notes:

• Approval is not required from the EC before creation of an account for a SIPB member. Furthermore, such accounts need no expiration date.

• Some scheme will have to be devised for incorporating current guest accounts into this system.

3.2.2 Temporary (sipbn) accounts

There are 10 SIPB temporary accounts named sipb[0-9]. sipb0 should never be given out. The others may be given out to whomever may need temporary access to the net or athena or whatever. The policy about these ac-

counts is described here, taken from /afs/sipb/project/guests/admin/HOW TO USE.

• Decide that the person really does need a SIPB guest account. This is Athena; if he only wants to log in once to read mail, consider logging him in as sipb0 in the office (but don’t give him the password). There aren’t any real hard-and-fast rules about use of SIPB guest accounts, so just use your best judgement.

• Choose an unused account from the list in the accounts file. sipb0 is normally reserved for testing, etc.

• Check out the accounts file with RCS. Using RCS insures we have a log of who has been using the guest accounts and why.

• Write down the user’s real name, local contact (phone), permanent email address if s/he has one, how long s/he will be using the account, why the account is being given out, the current date and your username. The easiest way to do this is to copy the information for sipb0 and replace it with the correct info. (Temporary accounts should be restricted to two weeks.) Then ask for a password, and change the password of the account to this password. Record all this information (including the temporary password) in the accounts file. It’s a good idea to make sure nobody has accidentally left the admin directory world-readable or writeable.

• check in the accounts file with RCS.

• When the user is done, change the password back to the canonical password, and email to sipb-afsreq to clean up the account.

• The script clean dir.csh needs to be run to clean the directory out. It needs to be run with system:administrators tokens in the sipb cell. The argument is the account name. The person who cleans the account should then remove the information from the accounts file, signifying this account is no longer being used, and can be given out again.

Marc Horowitz

3.3 Mailings lists for SIPB services

(written by ghudson@mit.edu and being edited into format by rei)

I’ve written up a list of mailing lists and corresponding discuss meetings. Some of the information I give here (e.g. how much volume is on the lists) could change in the near future.

This file is /mit/ghudson/projects/sipb-maint/mailing-lists. I’ve probably left some lists out, and explained some lists inadequately. The final resting place for this list should probably be the office manual.

I’ve also left out sipb, sipb-prospectives, sipb-staff, and sipb-core-staff. I’ve tried to explain most of the terms that people might not under-

stand, but if there’s something on here you’re curious about (e.g. ”What’s WAIS?”), feel free to ask me or someone else.

I haven’t tried to explain how to use discuss; we have a document ”Using Discuss” which does a good job of that.

Enjoy.

–GBH

Time of writing: February 5, 1994

*** (this section being worked on —rei)

3.3.1 sipb mailing lists

sipb, sipb-prospectives, sipb-staff (all the people actively around doing things), sipb-core-staff (relatively unused list), sipb-soc (social mailing list), sipbtodo, sipb-ec, sipb-events, bug-sipb, sipb-afs, sipb-bitnet.

***

Except when otherwise noted, the contact list for a service (the best place to send questions or requests) is the same as the maintenance list (the place where maintainers send mail after making changes to the service).

Discuss meetings, if not otherwise noted, archive mailing lists.

3.3.2 usenet, usenet-grunge

The usenet list is for maintenance of the news servers.

There are a lot of people on usenet; a few of them actually read and, if appropriate, answer the mail that gets sent to it.

There is a separate list ”usenet-grunge” that gets control messages (messages creating and removing newsgroups); no one actually gets this list in mail, but several people read the discuss meeting for it.

Discuss meetings:

bloom-picayune.mit.edu:/usr/spool/discuss/usenet

charon.mit.edu:/usr/spool/discuss/usenet-grunge

bloom-picayune.mit.edu:/usr/spool/discuss/usenet-stats

This meeting archives status reports from senator-bedfellow, the news server that newsreaders connect to. Currently, it archives two status reports each day, one report giving some statistics for the whole day, and a second report giving various load indicators for each fifteen-minute interval during the day. This meeting does NOT archive the status reports sent to usenet.

charon.mit.edu:/usr/spool/discuss/usenet-archive

This meeting is for permanent archives of usenet information. Currently, it is used for just about nothing. Some information is archived in /afs/sipb.mit.edu/project/news/notes instead.

3.3.3 charon-maintainers

This is a list for people who maintain services on charon.mit.edu. Currently, these services include the web server, several discuss meetings, one of the webster servers, the bitnet gateway, a gopher server, mail, and SIPB member logins, and maybe a few I left out. This is currently a low-volume list.

The web server has its own mailing list; see ”webmaster” below.

Discuss meetings:

bloom-beacon.mit.edu:/usr/spool/discuss/charon-maint

3.3.4 rtfm-maintainers

This is a list for people who maintain services on bloom-picayune.mit.edu. Currently, these services include the RTFM services (archiving of periodic Usenet postings and access to these archives via WAIS, ftp, and a mail server), irc, ...

Discuss meetings:

charon.mit.edu:/usr/spool/discuss/rtfm-maint

3.3.5 linux-dev, linux-help, linux-athena

linux-dev is a list for development of the SIPB port of the Athena environment to Linux, and also for other Linux-related matters appropriate for the SIPB members active in supporting Linux. This is a medium-volume list.

linux-help is a list for users to send questions about Linux to. It’s primarily for questions about the Athena port, but other questions are also reasonable. Most questions to this list get answered fairly quickly. This is a pretty high-volume list.

linux-athena is a list for announcements about the Athena port. This is a public list; everyone who uses the Athena port or wants to receive announcements about it can add themselves. Currently, this list is just getting started, and isn’t advertised all that well. It is expected to be a low-volume list.

Discuss meetings:

charon.mit.edu:/usr/spool/discuss/linux-dev

charon.mit.edu:/usr/spool/discuss/linux-help

charon.mit.edu:/usr/spool/discuss/linux-athena

3.3.6 bug-sipb, bug-outland

These lists are for bug reports about software in the sipb and outland lockers. Most bug reports sent to these lists get answered fairly quickly. This is a medium- to low-volume list.

Discuss meetings:

bloom-picayune.mit.edu:/usr/spool/discuss/bug-sipb

charon.mit.edu:/usr/spool/discuss/bug-outland

3.3.7 webmaster

This list is for maintenance of the SIPB Plexus server. I don’t know if this is a high-volume list, or how responsive it is.

Discuss meetings:

charon.mit.edu:/usr/spool/discuss/webm

3.3.8 sipb-gnu

This list is for maintenance of the SIPB gnu locker (/afs/sipb/project/gnu). It is a low-volume list.

This list is not archived.

3.3.9 sipb-afsreq

This list is for maintenance of the SIPB AFS cell. It is a low-volume list. Discuss meetings: bloom-picayune.mit.edu:/usr/spool/discuss/sipb-afsreq

3.4 MITVMA and Bitnet accounts

SIPB currently sponsors MITVMA accounts to supply the community with bitnet access. This is primarily used for real time talk using the tell command on VMA. This service of providing a $50 account to whomever asks for one will hopefully soon go away and be replaced by an MITSIPB bitnet node. With this, users can send tell commands from athena workstations through the node to the Bitnet.

3.4.1 Athena ↔ Bitnet

bwrite

bfinger

3.4.2 How to give out a VMA account

The VMA account forms are currently in the lower left drawer of the front left desk in the office. Pull out the draw and fuddle around for a hanging folder labled MITVMA. The instructions below are also included in the front page of the contents of that folder:

1. Find a “Person Registration - IBM System” form, form 8. If you don’t know where they are, then ask someone. You should fill out the form yourself, getting the necessary information from the user and getting his address from his student ID. If you use the second to last form, make ten or so copies of the last one as soon as possible after you give out the account.

2. Check off VM/CMS under system required.

3. Printed output can be mailed to users who are using the system remotely and can’t get to the Information Systems Dispatch desk to pick it up. Of course, there is a charge for this service.

4. The user should get one cylinder for CMS. The virtual address for CMS is 191.

5. Dollar limit is $50. This should last for a while, and if it runs out, the user can come in and request more money if he wants it. If the account is for a particular project, place the end date of the project in the “End Date” blank. If it is just an account for general use, ask the user when he plans to graduate and use that as the end date. Write “SIPB” and your initials or username in the “Approved by ” blank.

6. The project number is M30010.

7. To determine the userid, look in the table of already assigned numbers and use the next one sequentially, i.e. if the last number assigned is “S20037,” then use the number “S20038.” Neatly write in the userid table the new userid, y our initials or username, the name of the person to whom you are giving the account, the date on which the account was assigned, and the end date.

8. The “Destination” blank should be filled in with a 30. Tell the user that his printouts will be placed in bin 30 (one of the hanging bins) at the IS Dispatch Desk, unless he is having them mailed.

9. Tell the user to take the registration form to the Information Systems User Accounts office, room 11-205, and to give it to them. User Accounts will process the application; this should take about a day.

10. If a user who already has an account comes in to ask for more money, check to make sure that his account has not expired (Look in the userid table.). If it has not, then write a dated note to User Accounts, with the userid and permission to give the user another $50. Sign the note, print your name and write “For SIPB” underneath it. Send them down to User Accounts with the note, and place a hash mark next to their name in the userid table. Send the treasurer mail, telling him/her what you’ve done.

11. Leave security group blank.

Hardware

4.1 Machine-Specific Software

It is customary to copy all special files which are stored on the local disk of a SIPB workstation into:

   /afs/sipb/project/office-machines/machine-name/path-to-file

This is so we can restore these local customizations easily in the event that a future Athena release upgrade changes or removes these files, or if some other failure occurs (e.g., a hard disk problem) which requires us to reinstall the software. At the very least, the site/CHANGES file should mention where copies of the necessary files are kept, so that any reasonably clueful SIPB member can restore the machine to its proper state if and when it becomes necessary.

4.2 SIPB Terminals and Supplies

The SIPB owns many terminals. Chiefly, they are located in the SIPB office (w20-557) or in the machine room in the public Athena cluster next door. They are used in many ways, such as providing NetNews to the MIT community and serving as a major node on the usenet, providing locker full of useful, interesting and/or entertaining programs available to anyone on the Internet with AFS access. And several machines, residing in the SIPB office provide a place for members and prospectives to log in.

Currently (as of today, perhaps not as of the time you’re reading this), the SIPB machines are: hodge (18.70.0.217, hodge, w20-557-8) – hodge is a DecStation 3100 run-

ning standard Athena release software. Hodge takes remote logins only from people with entries in /etc/passwd.

podge (18.70.0.222, podge, w20-557-12) – podge is a DecStation 3100 running standard Athena release software. Podge takes remote logins only from people with entries in /etc/passwd.

bill-the-cat (18.70.0.215, bill-the-cat, w20-557-6, btc, bill, ackphthp, ackpht) – bill-the-cat is an IBM RT running the standard Athena release software.

steve-dallas (18.70.0.211, steve-dallas, w20-557-4, steve, jerkface, dallas) – steve-dallas is an IBM RT running the standard Athena release software.

portnoy (18.70.0.218, portnoy, w20-557-9, sipb-n) – portnoy is an IBM RT running the standard Athena release software. It also runs the server for webster and has the neat feature that kilroy is called from crontab if potluck is attached.

cutter-john (18.70.0.158, cutter-john, w20-557-2, cutter, half-a-computer) – cutter-john is an IBM PS/2 Model 70 running OS/2 2.0 with PMX.

binkley (18.70.0.214, binkley, w20-557-5 mad-dog) – binkley is a VaxStation II running standard Athena release software.

oliver (18.70.0.212, oliver, w20-557-3, oliver-wendel-jones, hacker) – oliver is a VaxStation II running standard Athena release software.

yaz-pistachio (18.70.0.225, yaz-pistachio, w20-557-14, yaz) – yaz-pistachio is a VaxStation II running standard Athena release software.

deathtongue (18.70.0.228, deathtongue, w20-557-13, tongue, dt) – deathtongue is a Sparcstation IPX running pre-release Athena software.

milo (18.70.0.216, milo, w20-557-7, sipb-next) – milo is a NeXTCube running NeXT Step software.

banana-sr (18.70.0.221, banana-sr, w20-557-11, banana) – banana-sr is a Macintosh II. It is running After Dark with the Lunatic Phringe add-in Module. airplane (not on ethernet) – airplane is an IBM PC Convertible, not run-

ning anything. rob’s amiga (not on ethernet) – rob’s amiga is an Amiga 1000. lw-sipb (printer) – lw-sipb is an Apple Laserwriter. bloom-beacon (18.70.0.223, bloom-beacon, beacon, bacchus, mit-bloom-

beacon) – bloom-beacon is a VaxStation II acting as the server for bloom-picayune (18.70.0.226, bloom-picayune, w20-575a-10, picayune, news,

news-digests) snorklewacker (18.70.0.211, snorkelwacker, w20-575a-11, snork, snorkel,

wacker) ronald-ann (18.70.0.219, ronald-ann, w20-575a-8) rosebud (18.70.0.210, rosebud, w20-575a-12) – rosebud is an RS/6000, and

a server for the SIPB AFS cell. charon (18.70.0.224, charon, w20-575a-9, sipb-vax sipbvax, sipb, multics,

irc, lnf) –

Chores

5.1 SIPB AFS Backups

• Before starting the backup, there are a few things that ought to be checked, since they could result in the backup failing (or being incomplete) unless detected in advance.

– See if all the server processes are running:

   bos status ronald-ann -long -noauth
   bos status rosebud -long -noauth

– See if there’s enough free space:

   fs df /afs/sipb/service/partitions/*

Volumes should be moved, before continuing, if any partition is close to full.

– See if any volumes are offLine or busy:

   vos listvol ronald-ann -noauth
   vos listvol rosebud -noauth

Ideally, all the lines that start with ”Total volumes” should have ”Total volumes offLine 0 ; Total busy 0”. Otherwise, find out if someone else is doing volume operations, or if some volumes need to be salvaged (see part D below). Since the listvol output also gives disk-space usage, it be scanned for numbers that look way out of line, e.g., 100 Mb user volumes.

– Read all the log files from both servers, i.e., ronald-ann:/usr/afs/logs/*Log and rosebud:/usr/afs/logs/*Log. There will be a lot of messages that are actually fairly normal occurrences, and can usually be ignored. These include

Break call back failed for host
CB: Call back connect back failed (in break delayed)
CB: RCallBack (zero fid probe in host.c) failed for host
CB: RCallBackConnectBack (host.c) failed for host
Discarded a packet for ########
VAttachVolume: Cannot read volume header
fssync: callbacks broken for volume #########
fssync: volume ######### moved to ########; breaking all call backs
trans ######## is older than 300 seconds

The most common messages that are of interest are

Partition /vicepX that contains volume ######### is full
Volume ######### needs to be salvaged

Both of these indicate a potential need to do bos salvage immediately.

– Make sure the backup software and database still exist, e.g.,

ls -l /afs/sipb/project/newdump /usr/afs/backup

(/usr/afs/backup is a local directory on the /var partition of hodge)

• The next step is to find the correct three tapes for the current week’s backup. There are four groups of tapes, i.e., tapes are reused every four weeks. Each group of tapes includes one for each of the following three purposes:

– ronald-ann, all partitions

– rosebud, /vicepa and /vicepb

– rosebud, /vicepc

Each tape has a label (i.e., written to the tape media – not the one written on the tape package) that identifies the volume set and dump level that it is used for. The names of the volume sets are rann, rbud, and rsqr. These correspond, respectively, to A, B, and C above. That is, a volume set is the collection of all volumes having in common one of these server or server/partition locations.

The four groups of tapes correspond to four dump levels. The dumplevel names are of the form /volume-set-name # (e.g., /rann 1, /rann 2, /rann 3, /rann 4, /rbud 1, etc.). There is no particular reason for having separate dump-level names for each volume set, i.e., /foo 1, /foo 2, etc. could also have been used. In other words, the dump-level name is just an arbitrary string to distinguish the different tapes used for the same volume set. Regardless of the dump level, the full contents of all volumes in the volume set are written to tape. All levels are equivalent; none is higher or lower than any other.

The tape label is formed by putting together the volume-set name, dump-level name, and a sequence number. For example, the tape used for volume set rbud and dump level /rbud 3 has the label rbud.rbud 3.1. The ”.1” means that it is the first tape of the sequence. For sipb-cell backups, there is always just one tape in a sequence, so the label names will always end in ”.1”.

(Incidentally, there is no particular reason for having cryptic fourletter volume-set names. Originally, there was only a single volume set for the sipb cell, called sipb. Once the cell had too much data to fit on one tape, two new volume sets replaced it, with names rann and rbud, for compatibility with the original four-letter name. When the R-Squared external drive was connected to rosebud, a third volume set was added, called rsqr.)

The information written on the tape package will indicate what tape is inside. For example, the rbud.rbud 3.1 tape will say ”ROSEBUD 3”, the rsqr.rsqr 4.1 tape will say ”RSQR 4”, etc.

The dump levels are used sequentially. That is, if one week the levels /rann 2, /rbud 2, and /rsqr 2 are used, then the next week /rann 3, /rbud 3, and /rsqr 3 would be used. If the tapes for the current dump levels are not in the SIPB office, they are with the IS Media Storage service in Building 11. They can be retrieved by bringing our tape receipt (storage number CTG007) to 11-226 Monday-Friday from 8 AM - 4 PM. It takes about 5 minutes for the people there to get the tapes. Remember that the tapes should be obtained by Friday if Monday is a holiday. When retrieving tapes, a new set of tapes should be brought there, to swap into storage. The tapes to bring are the second-to-most-recent ones. The most recent tapes should be kept in the office, in case they are needed to restore data.

If the tapes for the correct dump levels can’t be obtained, it is OK to use different dump levels. Using the dump levels sequentially is just a convention (and it makes sense to overwrite older backups, not newer ones); none of the software requires it.

If it’s necessary to use a new tape, or one that was previously used for something else, then a labeltape operation should be done prior to the backup. (Note: usually, the only tapes that should be reused are AFS tapes from previous years. The other tapes in the SIPB office generally have some archival value.)

To do labeling, start up two separate root shells on hodge. Each of them should be in a PAG with suitable root-instance tokens, and have the cwd /afs/sipb/project/newdump. In the first one, type

   # @sys/backup -cell sipb.mit.edu

and in the second, type

   # @sys/butc

In the first shell there will be a ”backup¿ ” prompt. To label a tape as rbud.rbud 3.1, type

   backup> labeltape rbud.rbud\_3.1

There will be a prompt to hit return in the second shell. The second shell will eventually indicate that the labeling finished (it takes a few minutes). At this point, type quit in the first shell, control-C in the second, and (presumably) unlog and kdestroy in one or both of them.

• Before starting the backup, obtain a single root shell on hodge. Get tokens for someone listed in system:administrators and in /usr/afs/etc/UserList on ronald-ann and rosebud. Presumably, these should be in a separate PAG from any other shells on hodge, so that an accidental unlog elsewhere doesn’t disturb the backup. One way to do this is run the newpag program, then setenv KRBTKFILE, do a root-instance kinit, aklog sipb, and kdestroy. Root-instance tickets aren’t needed for the backup: tokens for only the sipb cell will be adequate. It’s best to set umask to 022 or 002 so that the log files on hodge’s local disk will be readable.

• The backup process itself has two steps: volume cloning and volume dumping. Volume dumping is done separately for each volume set, i.e., rann, rbud, and rsqr. They can be done in any order.

Volume cloning is done once per server. Volume cloning must be done before volume dumping. It takes much less time (about one-tenth as much). It is probably best to do it immediately before. Volume cloning accesses all of the volumes that will be dumped. If there is a problem with accessing any volume, it will often be detected during cloning, and can be corrected (e.g., with a bos salvage) before dumping. If cloning is done too long before dumping (e.g., a day earlier) there’s a possibility that some problem will develop in between the two times. This can cause the backup to be incomplete, since that volume will not be dumped.

The volume cloning is done via sh scripts. The general idea is to clone all volumes that have names not ending with ”.nb” and not beginning with ”disk.”. First, use mkvbscript to create a script containing the series of vos backup commands:

   cd /afs/sipb/project/newdump
   scripts/mkvbscript servername

Then, run this script, recording its output to a file:

   script vb-script.server\_abbreviation.YYMMDD
   /usr/tmp/vb-script.servername.DDMonYYYY
   ^D

Compress the output file, and save it in project.newdump:

   compress vb-script.volume-set-name.YYMMDD
   mv vb-script.server\_abbreviation.YYMMDD.Z last/

(The server abbreviations are rann and rbud.)

If any of the vos backup commands failed, do a bos salvage on that individual volume, then run that vos backup command again.

The volume dumping is done with a perl script. The perl script currently has some problems (mainly: it does not finish cleanly) but it is still a bit more convenient than other methods. The main function of the script is to run the backup program, giving it the command ”dump volume-set-name dump-level-name”, e.g., ”dump rann /rann 2”. The script also starts up the butc program, which controls I/O to the tape drive, and handles interaction between backup and butc using perl’s chat2 facility. Before running it, put the correct tape into the tape drive, and wait until the green light on the front is lit. Then, just give the dump arguments on the command line, along with the -noclone switch, e.g.,

   /afs/sipb/project/newdump/backup.pl rann /rann\_2 -noclone

For volume set rann, expect to wait about 4 hours. For rbud or rsqr, it should take less than 2 hours. There will be on the order of 10-50 lines of output reporting the status of the backup. At the end, there should be a final message of the form ”Finished doing dump rann.rann 2 successfully”. At this point, hit control-C until the shell prompt comes back (it will take either 2 or 3 control-C’s).

Once the backup of each volume set finishes, find the processes (on hodge) running ”@sys/butc” and ”@sys/backup -cell sipb.mit.edu” and kill them manually. There will be files in /usr/tmp whose names are backup and butc followed by the date. If the backup failed, they should be deleted. If it succeeded, they should be compressed and stored away in project.newdump, e.g.,

   cd /afs/sipb/project/newdump/last
   compress -c /usr/tmp/backup.960108 > backup.rann.960108.Z
   compress -c /usr/tmp/butc.960108 > butc.rann.960108.Z

The most common failure mode is:

   file\_tm: code = -1, errno = 5
   file\_tm: I/O error Writing data
   Error in receiving data
   butm: tape I/O error
   Dump volume-set-name.dump-level-name encountered an error

In this case, the tape should be marked ”bad”, a new tape should be inserted, and backup.pl should be run again with the same arguments. In general, it’s necessary to re-run backup.pl whenever a ”Dump ... encountered an error” message is obtained.

Write an entry on the tape package listing the date of the successful backup, the dump-level name, and username, e.g.,

   01-08-96 /rann\_2 paco

• After the backup of all the volume sets finishes, the AFS copy of the backup database should be updated. This is for safety, in case the local disk on hodge dies:

   rm -rf /afs/sipb/project/newdump/hodge/*
   cd /usr/afs/backup; tar cf - . | (cd /afs/sipb/project/newdump/hodge; tar xpf -)

This would usually be the time to unlog.

5.2 Webster

Currently there is a webster server on podge and snorkelwacker. Administrative details include:

A hesiod entry for “webster.sloc” which points to one (or more) webster servers.

/mit/dictionary points to /afs/athena/project/webster

It gets restarted at 4:33 every morning, to save on memory consumption.

There is an entry in /etc/ttys to restart it automatically in case it dies or is killed off.

Webster uses UDP-based Sun RPC as a transport. This means that there isn’t an /etc/services entry for it, the procedure number is compiled into the program.

(Much of this can be gleaned from project/office-machines or the sources, and you should look in both of those places to be really sure of the details.)

5.2.1 [Re]Starting the Webster Server

Verify that the symlink from /mit/dictionary exists and points to /afs/athena/project/webster.

Obtain root on the server.

Restart portmap by killing it and running /etc/portmap. This should cause websterd, the webster server daemon, to restart itself automagically. If it doesn’t, find a wizard.

Where did the dictionary come from? There are legends about this, but some one should know for sure. Note that it is not freely releasable.

5.3 Buying Stuff

The protocol for buying stuff is simple. First find good reasons why SIPB should purchace the item. Then convince SIPB members at a meeting and convince the head of IS that it’s worthwhile. A vote will then be taken at the SIPB. If SIPB and IS approve of the purchase, then it can be made using an MIT requisition form.

Small purchases, such as money for making copies of an Inessential document, require only a SIPB vote.

If a purchase is made without prior approval, that purchase will be considered a personal purchase by the individual.

5.3.1 Requisitions

Many supplies SIPB uses are ordered using requisitions. What you do is get the req book (talk to the Treasurer for the current location), take a look at some of the older filled reqs and imitate how it was done.

For a req less than 200, getanofficertosignit.F orareqmorethan200, get an officer to initial the req and send mail to Jane and Lorraine saying that you are going to go over there to get them to sign it (Lorraine Rappaport, ljr@mit, e40-321; Jane Trull, janej@mit, e40-315). After you have gone there, you can spend the money.

Projects

6.1 Documentation

The SIPB provides a variety of documentaion to users. Some we’ve purchased, some we’ve copied out of other manuals, and some are from

6.1.1 SIPB-Written Documents

The Board has written several introductory documents, all of which are given free to users who need them.

An Inessential Quick Reference to Athena is a one sheet manual that contains the least you need to know to use Athena. For more detail, see Getting Started on Athena, available at Graphic Arts for free.

The Inessential Guide to Athena provides a catalog of the less-publicized commands and capabilities of the Athena system of people who have learned the basics of Unix. This document is for more experienced Unix users. Beginners should refer to An Essential Guide to Athena.

Inessential LaTEX is a short guide to the more commonly used features of this typesetting system. Currently, LaTEX is one of the two supported text-processing systems, and the only one both powerfull and stable enough for thesis work. Athena itself provides several documents on LaTEX through Graphic Arts, and full manuals are available in the office.

Netnews: A One-Page Guide to the Usenet is intended to provide the absolute minimum information required to keep things working smoothly for users of the Usenet. For more details, you should see the newsgroup

news.announce.newusers.

How to Use xdvi is a short guide to using the program xdvi, which can be used to view DVI files such as those produced by LaTEX.

Discuss - Using Discuss is a guide to using Discuss, a networked electronic conferencing system. For more details, see the office manual under em Discuss.

Inessential AFS describes the Andrew File System and how it is used. AFS is a network file system or a distributed file system. This means that the files you gain access to through AFS do not actually reside on the workstation you are using.

6.1.2 How to Make More Documentation

If you want to write a new SIPB document, simply tell people (so as to avoid duplicating work, and possibly get suggestions) and start doing it. Once you’ve got a draft, /afs/sipb/project/doc is a good place to put it (usually in its own subdirectory.) Be sure to put draft copies around the office so that people “bleed” on them, ie. scribble on them with comments one what they think is wrong, poor, or badly typeset. (Don’t get discouraged by it – would you rather have thousands of users notice instead?)

Once a document is useful enough to be handed out to people, we need to make sure copies exist. Survey of in-stock documents is done during the “Documentation Report” section of the weekly meeting; if anything is critically low, someone volunteers to get more copies made. This involves estimating how many new copies are needed, getting a requisition filled out, having the Office of the VP of IS sign it (namely, Kathy Allen, though in theory anyone with signing authority can do this. [find out her real title!]), and then taking the originals (which are usually filed in the documentation drawer) and the requisition down to Graphic Arts and having them done. [Someone who has actually done this should expand and correct it.]

6.1.3 On Line Help

The Athena OLH system doesn’t actually contain any documentation, it only points off to other documentation subsystems. To put your document under OLH, let Sharon Belville (or the docsourc mailing list???) know about it, in particular give them a filename of a .dvi file that will stay around (preferably under /afs/sipb/project/doc/...) and they’ll weave it into their web.

6.2 Maintaining SIPB software

6.2.1 XScreenSaver

Included here should be collected XScreenSaver lore, such as The Athena 20 minute rule, and how we finally decided to put in code to recognize it. Various other flaming about it in the past (logging in particular.) Why is the RS/6000 special? (/etc/security, gid 7, HFT) What is the “xfree” program, and why did we need it? Why doesn’t xscreensaver use Kerberos?