yvw@gmdzi.UUCP (Yvo Van Wezemael) (12/11/89)
The subject line already is the whole question. Is there a way
(modified AppleShare, init, rdev, commercial product...) to control
login/logout and/or operations on AppleShare servers?
Thanks in advance --- Yvo
--
Yvo Van Wezemael:
German National Research Center for Computer Science (GMD)
P.O. Box 1240 (Schloss Birlinghoven) D-5205 Sankt Augustin 1
phone: (+49 2241) 142422 yvw@gmdzi.UUCP YTHPRGDB@MTUS5.BITNET (12/13/89)
We have a network of eight Macs running off of an AppleShare server in a writing workshop. In order to control usage, we have set up a bit of a conglomerate system, but it works pretty well: The user list on the AppleShare server is used to determine user id's. All the applications are on a separate partition of the local hard disk. A macro to link the applications partition is available on the server. A macro calls up Chooser, which gets the user id and password and logs onto the server, then links up the applications partition. Also, all of our applications have been "Doppleganged" (sp?) with Doppelmaker, so the visible applications are not the actual ones -- the actual applications files are invisible -- this keeps the users from copying the applications. In addition, the AppleShare printer spooler captures the printers so the users cannot print without logging on to the server first. This may not be the simplest way to do things, but it seems to be working for us. Any ideas or input would be welcome (we are always looking for ways to improve our lab!) ------- -- Noel Maddy Bitnet: ythprgdb@mtus5 Technical Consultant Snail: 210 Vivian MTU CCLI Humanities Lab Hancock, MI 49930
chris@accuvax.nwu.edu (Chris Krohn) (12/16/89)
In article <89347.023020YTHPRGDB@MTUS5.BITNET> YTHPRGDB@MTUS5.BITNET writes:
##Also, all of our applications have been "Doppleganged" (sp?) with
##Doppelmaker, so the visible applications are not the actual ones --
##the actual applications files are invisible -- this keeps the users
##from copying the applications.
This is not necessary. There is an option in AppleShare 2.0 to set
a copy-protect feature on within the Administration utility which prevents
users from copying the applications.
##
##In addition, the AppleShare printer spooler captures the printers so
##the users cannot print without logging on to the server first.
This is incorrect. Users may print to the spooler without logging
into the AppleShare server at all.
##This may not be the simplest way to do things, but it seems to be
##working for us. Any ideas or input would be welcome (we are always
##looking for ways to improve our lab!)
##
To make things simpler, just drop the Doppelganger utility and use
the built-in features of AppleShare.
## -- Noel Maddy Bitnet: ythprgdb@mtus5
##Technical Consultant Snail: 210 Vivian
##MTU CCLI Humanities Lab Hancock, MI 49930
Christopher Krohn
Northwestern Universitydemarsee@ICARUS.CNS.SYR.EDU (Darryl E. Marsee) (12/16/89)
>##Also, all of our applications have been "Doppleganged" (sp?) with >##Doppelmaker, so the visible applications are not the actual ones -- >##the actual applications files are invisible -- this keeps the users >##from copying the applications. >This is not necessary. There is an option in AppleShare 2.0 to set >a copy-protect feature on within the Administration utility which prevents >users from copying the applications. I would like to point out that there is a relatively trivial way to circumvent AppleShare 2.0's copy-protection system. Apple has been informed of the problem, and hopefully is working on a solution (I have not heard of one yet). I will say that both Doppleganger and Multilauncher, while not alleviating the problem, do make it a bit more difficult for a user to circumvent the copy-protection scheme. Note: If you don't know this "relatively trivial way", then don't bother asking, I'm not going to tell you. >To make things simpler, just drop the Doppelganger utility and use >the built-in features of AppleShare. Due to the above-mentioned problem with AppleShare 2.0's copy-protection, Noel, I DO NOT recommend that you drop Doppelganger. Regards, Darryl Marsee <demarsee@icarus.cns.syr.edu> Syracuse University Postmaster, TechReper, & MacHacker
billkatt@mondo.engin.umich.edu (billkatt) (12/16/89)
In article <1989Dec16.001228.14970@caen.engin.umich.edu> mac_support@caen.engin.umich.edu (billkatt) writes: >In article <8912152130.AA15654@icarus.cns.syr.EDU> demarsee@ICARUS.CNS.SYR.EDU (Darryl E. Marsee) writes: >>>##Also, all of our applications have been "Doppleganged" (sp?) with >>>##Doppelmaker, so the visible applications are not the actual ones -- >>>##the actual applications files are invisible -- this keeps the users >>>##from copying the applications. >> >>>This is not necessary. There is an option in AppleShare 2.0 to set >>>a copy-protect feature on within the Administration utility which prevents >>>users from copying the applications. >> >> I would like to point out that there is a relatively trivial way >> to circumvent AppleShare 2.0's copy-protection system. Apple has been >> informed of the problem, and hopefully is working on a solution (I >> have not heard of one yet). I will say that both Doppleganger and >> Multilauncher, while not alleviating the problem, do make it a bit >> more difficult for a user to circumvent the copy-protection scheme. >> >> Due to the above-mentioned problem with AppleShare 2.0's copy-protection, >> Noel, I DO NOT recommend that you drop Doppelganger. >> >> Regards, >> >> Darryl Marsee <demarsee@icarus.cns.syr.edu> >> Syracuse University Postmaster, TechReper, & MacHacker > >Just to throw my hat into the ring... We here at the University of Michigan >CAEN have developed a system similar to MultiLauncher, but it prevents >copying of programs. It involves modifying applications to check with the >server before running. It is very difficult to circumvent and will be >neigh on impossible to circumvent version 2.0. Our system is called >LaunchBreak and is available in a very late beta right now. (Unlike U of >M Computing Center (makers of MultiLaunch), we admit we have bugs right now) > >How about a quick feature list, eh? > >1. LaunchBreak works under MultiFinder. > >2. LaunchBreak prevents copying of applications. This is because the > copies on the server are modified to only work when the are in the > computing lab. There are no copies which are simply hidden in folders. > ^^^^ oops, messed up before > >3. Applications modified with LaunchBreak may be copied down to the local > hard disk and run from there (or run from floppy if you want). This > way, people may copy things like Microsoft Word to the hard drive and > run them from there. When programs are run in this way, they act > exactly like they are run off the server, except faster. The correct > count of copies is still kept and still deny usage when more than the > legal number are run. > >4. LaunchBreak does not cause a flurry of packets every five minutes. > LaunchBreak uses an intelligent algorithim to keep accurate track of > how many copies of a program are in use. Checks are only made when > necessary, not every five minutes. > >5. LaunchBreak allows the user to modify the memory usage of a program > under MultiFinder. This is not possible on MultiLaunch because the > program a person sees is only a doppleganger, and the person usually > doesn't have write permissions to that folder. Under LaunchBreak you > just copy the program to the local hard disk and modify the memory usage > there. > >6. LaunchBreak is remotely administratable. You can download stats and > upload new licensing information remotely via the network without > bringing down the server. > >As another quick convincer... There are roughly three computing groups >at the U of M, CAEN, CC and ResComp. CC runs MultiLaunch since they wrote >it. CAEN runs LaunchBreak because we wrote it and we are on a huge >AppleTalk internet. If we ran MultiLaunch, any knowledgeable person could >mount our lab servers, look in the hidden folders and steal out software >through the network without even entering a lab. The third division, ResComp, >took a look at ML and LB and choose LaunchBreak. You decide for yourself. > >We are right now making LaunchBreak available on a sort-of beta system. You >can have it, and we would like you to share your problems with it with us. >In addition, we will try to rectify any bugs you find for your sake and ours, >but we cannot really add features into 1.0. Any new feature requests would >not be realized until version 2.0 (6-12 weeks until first beta). The current >policy on LaunchBreak is that it is free to educational institutions, but >corporations, etc. must ante-up. No fee has been set since we will not sell >it as a finished product until 2.0. > >Inquiries may be sent to mac_support@caen.engin.umich.edu > >-Steve Bollinger (billkatt@mondo.engin.umich.edu)
geo@orac.hss.bu.oz.au (George Bray) (12/17/89)
in article <89347.023020YTHPRGDB@MTUS5.BITNET>, YTHPRGDB@MTUS5.BITNET says: > Xref: orac comp.sys.mac:3351 comp.protocols.appletalk:257 > In addition, the AppleShare printer spooler captures the printers so > the users cannot print without logging on to the server first. How is this done? I thought being able to print to a spooled LaserWriter was not dependent on a valid server login. geo ________________________________________________________________________ George Bray > CompuServe:72711,253 Phone:075-30-3705 Sand Consulting Pty Ltd > AppleLink:AUST0287 Mobile: P.O. Box 157, > Internet:geo@orac.hss.bu.oz.au MacNet:GEO Bond University, 4229. > UUCP: ..!uunet!munnari!orac.hss.bu.oz.au!geo A U S T R A L I A. > Disclaimer: All Applicable Disclaimers Apply
teener@apple.com (Michael Teener) (12/19/89)
In article <310@orac.hss.bu.oz.au> geo@orac.hss.bu.oz.au (George Bray) writes: > in article <89347.023020YTHPRGDB@MTUS5.BITNET>, YTHPRGDB@MTUS5.BITNET says: > > Xref: orac comp.sys.mac:3351 comp.protocols.appletalk:257 > > > In addition, the AppleShare printer spooler captures the printers so > > the users cannot print without logging on to the server first. > > How is this done? I thought being able to print to a spooled > LaserWriter was not dependent on a valid server login. You are correct. The AppleShare printer spooler does *not* depend on the AppleShare file server for some kind of login ... the "capture" Mr. Bray talks about involves establishing a connection to the printer and changing the printer device name from "LaserWriter" to "LaserShared" so that the chooser doesn't list it. ---- Michael Teener -- 408-974-3521 ---------------------------------+ ---- Internet teener@apple.com, AppleLink TEENER | ---- Apple may know my opinions, but *I* am responsible for them | ---------------------------------------------------------------------+ Transportation by Cheetah N9900U, a loyal beast for the past 5 years.