Jim Mohr's SCO Companion
Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of
Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/
Basics of SCO UNIX
There are many SCO systems around where the user does not even know
that it is an SCO system. Many company have point-of-sales systems
hooked up to an SCO host. For the users at the cash register, they
never see what is being run. Therefore, there is really no need for
you to go into details about your system for any other reason than
pure curiosity. Assuming you find out that you are running on an SCO
On the other hand, if you do have access to the command line or
interact with the system by some other means, knowing how the system
is put together is useful information. Knowing how things interact
helps expand your knowledge. Knowing what's on your system is
helpful in figuring out just what your system can do.
That's what this is chapter is about: what's out there.
We're going to talk about what makes up the SCO Open Desktop
and Open Server products. Part of this includes the different
components that make up each product. The components are related to
the different processes that go on in a computer system, such a
printing and accessing a network.
Each of these components is composed of individual files and
programs. What each of these programs is and what it does may provide
you with new tools to make your life easier. This goes for both the
user and the administrator.
What SCO is All About
A Guided Tour
Unless you are on familiar ground, you usually need a map to get
around any large area. To get from one place to another, the best map
is a road map (or street map). If you are staying in one general area
and are looking for places of interest, you need a tourist map. Since
we are staying within the context of SCO and we're looking for things
of interest, what I am going to give you now is a tourist map of SCO
In later chapters, we'll go in detail about many of the
directories that we are going to encounter here. For now, I am going
to briefly describe where they are and what their function is. As we
later get into different sections of the book, it will be a lot
easier to move and know how files relate around if we already have an
understanding of the basic directory structure.
The top-most directory is the root directory. In verbal conversation,
you say "root directory," whereas it may be referred to in
text as simply "/". Under root, there are several
sub-directories with a wide range of functions. shows the key
sub-directories of /. This representation does not depict every
sub-directory of /, just the more significant ones. In subsequent
diagrams I will continue to limit myself to the most significant
directories in order to keep from loosing perspective.
Figure 0-1 The
In order to talk about the root directory, we actually need to
talk about two directories at the same time. With ODT 3.0, the
programs needed to boot and load the operating systems were located
in the root directory. OpenServer changed that with the introduction
of the /dev/boot
filesystem. The programs needed to boot are now located here. Rather
then repeating this explanation for every file, I will simply refer
to them without any path. Unless otherwise noted, these files are in
/ on ODT 3.0 and in
/stand on OpenServer.
One of these files, one could say, is the single most
important file: unix. This
file is the operating system proper. It contains all the functions
that make everything go. When referring to the file on the hard disk,
one refers to /unix
whereas the in-memory, executing version is referred to as the
kernel. On OpenServer this file resides in /stand,
but there is a symbolic link to it in /.
The next file is actually accessed before unix.
This is the boot
program. For those of you who are familiar with SCO UNIX systems, it
is the boot program that
presents the now famous Boot:
prompt. It is this program that reads the unix
file from the hard disk into memory and begins executing it. We'll
get into more details about how the system gets to the
boot program and the entire boot process in the section on
booting your system.
The dos file
can be used to boot the system, as well. Rather than booting
UNIX, the dos program
finds the primary DOS partition on your system (if you have one) and
New to the /stand
directory are two programs: link
program is used to install boot-time loadable drivers into your
system (these are drivers that normally come with third party
products that are needed when booting your system). The /stand/bootos
program is used to boot other operating systems. This not only
includes DOS as in previous versions, but also Microsoft Windows NT
and OS/2. Lastly there is the sfmt
program. This is used to low-level format hard disk connected via an
OMTI controller. For more details see the respective man-pages.
In addition to the programs needed to boot the operating system,
there are many files located in the root directory that are used by
the root user (the system administrator). This is because the /
directory is the root user's home directory. This is
where these files reside. Since the root user does not login until
well after the system has booted, there is no need to have these
files in /stand.
Therefore, on both ODT 3.0 and OpenServer, they only exist in /.
The first directory we get to is /bin.
Its name is derived from the word binary. Often the word
binary is used to refer to executable programs or other files that
contains non-readable characters. The /bin
directory is where many of the system related binaries are kept,
hence the name. Although several of the files in this directory are
used for administrative purposes and cannot be run by normal users,
everyone has read permission on this directory, so you can at least
see what is here.
The /dev directory
contains the device nodes. As I mentioned in our previous discussion
on operating system basics, device files are the way both the
operating system and users gain access to the hardware. Every device
has at least one device file associated with it. If it doesn't, you
can't access it. or more details on what each of the individual
device files is, take a look at chapter 5.
The /etc directory serves
as sort of a dumping ground for programs that don't seem to
belong anywhere else. Its name comes from the common abbreviation etc
for etcetera. This means "and so on." Normal users do not
normally execute programs in
/etc. Although there are a few programs there that can be
executed by normal users, most of what is kept here is generally for
system or administrative use.
are several sub-directories of varying importance to both
administrators and users Figure 0472 shows what the sub-directories
of /etc would look like
Sub-directories of /etc
sub-directory contains security or authorization related information.
The name "auth" comes from "authorization."
Normal users do not have access to this directory (for obvious
reasons). However, if you'd like to take a peek at its insides, take
a look at chapter 4.
Although normal users can move around inside of it, the /etc/conf
directory is primarily of use to the system administrator. The name
"conf" is short for "configuration." Underneath
/etc/conf are several more
sub-directories. Combined with a few programs scattered around the
system, these directories are collectively called the link kit. These
are the files and programs used to add new devices to the system,
change system parameters and combine them all into a new copy of the
operating system, /unix.
One sub-directory that is of importance to both users and
administrators is the /etc/default
directory. As its name implies it contains default information. In
general, the files in this directory are readable by everyone, so the
users on a system can take a look at the defaults themselves. Most of
the files in this directory either have their own man-page or are
associated with programs that do.
The /etc/fscmd.d directory
is another one that is of interest only to administrators. The name
"fscmd" is from "filesystem commands" and the
".d" at the end is a standard convention to indicate a
directory. In practice, even administrators do not need to go into
here. This is where the filesystem specific programs exist, which are
actually called by their generic namesakes. For example, the program
used to clean (ensure the integrity of) a filesystem is called fsck.
When invoked by the system administrator, the fsck
program first determines what type of filesystem is being cleaned,
then executes the appropriate program in /etc/fscmd.d.
Rather than having one monolithic program that contains the code for
all the filesystems, there is one, small front-end that calls the
When you run the ps
(process status) command, rather than hunting through several system
files, it simply reads the information in the files in the /etc/ps
directory. If you have write permission in this directory (for
example, as an administrator) you can remove these files and see how
much longer the ps command
takes to run as it must first gather the information stored in
In the /etc/perms
directory are files containing lists of all the files that come with
the installed products. Sort of a packing list, you might say. In
addition to file and directory names and where they end up, there is
also the name of the owner, group and default permissions on each
file. The name "perms" comes from "permissions."
In OpenServer, the /etc/perms
directory is not used in the same way. We go into more details
about that later. For more information, see both the custom(ADM)
The /etc/rc.* directories
contain files that the system uses when starting up or shutting down.
Which files are read depends on whether the system is being started
or shutdown. We'll talk more about these directories and their
associated files in the section on starting up and shutting down the
Moving back up to the root directory, we next find the
/lib directory (for library). If the SCO Development System
has been installed on your system then this directory will contain
the libraries needed for program development. Hence the directory
name "lib." In addition, there are usually some of the
programs necessary for a kernel rebuild.
The /shlib directory
contains the shared libraries used by the
system. For those of you who are not programmers, a shared library is
a means of providing uniformity across programs as well as saving
space. For example, almost all of the programs that users and
administrators use accept input from the keyboard and write output to
the screen. Rather than each program having copies of the necessary
functions to do this, a single copy is stored in a shared library.
Since the code for performing this I/O is not in the program itself,
the program can be smaller and thereby saving space. If ever this
code needs to get changed, it can be changed in one place and you
don't run the risk of forgetting to change it somewhere.
The /tcb directory is used
in conjunction with the /etc/auth
directory. TCB is an abbreviation for Trusted Computing Base. Whereas
the /etc/auth directory
contains just data files, the
/tcb directory contains both data files and the support
programs used to manage and administer system security. We will be
covering system security in a lot more detail in chapter 4.
The /usr directory
contains many user-related sub-directories. Note the 'e' is missing
from "user". In general, one can say that the directories
and files under /usr
are used by and related to users. There are programs and
utilities here that users use on a daily basis. Unless changed, /usr
is where users have their home directory. Figure 0473 shows what the
sub-directories of /usr
would look like graphically.
Sub-directories of /usr
Whereas /bin contains
programs that are used by both users and administrators, /usr/bin
contains files that are almost exclusively used by users. (However,
like everything in unix, there are exceptions.) Here again, the bin
directory contains binaries.
The /usr/adm directory
contains mostly administrative data. The name "adm" comes
from "administration." The name There are three key files
stored here. The first is the messages
file that contains all the system service, kernel and device driver
messages. Next is the hwconfig
file. This is where the hwconfig
program gets its information. Last, is the syslog
file. This is where the system logs messages from the syslogd
daemon. For more information, see the respective man-page.
There is also an important directory here: sa
(system activity reporter). This is were
the sar utility gets and
writes its information. Many of the files in this directory are data
files, so you really can't go looking through them with a text
editor. Check out the sar(ADM)
man-page for more details.
The /usr/include directory
and its various sub-directories contain all the include files. For a
normal user and even most system administrators, the information here
is more a place to get one's curiosity satisfied. However, for me
that is enough. This directory, and its various sub-directories
contain information that both the kernel needs when being re-created
and programs need when being compiled. (For those of you who know
that this is dramatic over-simplification, all I can say is that you
already know what this directory is for anyway)
Many system parameters and values are stored inside the files
Because of the information provided in many of the files, I will be
making reference to them through the book. Rather than spelling out
the full path of the directory I will make a reference to the files
relative to the /usr/include
directory, the same way that is done in C source code. For example,
when I refer to something like <sys/proc.h>,
I mean the full path /usr/include/sys/proc.h.
When you see something enclosed in the angle brackets like this, you
can make the expansion yourself.
The /usr/lib directory is
difficult to explain. Without belittling its significance, I have to
say that it's pretty much a dumping ground for things that don't
fit elsewhere. (didn't I say that about /etc?)
We could say that it contains the user related library files (based
on its name). However, that still does not accurately describe the
complete contents. One thing it contains is the library files that
are less general than those you find in /lib.
These include the libraries for cross compilation in DOS and OS/2.
shows what the sub-directories of /usr/lib
look like graphically.
Sub-directories of /usr/lib
A little known aspect of SCO UNIX is that it has built-in (albeit
limited) abilities to do system accounting. You can keep track of
system resources on the system on a per user basis and charge them
for that usage. All the associated files are kept in /usr/lib/acct.
The name "acct" comes from "accounting."
directory contains the data files that the cron,
at, and batch utilities
use when running non-interactive jobs. Not only does it contain the
commands to be run and the schedule to adhere to, but it also
contains configuration information for the jobs as they run. This is
also where the access lists for the three utilities are stored.
For a normal user, the /usr/lib/custom
directory is of little value. It contains information, which custom
uses when installing or removing software packages. In addition is
contains a history file (/usr/lib/custom/history)
that list all the software that has been added or removed using the
custom utility. Here you
will also find all the removal scripts for the installed packages.
Every time you run passwd
to try to change your password, the system determines if your
password is "good." "Good” is determined by
both the /etc/default/goodpw
file and the files in
/usr/lib/goodpw. It is possible through configuring the files
in this directory to restrict it far beyond the defaults. For more
details see the goodpw(ADM)
directory contains files that are used to configure the system
console keyboard. Through these files, you can configure your
keyboard to accommodate one of several different languages. You can
even configure them for dialects of the same language, such as the
German keyboard as used in Switzerland or Germany. You can also
change these files to create some totally new keyboard layout, such
as the Dvorak. For more details see the
In keeping with the internationalization theme, we next look at the
Here we have the file used to determine language specific things such
as the collation sequence, decimal and thousand's separator, or the
names of the months and days of the week. For more details on this,
look at the locale(C) man-page.
The /usr/lib/mkdev is
normally only of interest to system administrators. The name "mkdev"
comes from "make device" and the scripts in this directory
are used to add devices to your system. Adding devices to the system
is done by using the /etc/mkdev
utility. The argument passed to it is the name of the device that you
want to add, which turns out to be the name of one of the scripts in
this directory. The scripts then ask the necessary questions to
install that device and may relink the kernel. We'll talk a lot more
about adding devices in chapter 5.
directory is usually never accessed directly. Instead, the
files here are used every time you run the system administration
shell (sysadmsh in ODT or
scoadmin in OpenServer).
The files in here are accessed when you add or "make" a
user. Hence, the name. Along with the information in the
the system creates user accounts based on the values input in the
sysadmsh. We'll talk more
about these files in chapter 4..
directory contains information used by the system administration
shell. Here the data files are located that are used to create all
the menus as well as other programs that the sysadmsh
calls to actually get the work done. Keep in mind that if you are
running SCO OpenServer, the sysadmsh
has been replaced with scoadmin.
directory contains both the source files and compiled versions of the
terminfo database. Terminfo is the mechanism by which the system can
work with so many different types of terminals and know which key is
being pressed. For more information, see the terminfo(M)
When configuring UUCP, all the necessary files are contained in the
Not only are the configuration files here, but this is also home for
most of the uucp programs. UUCP (Unix-to-Unix Copy) is a package that
allows you to transfer files and communicate with remote systems
using serial lines. We'll talk in more details about this directory
in the section on Networking.
One directory that I didn't mention above requires special
attention: /usr/lib/sh. It
contains a single file and that file is a gold mine. Well, it's a
gold mine if you are a shell programmer. It contains a dozen shell
functions that can be used in many different circumstances. If you
are a shell programmer, take a look at this file and you will learn a
load of new tricks. I'll talk more about this file and those tricks
in the section on shells and shell programming.
Moving back up to the /usr
directory, we find the /usr/local
sub-directory. This may or may not contain anything. In fact, there
are no rules governing its contents. It is designed to contain
programs, data files, and other information that is specific to your
local system, hence the name. There is often a bin
directory that contains local programs and a lib
directory that contains data files or libraries used by the programs
Also in the /usr directory
is /usr/man. This is where
the man-pages and their respective indices are kept. This directory
contains the index files, which you could search through to find a
command you are looking for. You can also create and store your own
manual pages here.
The /usr/mmdf directory
contains all the programs and configuration files for MMDF. MMDF is
SCO UNIX's default mail system, which we will get into details
about MMDF in later chapters. By default the sub-directories in here
are readable by everyone, so you can poke around a little and see
what it's all about.
The /usr/spool directory
is the place where many different kinds of files are stored
temporarily. The word "spool" is an acronym for
simultaneous peripheral operation off-line.
This is the process whereby jobs destined for some peripheral
(printer, modem, etc) are queued to be processed later.
There are several sub-directories that are used as holding areas for
the applicable programs. For example, the
/usr/spool/cron directory contains the data files used by cron
and at. The /usr/spool/lp
directory not only contains the print jobs as they are waiting to be
printed, it also contains the configuration files for the printers.
As you might guess, since MMDF is SCO's primary mail system, the
contains mail messages that are being processed, waiting to be sent.
The same thing applies for /usr/spool/uucp.
The two directories /usr/spool/uucplogins
are used by UUCP when communicating with other systems via UUCP.
We'll talk about them later in chapters 10 and 13.
Lastly is a pair of directories that work together:
/opt and /var/opt.
Although these directories did exist in ODT 3.0, they were
essentially empty. However, these two directories are one of the key
components of OpenServer. These directories are used by the Static
Storage Objects (SSOs), which I will talk about in a moment.
Okay, so that's about it. There were many directories that I skipped
(As I said I would at the beginning of this section). Think about the
comparison that I made to a tourist map. We visited all the museums,
200-year-old churches and fancy restaurants, but I didn't show you
where the post office sub-stations were. Granted that such offices
are necessary for a large city, but you really don't care about them
when touring the city. Just as there are certain directories and
files that are not necessary for an appreciation and understanding of
the SCO UNIX directory structure.
What is SCO UNIX made of?
There are many aspects of the SCO UNIX operating system that are
difficult to put labels on. We can refer to individual programs as
either utilities or commands, depending on the extent of their
functions. However it is difficult to label collections of files.
Often the labels we do try to place on these collections do not
accurately describe the relationship of the files. However, I am
going to try.
If you have been working with an SCO system for a while, there are
certain aspects of the operating system that you may have heard of,
but not fully understand what they do. In this section we're going to
talk about functions that the system performs some of the programs
and files that are associated with these functions. We're also going
to talk about how many of the system files are grouped together into
what are referred to as "packages" and discuss some of the
more important packages.
In our tour of the SCO UNIX directory structure, I talked about the
/etc/perms directory and
described it as sort of a packing list. It is here in the files of
the /etc/perms directory
that the packages are defined. Each file in /etc/perms
has a name that reflects its function and the packages it contains. I
will go into more detail about the contents of these files in the
section on installing your system. However, I need to talk about some
of these packages in order to set the stage for many of the topics I
will be covering later.
Why is it important to know the names of the different packages?
Well, for the average user, it really isn't. However, the average
user logs on, starts an application and has very little or no
understanding of what lies under the application. The mere fact that
you are reading this book says to me that you want to know more about
the operating system and how things work together. Since these
packages are the building blocks of the operating system (at least in
terms of how it exists on the hard disk), knowing about them is an
important part of understanding the whole system. First, let's talk
about how the packages are broken down in ODT. You can get the names
of all the packages by running this command:
grep '#!' /etc/perms/*
In order to be able to do any work on an SCO UNIX system, you have to
first install software. Most people think of installing software as
adding a word processing program or database application, but any
program on the operating system needs to be installed at one time or
another. Even the operating system itself was installed.
Earlier, I referred to the SCO UNIX operating system as all the files
and programs on the hard disk. For the moment, I want to restrict the
definition of "operating system" to just those files that
are necessary for "normal" operation. SCO has defined that
set of programs and files as the Run-Time System or RTS. Although
there are many files in the RTS that can be left out to have a
running system, this is the base set that SCO installs.
The list of the files that compose the RTS package are in two files:
/etc/perms/rtsmd. If you examine these files, you see a major
separation in functionality. Whereas both contain very basic
programs, the /etc/perms/rtsmd
contain files and programs that are related to the hardware or the
machine itself. These are dependent on the machine, or machine
dependent, hence the name /etc/perms/rtsmd
(RTS Machine Dependent). (Note that these files do not
change if you have a different machine or architecture, but rather
the files are, for the most part, directly related to the hardware.)
Perhaps the next most significant package is the extended utilities,
or EXT package. These cover a wide range of areas such a printing,
mail, backups and adding users. Like the RTS, the extended utilities
have two files, /etc/perms/ext
and /etc/perms/extmd. Also
like the RTS, the file /etc/perms/extmd
contains machine dependent (machine related) programs and files. The
file contains only the link kit, which is the collection of files
used to create a new kernel. We will talk about the link kit in much
more detail later.
SCO has defined a set of files that it considers the base set of
extended utilities. This package is called BASE and contains such
things as an unlimited precision calculator (bc),
a calendar (cal) and a
disk copying program (diskcp).
SCO product units
One would be hard pressed to find an SCO system where users don't
print. Printing is one of the more common operations on a system. If
one is talking about the act of printing, the files and programs that
allow users to print are collectively called the "print
spooler." If one is talking about the files and programs
themselves, these files are referred to as "the LPR package."
This is what we will talking about here.
Contained within the LPR package are the programs that the system
uses to manage the printing process. These include the program that
schedules specific print jobs for specific printers: the print
scheduler; as well as the programs that actually send the files to
the printers. There are, of course, other programs that check the
status of the print process, stop and start the print schedule, etc.
We'll be talking in more detail about all of this in the section on
Another commonly used package is MAIL, which contains the files used
to communicate between users via electronic mail (what else). This
includes the mail program itself and its related programs, but it
also contains the MMDF files. Although MMDF, is actually part of the
MAIL package, it is often (although incorrectly) referred to as a
package on it's own.
Saying that the MAIL package contains just the files for
communication between users via electronic mail is not entirely true.
The MAIL package also contains a few other programs (write,
hello, and mesg)
that are used to communicate directly between users. This shows how
files are sometimes just lumped together in somewhat arbitrary
packages. For more information see the respective man-pages.
Similar terminology applies to the UUCP package. It contains more
than just UUCP. The UUCP (UNIX-to-UNIX copy) package can be used in
conjunction with mail, but can also be used on it's own to transfer
files between systems. This package also contains the modem
configuration and access files (referred to as "dialers" as
they dial the phone). However, the UUCP package contains more than
just programs to copy file between systems. There is also the ability
to start programs on the remote system (uux),
as well as a simple terminal program (cu).
The SYSADM package contains system administration programs. This,
however, does not contain the system administration shell, which is
considered part of the RTS package.
What the SYSADM package does contain is "supplemental"
administrative tools. This includes programs like last
which reports on the last time a user was logged in, or
ncheck, which can be used
to find out what file is associated with a particular inode. The
package also contains the tunesh
or Tune-Shell program.
The BACKUP package, like the SYSADM package does not contain most of
the files that do the actual backup, but rather contains supplemental
files, such as those used for scheduling backups. The "real"
backup programs, such as tar
and cpio are part of the
There are other packages that are less obvious, such as DOS, which
contain programs to access DOS disks; or CSH, which contains the
C-shell and it's support files.
Is that all? No, on an ODT or OpenServer system with the SCO
Development system installed, there are well over a hundred packages.
Many are rarely used. Many contain just a few files and are related
to a single entity such as the VI package that contains only vi
and it's related files.
Administering over a hundred packages is a big task. To make things a
little simpler, the packages themselves are grouped into larger units
called Service Components. These components are then grouped into
Services. Whereas the separation of files into packages occurs in the
files in /etc/perms, the
separation of packages into services and service components happens
in the files in /etc/perms/bundle.
Except for the entire Operating System or the RTS, each of these
services, service components and packages can be removed from or
installed on the system. The officially supported way to remove these
files is by using the custom
utility. It is important to use custom
to remove the files in a package, service components or
service. If they are removed or installed by hand, inconsistencies
can develop making it impossible to add or remove anything without
completely corrupting your system.
The newest shipping SCO operating system, OpenServer, has a
redesigned product organization. Some of the changes help in cutting
down software piracy, while others were implemented to help in remote
distribution of software. In this new organization, there is still
the basic concept of a "product." This is the unit of
software that you buy such as SCO OpenServer and has its own version
Each product is broken down into components. This is the
largest unit of functionality. TCP/IP cannot be (or rather is not)
broken down further for sale. However, it could be sold as a
stand-alone product, as it was before. Like products, components have
their own version number. Smaller than the component is the package.
This is the smallest unit of software that can be installed or
removed (not counting single files).
Software Storage Objects- SSO
Under OpenServer, the central concept of the new product structure is
the Software Storage Object (SSO). SCO designed the SSO
structure based on its concept of software management, which covers
installing, updating, removing and administering already installed
software packages. The files that make up a product can be separated
into those that remain unchanged (such as binaries) and those that do
change (such as configuration files). Each represents a particular
package and since there is one, unique SSO for each package, you can
have copies of different versions of the same software. Which is used
is dependent on the configuration and the connection to the SSO is
made through the use of what are called symbolic links. (More
on those later)
Although divided into products and components like ODT, in OpenServer
they take on greater significance in view of the importance of the
SSO. It is these components that are the "objects" of the
SSO. Because of the design of the SSO architecture, it is even more
important that components be more "self-contained" units
than in previous releases.
These components are broken down even further, like ODT and previous
releases. This is the concept of the package. These packages may
contain files or other packages. New to the SSO model is the idea of
a parcel. This is used for more complex products, where
breaking them into components and packages does not provide enough
"granularity." Therefore, a parcel is a unit of the product
smaller than the package. However, the distinction of what a parcel
is not as clear cut. There is the OpenServer Enterprise product,
which contains the Graphics parcel, for example. It is also possible
for parcels to cover portions of multiple components. For example,
the man-pages and other documentation may be thought of as a parcel.
An SSO is essentially broken down into two parts. There is a part
that is shared and other machines have access to it. These are kept
under the /opt directory.
The other part belongs to one specific client and is not accessed by
other machines. These are kept in /var/opt.
Here a client is any machine that uses the SSO, including the local
Files within the SSO have several characteristics. A shared file
is one that clients can read only. The only copy of a shared file is
in the original location within the /opt directory. Why make copies
when they aren't going to get changed anyway? As you might guess,
non-shared files are ones that can be modified by the client.
To keep these separate from the shared files, these files are copied
into /var/opt. These files
now belong to the client.
Public files are visible and accessible outside of the SSO.
These are made available to the rest of the world (users and other
SSOs) as links. Almost exclusively, these are symbolic links, which
have grown to become one of the primary administrative tools in
OpenServer. These links make the real location of the file
transparent to the system and applications. Private files are
only visible to that SSO.
This provides a very important advantage. Let's first consider files
that are not modified by the clients, that is, the shared files.
These generally consist of the programs (versus data or configuration
files) belonging to a particular package. Every client with a
particular version of a package will be using the same programs and
utilities. The non-shared files are the data and configuration files.
These are the aspects of that package that are applicable only to
that particular client. Why should other clients have access or even
care what is in these files?
By keeping these two separate, all you need to do when updating a
package is to update the program portion and leave the data portion
alone. This essentially eliminates problems with updating packages
where configuration files would often get overwritten during the
update. Since only the program files are getting update, there is
less fear of overwriting the data files.
Reside in /opt. Not
linked to an external directory.
Copied to /var/opt
on each client. Not linked to an external directory.
Reside in /opt.
Linked to an external directory.
Copied to /var/opt
on each client and linked to an external directory.
Table 0.1 Relationship of Static Storage
This is one reason why things are done with symbolic links. Like a
regular link, a symbolic link is just another name for a given file.
However, symbolic links do not need to point to anything "real."
It is not until the file is accessed that something needs to be
there. We can then overwrite the real file, without the symbolic link
being effected. In addition, this scheme allows us to backup the data
components without having to backup the programs files.
Okay, so we now have an idea of how everything works, now let's take
a look at where everything is. To find where the actual files you
need to dig deep. To help let's take look at a road map. The program
files for a particular component are found in:
The data files are found in:
This directory is called a component's SSO root. For
example, the SSO root for the SCO Operating System, version 5.0.0d,
So, what's with the K and P? Well, the single letters
were chosen in order to keep the names as short as possible. Second,
P refers to both products and packages. As for the K, well
that stands for component. Originally, this was a C, which was
often confused with the C programming language. Instead they used K.
Urban legend has it that one of the members of the SCO SSO
development team is Norwegian and "Komponent" is the
Norwegian spelling of "component."
In order to allow different vendors to use the same component name
without conflicts, the vendor code defines a unique vendor. In
this case, the vendor code is SCO as we are referring to SCO
products. The component code is used to uniquely
identify a component. The version number is, as one might
guess the version of that particular component. By including version
numbers in this scheme, it is possible for different versions of the
same component to exist.
What SCO UNIX Does
On any operating system there is a core set of tasks that are
performed. On mutli-user or server systems such as SCO UNIX these
tasks include adding and configuring printers, adding and
administering users, and adding new hardware to the system. Each of
these tasks could take up an entire chapter in this book. In fact, I
do cover all of these, and many others, in a fair bit of detail later
However, I think it's important to briefly cover all of the basic
tasks that an administrator needs to perform in one place. There are
a couple of reasons for this. First, many administrators of SCO UNIX
systems are not only novice administrators, they are novice users.
They get into the position as they are the only ones in the company
or department with computer experience. (They've worked with DOS
before) By introducing the varied aspects of system administration
here, I hope to lay the foundation for later chapters. I first tell
you that a car has a motor, brakes, a steering wheel and a
transmission. Then, I tell you how each works.
Second, the average user may not want to get into the details that
the later chapters provide. So here, I give an overview of the more
important components. Hopefully, this will give you a better
understanding of what all goes into an operating system as well as
just how complex the job is that your system administrator does.
One of the first things that gets done is that users are added to the
system. Access is gained to the system only through user accounts.
Although it may be all that a normal user is aware of, these accounts
consist of substantially more than just a name and password. Each
user must also be assigned one of the shells, a home directory and a
set of privileges in order to access system resources.
Although the system administrator could create a single user account
for all users to login as, it ends up creating more problems than it
solves. Each user has their own password and home directory. If there
were a single user, everyone's files would be stored in the same
place and everyone would have access to everyone else's data. This
may be fine in certain circumstance, but not in most.
Users are normally added to the system through the system
administration shell (sysadmsh
in ODT ) or the Account Manager portion of scoadmin
in OpenServer. Here, when adding a user, you can input that
user's default shell, their home directory as well as their access
privileges. Should you need to change any of that for a particular
user, this is also done through the sysadmsh/SCOAdmin.
In addition, they are also used to "retire" or remove a
One of the key aspects of a user account on an SCO UNIX system is the
concept of privileges. Starting with SCO UNIX 220.127.116.11, there are four
levels of security that, among other things, specifies the range of
tasks the user is authorized to do. The higher the security level,
the less a user can do by default. If the security level does not
allow access to a particular function by default and the user must
have access, the system administrator has the ability to change this
through the sysadmsh
or the Account Manager.
Another very common function is the addition and configuration of
system printers. This includes determining what physical connection
the printer has to the system, what characteristics the printer has
(in order to choose the appropriate model printer) as well as making
the printer available for printing.
Adding a printer is accomplished in three ways. As you would
guess, the first is through the system administration shell. The
second is by running the command /usr/lib/sysadm/lpsh
or mkdev lp
on ODT 3.0 or
running the Printer Manager or mkdev
lp on OpenServer. Why so many different ways? Well, both lpsh
and mkdev lp are
the same under ODT 3.0 and mkdev
lp and the Printer Manager are the same on Open Server. The
program that is called in the end is the same one every time. It is
simply to make things easier for administrators who may have come
from older systems without the new front-ends.
What happens when you want to remove a file and inadvertently end up
removing the wrong one (or maybe all of them)? If you are like me
with my first computer, you're in big trouble. The files are
gone, never to show their faces again. I learned the hard way about
the need to do backups. If you have a good system administrator, he
or she either has already learned the lesson and makes regular
backups of your system.
There are several ways of making backups and several different
utilities for doing them. Which program to use and how often to make
backups is completely dependent on the circumstances. The system
administrator needs to take into account things like how much data
needs to get backed up, how often the data is changed, how much can
be lost, and even how much will fit on the backup media.
Using the versioning capabilities of SCO OpenServer,
even the hassle of restoring from backups has been eliminated. With
versioning turned on, you can undelete files that you have removed as
well as automatically save multiple copies (versions) of files.
There are things that an administrator may need to accomplish at
regular intervals such as backups, cleaning up temporary directories
or calling up remote sites checking for incoming mail. The system
administrator could have a check list of these things and a timer
that goes off once a day or every hour and he or she could do all
these chores by hand.
Fortunately, you don't have to. One of the basic utilities in every
UNIX version is cron. Cron
(the 'o' is short) is a program that sits in the background and waits
for specific times. When these times are reached, it starts
pre-defined programs to accomplish various, arbitrarily defined
tasks. These tasks can be set to run at intervals ranging from once a
minute to once a year, depending on the needs of the system
Cron 'jobs' (as they are
called) are grouped together into files, called cron tables or
crontabs, for short. There are several that are created
by default on your system and many users and even system
administrators can go quite a long time before they notice them.
These monitor certain aspects of system activity, clean up temporary
files, and even check to see if you have UUCP jobs that need to be
What about a program that you only want to run one time at a specific
time and then never again? SCO UNIX provides a mechanism: at.
Like cron, at
will run a job at a specific time, but once it has completed, the job
is never run again.
There is a third command that relates to cron
and at. This is the batch
command. This differs from the other two in the fact that batch
gets around to running the job you submit, whenever it has time. That
is when the system load permits.
What goes with SCO UNIX?
Throughout this book, we are going to be talking a great deal about
what makes up the SCO UNIX operating system. Up until the newest
release it could be purchased as a single product under the name SCO
UNIX System V/386 Release 3.2 Operating System Version 4.2. This
product contains, the run-time system and the extended utilities
(including UUCP, MMDF, LPR, etc).
For many companies or businesses, that's enough. You may have a
single computer with several serial terminals attached, running a
word processor, database or some other application. However, when a
single computer is not enough, the SCO UNIX product does not provide
you everything that you need.
Suppose you want to be able to connect all the computers in your
company into a computer network. The base SCO UNIX product does
provide them with a certain networking capability with UUCP. However,
this is limited to exchanging files, remotely executing programs, and
simple terminal emulation. However, for the most part, this is
limited to serial lines and the speed data can be transferred is also
So it was in dark recesses of ancient computer history. Today,
products exist that allow simultaneous connection between multiple
machines with substantially higher performance. One such product is
SCO's TCP/IP (Transmission Control Protocol/Internet Protocol). So,
if a company decides it needs an efficient network it might decide to
install TCP/IP, which has become the industry-standard for connecting
not only UNIX Systems, but other systems as well.
The SCO TCP/IP Runtime System allows users log into remote systems,
transfer files, use printers anywhere on the network, as well as send
and receive electronic mail. Plus, the group of protocols that
composes TCP/IP serves as the bases for many other programs and
There is a problem with TCP/IP that many companies run into. Suppose
you want everyone in the company to be able to access a specific set
of files. With TCP/IP you could devise a scheme that copies the files
from a central machine to the others. However, if the files need to
be changed, you need to ensure that the update files are copied back
to your source machine. This is not only prone to errors, but it also
Instead, why not have a single location where the source files
themselves can be edited? That way, changes made to a file are
immediately available to everyone. The problem is that TCP/IP by
itself has nothing built in to allow you to share files. You need a
way to make a directory (or set of directories) on a remote machine
appear as if it was local to your machine.
Like many operating system vendors, SCO provides an answer: NFS
(Network File System). With NFS, directories or even entire
filesystems can appear as if they are local. One central computer can
have the files physically on its hard disk and make them available
via NFS to the rest of the network.
Soon you discovered the wonders of a graphical user interface (GUI).
Maybe at home you use Microsoft Windows or have a Macintosh and are
used to being able to point and click or having multiple sessions or
terminals on the screen at the same time. SCO provides a solution in
the form of X-Windows. This was available separately as the X-Sight
product. However, the new OpenServer has X bundled with every version
Since you just switched to SCO UNIX, you still have quite a few DOS
applications that you can't live without. Rather than making you junk
all of your DOS applications, SCO provides a solution: SCO Merge.
SCO Merge actually runs MS-DOS 5.0 in ODT and 6.2 in
OpenServer. Each of these is licensed directly from Microsoft. Merge
can support most character-based MS-DOS applications on terminals or
the system console, as well as graphical MS-DOS applications on the
system console or X11 graphics terminals. Since it behaves like a
real MS-DOS machine, SCO Merge provides access to thousands of MS-DOS
applications, even many that bypass MS-DOS and access the hardware
The only limitation is that since it is a software emulation, SCO
Merge cannot run programs in 386 protected (enhanced) mode. This
includes running MS-Windows in enhanced mode. However, this isn't
a problem as you can run it under Merge in standard mode just fine.
In fact, you can start SCO Merge from within X-Windows and then start
MS-Windows. You end up with windows within windows.
Okay, you bought the operating system. Soon you discovered that was
not enough, so you got TCP/IP and then NFS. A short time later, you
wanted the best of both worlds so you got X-Windows and SCO Merge.
Each time you had to lay out several hundred dollars.
After running for a few months, you discovered that SCO offers all of
these products together in a package called Open Desktop. You're
annoyed that you had to install everything individually, but when you
see how much you could have saved by buying everything at once in the
form of Open Desktop, you get angry.
Phone calls to your distributor and then to SCO have little effect.
You bought separate products, each with their own price so it only
makes sense that you pay the price for separate products. Just as
power steering costs more when you get it installed after you have
the car than it would if it came equipped with it.
You got penalized for not considering all the options when you first
purchased your system. That's the nature of the business. That's the
nature of any business. If you buy more at once, it usually comes out
being cheaper. At least that was the way it was originally.
Well, SCO thought that was wrong. By "forcing" you to buy
something you may not need just because you can get it cheaper is
great for business, but only for short term business. It looks good
on paper, but when your customers never come back because your "hard
sell" put them off, you lose in the long run. Instead, SCO came
up with a way of allowing you to let your system grow as your needs
change, without having you lose any money.
When you purchase the SCO UNIX operating system on tape or CD-ROM,
the media already comes with the other products. If you purchase one
set of products and later discover you need more, you can easily
purchase the missing components for only the difference between the
product you have and the product you want. You don't pay for what the
products would cost separately.
One company might only need the networking capabilities so there is
no need to by X-Windows or SCO Merge. So, SCO created the "Network
Bundle" that contains only the network products such as TCP/IP
and NFS. Perhaps a user needs a workstation capable of running
X-Windows across a network. The solution is ODT Lite, which contains
only X-Windows and TCP/IP. If you decide that you need everything
including the kitchen sink, there is the SCO Open Server Enterprise
System. (Including your choice of Captain Kirk or Picard) With the
right kind of trickery you could pull off the components that you
want but didn't pay for. However, there are some problems with this.
First, it's software piracy. It would be the same as if you copy
software from someone else. You are using software that you didn't
Second, you won't get support for it. SCO can tell what product was
purchased and what components that product has. Suppose you bought
the Network Bundle and figure out a way to extract the files to make
it the Open Server. If you call into SCO Support for help, they will
know what is going on.
Lastly, you can't. The serial number and activation key are matched
to the product you have. If you purchase the Network Bundle and try
to install X-Windows, for example, you can't. The serial number and
activation key you have won't work with X-Windows. Also if you try to
use that same serial number on a machine that just has the operating
system in an effort to get TCP/IP, that won't work either.
SCO's newest product line can be broken down into three
separate products. Although the base operating system is the same in
each case, the components each has is based on the intended purpose.
The Host System product is intended for "turnkey" solutions
as well as other situations were networking is not required. An
example of this would be a point-of-sales system. Despite the lack of
networking, the Host System contains full X-Windows capabilities.
Next is the Desktop System. As its name implies, this system is
intended to sit on your desktop and is designed as a single-user
workstation. It does contain full networking and graphical support.
One added feature of SCO Open Server is their new Desktop filesystem.
In this a compressed filesystem that allows up to 1 Terabyte (A
Mega-Megabyte) of data!
At the top of the line is the Enterprise System. Due to the recent
and long overdue demise of his predecessor, this version of the
Enterprise System only comes in the Picard version. (Okay, the joke's
getting old) This is a superset of the tools and functionality of the
Host System. In addition, it has built-in networking in the form of
TCP/IP, NFS, IPX/SPX, Netware Gateway, as well as LAN Manager Client
support. The Enterprise System also enables you to do network
installs. That means the actual files used for an installation exist
on a server on your network and are copied to the machine you are
A major change since ODT 3.0 is the distribution media. For those of
you who still only have a 5.25" floppy, you are out of luck.
None of the new SCO products are available on 5.25". In fact,
the only one that is available even on 3.5" floppies is the Host
System. Although you do get a single 3.5" to boot from, both the
Desktop System and the Enterprise System are available only on CD-ROM
or 150MB cartridge tape. Earlier releases fit on 60Mb cartridge tape.
However, even with compressing things, the operating system no longer
fit on the 60Mb tapes.
SCO has also decided to reduce the number of printed manuals that
come with the system. Each product will be shipped with both Release
Notes and the SCO OpenServer Handbook. However, the remainder of the
documentation is shipped on-line. This is all written in the
Hypertext Markup Language (HTML). Hypertext is the concept whereby
you click on many of the words and phrases, which then jumps you to
other parts of the documentation or even other documents.
The basic format of the on-line documentation reader is the same as
MOSAIC, which many net surfers are familiar with. This provides not
only a history mechanism, but allows you to define "bookmarks"
that you can use to immediately jump to places that you access
regularly. The only major shortcoming is its searching abilities.
Although you can search, as of this writing they are limited to
single words, so you need to be careful with what you search for.
We'll talk more about the documentation reader in the section on SCO
If, like me, you find that you cannot live without hardcopy
documentation most of the on-line documentation is available in
printed format in two sets. The first set contains the Operating
System User's Guide and the System Administrator's Guide. The second
set contains the man-pages.
Another major change that I find particularly neat is the fact that
many add-on products are included on your distribution media. This
includes: SCO Symmetrical Multiprocessing (SMP-The successor to MPX),
SCO Virtual Disk Manager, SCO Merge, SCO Windows Application Binary
Interface (Wabi) and the SCO OpenServer Development System. Some,
like SCO Wabi and the SCO Development System, contain additional
At first this seem odd to me. Without even asking for it, let alone
paying for it, SCO provides you the software for all sorts of
wonderful tools. They will even allow you to install it. However,
having it run is a different matter. This is all accomplished by the
SCO License Server.
The SCO License Server is a set of programs that runs on you system
and "allows" other programs to run. Each system has a
license database that allows licensed (purchased) products to run.
All the licenses are all contained in a database. When a program
starts, it first checks the license server to see if it is licensed.
If so, all is well. If the product is not licensed, the system will
tell you and won't allow you to run. A single license server can
manage multiple machines, thereby allowing licenses to be used where
needed and not restricted to single machines.
Each product has a License Number, which is a unique number
identifying each SCO product. There is a License Code, which is used
to activate the product. The third piece of information provided with
your license is your License Data. This is not always present on the
Certificate of License and Authenticity and is, therefore, not
required in those cases.
One disadvantage I see with the License Server is something that
could have been left out. However, the marketing people have a very
strong voice in any company the size of SCO. As a result, you are now
required to register your product within a predefined grace period.
If you don't, you get annoying messages when you login that says the
software is unregistered.
As the system boots, you will get a message saying that you have to
register and that the reason is to prevent software piracy and keep
you informed on updates, etc. Although, you are not actually forced
to register, if you don't, "reminders" will continue to
appear at system start-up and even after you have logged in.
Generically this is referred to as "nag-ware."
When your system is installed, a SCO System ID is generated. This is
a unique number, specific to your machine and is used to identify
your SCO OpenServer installation. Since it is generated each time
your system is installed, a new SCO System ID is generated, if you
reinstall your SCO OpenServer system. You can find out your system ID
by running the License Manager.
When you register, the Registration Center will issue you a
Registration Key for each product. Another very annoying feature is
that The Registration Key is tied to the SCO System ID and therefore
you must re-register your SCO products if you reinstall your SCO
Next: Reading all about it — SCO Documentation
Next Chapter: Shells and Basic Utilities
Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of
Be sure to visit Jim's great Linux Tutorial web site at http://www.linux-tutorial.info/