zwicky@erg.sri.com (Elizabeth Zwicky) (05/30/91)
This is my "interesting questions" list. A previous version has appeared here before. I'm posting it again for two reasons. First, there are significant changes; new questions, new pieces of questions, new references. Second, I want to make clear my not very hidden agenda. This list started out as a suggested topics list for the LISA conference, and then got out of hand. It's still intended, among other things, as a list of things I would be overjoyed to get papers about. If you're thinking about writing a paper, and you don't know what about, something in here ought to turn you on. And if you find yourself seized by a burning desire to answer one or more of these questions, writing a paper might be a good way to do it, and find fame and glory in the process. (Well, moderate amounts of fame and glory, anyway.) A second article follows, containing the BibTeX format bibliography that this one refers to. "Proverbs for Paranoids, 3: If they can get you asking the wrong questions, they don't have to worry about the answers" -- Thomas Pynchon, {\it Gravity's Rainbow} KEY: A * marks a question that I think is about a paper's worth. People who appear in [] are working on things relevant to the question. Citations (\cite{foo}) refer to the work with that key in the BibTeX format bibliography - the works in question may directly address the asked question, but more often should be thought of as background. 1) Storing data. *A) Partitioning disks. Little partitions separate out different uses of disks; big partitions avoid some waste space. How do you decide where to draw the line? How do you balance loads between disks and controllers? Where do you tradeoff between manageability and efficiency? What are the issues you should consider when partitioning disks? (Some seemingly obscure things, like putting high-traffic partitions closer to the center of the disk, can have noticeable effects on performance.) B) Migration systems. Some users have a lot of data that they don't use much but insist on having around just in case. One way to deal with this is to provide ways to silently transfer files away from expensive, size-limited, but quickly accessible magnetic disk onto slower but larger and more extensible media, and transfer them back when they're looked at. Such systems exist, but usually require either major investments of money, or kernel modifications. *i) What options currently exist, and how do they compare? (References: \cite{muuss88lisa}) *ii) Supposing infinite resources, what should such a system really do? Can it be done without kernel modifications? How do you decide when to move files off line? Are vendors making the right assumptions about file usage patterns? Is there a single set of right assumptions, and what can you do if there isn't? What do you do about really long delays? How do you reclaim space on tertiary storage? *C) For convenience, the rest of this section is divided between backup systems (designed to restore data lost in the event of a failure of some sort) and archive systems (designed to save data for long periods of time). Current systems do not make this distinction well, so most sites use a backup scheme to provide a historical record of some sort, as well as for immediate recovery, and patch in a second system (or non-system) to deal with files that they know will need to be accessed in ways that the backup system doesn't support. For both backups and archives, assuming that a system has only the one purpose simplifies its design. Is this really a defensible assumption? Even if it is, where do you put the current historical uses of backups? Because we currently use our backup system to support some archive purposes, we keep some tapes for a very long time. We have needed those ancient tapes for purposes we did not forsee, and therefore have pulled off data which we would not have explicitly transferred to archives. D) Backups (References: \cite{hecht88lisa, harrison88alisa, parseghian88lisa, zwicky88lisa, montgomery89lisa, placeway89alisa, simicich89lisa, yashinovitz89lisa} Commercial products: BACKUP.UNET, Unitech; UBACKUP, Unitech) *i) Almost everybody has a locally designed backup system; there are also commercially available systems. There are no available source of information about what to consider when designing such a system, or what common pitfalls are. [Elizabeth Zwicky, zwicky@erg.sri.com] *ii) Any careful attempt to design a backup system reveals that the available programs which transfer data from filesystems into other forms have severe problems. There are now known serious bugs in every program (including dump) used for this purpose. We need a new one. [Steve Romig, romig@cis.ohio-state.edu] *iii) Techniques for reliably speeding up dump are reasonably well known. Now what do we do about restore? Is it worth speeding up, or should people who do a lot of restores use something else? *iv) How do you back up a terabyte? Suppose you have a migration system, with a terabyte or so of secondary storage, what do you do if the building burns down? *v) How do you test your backup system? Once the disk dies, it's a bit late to discover that you can't actually do the restore. *E) Archive systems. If a user comes to me and says "I have here 100M of data which I may or may not need to look at some time in the next 20 years," what do I do with it? 2) Security *A) What can you do when users have root? There are many situations in which it is simply impossible to take all root permission away from the users. What are the technical and personal measures you can take to let the users do what they need to without unduly compromising the security of your network? *B) How can you convince users to co-operate with security precautions? You can force them to choose good passwords; if you try hard enough, you can even pretty much not drive them mad in the process. But you can't forcibly prevent people from writing down their passwords, or giving them out to other people. How do you make security safeguards that are livable and comprehensible, and get people not to turn around and destroy them for their own purposes? *C) Trust in confederations. In many situations, systems with separate administrators are grouped together in loose confederations, where administrators on different systems are roughly peers, but need to work together. (For instance, two departments within a company may each have separately administered machines.) In such a situation, you can't force your confederates to be trustworthy, but you may nevertheless have good reason for wanting to share resources in ways that require trust. How do you negotiate that trust while remaining secure? *D) What tools are there for evaluating security, and how do they compare? *E) How do you decide how secure you need to be? Security measures all have costs, mostly in convenience. Therefore, you'd like to be as secure as you need to be, but not more so. Should you be worried about people tapping your ethernet? Should you get rid of .rhosts files in people's home directories? Who is it that you expect to be trying to break security, and why? 3) Adding machines to your network *A) How do you keep users from adding random machines to the network? When they do add random machines, how do you find the machines and deal with them? *B) Usually, you need to be willing to deal with all reasonable requests to add things. How can you tell which machines are reasonable to add to the network, and which aren't? Someone shows up in your office with a hyper-intelligent coffee maker that runs Mr. UNIX, and wants you to integrate it. Is it going to make the network explode or not? *C) How do you figure out what it costs to add a machine? Obviously, if you have 200 Suns, adding another Sun costs something (adds network load, uses server space, etc.), adding a VAX costs something more (now you have to support another architecture), adding a hyper-intelligent coffee maker running Mr. UNIX costs something more (now you have to support another architecture that nobody can help you with), adding a VMS VAX costs yet more (a whole new operating system, another networking protocol...) But just what are the costs? Some increase linearly; it takes roughly twice as long to compile a program for two different architectures as for one. Some of them are much worse than linear; NFS may be a great thing, but it isn't always the same, and you need to test every architecture as client vs. every architecture as server, giving you an order N! problem. *D) Once you know you have to add a machine, what do you need to do to integrate it? *E) How do you plan your network to make it easier to add things to? *F) What do you do when you need to increase the number of machines on your network by a factor of 2 or more? 4) Acquiring software *A) How do you determine what the administrative cost of a piece of software is? Programs differ in costs to administer, sometimes in obvious ways (for instance, they require complex and horrible printcap files, or a separate printcap for every user), and sometimes in unobvious ways (using mh for mail makes for vast numbers of small files changing every day, strongly biasing the pattern of file system usage). When you are evaluating software, where do you look for these costs? *B) How do you manage to install software, since vendor installation scripts tend to break things, or to fail? *i) What would a vendor install script that you didn't hate look like? *C) How do you select software to purchase? Given that users and system administrators tend to have different agendas in selecting software, what procedures and criteria can you use to make decisions that everybody can live with? *D) How much are you willing to pay for free software? Do you install it, just because it's free? If you do, how do you handle supporting it? 5) Monitoring usage A) Statistics used for fairness and charging purposes *i) Disk quotas. Berkeley UNIX systems come with a disk accounting system, but it isn't very effective. Many sites have their own accounting systems. What are the appropriate abstractions in such a system? Some quota systems look at file ownership; some look at position of the file in the file hierarchy. What do you do about tracking usage for multi-user groups or projects? How do you determine where quotas are set? Do you set quotas so that they total to no more than the available disk, and risk having users run out of quota before you run out of disk, or do you set them higher, and having users run out of disk before they run out of quota? Since disk space usage changes over time, how do you charge people for it? Who do you charge for it (users, projects, groups)? What do you do when they run out of it? Who gets to decide how much space people need, and what criteria do they use? How do you keep people from cheating? (References: \cite{zwicky89lisa}) *ii) Printer accounting. There is moderate vendor-supplied support for tracking number of pages printed on some printers. This is not sufficient for most people who want to do printer accounting. There are also other issues; on a PostScript printer, you may spend many hours of printer time to produce a one-page image. Do you start accounting for printer CPU? On a network connected printer, where random machines may send it jobs, how do you even do page accounting? *iii) Process accounting. Again, some versions of UNIX support some process accounting. Unfortunately, business usually want to charge projects, not people, and support for that is non-existent. How do you hack it in? (References: \cite{gray88lisa}) *iv) OK, so you've figured out how to track usage of printers, usage of disk, usage of CPU. How do you provide a single interface to all this data? *v) You have all the data you could possibly want. How do you charge people? Do you charge them for connect time, or CPU cycles, or something else completely? If you don't charge them based on usage, do you charge them a flat fee, or a fee based on availability, or what? *B) Statistics used for capacity estimation. It's easy to tell that you don't have enough network bandwidth, once you run out. How do you tell how much you have left before you run out? How do you know how soon you're going to run out of disk space? How do you know how many usable spare CPU cycles you have? (References: \cite{watson88lisa}) *C) Statistics used to track usage patterns for design and optimization purposes. When you go out to design a backup system, or speed up your network, or otherwise fiddle with things, you often need to know exactly what it is that people do with your system, and when. The sort of information you need tends to be different from the sort of information you need for charging people; for instance, you may need to know the number of files changed in a day, or the number of NFS reads as opposed to NFS writes that occur. How do you figure out all of these things? nfsstat will tell you about NFS traffic (once you figure out what statistics you want and where you're going to keep them and how you're going to analyse them), and if you happen to have sources to it, your backup system can be instrumented to give you information about what files are changing when. But you need to know what statistics are important, how to gather them, and how to figure out what they mean. *D) Statistics for communicating to users. System administrators generally have a vague idea what's going on with their machines. Users rarely have that much of an idea. How do you make available to them information that they can understand about what the computers are doing? *E) Performance monitoring. How are your machines doing, and is it getting better or worse? Are the users complaining because users are like that, or because something is really wrong? And where do you get cute graphs that management likes that show how you're supplying marvelous facilities to people? 6) Send in the clones. 100 identical machine are a lot easier to deal with than 100 different machines, and so are 100 mostly identical machines. But how do you get them that way, and how do you keep them that way, and how do you use their identicality to help you? (References: \cite{hillery89lisa}) *A) Turning chaos into clones; how do you create a cloned site out of individual machines? *B) Executing across multiple hosts. There are available programs that take a command and execute it on multiple hosts (for instance, gsh) but they tend to be highly site specific. How do you set one up for your site? Or, how about someone writing one that will work for a lot of sites without too much fiddling? C) A cloned facility needs tools to make machines look alike. *i) An overview of existing methods and philosophies for distributing changes between machines. (References: \cite{ladipo88lisa}) *ii) An improved version of rdist that would be widely available and applicable while implementing useful features like time-outs. [Slightly worked on by Tom Christiansen, tchrist@convex.com] D) When clones develop personality; how to deal with machines that are alike in some ways, but different in others. Machines are never quite perfect clones of each other, especially if they sit on people's desks. In many cases, the changes are encapsulated in pieces of files (for instance, printcap files that differ by default printer, or that have one printer local but all the rest remote). These are currently handled on a case by case basis at most places, with a program to take care of printcaps, and one to build rc.local files, and so forth. *i) Those case by case programs are in themselves of interest. *ii) A more general solution to the problem is also needed; how do you provide a flexible ability to customize files for multiple hosts? [slightly worked on by Elizabeth Zwicky, zwicky@erg.sri.com, separately by Steve Romig, romig@cis.ohio-state.edu] (References: \cite{hagemark89lisa, finkel89lisa}) 7) Users as abstractions *A) Creating user accounts; how to make an add user program. Unscientific surveys show that almost every site has their own add user program. There are good reasons for this, which are unlikely to change soon; what would be really nice is a comparative study of add user programs, suggesting what one ought to do in order to be secure, safe, effective, and flexible enough so that it won't have to be rewritten too often. (References: \cite{connelly88lisa}) *B) User information beyond the password file. Gecos field or no gecos field, the password file doesn't hold all of the information that you want about users. What other information are people using, and how are they storing it and keeping it in sync? *C) Removing user accounts. Creating accounts is comparatively easy. Removing accounts requires that you clean up all sorts of loose ends, and doing it from programs exposes you to all sorts of interesting problems (for instance, the operator who told the account program to remove an account which had / for a home directory). What are the technical and political pitfalls, and what can you do about them? [Steve Simmons, scs@iti.org] (References: \cite{foree89lisa}) *D) Making your users into clones. Users will persist in having personalities, and in expressing them in their initialization files. What ways exist to force them into some sort of regularity, and what are their pros and cons? [One system is being worked on by J Greely, jgreely@cis.ohio-state.edu] *E) In a site with multiple machines, user accounts need to be created across all machines in some co-ordinated fashiom. What are the benefits and drawbacks of the various ways of achieving this? Such systems include Sun's NIS (formerly YP), MIT Project Athena's ?Hesiod? and various site-specific methods. (References: \cite{hunter88lisa, curry90lisa, stolfa90lisa, urban90lisa, schaefer90lisa}) *F) It is often useful to co-ordinate user name assignment among a group of sites (for instance, across an entire university that does not have centralized computing resources). How do you do that? (References: \cite{phillips89lisa, doster90lisa}) 8) Users as people *A) Training users. Answering questions is all very well, but getting people to where they don't need to ask them is even better, and leaves you with more free time. How do you do that? [Bryan MacDonald, bigmac@erg.sri.com] *B) Users as customers vs. users as pond scum. System administrators are famous for a bad attitude about users (calling them lusers, for instance), but the users are also the people who pay the salaries. What attitude should we take towards the users, and how do we manage to have it and spread it? [Kevin Smallwood, kcs@houdini.cc.purdue.edu] *C) Making users happy without actually fixing anything. You can't always fix everything, especially if you're hiding from user lynch mobs. What are the non-technical tricks that allow you to make the users happier, thereby disassembling the lynch mobs, so that you can peacefully go about your work? *D) Should stupid users get stupid programs? People frequently complain about the difficulty of common UNIX programs, and want to replace them with easier ones for users who claim to be, or are perceived by administrators as being, incapable of using the normal tools. Is this a good idea? If it is, where do you find such programs? Can you find programs that are easy to use that also lead into normal UNIX tools? *E) Notifying users. How do you tell all the users the important things? Mail and news don't tend to get read. /etc/motd is hard to update if you have many machines, is only briefly visible if people automatically go into window systems, and is completely worthless if people don't log out regularly. (References: \cite{erlinger88lisa}) *F) Performance from a user's point of view. Users are forever complaining that things are too slow. How do you figure out what it is that makes them think that? There are certainly things that users can do in their environments to slow down the apparent speed of the system (like having a .login and .cshrc that end up pulling in 5 files, totalling nearly 10 kilobytes, much of it repeating the same actions, undoing them, and redoing them). Where should you look for these? If it turns out that the user simply has expectations that are too high, how do you reset them? 9) Training system administrators *A) What is the career path for system administrators? Where do they come from and where do they go? *B) What do you do with new system administrators once you've got them, that gives them information without risking damage to your site? (References: \cite{christiansen89lisa, simmons90lisa}) *C) What resources are out there for people to learn from, particularly from other fields? (For instance, people have suggested a reading list including such things as "Search for Excellence", and "The Mythical Man-Month") 10) What do system administrators do? *A) Just what is the point of all this? Are we trying to make existing machines run? Are we trying to provide some level of service? To whom? *B) How are system administrators like and unlike user support people, system programmers, and so on? *C) How do you explain to managers what system administration is like; why it can't be managed the same way that research programming can, why it is difficult and takes trained people who get paid real money? *D) Towards a philosophy of system administration. How do you build a framework in which to make decisions about administering systems? What sort of overall guidelines and decisions do you need, and why? (References: \cite{hayes88lisa, kint89lisa, hillery89lisa, smallwood90lisa}) *E) How do you evaluate whether or not system administration is being done well, in a way that you can communicate reliably to management? 11) Centralization vs. decentralization *A) How do you figure out where to make the tradeoff between the economies of scale and administrative advantages of centralizing things like disk space and printer service, and the fault tolerance and individual control of distributing them? *B) What administrative functions must be centrally controlled, and which ones can be safely handed out? How do you make central organization in a group with no center (for instance, trying to share a network between projects, where somebody has to administer network addresses, but nobody has authority over anybody else)? 12) Working together *A) How do you administer sites that are physically remote? (References: \cite{zadrozny89lisa}) *B) As a large site, how can you deal with associated tiny sites? If you admister 300 machines in one place, and 3 in another, how do you come up with a system that copes with both? *C) How can you make a confederation of administrators within an organization, and what can one do for you? [Mark Verber, verber@pacific.mps.ohio-state.edu] 13) Are those apples treated with Alar? Motherhood and apple pie reconsidered. *A) Are policy free tools possible, or even advisable? Is it really better to give people the ability to make their own stupid policies easily, or to give them tools that implement intelligent possibilities with a few degrees of freedom? 14) When things break *A) Hack it, or track it? When you run across a problem that has a fix, do you apply the fix even if you don't yet understand the problem, or do you attempt to track it down even if that means leaving things broken? Obviously, rebooting the machine will fix a lot of problems, but sometimes it will keep you from figuring out the bug and reporting to the manufacturer and getting it fixed forever. *B) 24 hour support; do you provide it and if so how? Are beepers evil? Programmers are famous for working at all hours of the night, which is all very well for them, but if you have to deal with a whole bunch of them, they might want help at any hour of the day or night. Most system administrators want a life of some sort; how do you get one while keeping the users happy? *C) 20 questions to ask users when they report a problem. So a user calls you up and says "Mail doesn't work." What do you ask them? *D) You have found a problem. You know how to fix it. How do you install the fix in such a way that you don't undo it later? What should you do with the fix besides install it? Tell your vendor? Tell other people? How? *E) You buy a program. It doesn't work. You call phone support. The person on the other end of the phone line says "Well, are you sure your Ethernet works?" or "Why don't you just turn off YP?" or any of a thousand other questions which reveal that they think you own a machine or two which you can modify at the drop of a hat. How do you convince them to change their mindset? 15) Making changes *A) How do you help users adjust to changes? You can't run V7 on a PDP-11 forever; at some point, the users are going to have to change hardware and software platforms. How do you reduce the trauma? *B) When is it time to upgrade? Folk wisdom says "never install an even release", and self-preservation suggests that switching your entire site over to a beta release is not a good idea. But there is no release without bugs, and at some point you're going to have to decide to live with it. When? For that matter, when is the pain and expense of upgrading your hardware platform outweighed by the pain and expense of keeping the old one? *C) Beating swords into plowshares versus buying tractors. Most system administrators are virtuosi at the UNIX philosophy of combining together old tools with baling wire and string, which is cheap in some ways, and gives you that warm glow of accomplishment. On the other hand, there's a lot to be said for throwing out the old and doing something new. When do you decide that you should stop trying to coerce the old operating system (name service, printer system) into working and design a new one from the ground up? *D) How do you manage to keep local "improvements" and still be able to change with the rest of the world? So you rewrote the printer system (or you wrote an adduser program, or you made talk(1) work on everything). And then you bought 10 new machines, 2 each from 5 different hardware vendors, and all your old vendors released new OS versions. What makes this not a really good time to become a carpenter? *E) Justifying the expense. It may be obvious to you that life would be much better if you had more than 4 M of real memory in the Sun 3s that everyone wants to run Sun OS 4.1, OpenWindows, and 5 copies of emacs on, but how do you make it obvious to the people who spend the money? 16) Electronic communication *A) Usenet; how do you control your users and your disk usage without being (too much of) a fascist? *B) Mail *i) Compare and contrast the various methods of getting all the mail for a site to deliver to one place. Among these methods; NFS mount /usr/spool, use aliases or .forwards everywhere to deliver mail to one machine, or one machine per user, deliver mail to home directories, automount /usr/spool/username for every user. (References: \cite{phillips88lisa}) *C) When you have groups of users who want to talk to each other, should you encourage them to use mail, or newsgroups, or something else? Mailing list maintenance is a nuisance, and large mailing lists spread traffic out all over the place. But people are more able to ignore news, and therefore may lose track of important messages. 17) Testing *A) You install, reinstall, or upgrade a machine. Without using users as test suites, how do you know it works? *B) You have NFS, or NIS, or Kerberos, or X Windows implementations from many vendors. How do you figure out where they do and don't work with each other? 18) Documentation [A & B both worked on by Elizabeth Zwicky, zwicky@erg.sri.com, and Mark Verber, verber@pacific.mps.ohio-state.edu jointly] *A) What documentation should you produce for your site, aside from that shipped by vendors? What available documentation is out there to give to users? *B) What tools are there to make producing user documentation easier? C) On line documentation as implemented by the man pages and the man command is pretty painfully bad. *i) So you have 18 sets of manual pages, for 18 slightly different operating systems. Then you have another few hundred manual pages that didn't come with the operating system. What on earth do you do with them? (References: \cite{braunsdorf90lisa, christiansen90lisa}) *ii) What can we do about the concept? People ship manual pages in troff format, which is so entrenched it's probably unavoidable. But now more and more systems don't have troff, anyway. Then there's texinfo, which really wants Gnu Emacs and TeX both... Neither system accomodates illustrations reasonably. What is a poor system administrator to do, that provides a good user interface, a reasonable author interface, and compatibility with the documentation that people ship? 19) Little machines become big problems *A) How do you make the PCs talk to the world at large? You need to connect them to big networks, and provide services to them somehow. But it's a very uneasy alliance between PC programs designed for little networks, and protocols designed for big networks. How do you make the connections work smoothly? (And has anyone every met a Mac mail program they actually like? The users liking it doesn't count if the administrators hate it...) *B) What do you do with the users who stare mistrustfully at the high-powered workstation on their desk and say "But the Apple II I have at home is so much nicer"? How about the "real machine" wars, where the UNIX users make snide remarks about fixing the PCs by dumping them for *real* machines, and the PC users make snide remarks about how much more popular PCs are and how their PCs never crash ("Neither does my clock radio," mutters the UNIX wizard, and then things get really nasty). 20) Parcelling out the CPU cycles A) How do you let users make use of spare CPU cycles anywhere in the network, without giving them non-spare CPU cycles? *i) In a workstation environment, users coming in over a network, instead of logging in at consoles, need to be distributed easily between machines. How do you do that? How do you mediate between users coming in over the wire, and users at the console of the machine? ii) Single jobs may also want to be distributed, either by *a) using an entire network of machines as an extremely coarse-grained parallel processor or *b) using a more powerful or less loaded machine elsewhere on the network. Facilities for doing the latter exist, certainly; I'm not certain there is even any help for doing the former. How do the available facilities compare? How do you assist people in making programs work in these situations? *B) How do you deal with batch jobs under UNIX? (References: \cite{harrison88lisa} Commercial products: UQUEUE, Unitech) 21) Watching users *A) Users with questions are often unable to adequately describe what they are doing and what the machine is doing in response. What facilities are available for connecting to what they are doing to watch and assist? *B) How do you keep an eye on suspicious or malicious users? 22) The printer system (Commercial products: UQUEUE, Unitech; Qprint, Xi-software. Other available products: PLP, something beginning with a P that Posix is contemplating standardizing on)(References: \cite{placeway89lisa}) *A) Remote printing; you don't always want to print to a printer attached to the machine you're on. If you're on a machine that uses the Berkeley line printer system, and you want to print to a printer driven by a machine that also uses the Berkeley line printer system, and either a) your machine is in that machine's hosts.equiv file or b) that machine runs a relatively recent version and you are in the hosts.lpd file, then all you have to worry about is keeping the printcap files right, making certain that the permissions for lprm actually work right, and worrying about maximum job length issues (including explaining to users why you cannot use symbolic links when printing to a remote printer). Or, in other words, you can't always even try to print things remotely with the software supplied with your operating system, and when you can it isn't very much fun anyway. (References: \cite{goldberg88lisa}) B) At SRI, the printer-control programs generate /etc/printcap files (plural intentional, different machines have different printcaps), used by lpd; /etc/imagen.df and /etc/imagen.db, used by Imagen, err, QMS, printers; .pr files, used by Interleaf; /etc/appletalk.rc, used to do Mac printing to UNIX printers; /etc/cap.printers, used to do UNIX printing to Appletalk printers; .param files, used by NeWSprint; and printer.info files, used by Wingz. i) This is not how life should be. What can we do to make companies stop this? I can hardly buy a printer or a piece of software without having to twiddle my software to produce some new control file... *ii) Given that you have to produce 7 different kinds of files today, and may need 8, 10, or 437 next week, how do you handle your printing environment. (Both Ohio State and SRI have programs in use - actually, both sites have simple ones existing and more complex ones in progress.) *C) Just what exactly should a printer queuing system do for you? 23) When users get together; handling sets of users. *A) Users working on projects together tend to come in relatively fluid arrangements. Yet they need to communicate with each other, usually via mailing lists or newsgroups, they may need to share files with each other via groups, and they may need centralized disk space for the project. How do you provide the sort of immediate access to changes (adding and removing users, for instance) that projects need? Can you let the users do it themselves, and if so how?