Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!shadooby!netnews.engin.umich.edu!news From: billkatt@mondo.engin.umich.edu (billkatt) Newsgroups: comp.protocols.appletalk Subject: Re: Accounting on an AppleShare server? Message-ID: <1989Dec16.002606.15333@caen.engin.umich.edu> Date: 16 Dec 89 00:26:06 GMT References: <8912152130.AA15654@icarus.cns.syr.EDU> <1989Dec16.001228.14970@caen.engin.umich.edu> Sender: news@caen.engin.umich.edu (USENET News System) Reply-To: billkatt@mondo.engin.umich.edu (billkatt) Organization: Computer Aided Engineering Network (CAEN), University of Michigan Lines: 87 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 >> 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)