martyz@idui1.csrv.uidaho.edu (Marty Zimmerman) (06/17/91)
Any tips for setting up Macs (LCs in this case) on a network in a student lab? As far as I know, there is no way to have them boot from the network, but I would like to convice them to read their system folder from the net to speed things up a bit. Any advice in this area will be greatly appreciated. The hardware: 10 Mac LCs with Ethertalk adaptors. The server is currently a Mac IIfx, but will eventually be a Mac IIci. We can use either System 7 or 6.0.7. -------------------------- Marty Zimmerman <martyz@idui1.csrv.uidaho.edu> Computer Services <martyz@idui1.bitnet> University of Idaho Moscow, ID USA
datta@vacs.uwp.edu (David Datta) (06/18/91)
In article <1991Jun17.165139.575@groucho> martyz@idui1.csrv.uidaho.edu (Marty Zimmerman) writes: >Any tips for setting up Macs (LCs in this case) on a network in a student lab? Have fun, I installed a lab full of MAC SE30s last year, here is the results: You cannot make the mac boot from the network or use system files from the network. I have bitched and moaned to our apple reps and they finally told me, "you can't do it, period." (after much hemming and hawing.) Be ready to re-install about 2-3 machines a week unless you hide and rename the system folder. If the lab is in a public access area, things will be erased on a regular basis. Lock all of the files in the system folder that you don't want messed up, (I.E. EVERYTHING) put gatekeeper and gatekeeper aid on all of them and lock out the disable buttons. Modify the control panel so that none of the settings will work. (Leave the buttons for the values you want things to be active so you can re-set them if someone boots from their own floppy.) Don't install neat things such as kolor. You will find that wise-ass students like to change EVERYTHING to the same color so you can't see anything. Many packages that advertise "networkable" aren't, ask for a preview copy before buying 10 licences for your favorite package. If you keep software on the hard disks, be prepared to have it erased by students who are trying to install their favorite game that "won't fit" because of the stuff you installed. Keep a master backup of the hard disks, it is usually easier to configure everything the same and if someone messes something up, to erase the hard drive and start over. We keep an image of the hard drives on the server (in a folder that users cannot access) and boot the machine with a clean system disk when things get messed up. Be VERY aware about software incompatibilities, in the last few months, we have had students installing Sound Master and other things that eat up the RAM and make other programs not work. (Also it is recommended to turn off RAM cache from the control panel, some packages don't work with it.) -- -Dave datta@vacs.uwp.edu. So, are there any words that rhyme with orange?
zben@ni.umd.edu (Ben Cranston) (06/18/91)
In article <13187@uwm.edu> datta@vacs.uwp.edu (David Datta) writes: > You cannot make the mac boot from the network or use system files > from the network. Actually you can. Since it is a commercial product and I was one of the three people who developed it, I probably shouldn't say too much about it on this non-commercial medium. One of us did a ROM that fits onto an Apple/3Com or Asante ethernet card. This ROM get control early in the boot process and carves out a RAM disk. Then it does a BootP to get a boot file name and a TFTP of the file into the RAM disk. Then the boot continues with the RAM disk as the boot disk. The user gets a perfectly writable system on the RAM disk that goes away the next time the system is booted. Disadvantages: the RAM disk costs memory and System 7 is *MUCH* bigger than System 6. You end up with two copies of the System in memory, one on the RAM disk and another in real executable memory. For each byte the system is bigger, you lose two bytes. My personal feeling is that it should be possible to switch-launch over to a read-only copy of the system on a server at some point during the boot process. You would have to remove all the desk accessories and things that try to write the system file (chooser, monitors, etc) or patch out _Write to ignore write errors on the system file. You would have to figure out how to get "preferences" back onto writable medium, perhaps with a patch to the Folder Manager. Perhaps I should make the final point that there will be a quantum differance in practical experience and expertise between people who "installed a server last month" and people who have been running servers for the last five years... Ben Cranston <zben@ni.umd.edu> University of Maryland at College Park And, as of Friday, KA3ZDF -- that's Kilo Alpha Three Zulu Delta Foxtrot!
Brian.V.Hughes@dartmouth.edu (Brian V. Hughes) (06/18/91)
In article <1991Jun17.165139.575@groucho> martyz@idui1.csrv.uidaho.edu (Marty Zimmerman) writes: > Any tips for setting up Macs (LCs in this case) on a network in a student lab? > > As far as I know, there is no way to have them boot from the network, but I > would like to convice them to read their system folder from the net to speed > things up a bit. Any advice in this area will be greatly appreciated. This would be a great idea, but I don't believe that it is possible. I worked for a while in a lab pretty much as you are descibing, but we had one of every type of Mac on our network, which is a subset of the main network here at Dartmouth. We had one major piece of software that saved us coutless ours of having to deal with problem users scewing up the hard drives; FILEGUARD. Purchace a 10 pack for the lab and install it on each of the LC's. It will allow you to completely control the access that the students will have to every piece of the hard drive including the system folder. It is an absolute lifesaver. I also strongly recommend, as did someone else, that you keep a backup of the main contents of the hard drives in a locked folder on the server. > The hardware: 10 Mac LCs with Ethertalk adaptors. The server is currently a > Mac IIfx, but will eventually be a Mac IIci. We can use either System 7 or > 6.0.7. The server probably won't really matter, as long as you have sufficient disk space for everything that you want to keep there. If you have the Ram for the LCs I would recommend using Sys 7.0. It will allow you to customize other aspects that you can't do as easily in 6.0.7. For instance you could set up a standard list of aliases that access folders, applications and documents on the server and install them in the apple menu folder of each of the LCs. This is the direction that I would go in if I were starting from the ground level as you are. Later. -Hades Brian Hughes hades@Eleazar.Dartmouth.Edu Dartmouth Medical School - Computer Information Specialist
dnebing@bgsuvax.UUCP (David Nebinger) (06/19/91)
From article <13187@uwm.edu>, by datta@vacs.uwp.edu (David Datta): > In article <1991Jun17.165139.575@groucho> martyz@idui1.csrv.uidaho.edu (Marty Zimmerman) writes: > > Be ready to re-install about 2-3 machines a week unless you hide and > rename the system folder. If the lab is in a public access area, > things will be erased on a regular basis. > Some applications need things to be in the system folder. > Lock all of the files in the system folder that you don't want messed > up, (I.E. EVERYTHING) put gatekeeper and gatekeeper aid on all of > them and lock out the disable buttons. > The Macintosh is a computer that is made to suit the user. A lot of work has been done to make the Macintosh one of the best computers there are. Don't make that work worthless by destroying the very things that make the Mac popular. > Modify the control panel so that none of the settings will work. > (Leave the buttons for the values you want things to be active so you > can re-set them if someone boots from their own floppy.) > Modifications to the control panel further destroy the Macintosh's appeal. > Don't install neat things such as kolor. You will find that wise-ass > students like to change EVERYTHING to the same color so you can't see > anything. > Why hold the actions of a few against the many. Some bad apples (excuse the pun) do exist. Instead of not baking the pie because you have one bad apple, just remove that apple. Our computer lab has tried many things to "lock" down the Macs that we have. The fact is that there is no good way to do so. Anyone who has a boot disk can overrun almost any security that you might set up. Our lab uses MacTools to do many things with the systems; they must not understand that it is available to anyone who wants to buy it. MacTools can do a lot of good things to a personal hard disk, but if one wants to totally screw things up, it is an easy matter. The soft partitions created by the Partition DA can be made visible, unlocked, and then deleted. And to try and "hide" the system folder is also a worthless idea. Apple File Exchange can see the hidden folder, and once again, if you have a bootable floppy, you can put working versions of the system back for those that were locked before. What everything boils down to is that the typical sys-admin person will try to make the machine "quasi-untamperable". This is typically the wrong approach to setting up a lab. Any defaults you set can be changed by a student who really wants to do so. A much better approach would be to teach everyone about the Mac. Not just how to run MacWrite or some other applications, but also the finer points. There is a big argument right now about the help balloons in System 7. It must be obvious to the developers that even though people can be taught about there favorite applications, they would miss out on the really nice things that go along with the Mac. If time were spent showing the novice user how to handle a Mac no matter what it looks like or how it is configured, the argument dealing with the protection of the Mac from the novice would disappear. It is not a request that is far-fetched, either. Most of the computers in our labs are Macs; more students use them than the Big Blue. If they can be shown the Mac to it's fullest now, the Mac will eventually start to look better to the business world than it does right now. The Mac can be a very capable business computer. It's ease of use far outweighs that of the IBM. If the students were educated in it's finer qualities now, they would carry the desire to use the Mac to their future carreers. At this point you can take this other man's advice and lock everything down, condemning yourself to reconfiguring the "tampered" machines every week, or you can spend a short period of time now educating your student users about the Mac's through and through. The first may seem easier, but the latter will save a lot of time later. You will still have to do the reformatting occasionally, but if you can find your bad apples, pluck them off the tree before they can infest others. This is logically the best solution. Though I can not make the decision for you, I hope you will take heed to some of the things I have said. David Nebinger dnebing@andy.bgsu.edu
rand@merrimack.edu (06/19/91)
In article <1991Jun17.165139.575@groucho>, martyz@idui1.csrv.uidaho.edu (Marty Zimmerman) writes: > Any tips for setting up Macs (LCs in this case) on a network in a student lab? There are two things on the net you might want to look at. InitShare--lets you stick a bunch of inits a a fileserver and have them run by those macs with the InitShare init. VolumeImage--lets you keep a mirror of what you want a disk to look like on a file server. Run VolumeImage and it does a DIFF, only refreshing stuff that's been changed deleted or moved. pretty flexible...
rand@merrimack.edu (06/19/91)
In article <7621@bgsuvax.UUCP>, dnebing@bgsuvax.UUCP (David Nebinger) writes: > From article <13187@uwm.edu>, by datta@vacs.uwp.edu (David Datta): >> Lock all of the files in the system folder that you don't want messed >> up, (I.E. EVERYTHING) put gatekeeper and gatekeeper aid on all of >> them and lock out the disable buttons. >> > What everything boils down to is that the typical sys-admin person will try > to make the machine "quasi-untamperable". This is typically the wrong > approach to setting up a lab. Any defaults you set can be changed by > a student who really wants to do so. I think you're missing the point here. You `tamper-proof' a workstation so the naive user doesn't screw it up--not to keep people from playing. In any event, by taking these measures you have made it necessary for people to HAVE to try to screw it up INTENTIONALLY. At our school we've strictly defined that this is a no-no and the 'rents will be disappointed that you got your butt kicked out of school. > A much better approach would be to teach everyone about the Mac. Not just > how to run MacWrite or some other applications, but also the finer points. Ideally. We don't have the human resources to do this, does anyone? Techies (of which I am one) often forget that not everyone needs to know what TrueType is. Does your wife know what a MacPherson strut is? She just wants to get herself from point A to point B--just like me. I'm going to get $9,900 worth out of my $10,000 car. The rest isn't worth my time.
ramdas@buitc.bu.edu (Ramdas Rao) (06/19/91)
In article <1991Jun17.165139.575@groucho>, martyz@idui1.csrv.uidaho.edu (Marty Zimmerman) writes: |> Any tips for setting up Macs (LCs in this case) on a network in a student lab? |> |> As far as I know, there is no way to have them boot from the network, but I |> would like to convice them to read their system folder from the net to speed |> things up a bit. Any advice in this area will be greatly appreciated. |> A couple of months ago, we did some research into setting up a public access Mac lab. We also were interested in having the Macs boot over the network. What we found was a product called, BootToob. Here's the info on the company. Mauswerks 1242 Neil Ave., Suite J Columbus, OH 43201 (614) 294-7300 What this product requires is that client Macs be Mac IIs (or one of the new Macs with a NuBus adapter) with a NuBus Ethernet card and at least 2 MB RAM. For the server, any Mac or UNIX machine with BOOTP will do. A BOOTP init for the Mac is provided. The product is a firmware and software solution. For each copy (I believe the list price/copy is $139), you get a ROM chip and software. The ROM replaces the ROM on Apple and Asante Ethernet cards. An included application is used to configure the Mac for remote booting as well as configuring the server on the net. BOOTP is used for the booting process, so, you could have a UNIX machine be the server. What the client Mac boots is an image of the system (and applications, if configured so). It is recommended that you limit this image to below 2MB. The RAM on the client becomes a RAM disk and the system is run from there. So, whatever the difference is between the RAM in the client and the image size is the amount of memory available to the user's application(s). In our implementation, we decided that the image would contain only the System s/w and the applications would be accessed from an AppleShare volume (either by inits in the System folder or manually by users). This made the image size about 1 MB in size. The clients took an average of 2 minutes to load this image and boot up. While the Lab has not as yet been set up, we decided that this would be the option we would choose instead of having local hard drives with various options for protection. |> The hardware: 10 Mac LCs with Ethertalk adaptors. The server is currently a |> Mac IIfx, but will eventually be a Mac IIci. We can use either System 7 or |> 6.0.7. |> |> -------------------------- |> Marty Zimmerman <martyz@idui1.csrv.uidaho.edu> |> Computer Services <martyz@idui1.bitnet> |> University of Idaho |> Moscow, ID USA Once the client has booted, the Ethernet card is available to applications as a standard interface. This means that things like, NCSA telnet can use the Ethernet interface. So far, it sounds like everything you want right? Well, there are a couple of small catches, but, we didn't think they were big enough to prevent our use of this product. One of the problems, as mentioned earlier, is that it takes the client about 2 minutes to boot up. There was mixed opinions about this. A second problem is that the configured boot information can be altered if the Mac is booted from a floppy disk with a System file on it. This floppy would have to be inserted before the client booted from the server. What happens is that the Mac boots off the floppy and changes the PRAM to boot from the floppy by default instead of the network interface card. The easy (easier than restoring a corrupted disk, anyways) fix is to restore the PRAM to boot from the network interface card. This process takes about 45 seconds. Another advantage is that you could have as many System images as clients to customize each client or one image for all clients. It would be attractive to have one image that all Macs in a public access lab boot, so, a user can always restore the default environment from any Mac by simply rebooting. Hope this is of some use. ---Ram Das Rao Information Technology Boston University
majors@milton.u.washington.edu (Robert Majors) (06/20/91)
There are many issues concerning security and public access labs. Here are some, with some ideas &/or questions: PHYSICAL SECURITY: We've installed locks and cables, and a capacitance/loop system which uses satin cord (phone line) to detect either/or a break in the system (indicating the cord has been cut or disconnected (it's looped through the devices)) or if someone has touched the device (at night) using a capacitance system. When set off, the central unit makes noise, and/or triggers an external security system. SOFTWARE SECURITY: We've purchased PassProof units to physically block access to the floppy drive (it can be unlocked and removed). There are also special screws to make it harder to open the CPU and take cards/SIMMS; also blocks to the SCSI port. Other ideas are appreciated. PS At some point, would there be enough interst to set up a mac/student/ public access group??? Bob Majors UW Language Learning Center