logins, leading to UNIX access

Robert Rasmussen ras at nimbus.anzio.com
Thu Aug 21 12:48:21 EDT 1997


For you web4lib readers, I'm expanding a discussion from the Innopac mailing
list, as I think it has interesting and serious implications, and I can see
how you enjoy a good debate.

On Thu, 21 Aug 1997, Peter Murray wrote:

> In the INNOPAC world, libraries typically do not have access to the UNIX
> shell to make such changes...

Let me preface my remarks by stating that I am not a librarian; rather I am a
computer software author, consultant, etc., with 20 years experience (yes,
there were computers before PCs).

A critical issue in any organization that buys software, or a
hardware-software bundled package, is degree of access. In a larger sense,
it's an issue of degree of ownership. This has long been an issue, and often
"where you stand depends on where you sit." 

A vendor supplying a software system to many customers has an interest in
keeping each customer's system "pure". If the customer can fiddle with things,
that may increase the amount of work the vendor has to do in debugging,
maintaining, and upgrading the system. 

The customer, on the other hand, may have an interest in making things work
better, adapting faster to new technologies, doing additional unrelated tasks
on the same hardware, plugging in "unauthorized" peripherals, generating
non-standard reports, protecting their data from catastrophe, and so forth.

Many years ago, it was common practice to do "one stop shopping", buying
hardware, software, consulting, maintenance, and even paper from one of the
major suppliers, who shall remain nameless. These vendors often imposed
restrictions that would strike us as absurd today. A customer could violate a
maintenance contract by plugging in a foreign printer or terminal. File
layouts were something you "didn't need to know". The vendor could keep things
working, while boosting profits by keeping a lock on the customers.

The problem was, there were many things the vendor didn't do. If they hadn't
solved your problem, you had nowhere to turn, other than to throw it all out
when your contract was up, and hope you could migrate your data.

Ah, but I wax historical... Let's fast forward to the present. We now work in
an era of more-or-less open standards: terminal types, printer types, TCP/IP,
operating systems, etc. But we still often have situations where the vendor
can't or won't deliver ALL the solutions we need.

To fashion a metaphor, if the marriage goes bad, do you want all the money in
one account?

The issues are access and ownership. To what degree can you access the
hardware/software systems that you own? Is this stated in the contract you
have with your vendor? Following are some pointed questions, drawn from
years of experience.

* Who has the root password? Do you? Is it locked up somewhere? What happens
if the vendor has business problems?

* Are you free to separate your hardware maintenance from your software
maintenance? Can you shop around for hardware maintenance?

* Are you able to add a new disk drive, or replace one?

* What minor tweaks can you make to the system for changes in terminal type,
login messages, printer models, etc.?

* Can you protect your investment in information (your data) if something
happens to your vendor? Short term? Long term?

* If you find a local guru who, you believe, can make minor changes to make
things work better, will that get you in trouble with your vendor?

* Is your vendor amenable to a security audit? Does the vendor represent a
security risk? What could a vendor's disgruntled or fired employee do to your
system?

In conclusion, let me state my personal opinion. The customer owns the system,
and the data on the system. The customer has the most interest in protecting
the system, and the most responsibility for protecting that investment. The
customer organization needs to have an accurate assessment of its technical
expertise or lack thereof, in order to prevent damaging the system. But
ultimately the control of the system must rest with the customer.

Just stirring things up, and interested in other opinions,
....Bob Rasmussen,   President,   Rasmussen Software, Inc.

personal e-mail: ras at anzio.com
 company e-mail: rsi at anzio.com or sales at anzio.com or support at anzio.com
 ftp://ftp.anzio.com               voice: 503-624-0360
http://www.anzio.com                 fax: 503-624-0760



More information about the Web4lib mailing list