KeyServer
Andrew S. Humphreys
like the program?
Andrew S. Humphreys
"When an error has been detected and corrected, it will be found to have
been correct in the first place!" - Scott's Second Law
John Mearns
>Has anyone used the program KeyServer by SassaFras Software? If so do you
>like the program?
We are using KeyServer. It has at least two advantages: it allows the
sysadmin to have confidence that s/he has complete control over distribution
of software and it reduces costs by allowing companies to purchase licenses
for the number of concurrent users as opposed to licensing each machine
which might have to run the software.
I am not sure, but I believe that KeyServer licenses are somewhat more
expensive than single copy licenses. However, with the KeyServer package,
keys get checked out and back in as people fire up programs and exit them.
Therefore, the total pool of licenses required may be smaller. (If everyone
uses the same set of software and needs to have it running at all times
during business hours, there is probably no savings or even a net loss to
using KeyServer.)
When KeyServer is used, the sysadmin does not need to guard against copying
software from one machine to another. In fact, KeyServer controlled
software on our network is available for anyone to copy from an AppleTalk
server. If you can't get a key (because you took it home or took it with
you to your next job), it won't run. However, KeyServer does have provisions
to take legal copies home with temporary keys, checked out from the central
pool.
KeyServer does have two drawbacks: when the network is down keyed software
will not run and the number of keys for a given peice of software must
match the real needs.
If the network is down (and ours has been a little tender of late), the
KeyServer can't be contacted, no keys are available and S/W launch fails.
If you can find the sysadmin while the network is down and if s/he can
spare you the necessary time (they tend to feel that they are up to their
ears in allicators when the network is down) you might be able to talk them
into giving you a temporary key for the critical package(s).
If the number of licenses is too small with respect to the number of real
concurrent copies needed, no keys will be available when they are needed.
This, of course, is a variant on the problem of how many packages to buy.
The twist is that you need to accurately predict how many are needed
concurrently. If the number is low-balled, users will start acting
defensively and create chaos. Among other strategies, they will start up
a copy as soon as they arrive for work, even though they don't need it
until hours later. When they need it, they will have a copy but other
people will be left out in the cold. However, the number of concurrent
licenses required is not easy to predict unless you really know how the
community to be served actually functions. Are there large numbers of
users who need the licensed packages up for small numbers of minutes at
at time? Are there smaller groups who need a package up for much longer
periods? Is there a mixture of usage models? It is much better to go a
little overboard in the begining than to allow defensive behaviour to take
root.
On the whole, from a user perspective KeyServer does a good job. It costs
a little additional time at system boot while it establishes communications
with the server. There must be a message exchange for key checkout when
launching software and another at exit to return the key, but the time
required to do that just isn't noticable to me. Initially I was not
convinced that there was any benefit for me. Then I had to read a document
and I did not have the package installed in my machine. Instead of going to
the sysadmin, telling them I needed to read this document, blah blah (cost
justfication), blah blah (order cycles), etc; I mounted the AppleShare volume,
copied the package I needed to my Mac, launched the package and read the
document and I did it legally.
jme...@amdahl.amdahl.com -- I speak for myself, not Amdahl.
Alex Morando
>hump...@elrond.ceri.memst.edu (Andrew S. Humphreys) writes:
>
>>Has anyone used the program KeyServer by SassaFras Software? If so do you
>>like the program?
>
>We are using KeyServer. It has at least two advantages: it allows the
>sysadmin to have confidence that s/he has complete control over distribution
>of software and it reduces costs by allowing companies to purchase licenses
>for the number of concurrent users as opposed to licensing each machine
>which might have to run the software.
>
problems (hybrid EtherNet/LocalTalk network).
My question is that how does this relate to a recent discussion regarding
network-based copy protection? For example, if a company has two licenses
for Photoshop, it places two keys on the KeyServer, and "keys" ONE copy
of Photoshop. Thus, if two people use it concurrently, it is OK from the
KeyServer, but there will be TWO copies of Photoshop running the same
serial number.
An answer might be to have two copies on the KeyServer, but that would
mean excessive disk usage, and there is no way for one person to know
what serial number another person may be using.
Please enlighten me :-)
>jme...@amdahl.amdahl.com -- I speak for myself, not Amdahl.
--
! Alex Morando, Engineer, ASAASESBU, Torrance, CA
! Internet: a...@netcom.com
! mor...@alad.gedlab.allied.com
! Most of what I say does not reflect the views of my employer.
Kyle Barger
> My question is that how does this relate to a recent discussion regarding
> network-based copy protection? For example, if a company has two licenses
> for Photoshop, it places two keys on the KeyServer, and "keys" ONE copy
> of Photoshop. Thus, if two people use it concurrently, it is OK from the
> KeyServer, but there will be TWO copies of Photoshop running the same
> serial number.
And the two copies will talk to each other, decide they have the same
serial number, and will not be happy. The only solution to this problem is
not to use Keyserver on the software, or to get the vendor to supply a
version that's happy with running multiple copies (I believe somebody said
they got Wolfram to do this for them with Mathematica).
Kevin A. Garceau
> Subject: KeyServer
> From: hump...@elrond.ceri.memst.edu (Andrew S. Humphreys)
> Date: 21 Jul 93 15:19:09 -0600
> Organization: Center for Earthquake Research - MSU
> Has anyone used the program KeyServer by SassaFras Software? If so do
> you like the program?
>
Here at Draper Laboratory we have been using KeyServer for over a year now
with excellent results. The ability to consolidate software licenses into a
"manageable pool" available to users is long overdue. We were pleasantly
surprised to see we needed far fewer licenses than originally thought would
be in simultaneous use. The cost savings for our company has been
considerable! As far a reason for software developers to allow this approach
in their software licenses, we've found many users trying and actually using
different software packages that they could not normally justify an
individual copy for. This has resulted in increased usage and INCREASED
SALES for software developers. This approach is a win-win solution for both
parties involved.
In terms of the software itself and the technical support from Sassafras, I
can only say that I am an extremely satisfied user (administrator that is).
Sassafras is to be commended on being very compentent and receptive to its
users. I have never had any problems in getting any technical assistance I
have needed. The software itself is very stable and all of our software is
compatible with it. The recent release of KeyServer 3.1 makes the product
even more reliable with the additional feature of portable keys (the ability
to run keyed applications without network connectivity, i.e. remotely) and
"shadow servers" (an automatic backup approach for providing KeyServer
service).
I should point out that I am in no way affliated with Sassafras Software,
except for being a very satisfied customer. I'd be happy to answer any other
questions you might have about the product in terms of an administrator's
perspective.
Kevin A. Garceau
Draper Laboratory, Inc.
Cambridge, MA 02139
> Andrew S. Humphreys
>
> "When an error has been detected and corrected, it will be found to
> have been correct in the first place!" - Scott's Second Law
>
Kevin A. Garceau
Draper Laboratory
555 Technology Square
Cambridge, MA 02169
Kevin A. Garceau
(John Mearns) writes:
> From: jme...@uts.amdahl.com (John Mearns)
> Newsgroups: comp.sys.mac.apps
> Subject: Re: KeyServer
> Date: 21 Jul 93 23:04:41 GMT
> Organization: Amdahl Corporation, Sunnyvale CA
> hump...@elrond.ceri.memst.edu (Andrew S. Humphreys) writes:
>
> >Has anyone used the program KeyServer by SassaFras Software? If so do
> >you like the program?
>
> We are using KeyServer. It has at least two advantages: it allows the
> sysadmin to have confidence that s/he has complete control over
> distribution of software and it reduces costs by allowing companies to
> purchase licenses for the number of concurrent users as opposed to
> licensing each machine which might have to run the software.
>
> I am not sure, but I believe that KeyServer licenses are somewhat more
> expensive than single copy licenses. However, with the KeyServer
> package, keys get checked out and back in as people fire up programs
> and exit them. Therefore, the total pool of licenses required may be
> smaller. (If everyone uses the same set of software and needs to have
> it running at all times during business hours, there is probably no
> savings or even a net loss to using KeyServer.)
Although the cost of each KeyServer client is very reasonable in relation to
the cost savings it produces, this is a good point. With over 1000 macs at
our site, you can very well imagine the large number of software packages we
have. Even if there are users who use several software packages all day,
there are times when they are in meetings, out sick, on vacation, etc. ,
that it still becomes advantageous for everyone to be using keyed
applications.
>
> When KeyServer is used, the sysadmin does not need to guard against
> copying software from one machine to another. In fact, KeyServer
> controlled software on our network is available for anyone to copy from
> an AppleTalk server. If you can't get a key (because you took it home
> or took it with you to your next job), it won't run. However,
> KeyServer does have provisions to take legal copies home with temporary
> keys, checked out from the central pool.
Agreed! This is a very important feature. The KeyCheckout provision is the
answer for remote usage of keyed applications, and is totally customizable as
to the which applications may be "checked out" and for how long. The most
important part is that a user can do this him/herself.
>
> KeyServer does have two drawbacks: when the network is down keyed
> software will not run and the number of keys for a given peice of
> software must match the real needs.
>
> If the network is down (and ours has been a little tender of late), the
> KeyServer can't be contacted, no keys are available and S/W launch
> fails. If you can find the sysadmin while the network is down and if s/
> he can spare you the necessary time (they tend to feel that they are up
> to their ears in allicators when the network is down) you might be able
> to talk them into giving you a temporary key for the critical package(
> s).
The creation of portable key diskettes for emergency backup use has been a
very important part of our strategy for dealing with network outages. Since
usually only part of a network segment will go down, it's usually possible to
make a temporary key diskette somewhere on the "live" network.
However, a more automatic approach is handled by newest KeyServer 3.1 in
the feature called "Shadow Servers". This init sits on users' macs
(utilizing only 150K RAM and no noticeable system degradation) and provides
temporary and automatic KeyServer service should a network segment become
isolated. These shadow servers maintain their own database of keys,
including automatic periodic updates from the main KeyServer, and activate
and deactive without any user or administrator intervention.
>
> If the number of licenses is too small with respect to the number of
> real concurrent copies needed, no keys will be available when they are
> needed. This, of course, is a variant on the problem of how many
> packages to buy. The twist is that you need to accurately predict how
> many are needed concurrently.
KeyServer generate extensive reports on software usage, even down to how many
users were put in waiting queues for each application, and what the average
wait period was. This gives the administrator valuable information to base
his/her estimate on the number of further copies to purchase.
> If the number is low-balled, users will
> start acting defensively and create chaos. Among other strategies,
> they will start up a copy as soon as they arrive for work, even though
> they don't need it until hours later. When they need it, they will
> have a copy but other people will be left out in the cold.
It is possible to put a time limit on the usage of a program, but even I
dislike this approach. But the feature is there. Also, KeyServer has the
concept of "Preferred Users" and "Common Users" which an administrator can
make sure there's a specific number of copies reserved for people who must be
able to access a keyed application.
> However, the number of concurrent licenses required is not easy to predict
> unless you really know how the community to be served actually
> functions. Are there large numbers of users who need the licensed
> packages up for small numbers of minutes at at time? Are there smaller
> groups who need a package up for much longer periods? Is there a
> mixture of usage models? It is much better to go a little overboard in
> the begining than to allow defensive behaviour to take root.
Agreed. Unless the software program is prohibitively expensive, a few extra
copies as a margin of safety is a good idea to prevent this type of
"hoarding".
>
> On the whole, from a user perspective KeyServer does a good job. It
> costs a little additional time at system boot while it establishes
> communications with the server. There must be a message exchange for
> key checkout when launching software and another at exit to return the
> key, but the time required to do that just isn't noticable to me.
> Initially I was not convinced that there was any benefit for me. Then
> I had to read a document and I did not have the package installed in my
> machine. Instead of going to the sysadmin, telling them I needed to
> read this document, blah blah (cost justfication), blah blah (order
> cycles), etc; I mounted the AppleShare volume, copied the package I
> needed to my Mac, launched the package and read the document and I did
> it legally.
>
> jme...@amdahl.amdahl.com -- I speak for myself, not Amdahl.
>
Mark.R....@dartmouth.edu
a...@netcom.com (Alex Morando) writes:
> My question is that how does this relate to a recent discussion regarding
> network-based copy protection? For example, if a company has two licenses
> for Photoshop, it places two keys on the KeyServer, and "keys" ONE copy
> of Photoshop. Thus, if two people use it concurrently, it is OK from the
> KeyServer, but there will be TWO copies of Photoshop running the same
> serial number.
>
> mean excessive disk usage, and there is no way for one person to know
> what serial number another person may be using.
Indeed, "network serial number lookup" does keep KeyServer from
managing those applications in an efficient manner. There are a few
solutions to the problem, which I will enumerate.
1) As Alex suggests, key all copies and let users launch them one at a
time until an unused copy is found. Alex is also right about the
drawbacks: more space used on the file server or users' disks, and
still a hassle from the users' perspective.
2) Call the developer in question and ask if they have a
non-serialized version. Some vendors are willing to send copies that
do not have network serialization, as long as you are using KeyServer
to provide the control.
3) Tell the developer to use our KeyStatus library. Some developers
are already using KeyStatus to provide a single-package solution for
both KeyServer and non-KeyServer sites. Basically, the developer uses
the KeyStatus library to determine whether the particular instance of
the application is under KeyServer's control. If not, it can proceed
to protect itslef by using its own network serial number lookup. If
KeyServer is controlling the program's license, then the program can
alter it's behavior and forego the network check.
Aldus PageMaker 5.0, which performs serial number lookup, utilizes the
KeyStatus library. We are also talking with other developers - some of
whom are on the recently published list - about including KeyStatus in
their programs.
If you are a developer looking to do network serialization, then I urge
you to use the KeyStatus library. It's free, and it's easy to throw
into your program.
For more info and details, just call or send e-mail.
Mark Valence
Sassafras Software Inc.
PS:
In article <1eFV03R...@amdahl.uts.amdahl.com>
jme...@uts.amdahl.com (John Mearns) writes:
> If the network is down (and ours has been a little tender of late), the
> KeyServer can't be contacted, no keys are available and S/W launch fails.
> If you can find the sysadmin while the network is down and if s/he can
> spare you the necessary time (they tend to feel that they are up to their
> ears in allicators when the network is down) you might be able to talk them
> into giving you a temporary key for the critical package(s).
KeyServer 3.1 includes a feature we call "shadowing", which solves this
problem. If a network goes haywire and users are disconnected from the
KeyServer, emergency shadow servers will automatically take over
service and users will be able to continue usig keyed programs. Once
the network heals again, users who have been protected by the shadows
are "handed back" to the KeyServer, which then regains central control
of the programs.
James A. Nauer
(Kyle Barger) wrote:
Actually, both Wolfram and Adobe will provide special serial numbers that
override the one-simultaneous-user limit. All it took for me was one phone
call to each of their tech. support numbers. As long as vendors are
reasonable about this, I don't have any problem at all with applications
that do network serial number checking (I find the griping in the
"net-hacking apps." thread a bit amusing...)
James A. Nauer | "I shall not yield one whit of maturity,
L.I.T. Facilities Manager | not grace, not respectibility, to the
Library Information Technologies | passing of time. I declare that I shall
Case Western Reserve University | forever be, if not a child, certainly
(216) 368-MACS | childish" --Kennet Shardik
(368-6227) |
| -=| Save a tree. Send e-mail. |=-
Anssi Porttikivi
I am working in a public access Mac laboratory in Helsinki University. I
agree the Mac is "the most intuitive computer ever sold, but that's not
saying much." (The Macintosh Bible). And I think the ease of use is
ABSOLUTELY the most important productivity factor in computer
investments.
But my first computer loves were DECSystem-20 and Unix and I have used
a dozen different operating systems. So I see there is one glaring
omission in a Macintosh network: the lack of multiuser perspective. Why
should a network have the added complexity to allow workstations to be
used by different people at different times, then? Well, think about the
future. Many people will be carrying their own computer around all the
time like pens and bags, but we will still want to use the better
computers lying around us when we are at them.
I definitely would like floating-license-aware, network-aware and
multiuser-multiworkstation-aware software but there is almost none.
Macintosh multi-user-multi-workstation problems (DON'T FOLLOW UP!
MAIL ME AND I WILL SUMMARISE!):
Problem 1. The settings files are in the workstation. Not good, when
several people use the same Mac workstation.
Solution 1: Keep the settings in a networked home folder. The ability
to have the various settings files as aliases resolving through a
generic "active home folder" ($HOME, you know!) would solve the problem.
And those aliases should be allowed in the system folder, too.
What? Appletalk doesn't recognise the concept of active user's home
folder! Unbelievably short-sightedly microcomputer oriented but true.
So the alternative solution is to launch from your own settings files
which means there is no fixed routine that the operator could set up for
naive users.
Or you can launch from templates storing an arbitrary and varying
subset of all the settings concerning your document and your environment.
The problem of operating system settings and resources being
workstation-dependent and not user-dependent still remains. If aliases
were allowed inside the system folder it would help.
Problem 2. The writable files which are shared by several users (network
installed programs the resources of which are modified run time; style
libraries, user dictionaries; Netnews spool files) are not safely
sharable and in worst cases are hard coded by the software to be in the
local system folder.
Solution 2: In people's minds, make it clear which is a) program's data
and code resources only touched by the maintenance, which is b) common
sharable data and which is c) individual user settings. Keep all these
in the network in different places and provide appropriate locking.
With a lot of software you can't do that. And even if you can, this
strategy is not covered in the manual and you can never tell if it works
safely or not, because multiuser conflicts typically occur very rarely. I
have spent hundreds of hours during the past year debugging e.g. Canvas,
Statview and various HyperCard stacks in this respect, mostly with no
results: I still don't know which problems if any are related to this.
The other non-solution: don't share resources, to the h#&l with
productivity and group collaboration. Install suspicious software
locally. It will only increase my maintenance work 100-fold. (The
Helsinki University owns dozens of different software packages and 500
Mac workstations on the metropolitan network.
Problem 3. The software you can only launch once with one serial number
in the same network.
Solution 3: Don't buy them. Buy programs which allow you to use floating
license servers or some other sensible method of copy protection. (I have
a very smooth pay by use copy protection product idea, interested capital
can contact me ;-) ) We at the Helsinki University use LaunchBreak
license server from the University of Michigan.
I accept this method of copy protection though, if a network
installable multiuser version is available! Again the real problem is
that there is no standard floating license server in the operating system.
VERY HOT TIP: There is only a network-unique-serial-number protected
Aldus PageMaker 4.2 version available. Buy N packages of it. Install
PageMaker in the network and put the Aldus-folder there too. Reinstall
it N times in some workstation and save the resulting N pieces of PM 4.2
RSRC -files from the local Aldus-folder. Now you can easily install PM
to any workstation by copying the PageMaker-folder from the network and
putting a unique PM 4 RSRC -file in there. The Aldus folder may be in the
network. PM asks its place when run first time, then it remembers. We
can never be sure that this wouldn't cause write conflicts in the
networked Aldus folder but it seems to work.
--
Anssi.Po...@helsinki.fi
Helsinki University Information Center
Blair M. Burtan
Here at Mattel Toys, I've set up a 70+ user KeyServer system. It has worked
without major incident for a year now. Well, until we got 25 new machines.
Our designers using Illustrator 3.2.3 suddenly increase their usage of the
software. KeyServer acted accordingly to the tearing out of hair by the
designers. Everybody was screaming at me for one reason or another including
"How come we didn't have this problem until now" Well, you guys are now
using the software much more than before. So, I was given the directive to
buy more copies of Illustrator. Well, Adobe has released Illustrator 5.0.
Good news, no? No. See the new Illustrator has the network checking crap in
it. No problem, I can call Adobe for an unchecked version, right? Wrong. The
folks at Adobe were most unpleasent when I asked for such a thing even though
I told them that I was using KeyServer. There was lots of screaming on both
parts. I have a master's degree in Software Engineering. I don't
appreciate having my intelligence insulted which is just what they did. If
one were planning to steal the software, who would be stupid enough to call
the company for it. Well, I hung up and called back later and talked to a
different person who calmly explained that there were going to be multi-packs
available with one serial number. Packs of 5, 10, 25, and 50, I believe.
Okay great. Well, that still presents a problem for a sys-admin with a 70
machine site. Purchase a 50 pack and a 25 pack, right? Wrong. The packs will
have 2 serial numbers. Suppose you install the smaller pack on a high usage
group of machine. The users complain. And it's too damn expensive to buy
a 100 pack. So, here's my request to Adobe and related companies. It's
time to start respecting to customers wishes. When I bought the KeyServer,
Sasafras was great. We ordered a 50 user system. Later, when we wanted 20
additional users, no problem. One phone call and we got a 70 user system.
Adobe should do the same thing to large sites. It can't be that difficult to
provide an updater that will alter the number of concurrent users. Come on
guys!!! People are not going to buy the software if it's a pain to use.
<Flame off>
Blair Burtan
Mattel Toys, Inc.
P.S. If any Adobe employees are reading this and can help me out, call me
at (310)-524-3747
--
+----------------------------------------------------------------------+
+ Blair M. Burtan: be...@netcom.com be...@csa.bu.edu be...@bu-pub.bu.edu +
+ My opinions don't necessarily reflect those of Mattel Toys, so there +
+ "If it's not baroque, don't fix it." - Beauty and The Beast +
+----------------------------------------------------------------------+