|
Consulting GuideFall 2001 EditionComputer Science Staff Computer Science Department Harvey Mudd College Claremont, California ABSTRACT
This paper attempts to acquaint the UNIX ® consultant with the work, what needs to get done, and how to do some of it. It is by no means complete and therefore it does not set the limits for the responsibilities of the consultant. Consultants also should be familiar with the material in UNIX--The Basics.This document is available in postscript form in /staff/etc/consultants/consultant_guide.ps Outline of this DocumentConsultant DutiesThe primary job of the consultant is to assist users--to help them get the most out of the UNIX systems as they do their work. At the same time, the consultant is placed in charge of the systems. He or she is responsible for seeing that the department's computing facilities are not used improperly. Reasonable actions taken by consultants in meeting this responsibility will be backed by the department. With this dual role, the consultant may be viewed as a ``benevolent dictator.''Helping PeopleThis is the most important part of being a consultant. If you see someone having trouble with something, offer help. Don't wait for that person to come to you. Whenever possible, refer someone to the man(1) command or to the appropriate reference book. Both of these can be very helpful if one takes the time to read them. Once they have the proper documentation, encourage them to figure out some more things themselves. Never give an answer without a reason for why your solution works or an explanation of what it does.Always be courteous and polite when talking to people. Many people get on edge when working on a computer assignment, and a lot of them are probably not having a lot of fun. Try to be quiet and not hog terminals, cpu's, the printer, etc. Learn how to use the operator program. The best way to do so is to ask somebody who already understands the program. Descriptions of the available commands are given later in this guide for reference. Never kill anybody's job unless they ask you to do so, or it is obvious that they did not intend to leave it running. Whenever possible, show them how to kill the job themselves using the commands ps and kill pid. (Note that the more stubborn jobs will require kill -9 pid.) If you have a user that needs many processes killed, you may wish to see the man page for kill(1). The same guidelines apply to print jobs. You may want to see lpstat(1) and cancel(1) on turing. Be sure you know how to specify the proper printer queue.
As a consultant, you really should know how everything on the system works, but for starters (not necessarily in this order) learn about:
The Terminal RoomTerminal UsageDuring peak hours, one of your most important duties will be monitoring terminal usage and enforcing the terminal priority policy. Throughout your shift, be aware of what users are doing -- the w(1) command is useful for this. If somebody walks into the terminal room to do some serious work and all of the terminals are in use, be ready to throw out anybody with a lower priority--game players, news readers, web users, and telnetters to non-CS department machines have lowest priority. If the terminal room is crowded, be sure that all the usable machines are on.If you see someone with very much idle time (i.e. greater than a day or so) and you are unable to talk to that person, try to determine if the user has any processes other than a login shell (use ps and grep for the terminal name (ps -ft pts/8)). If not, kill them off using operator (described later). If they have some important-looking processes, let a staff member know about the problem. If a terminal has been locked for more than fifteen minutes, and users are waiting for a terminal, feel free to use the ``public logout'' button. However, save this for a last resort if there are not any other terminals available. The terminal usage policy is as follows:
Cleaning UpNobody likes a messy terminal room. At some point in your shift, place leftover computer paper in the reclamation box and waste of other sorts (paper, pizza, sleeping CMC'ers) in the trash can. Abandoned stuff can be placed in a neat pile on the floor in front of the room. Thanks. Also, push chairs in, and put away CS department books. Keep things neat.Also check to make sure that the laser printers still have paper. If it runs out, there should be more in the graphics lab. Make sure you know how to put new paper in the printer and how to change the toner cartridge. The cartridges should not require frequent changes. If you find evidence that any particular user has left a mess, or if any user refuses to cooperate with your efforts to keep things running smoothly, send mail to staff. We'll add the person to our hit list and take whatever action is appropriate. In severe cases, users may be removed permanently from the system. Also, at the beginning of your shift, make sure all of the terminals are functioning. If you don't know how to use the terminals' Setup feature, ask a consultant or staff member who does. The proper settings are listed in Section 2 of this guide. Other DutiesThere will be a checklist of consultant duties posted on the billboard in the large terminal room. This list will most likely be more current than the consultant guide. If you have any questions about the duties listed, send mail to staff.The TelephonesStaff members occasionally receive calls from technical support reps on the terminal room line, so please answer the telephone in a reasonably professional manner -- ``Computer Science,'' "terminal room," or ``consultant'' is appropriate. Messages may be sent to staff members via e-mail. The intern may receive calls when s/he is out of the office, which you should answer and leave a message on one of the postit notes or through e-mail. If the phone is for a user, check if they are in the room or in the graphics lab. If the phone is for someone who isn't in the room, finger(1) that person to see if they are logged in from one of the other labs.The terminal room phone has local access. To use this, dial 9 first, and then the phone number. There is a phone book there which should not be removed. Work on ProjectsFinally we get to the fun stuff. Most of you should have a project of some sort. If you have problems with what you are working on, just ask one of the system staff for help (sending mail is usually an effective way to reach us). These projects are meant to be a learning experience for you as well as being something useful for the system. If you're not having fun with your project and would rather do some thing else, let us know.There is a list of projects which can be found by using request(1). If you see an unassigned project there which you would like to work on, assign it to yourself. That way, staff knows what you are doing, and we don't have multiple people working on the same project. Generally requests of priority 4 are intended for consultants. The /proj directory is available for consultant projects. Only files associated with your project should be stored in your projects directory, and staff reserves the right to snoop through it at any time. Please keep all your other stuff in your home directory. Filling Out TimesheetsDon't forget to get paid! Timesheets are available from the C.S. department administrative assistant, in Olin 240. (Hours are posted outside the door.) Timesheets are due every other week, work-study by Wednesday afternoon and regular by Thursday noon. All new consultants must fill out the standard batch of paperwork to be added to the payroll as soon as possible after being hired. See the administrative assistant for information. Try to make sure to get your timesheet in on time. Below is a quote from a Financial Aid memo.The hours reported should only correspond within that certain time period. Back pay is subject for review and the student may not receive pay for the previous period they worked. Students should also keep in mind that they may not work for over 8 hours in one day and no more than 20 hours per week. SecurityBecause of the special privileges granted to members of the operator group, you should be especially careful not to give anybody access to your account. Don't forget to use the lock function whenever you must leave your workstation. (This is on the button bar in the lower right hand corner of the screen if you are using a default setup. It is the lock icon on the lower left in Gnome.)Terminals should be locked in general if the user is going to leave the terminal room. If you find an unattended terminal with someone logged in, send them (CC it to staff) a copy of /staff/etc/logged_in.msg and log them out. To assist in finding unlocked terminals, staff has created the script idleusers. Note that the output of this script may not be completely accurate. Common ProblemsThere are questions and problems that repeatedly come up. Here is a compilation of some them.Logging In and OutWhen people have trouble logging in, verify that they are using the correct case. Remind them that UNIX is case sensitive. This will happen often to first-time users as the initial password may contain both upper and lower case characters. Remind new users to change their passwords to something they can remember but not too easy for someone else to guess. (Lessons learned from the Internet worm are not to use words that can be found in a spelling dictionary or variations on the user's real and user names.) Users should have received a policy sheet which specifies what type of password to create. (Login names are always lower case. If a login name is typed in all caps, the system will assume that your terminal can handle only caps--this problem will be apparent if it displays everything in caps, and may be fixed with stty -lcase.)The common problem with people logging out is stopped jobs. Show them how to properly handle jobs in the background. This usually happens to VMS users who are accustomed to using ^Z to exit a program. If a user cannot login to an X terminal, look at .xsession-errors in their home directory to determine if and where their .xinitrc is failing. Make sure that the last program executed by .xinitrc is not run in the background. C++ ProgrammingThe standard C++ compiler on turing is GNU g++. The binary is located in /usr/local/gnu/bin, so C++ programmers need this in their path. G++ can be pretty verbose with error messages. If you want to pipe these through more(1) or less(1), you need to use ``| &'' instead of just ``|'' in the C-shell. Usually fixing the earlier errors will eliminate many of the later ones.There are several source-level debuggers on turing. The GNU debugger gdb(1) is probably most useful for C++ programs. Compile with the command-line option -g to create a debuggable executable. Note that compiling with -g makes the executable much larger. groff/nroff/troffAgain, a common mistake will be due to UNIX being case sensitive, so watch out for commands having the wrong case. Also make sure that the dot (.) commands are at the beginning of lines, no spaces before.Spaces at the beginning of any line will cause a ``break,'' resulting in a new paragraph. It is usually desirable to use the appropriate macros (.PP, .LP, .QP, etc.) to begin paragraphs, as these handle spacing and indentation automatically. Blank lines are kept in the formatted output, and they also cause breaks. If the user is using one of the macro packages, make sure it is properly specified, either using the -mname command option or by including ``.so /usr/lib/tmac/tmac.name'' as the first line of the file; name is usually s or e. If one or more the preprocessors ( pic, tbl, etc.) is being used, check the pipes and various redirections. It's easy to have them out of order or pointing in the wrong direction. Grog(1) will search through a -roff source file and suggest a command line which should apply the appropriate preprocessors and load the proper macro packages. Finally, don't forget about programs that help find mistakes like checknr and checkeq. The TerminalsOccasionally someone gets too ambitious and changes the terminal settings. This can wreak havoc for other users. The simplest fix is to reboot the terminal (on the NCDs, use the setup key to get the console menus). If one of the NCDs is sitting there with an X cursor, but no windows or chooser, select logout from the console menus.If someone's xterm seems stuck, try ``control-Q''. What happens is that ``control-S'' is the XOFF commands, which tell the machine to stop sending to that terminal. It is quite easy in some editors to accidentally type ``control-S''. Telnet and ServersUsers who use the servers or ssh (from the ``other department'') might complain that they can't run emacs or some similar program. The problem is usually due to turing not knowing what terminal they are using. Show them how to use setenv TERM termtype, where termtype is the appropriate terminal type (usually vt320 or vt220 or vt100), and tset. Look at the .login file in /etc/skel, There are two lines in the ``find out what is the term type'' section, that will query a terminal as to its type. setenv LINES 25 and setenv COLUMNS 80 will fix window-too-small errors which occur when using the AC PC Lab.MatlabMatlab, a math program, tends to eat up lots of resources on turing. Because of this, we've auto-niced it to 19 (see the policy on long jobs). If someone comes to you with a valid reason to run Matlab not niced, they can do this by running matlab.old or running matlab directly from the binary in /usr/local/matlab/bin/matlab.Weird editorsEmacs is just one of several text editors available on turing. Users occasionally may find themselves in strange editors due to mistyped commands. Here's how to get out of them (the caret: ^ indicates a control character)
|