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/
2 Free Sco
What you get on the CD is a complete version of the SCO OpenServer
Desktop System. In all the work I have done, I have found no
limitations as compared to the commercial version. Well, you are
limited by the fact that you cannot use the product in your business.
However, this is a limitation in the license and not the product
In addition to the SCO OpenServer Desktop System, you will find four
other products. The first is the SCO Advanced File and Print Server,
which will talk about later. Next is SCO Doctor Lite, which is a very
useful monitoring tool. Next is ARCServe Lite, which is a
well-rounded back-up tool. Finally, there is the SCO OpenServer
development system, which allows you to develop your own programs.
A Quick Tour
If this is your first experience with SCO, then there are a few
concepts that you need to know about before you go on. Many of these
issues were things that we had not addressed in the first book, while
others are things that I went into some detail about. Rather than
repeat myself too much, I am only going over the very basic
information to get you started.
I would like to point out some things specific to the first book.
Chapter 1 is an introduction to basic operating system concepts. I
talk about things like processes, files, and directories. If you
understand what these mean in a UNIX context, then you can skip this
Chapter 2, "Basics of SCO” talks about just that. I go
into detail of how SCO is laid out. I not only talk about directory
structure and what their function is, but I also talk about the basic
parts of an SCO system. I discuss what components go into making the
SCO OpenServer product. This gives you a good overview of what your
system can do.
In Chapter 3, Shells and Basic Utilities, I talk about the primary
interface between the users and the system: the shell. If you are not
comfortable with any of the UNIX shells, you will be after reading
Subsequent chapters go into the details of the various aspects of the
system. Each is important to running you system, so I would suggest
that at one time or another you look through them. Although each
chapter is not completely separate from the others, I try not to
repeat myself too much.
In case you hadn't guessed, SCO OpenServer is not like DOS.
Aside from the superficially similar command lines, they are quite
different. Whereas DOS uses the CONFIG.SYS file to configure drivers
into the system, these are already part of the operating system,
lovingly called the "kernel.” In general, this is the
same way that Windows NT does it.
Another key difference is that it is a multi-user system. Although
there might be several users accessing a Windows NT machine, the
primary purpose of the system is simply to give them files and
provide them printer services. You may be able to use the telnet
program to access a command prompt on a running system, but
having two users running applications on the same NT system is not
what it was designed for.
When they are created, each user is assigned a specific "shell”.
This is the general term used for the command line interpreter that
is automatically started when the user logs into the system. Like the
DOS AUTOEXEC.BAT file, each shell has a configuration file or files
that are processed each time you log in. These files are stored in
the user's home directory (the default when they log in). You
can see these by running:
There are also some system wide defaults found in the /etc
directory. These are the files /etc/profile
and /etc/cshrc. For
details on when these files are used, take a look in chapter 3,
Shells and Basic Utilities, in the first book.
If you will look at the previous example of the ls
command you will also notice another key difference. Options
to commands in UNIX are given using a dash (-), whereas (in most
cases) they are given to DOS commands with a slash (/).
Another key difference is where each system will look for
commands to execute. In DOS, Windows, and UNIX, the system allows you
to input a command without specifyingy it's exact location on
the system (including all of the directory names.) Instead of
searching the entire system each time you want to start a program,
the system only looks in a small sub-set of the possible directories.
This sub-set is something that you define and often referred to as
the search path or simply path. The difference is that
both DOS and Windows will search in your current directory, even if
it is not in your path. UNIX will only search your path. Therefore,
if the command you are looking for is in your current directory, but
this directory is not in your path, the system won't find it.
If you compare a DOS/Windows path to a UNIX path, you will
notice that the DOS/Windows path contains drive letters, whereas the
UNIX path does not. This is because UNIX does not use drive letters.
When a new hard disk/partition is connected to a DOS/Windows system,
the only way to do so is assigning it a new drive letter. Under UNIX,
you can connect the new drive (called mounting) to any directory on
the system. All files and directories are referred to in relationship
to the root directory and not just some arbitrary drive letter.
Finding Out About Your System
Without a doubt, you will need to find out how to do something on
your system. Although these two books provide a wealth of
information, they cannot come close to the scope of the documentation
that SCO provides for you on-line. This is the same source that's
available in most every dialect of UNIX. These are the manual pages
or simply man -pages.
Accessing the man pages is done using the man
command followed by the name of the entry you are looking for. For
example, to find out about all the options for looking at the
contents of directories using the ls
command, you would enter:
man lsThis will then bring
up the manual page for ls.
The man command supports a
wide range of options to help you find the exact manual page you are
looking for. To find out all of these options simply input:
One of the most useful options is -k,
for keyword. This tells the man
command to search for all man-pages that contain the input keyword in
their title. For example, if I wanted to find all man-pages with the
word "directory” in their title, the command would look
man -k directory
Be careful what words you search for, as you may bite off more than
you can chew. Even the example above should give you at least a dozen
entries. On my system I get close to 100! Therefore, you should send
the output through the more
command like this:
man -k directory | more
In other words, we would say that we are piping the output of
the man command through
more. The horizontal line
is referred to as the pipe symbol.
There are two things more about the manual pages. First, in
OpenServer 5, SCO changed the way they were stored on the system.
They are now stored as compressed HTML (Hypertext Markup Language)
pages. Compressed means that they are squished down to save size and
HTML means that they are in the same format as pages on the World
Wide Web (WWW). SCO has incorporated the manual pages into SCOHelp,
which also include the other manuals, such as the User's Guide
and the Administrator's Guide. (More about this in a moment.)
This provides a single interface to all of the documentation.
This advantage brings with it a small disadvantage. SCOHelp requires
that there be a server on the system, similar to the server that
provides access to the WWW. When the system is first started and you
bring it into maintenance mode, there is no WWW server running.
Therefore, the man-pages are not available. To correct this simply
For more details on this see the man
and scohttp man-pages.
Another way that you can get access to information is through
SCOHelp. Unfortunately, this does not work from the command-line, so
you need to be running the X Windowing System. On a default system,
when you start X (either it is started for you automatically or you
start it with startx), you
will have a desktop with several different icons. In the upper right
hand corner is an icon that looks like life-preserve with the word
What gets started is a modified version of the Mosaic Web browser.
The first page that is brought up is the list of all of the available
documentation. Just above the list is a short paragraph telling you
what it means if the text is not a hyperlink. There is a link
labeled, "more information.” Click on this to get some
basics in moving around in help.
Managing Your System
The term "managing your system” covers an
incredibly wide range of subjects. Everything from adding users to
hardware to network security are part of this. I talked about the
details of this in the first book, but failed to address it from an
overview perspective. Changes have been made to SCO UNIX since it was
Open Desktop to when it became OpenServer. The result was a system
that is easier to administer, but might be a little more difficult to
In essence, your system can be managed from a single program:
SCOadmin. It will provide the interface necessary to add users,
configure your hardware, set up network security and many othermore
issues. There is both a graphical- and character- based interface
which to allows you to administer your system both locally and even
across a modem.
Although accessed through a single name, SCOadmin is actually made up
of several programs, called managers. Each can be started
individually or through the SCOadmin hierarchy. To make things
simple, I will refer to both the program on the hard disk and the set
of programs simply as SCOadmin.
Although the appearance is different, this is the same set of
programs whether started from a character terminal or from X. Let's
assume you are running X, for the moment. A little later, we'll
talk about the character interface. On the desktop is the "System
Administration” folder. Double-clicking on this is the
graphical equivalent of starting scoadmin
from the command line. When the folder opens, you see what is in Figure 0-1.
This is the top-level hierarchy of SCOadmin. You see all of the files
and folder you would had you started it from the command line.
Figure 0-1 SCOAdmin Startup Window
At the top of the list are several managers, marked with what looks
like a Swiss army knife. At the bottom are entries marked with a
folder. Clicking these (such as Networks, as shown in Figure 0-2),
you will see some other managers and maybe even other directories.
This hierarchy can be added to at any time to create your own
managers. See the scoadmin(F)
man-page for details.
author: (F) after scoadmin OK?
Figure 0-2 SCOAdmin Network Window
At the bottom of Figure 0-2, you will see the two dots followed by
the work "Networks” to indicate the we are in the
Networks folder. If we to click on the "NetWare” folder,
we would see "Networks/Netware”. Clicking on the two dots
brings us up one level to the "parent.”
Each of the managers has a similar interface. However, since they are
accessing different parts of the system, the information you input
and the exact interface will be different. When you click on one of
the managers a new window will open. At the top will be a menu that
is dependent on the manager you started. However, in each case, the
Help menu will be the same. To get the specific details of the
particular manager you are in, select the entry "On Window”
in the Help menu.
One thing that many people have trouble with is that movement
with the keyboard is not always intuitive. Because of this, let's
run through one of the managers to get a feel for things. Since you
are probably going to add users to your system and it requires a lot
of different input, let's look at the account manager.
When you start the Account Manager, you get something that looks like
Figure 0-3. At the top, you have the expected menus, followed by the
tool bar and the content area. In this example, the window is not
large enough to list all of the users. To see the rest, you can use
the scroll bar on the right.
Figure 0-3 SCO Admin Account Manager
Movement is accomplished using the keyboard, or you can go
directly to something using the mouse (as one would expect). In this
example, there is nothing in the content area other then a list, so
only the up and down arrows work. If you press the TAB key, you might
notice that the border around the content area gets thicker and
thinner. When it is thick, the content area has the focus. (Meaning
the arrow keys are active.) When it is thin, the toolbar has the
focus. I have found that on some systems, you cannot tell which of
the buttons is active. Also, it is not the ENTER key that activates
the button, but rather the spacebar. To make sure I know what I am
clicking on, I normally use the mouse to activate buttons and menus.
Menus can also be activated using hotkeys. If you look, you will see
that certain letters are underlined. For example, the ‘t'
in the Host menu. By pressing ALT-T, you open up the Host menu. Here
the arrow keys can be used to move up and down this menu or across to
the other menus. We can also use the hotkey to open specific menus.
You will see that an active menu has a thicker border. Here pressing
the space bar or the ENTER key will select that menu. When you
open a menu, the top entry is always active. If we pressed the space
bar in the Host menu, a dialog window would open up in which we could
select another host to add users on.
If we clicked on the button with the one person, we could add a new
user. Clicking the button with the three people allows us to add a
group. The magnifying glass would allow us to examine and change
certain values for the current user select. Finally, the trash can
would remove the currently selected user. So, let's add a user
by clicking on the first button, which brings up the screen in Figure 0-4.
Figure 0-4 SCOAdmin Account Manager —
Add New User Window
Rather than going through the meaning of each field, I am going to
just talk about moving around within the window. In order to access
certain parts, we need to input a user name. Once you have input a
user name, you will notice that the buttons on the right hand side
are no longer grayed out. This is because you can't change user
parameters unless you have a user.
If you tried to move up and down using the arrow keys, you will see
that it does not work. To do so, you press the TAB key. If you were
in the Login: field and pressed the TAB key four times, you would
jump first to User ID, then to Comment, then to Password, and finally
to Change Login Shell. There are two things to note here. First,
although there are two options for the Password, it is still
considered a single field. I guess this is because it can only take
on a single value.
Also, you next went to the Change Login Shell button, rather than the
input field. When in the input field, I have tried to input a value
on my own. This does not work. (At least I can't get it to
work.) Instead, when I am on the Change Login Shell button, I press
the space bar to bring the screen in Figure 0-5. When the input field
showing the default shell (sh) is active, we can use the up and down
arrows to scroll through the choices. Or we can click on the down
arrow and select the shell we want.
Figure 0-5 SCOAdmin Account Manager —
Change Login Shell Window
Pressing the TAB button, you see that there are only three fields.
Here again, the OK, Cancel and Help buttons are considered a single
field. To move between these buttons, you use the left and right
arrow keys, like the menus.
If you select the "Change Home Directory” button, you
will see that the input field "Home Directory” can be
set to any value. When weclick on the OK button, we may get a screen
to input the user password, depending on what we selected in the
Password field at the top.
One thing that I forgot to mention is that pressing the shift, along
with the TAB key, moves you back in the opposite direction.
If you start scoadmin from
the command line you will get a character-based interface, in which
you use the keyboard to move around. I have tried using the mouse
(see the usemouse man-page
for details). However, the cursor moves around too much, so I stick
to the keyboard. Movement is essentially the same as in the X
version. Movement within a field is done with the arrow keys and
movement between fields is done with the tab key.
The structure of the directories on a SCO system is similar to
others on the large scale. However, there are a lot of differences
that may make finding things difficult. This something that I went
into detail about in the first book, but I need to talk about it here
for the beginners in the group. Keep in mind that this is an very
quick overview. In Chapter 2 of the first book, The Basics of SCO
UNIX, I go into much more detail and cover many more
directories than I do here.
The top most directory is referred to in speech as the root
directory. You will see it written as /.
Note that in SCO, as well as all other dialects of UNIX, the
directory separator is a slash, just as in DOS and Windows. However,
in UNIX the slash goes from the lower left to upper right (/),
whereas the DOS slash goes from the upper left to lower right (\).
The DOS slash is often referred to as a backslash.
Underneath the root directory is the bin
directory, which contains a large number of programs. The word bin
is short for binary as executable programs are often referred
to as binaries. You will also find a lot of binaries in the /usr/bin
directory. It is not easy to separate the function of these
files by simply saying that those in /bin
are primarily system related and those in /usr/bin
are user related. This is true, to some extent, however, there
is some overlap.
Adding to the confusion of where the system programs are is the /etc
directory. Although there are no programs here that a normal user
should be running, there are a lot of system programs here. In
addition to system programs, a large number of system configuration
files are kept here as well. One primary location is the
Here are the defaults for a wide range of system parameters. These
are all text files and can be viewed with any text editor or a
program such as more
Also under /etc
is the auth directory.
This contains security-related information about your system. The
provides details about authorizations based on "subsystems”
such as memory, printing, backups, etc. The system
directory contains general system information. Coupled with this is
directory. TCB stands for Trusted Computing Base which is the
foundation of a C2 level of security. The /tcb/bin
directory contains the executable programs used in security
administration. The /tcb/files
directory contains the set of user-based authorizations. For details,
see the section on security in Chapter 4, Users and User Accounts, in
the first book.
directory contains all of the device files or device nodes
that the system uses. In UNIX devices are accessed through files.
This has the advantage that you can access devices just as you can
files. You do not need to write special routines into your programs
to do so. If the device driver (the part of the kernel that directly
accesses the hardware) is configured, you can access any hardware
just like a file (provided the system administrator gives you the
permissions). For simplicity's sake, we can say that device
nodes are simply directory entries. When opening these "files”,
the system know that these are device nodes and reacts accordingly.
My advice is to leave these alone unless you know what you are doing.
I have dealt with customers who were "cleaning up” and
removed some "unneeded” files in /dev
which made their system unusable.
Perhaps the largest directory on your system (at least the one with
the most files) is /opt.
This contains the vast majority of the files on your system. SCO uses
something called "symbolic links” which enables the
system to make it appear as if files are where you expect them to be.
However, the files are actually located somewhere else on the system.
That "somewhere else” is the /opt
directory. (We go into a little more detail later.)
I mentioned that the /usr/bin
directory contained user-related executables. This generalization can
also be made about the /usr
directory. This is also where the system puts user's home
directories, by default.
The /var directory is
another place that actually contains the files and directories. In
general, one can say that this directory contains files that vary,
hence the name var. One
directory that is a symbolic link to a directory under /var
is /usr/adm. This
is the central location where system log information is kept. Also
under /var is the spool
which is where /usr/spool
is linked to. The spool directory
is a kind of temporary location where the system processes request
that it does not need to handle immediately, such as printing, mail
and UUCP. These requests are "spooled” and processed in
the background as the system "gets around to them.”
Booting the System
When a SCO system first boots up, you will see a prompt that says
something like this:
This, as you might have guessed, is the boot prompt. If you let it
sit there long enough (normally 60 seconds), the system will boot
automatically. As it does so, you will see a series of dots flash
across your screen. This tells you that the system is being loaded.
There will be a moment when the screen goes blank and you will then
see a list of hardware. This is what is referred to as the hardware
screen and lists what hardware the kernel has found on your system.
On my system, the hardware screen looks like this:
vec=13 dma=- type=80387
base=0x3F8 offset=0x7 vec=4 dma=- unit=0 type=Standard nports=1
base=0x3F2 offset=0x5 vec=6 dma=2 unit=0 type=135ds18
vec=- dma=- unit=vga type=0 12 screens=68k
base=0x330 offset=0x2 vec=11 dma=5 type=ad rev=01 ha=0 id=7 fts=s
base=0xCF8 offset=0x8 vec=- dma=- am=1 sc=0 buses=1
vec=- dma=- PM v1.2
base=0x300 offset=0xF vec=15 dma=- 3Com EtherLink III, unit = 0
vec=- dma=- type=S ha=0 id=2 lun=0 bus=0 ht=ad
vec=- dma=- type=S ha=0 id=0 lun=0
vec=- dma=- type=S ha=0 id=0 lun=0 bus=0 ht=ad
vec=- dma=- cyls=1170 hds=64 secs=32 fts=sb
vec=- dma=- type=S ha=0 id=5 lun=0 bus=0 ht=ad
vec=- dma=- cyls=1317 hds=64 secs=32 fts=sb
vec=- dma=- type=S ha=0 id=6 lun=0 bus=0 ht=ad
vec=- dma=- cyls=1317 hds=64 secs=32 fts=sb
vec=- dma=- Vendor=ARCHIVE Product=VIPER 150 21247
vec=- dma=- type=S ha=0 id=4 lun=0 bus=0 ht=ad
If you had let the system time out at the boot prompt, it will
automatically bring you into what is referred to as "multi-user”
mode. This is the normal running mode of the system, where all of the
normal functions have been started. If you had pressed the enter key
at the boot prompt, the system will stop at the following prompt.
Type CONTROL-D to proceed with
give root password for system maintenance):
If you input the root user's password at this prompt, you will
enter single-user or maintenance mode. It is referred to as
single-user mode as only a single user is working on the system. It
is referred to as maintenance mode as it is normally used only to
perform system maintenance. When in maintenance mode you can type in
exit which will then bring
the system into multi-user mode.
Both single-user mode and multi-user mode are referred to by
different names. They fall into what is called "run-levels”
as these are the states that the system runs in. In each of the
different run levels, different programs will be running. In
run-level 0, the system is not running anything and is stopped. The
way you get here is to go down from other run levels.
Run-level 1 is also called single-user mode. Run-level 2 is also
called multi-user mode.
The system (as well as the system administrator) can change run
levels using the init command.
What programs are run in each run-level is defined in the file
This file is often called the init table or simply inittab.
When the system changes run-levels, it will look into the inittab to
see what programs init
needs to run.
There are three special programs that init
will run when changing run levels. These are /etc/rc0,
/etc/rc1, and /etc/rc2. These are started whenw the system
goes into run-levels 0, 1 and 2, respectively. It is these programs
that actually determine most of what is happening at each run-level,
as these start the majority of the system's programs.
One key difference between DOS and UNIX is that you cannot simply
turn off the machine (well, you can, but it is not a good idea). SCO
provides three different commands that you should use. The first is
Running this command will stop all running programs
immediately and halt the system. Running reboot
will do the exact same thing, but will also reboot the system. Since
you are likely to annoy any users on your system, the better way is
to use the shutdown
command. Not only will this give users more warning, but you
can also send them a message telling them why the system is going
down. See Chapter 7, Starting and Stopping the System in the first
book for details.
Things of Note
If you are new to a SCO system, even if you have come from another
UNIX version, then there are a lot of things that are different.
Although these are described in a lot more detail in the first book,
I need to address them here.
Perhaps the most striking thing is that most of the files on
the system are not where you think they are. This is the result of
SCO's use of what are called symbolic links. Like the other
dialects of UNIX, SCO allow you to give a single file as many
different names as you want. They can even be spread out across
different file system. Whereas such a state (where multiple directory
entries point to the exact same file) would be considered a problem
on a DOS or Windows machine, with UNIX (and therefore SCO), this is
not only allowed, but most UNIX versions make a great deal of use of
The original problem was that these links could not span multiple
filesystems. Whether you had multiple hard disks or ever multiple
filesystems in the same partition, you could not span filesystems
using links. Then came along symbolic links. Unlike regular or
hard links, symbolic links are real files and take up space on
the hard disk. Hard links are only a new directory entry and do not
take up any additional space.
The advantage of symbolic links is that the content of the file is
the path to the original file. You can therefore specify any
file, including one that is on another filesystem. The problem with
symbolic links is, like the shortcuts in Windows NT 4.0 or Windows
95, if the original file is removed, the symbolic link is still there
and will point to something that does not exist. With hard links, it
is not until the last link is removed that the file itself is
If you look around your system. You will find that almost everything
on your system is a symbolic link. One advantage is that you can have
multiple system access in the same file. All of the links point to
the same set of directories. If that directory happened to be on
another system (one mounted via NFS, for example), several systems
could access the same files. When one is updated, they all are. These
are referred to as Static Storage Objects (SSOs). You can read the
details about SSO in Chapter 2 of the first book, Basics of SCO UNIX.
One thing to note is that SCO breaks the files on system into two
categories. Static files, like the ls
or vi programs, are stored
separately from the files that change, such as /etc/hosts
(which keeps track of the remote machines that you know about). By
updating just the static files, you do not need to reconfigure your
system each time you upgrade.
Another difference is that SCO allows multiple filesystems per
partition. Others will allow only one filesystem per partition, but
with multiple partitions per disk. SCO allows both. You can have up
to the four primary partitions allowed in the partition table and
each partition can have up to eight filesystems.
One of the changes made between Open Desktop and OpenServer
was the addition of two new filesystem types. The High Throughput
Filesystem (HTFS) and the Desktop Filesystem (DTFS). By default, your
root filesystem will be configured as a HTFS. The problem with this
is that the system cannot boot from an HTFS. The solution was to
store the kernel onto a file system from which you could boot and
then use the HTFS as the root filesystem. Details of these filesystem
types can be found in Chapter 6, Files and Filesystems, in the first
Normally, you should not notice this difference. However, you might
notice a new sub-directory under the root directory: /stand.
The is the where the filesystem is mounted that the system boots
from. If you look inside, you will find all the files that the system
needs to boot. As the system is booting, one thing it does is mount
the root filesystem onto the /
directory and then mounts the boot filesystem onto /stand.
Another difference that you might have noticed during the
installation is that SCO does not allow you to install a /usr
filesystem. With SCO, this is just a sub-directory like any
other. One thing that I need to point out is that although you can
create one after the system is installed, you no longer save as much
space as you thought. Remember what I said before about SCO making
use of the symbolic links? The files are no longer in /usr,
just the symbolic links. Therefore, moving /usr
somewhere is not going to save you the space. If you want to save
space by moving a directory to a filesystem, you need to consider
moving /opt, as this is
where most of the files are really kept.
Advanced File and Print Server
The question that you are probably asking yourself, which has been
asked before, is why use SCO OpenServer as a Windows file and print
server in the first place? Aside from the fact that SCO has proven
itself to be more stable, there is the issue of cost. The Windows NT
Advanced Server requires more hardware for the same functionality.
One reason for this is that there is no way to shut off the GUI in
NT. If you are running a file and print server, it may be days
between the times you login. Once you have configured your system,
why waste all the processing power and memory to keep a GUI on the
screen. Why not use the same resource that runs the GUI for your
There is also the fact that NT is not multi-user. Granted, it
presents itself as such in that it can run multiple tasks on "behalf"
of different users. However, there can only be one user logged into
the system at any one time. Note that there are programs such as
telnet from ATAMAN that allows multiple users. However, these are not
provided in the product and the functionality is very limited.
This has some dramatic effects when you do want to change something.
Although you can remotely administer an NT system to a certain
extent, much of what you need to do is limited. Adding drivers or
changing hardware parameters is something you cannot do. Even
something as simple as adding a route to your routing table not only
requires you to be physically at the machine, but also requires you
to reboot the machine. Something that is not necessary with SCO.
Windows NT does offer an advantage in terms of security. Although you
can configure your SCO system to a higher level, NT still is better.
Part of the advantage is you can define access to a file or directory
with as fine a detail as you want.
After administering a world-wide NT network with over 500 users, I
have found that this functionality is a limited advantage. In many
cases, this becomes a burden as there are too many possibilities and
combinations. Using a well thought out scheme under SCO (or any other
UNIX dialect), you can come close to the same functionality. In
addition, once the permissions are set on the Windows NT server,
changing them in ways other than globally (i.e. for a given
directory-tree) is impossible. The tools that SCO provides allows you
to change things exactly the way you want them.
If you want to do anything with the APFS, you have to get SCO
OpenServer: The Windows Network Solution by Charlie Russel and
Linda Gaus from Prentice Hall (ISBN 0-13-459421-5). Although you have
a lot more information in the on-line help, the information in this
book is far more accessible than through SCOHelp.
Keep in mind that the AFPS is not "silver bullet” that
will do away with NT once and for all. If you have an existing
Windows network, it may be a good idea to get Windows NT rather than
SCO. The interface will be similar so there is less of an
administrative effort needed to manage the NT machine. On the other
hand, if you already have SCO machines, then there is no need to buy
NT just to act as a file and printer server. An SCO machine can do it
Windows NT Concepts
In order to take full advantage of the capabilities of the AFPS,
there are a few concepts that we need to talk about. If you are
coming from an environment where you use Windows NT machines, you are
probably already familiar with many of the concepts that we are going
to talk about. However, if your background is purely UNIX, there are
a lot of differences in the way Windows NT does things. Although the
concepts themselves are generally the same, the way Windows NT
implements them is different.
Access Permissions under Windows NT
Access is gained to Windows NT machines in the same way as UNIX
machines: with user accounts and passwords. As with SCO (or any
dialect of UNIX), giving access to files and directories under AFPS
is done through permissions. These permissions determine what access
you have, such as reading or writing.
One advantage that NT (and therefore the AFPS) has is the
ability to "fine tune" the access as compared to UNIX.
First, in UNIX, you can only define access based on the owner of the
file, the group of the file and the rest of the world. With NT (and
therefore the AFPS), you can set permissions on a lists of individual
users or groups as well as specify permissions for the owner and the
rest of the world. (Exactly how, we'll get to shortly)
Also, you can only say who has access, but you cannot specifically
say who does not. This is a fine point, that requires a little more
clarification. Let's assume that the user jimmo is a member of the
group techdoc. In UNIX, any file that has an owner of jimmo or is
writeable by the group techdoc can be written to by jimmo (even if
not writeable by the owner, the owner can simply change the
permissions so it is). Additionally, any file that is writeable by
any group that jimmo is a member of can be written to by
What if the techdoc department was planning a birthday party for
jimmo and didn't want him to know about it. If there was a file that
had all of the plans for the party and had a group of techdoc, then
jimmo could access it. There is no way under UNIX, short of creating
a new group, to say that everyone in the group techdoc has access
except for jimmo. Under the AFPS (as well as NT) you can.
This is possible because NT and AFPS use an access control list
(ACL). The ACL is a list of who has access and what kind of access
they have. One thing that you can do within the ACL is to explicitly
say that a specific use has no access, even though they might
be a member of a group that does. Although you can get around this by
creating even more groups (such as techdoc_minus_jimmo), it is often
much easier to deal with exception like this.
As with UNIX; users can by thrown together into groups. This allows
you to specify the same permissions to a list a people. Groups serve
the same basic function in AFPS as in UNIX, in that you can bundle
users together and assign permissions based on the groups. By
including a user within a group, you can quickly assign access
permissions to a large number of people.
For example, in one company we had a Microsoft Select contract, which
meant we did not have to go out and buy a copy of each product.
Instead, we reported the usage to Microsoft and paid as we went. We
kept track of what users had what software by including them in
specific groups. We then limited access to the application to each of
the respective groups. For example, the MS-Word executable was only
accessible by members of the WinWord group.
An advantage of Windows NT is the "group within a group"
capability. That means a group can contain other groups. Under AFPS
there are two kinds of groups: local and global. As their names
imply, local groups are local in that they are specific to a domain,
whereas global groups are accessible across domains. This means that
a local group can contain a global group, but a global group cannot
contain a local group. In addition, a local group in one domain
cannot contain a local group from another domain.
This can be useful in a lot of instances. We used it when defining
access rights to specific applications. The MS Select contract we had
gave us licenses on a per user basis. This meant that we had to keep
track of who was licensed for each product. We created Global user
groups for each of the products (such as Excel and Word) and each
user was placed in a group based on the application he or she used.
We then created local groups with a similar name, which we then used
to assign access permission for the applications.
Although the applications were accessible all over the network, only
the members of the local application group could actually run the
program. Now, this might seem a round about way, since we could have
assigned permissions based on the global group. However, global
groups can only contain users. Local groups can also contain global
groups. We could then place the global groups from other domains into
this local group.
For example, there was a global group SI_Winword for all the users in
our Singapore office who could use Word. There was also a local group
SING_Word that contained not only SI_Word, but also ME_Word for our
Melbourne office, DU_Word for our Dublin office and so on. Therefore,
no matter where in the world a user logged into the system, they
would have access the same applications and we could still keep track
of our licenses.
One thing to note is that in contrast to trust relationships, group
membership is transitive. That means that if the user jimmo is
a member of the accounting group and the accounting group is a member
of the finance group, then jimmo is automatically a member of the
finance group. This is how we were able to set up the access
permissions for our applications. Since the SING_Word contained the
group SI_Word, all members of the SI_Word group could access the Word
There are several users and groups that exist by default. One group
is the global group "Domain Admins". This group is used to
administer all the servers within a particular domain. We have made
this group a member of all of the local administrators groups. Each
administrator in the main office is a member of the global group
"Domain Admins" and is therefore a member of each local
administrators group. We can then login with our own accounts
anywhere on the network and have complete access across the entire
company. In addition to the "Domain Admins” group, the
following groups are defined by default:
Administer domain users and groups
Administer the local machine
Guest uses in the domain
All users in the domain
Guest on the local machine
Administer replication of files between
All users on the local machine
Note that there are two kinds of users and administrators. There are
those that are valid across the domain and those that are valid just
for the local machine.
In UNIX, you have primarily the three permission read, write and
execute. If a directory has execute permissions, it means that you
can traverse that directory. (Note that there are other modes that
you can set on files and directories, but these are the ones that
have the most to do with permissions.) Windows NT has a few more.
There are the standard read, write and execute, in addition to
delete, change permissions and take ownership.
Under UNIX you if remove permissions to a file or directory,
then that person or group just doesn't have access. However, on the
AFPS you can specifically say that a user or group has "NO
ACCESS." This is a subtle difference, but it is an important one
since the first thing that is checked is whether access should be
denied. That means that even if a user were to have access by some
means, if they the user or a group they belong to has specifically NO
ACCESS, then they will not have access.
Note that three types of access under UNIX are the same for both
files and directories, although the meaning of executable is slightly
different. However, with the AFPS there are some differences. These
are the pre-define permissions sets:
Add and Read
In each case, you can define your own special permissions. For
example read and list a directory but not write to it. For the
directories, permissions have the following meanings:
- Users can display contents of a directory and traverse into
sub-directories, as well as display the directories owner and
Read - similar to
list, running application files, read data files.
Add - like lists,
but you can change permissions on directories, add new ones, add new
files, cannot delete subdirectories or files
Add & Read -
cannot delete a directory
Change - can delete
Full Control - Just
that. You have complete control over the file and can do anything
with it or to it.
As it's name implies, No Access specifically denies access; one use
is when the person would normally have access and you want to stop
it, as in the case of my birthday party. Another is when you want to
make sure that there is no access. We have often created users for
expositions and fairs that we want to give access to part of the
system. We then specially deny access to other parts of the system.
By denying access specifically to these users, we don't have to worry
when some file has access by everyone. Remember that even if given
access one way, NO ACCESS overrides that.
In general, newly created files and permissions take on those of the
parent directory. For example, is the user jimmo has read permissions
on a directory and someone else creates a new file in that
directory, jimmo will also have read permission on that new file.
However, not all permissions are passed on to sub-directories.
This happens when permissions are based on CREATOR OWNER. When
permissions are set for CREATOR OWNER all new files and directories
are set for the creator of the file or directory. So, if you
have permissions to access a file or directory because you are the
CREATOR OWNER of a file, you may not necessarily have access to
something created underneath it.
For example, Julie owns a directory where the permissions are set to
read/write for the CREATOR OWNER and write for Jim. Therefore, Julie
has read/write permission. Jim creates a new sub-directory, so the
permissions are also read/write for the CREATOR OWNER, which is Jim
in this case. Julie can no longer access the directory as she is not
To change permissions on existing files, you use the file manger.
This shows two sets of permissions for each group of individuals:
first are those for the directory, then the files.
Permissions can also be set as "Not Specified." This is not
the same a NO ACCESS. A directory set as "Not specified”,
but file set to read can still be read. A directory as NO ACCESS
means even if file could be read, it can't be, since no access
at all is allowed to the directory. Similar to UNIX, if a user or
group has full control on a directory, they can remove files despite
the permissions on the individual files.
As on a SCO system, permissions are cumulative. If you have read, but
your group has write, you can change the file. However, NO ACCESS
overrides all others. Once again, this means that no matter what the
other permissions are, if the system could somehow assign you NO
ACCESS, that's what you get.
When mapping permissions to the UNIX filesystem, problems arises
because UNIX only has the three sets of permissions. There are
several rules that govern permissions when using the AFPS. First, if
an AFPS user is mapped to a UNIX account using mapuname,
then the perms under AFPS are the same as for the user under UNIX.
Setting permissions to groups is easier than setting for individuals.
If a directory is to be used by more than one user, then it makes
sense to create a group.. We have directories with our technical
drawings that are accessible by several different groups, one is
TECH_READ, TECH_READ_WRITE; TECH_FULL.
There are eight special groups that the AFPS uses to determine if a
file is hidden(h), system(s) or archive(a). That is, the file's
group is one of the following:
If a file or directory has one of these groups, then the appropriate
characteristics apply. For example, if the group of a file is
DOS---h, the file is hidden. If the group is DOS--sh, it is a system
file that is hidden.
One concept is that is probably new to the UNIX-heads is the domain.
A domain under NT is similar in concept to that of an Internet
domain, but control and administration go beyond. Like the Internet
domains, an NT domain can be anything from a server and a couple of
workstations sitting in one root to several servers and hundreds of
workstations spread out around the world.
I worked for one company that had both ends of this spectrum and
several grades in between. Our central domain consisted of offices in
several European countries and we had other domains spread throughout
the world. None was any more complicated to administer than another.
It all depended on our needs and how we wanted to administer the
domains and provide access.
I would say that my favorite aspect of this was that we (the system
administrators) could administer every server and workstation from
our desks. Although it might have been nice to fly to Singapore every
time they had a problem, over a longer period of time it would have
The reason this is possible is part of the entire concept of
domains. By deciding that one domain is "trusted" you can
give every user in one domain the same rights in another. This is
similar to the concept of trusted hosts under UNIX, but is more
secure in that a user cannot allow access on his or here own.
Access is controlled by the administrator in both domains. (We'll go
into more details about this later).
As I mentioned, a domain can consist of any number of servers. If
there are no servers, then this group of machines is generally
referred to as a workgroup rather than a domain. Since the AFPS is
intended to replace a server, we'll limit our discussion to
domains. (That is, a group of machines with at least one server.)
Although there can be any number of servers, one takes a dominant
role and becomes the "primary domain controller" (PDC).
This is where the user account information is stored and is what is
responsible for overall security within the domain. Other machines
may be used to provide resources, but access to the resources is
ultimately controlled by the primary domain controller.
As with us, you may have several servers. Those that are not the
primary servers become "backup domain controllers" (BDC).
These will contain copies of the account and security information and
can allow access to the network. When changes are made to the account
database, the changes are propagated to the PDC and then to the
BDCs. On larger networks, the BDCs can ease the load of the primary
by becoming "login servers." These are servers that do the
In some offices, we had separate domains. This made administration a
lot easier. For example, the offices in America were in one domain,
those in Europe were in another and those in Asia were in a third. In
our case, this was done so that the local administrator could have
complete control over the domain. Otherwise, we had to worry about
time zone differences when problems arose and the administrator in
the central office had to fix things. (We also had other domains, for
Although there was a single PDC for the entire domain, each branch
office had it's own server. Being a server, it was also a BDC.
In our case, BDCs are useful because of the physical connection
between the branch offices and where the PDC is located. If every
authentication request had to go through the central office, the
connection would be overloaded and performance drops noticeably. (We
All local resources (directories and printers) exist on the local
server. Because the local server is the almost always the first to
answer login requests, there is essentially no network traffic.
However, should the BDC fail, the remote offices "could"
login to the PDC or visa-versa.
However, the administrators still has the ability to make changes and
administer the remote domains. This was accomplished through the
"trust relationship" mentioned earlier. Our (central)
domain was trusted by all of the other domains. This meant that an
administrator in our domain was considered an administrator in their
domain, with all the power and authority. This gives authorization in
just one direction.
Actually, in our case, the trust, did go both ways. That is,
each domain trusted the other. In each domain, we created a local
administrator who had control over all of the local machines, but was
not a domain administrator. The domain administrator's password was
kept by us which allowed us to administer any domain no matter
where in the world we were physically located.
Each of the domains’ sites trusted the central office
and visa-versa, but the trust is not transitive. For example, our
site in the US trusts and is trusted by the one in Germany. The
Australian site trusts and is trusted by the site in Germany.
However, since we did not explicitly say so, there is no trust
between the domain in the USA and the one in Australia. At one point,
we did have a situation where every domain trusted the other.
However, as the number of domains grew, so did the number of trust
relationships. Since only a small fraction of them were actually
needed, we decided to limit it to just those that were needed (mutual
trust to/from the central office plus a few others).
You know how the domain controllers interact with each other, so we
need to talk about what this is really good for. The first aspect is
something I mentioned a moment ago: logging in. In order to get
access to a domain you need to log into it. WfWG, Windows 95 and
Windows NT all allow you to log directly into a domain and skip
logging into the local computer.
In the case of Windows NT, access to files and directories on the
local machine can be controlled by the access rights within the
domain. Once an NT Workstation has "joined” a domain, you
could set permissions on the local machine to allow access for any
user or groups within that domain. Remember that local groups can
contain global groups. So if there are local groups on the Windows NT
Workstation, they can contain global groups from the domain. We
include the Global group Domain Admins into the local group
Administrators. Therefore, when any of the users logged into a
Workstation, we automatically had administrator rights.
Simply put, resources are services on the server that you provide to
a client. This is the same concept you have in a purely UNIX
environment, and usually refer to file services (where the server
provides files to the client) and print services (where clients can
print to printers attached to the server).
In an MS-Windows environment, resources are usually referred to
"shares, " because you are "sharing” the
resource between machines. In addition, these resources are made
available through a name that is called the "share name.”
This name may not even have any logical connection to the actual
resource you are sharing. For example, a directory called
R:\data\LVL42 could be
shared as "Finance”. When you connect to this share, you
access the share name "Finance” on the respective server.
Contrast this to UNIX resources where you generally access them by
the same name they have on the server.
A common misconception is that just by creating the trust
relationship, you give access to resources within another domain. All
that creating the trust relationship does is allow you to give
access. In other words, without the trust relationship you could not
give access. Once the trust relationship has been established, you
can assign access (normally called privileges) to both users and
groups in other domains.
The choice of where you put the resources is based on the hardware,
what kind of resource it is, and sometimes a matter of person choice.
Technically, it doesn't matter. You can spread your resources across
several machines. Since the Windows workstation sees the resources
the same way, no matter where they are physically located, it really
doesn't matter where they are. However, if you have multiple servers,
it is a good idea to spread the load.
Unlike applications running on UNIX machines, those on Windows 3.1x
will load as much into physical memory as possible. A lot of space is
saved using dynamic linked libraries (DLLs). However, you don't have
the paging mechanism you have with UNIX or Windows NT. Once a program
is in memory, there is no need to go back to the hard disk to get
more. Since the vast majority of the DLLs are on your local hard
disk, the server's job is done. However, if you are accessing data
(i.e., from a database), the server is constantly in action. Because
of this, we have one server that has the applications on it, and
other with the data. Because the program server is not as heavily
loaded as the application server, we also use it as our print server.
If you have one machine that is a lot faster, with much higher
through put, then this is a better choice for a data server. If
another machine is slower, then this might be the choice for the
program server. When programs are loaded, it might take a moment or
Installing the AFPS
Although the AFPS is on the CD, it is not installed by
default. Instead, once the OpenServer Desktop product is installed,
you need to go in and install it yourself. This is done, like all
other SCO software, from scoadmin.
If you are running X, you can start it by double clicking the
Software Manager Icon in the System Administration group. You can
also start it directly from the command as with scoadmin
Once scoadmin has found
the AFPS on the CD and has started the installation processes, you
will be prompted for the licensing information that you received from
the SCO Web with the rest of products. As with other products, you
need to be careful about spelling and ensure that letters are written
in the correct case.
During the installation, you will be asked a couple of things about
your server. One of them is the "role” that this server
will play. If you are configuring a primary domain controller, all is
well. If this is a backup, you must already have a primary defined.
You will also be asked for the name of the domain. If this is the
BPDC, then this will be the name of an existing domain that you want
to join. If a PDC, this will be the name of a new domain. Chose your
domain name carefully! NT domains and therefore AFPS domains are not
like Internet domains. Security information is encoded with the name
of the domain. Once the AFPS is installed, there is already security
information which contains the domain name. Therefore, once the name
is set, you cannot change it!
Here, too, you will be prompted for the password for the
administrator account. This account will be used to administer the
AFPS from your Windows machines. The first time you login, you cannot
create users that you can put in the administrators group, who will
then have the same privileges.
Configuring the Server
Charlie Russel, Author of "SCO OpenServer: The Windows Network
Solution" once sent me an email with an excellent rule of thumb
when configuring the AFPS: "Set things up on the server, but
administer them from the workstation." This stems from two
important facts. First, you do not have the same tools on the server
which means you edit things by hand. Second, it's not very easy to do
that. Remember that the information that the APFS maintains needs to
be in a form accessible from the standard Windows tools (User Manger,
Event Viewer). If they are stored in the ASCII files, there has to be
a mechanism to translate them to and from the format that the MS
tools require. Instead, the files are stored as binary data files, so
you need to use the appropriate tools to make changes.
We are going to make the assumption that you have the network
components configured. Run scoadmin
network to make sure that
the SCO AFPS is listed under TCP for both the loopback driver and
whatever you are using to connect to the rest of the net (i.e. PPP,
Ethernet card). Be sure that you have the latest patches for your
card or network; in general check the SCO web site (www.sco.com).
I won't go into details as this is repeated in the SCO documentation
The first step is to get the tools onto your Windows machine so that
you can work with them. By default, there is a share on your AFPS
system called astools. Although you can simply copy these files into
a directory, it is better to follow the correct procedures.
When you connect to the ASTOOLS share, you will find four
directories: win95, windows, winnt.351 and winnt.40. These contain
the server tools for, respectively, Windows 95, Windows 3.11, Windows
NT 3.51 and Windows NT 4.0. In each of the Windows NT directories is
a batch file (SETUP.BAT) that you should execute to install the
server tools. In the other directories is a file readme.txtł
which details how to install the tools.
Creating and Administering Users and Groups
Your AFPS users can be created through the User Manager. Once the
server tools have been installed, double-click the User Manager icon,
which will bring you something like . In this example, I have already
created several users. You will probably only have the Administrator
and Guest users. In the Users menu, click on the option "New
User” to add a user. This brings up the window in .
Figure 0-6 AFPS User Manager
Figure 0-7 AFPS User Manager -- Add new user
The Usename field is the name you want to give to the user
account,. whereas the Full Name field is the real name of the
user. One important point is that the User Manager will allow you to
create user names that are longer than what is allowed under UNIX. If
you do, the name on the SCO machine get changed to stay within the
limit of eight characters. For example, if I created a user named
jamesmohr, the name on the SCO machine might be jamesm88.
The description field is some descriptive text that you might want to
give the user. In our example, the system users do not have full
names, but do have some description. In the case of real users, this
might be some identification like what department they work in or
their phone number.
A password in AFPS can be longer than one in UNIX. Since this
is managed by the AFPS, the length of the password will be
maintained. When you create the users, you need to input the password
twice. This is to ensure that you typed it right as the password will
not be echoed to the screen.
As you see the box "User Must Change Password at Next Logon”
is checked. This is the default. This is to ensure that newly created
users change their password. Although you could remove the check, I
wouldn’t recommend. The other three boxes are self explanatory
and I leave it to the reader to get more details in the SCO doc if
they need it.
At the bottom of this window are several buttons. The Groups button
is used to place that user into different user groups. This looks
like . By holding down the shift key you can select multiple groups.
Select those on the right side that you want to add and then press
the Add button. When finished, be sure to press the OK button.
Figure 0-8 AFPS User Manager
The Profile button is used to set up the initial environment for the
user. The system can be configured so that a specific script is
started each time the user logs in. In addition, a home directory can
be assigned that will be connected automatically. For details on this
and the remaining button, I direct you to the SCO doc.
Just as you should have a personal account on the UNIX machine, you
should also have one in AFPS. One thing to note, you can make
yourself a member of the certain UNIX "system" groups to
ease access to files; to do most things you need to be in root, and
login. Under NT & AFPS, you can just put yourself in the
SCO's choice of putting users in /usr
is not necessarily a good one. There are a lot of system files
underneath /usr, already.
By putting users' home directories there,. you soon lose
track of what is what. By placing them in their own directory, you
know what is what. Most common on SCO is to create a /u
directory, but others have a
/home and even /usr/users.
This needs to be changed in /var/opt/lanman/lanman.ini.
The entry is userpath=/usr
by default, and you can change it to wherever you have it,
such as /u or /home.
Be sure to change the system default for the home directory using the
SCO account Manager, so that these match and you don't have one
set of users in one place and another set somewhere else.
In general, creating groups is the same as creating users. In the
User menu, there are entries to create either a local or global
group. (See above for the differences.) As mentioned previously, you
can only place users in global group. Therefore, if you select the
New Global Group entry, you will only get the list of users.
On the other hand, if you create a new Local Group, you can add users
as well as global groups. Here you have to explictely press the Add
button to get the list. Note also that there are no local groups
listed here such as "Administrators” or "Backup
Operators”. This is because, as we discussed earlier, you can
place global groups into local groups.
Another aspect of users is the policies to be employed. As you might
guess, this is done through the "Policies” menu. The
first entry allows you to change the basic aspects on the account as
shown in Figure 0-9. For example, here you define the minimum length
the password can be, how long before a user has to change it, and how
many passwords the user must use before they can use an old one
0-9 User Manager - Account Policy
What you decide to set these values to depends on the security of
your site. However, I would suggest that you not allow blank
passwords and force your users to change them every few weeks. Also,
do not allow immediate changes as the user will change it to some
nonsense password and then immediately change it back to their old
The User Rights menu defines what each user can do as far as the
system is concerned. The basic window you see is shown in Figure 0-10.
The selection box labeled Right, specifies which right is give to the
user listed in the "Grant To: " box. By pressing the Add
button, you can select from the list of Groups and Users who should
have this right. Unless you are very familiar with the system I would
suggest leaving these at the defaults.
0-10 User Manager - User Rights Policy
The Trust Relationship menu is used to define what trust
relationships exist. The first thing you need to do is in both
domains, specify that the other one is "Permitted to Trust”.
Here you specify the domain that can trust yours, as well as the
password they must enter to begin the trust relationship. Next
(again, in both domains) you can select the domain to trust.
Note that users can be shared between the UNIX machine and the
AFPS. That means that you do not have to have one set of user names
for the AFPS and another for your UNIX machine. When you create the
user in SCO's Account Manager, one of the options is to say
that this user is "Networked via” the Advanced Server.
When you do this, a user account will be created that can login
directly to the UNIX machine or across the net. When you add a user
just through the User Manager, the account is created on the SCO side
so that they have no access. Of course, this can be changed later if
Setting up shared directories
The directories and printers that you access through the AFPS are
called "shares" or resources. However, the Microsoft
documentation usually calls them shares. The best way to look at it
is to say that resources on the server, such as directories and
printers, are shared.
Each resource that you want to share needs to be first made available
on the server. This means that the directory must already exist or
the printer must already be configured. Once prepared on the server,
directories can be made available using the Server Manager. When you
double-click on the server manager, you are shown the window seen in
Figure 0-11. This shows you a list of the servers within your domain.
Select the sever you want to administer by clicking once on it.
0-11 AFPS Server Manger
There is a entry under the "Computer” menu, labeled
"Shared Directories”. By selecting this, you have the
"Shared Directories” dialog window (see Figure 0-12).
This shows you a list of the directories that are currently being
shared on that server. Even if you haven't shared any
directories yourself, you will find that there are already several
listed here. These are the ones that the AFPS creates when it is
0-12 AFPS Shares
Here you define not only the directory to be shared, but access
permissions as well. To create a new share, you click on the button
"New Share” which brings up the dialog window in Figure 0-13.
The "Share Name” is the name by which you want users to
access it. This is what will appear in the browser. The Path is the
directory on the server that you want to share. Although there is no
C: drive on the SCO machine, the convention is to refer to the root
directory as C:\. Therefore, you will see most of the shares
referring to C: followed by some path name. For example, I wanted to
make the /tmp available as
the share COMMON. The directory I specified was C:\TMP.
0-13 Adding a new share
Note that if you have any DOS or Windows for Workgroups machines on
your network, you need to be sure that the share names are less than
eight characters. If not, you won’t be able to access them.
The "Permissions” button allows you to set the access
permissions on this share. The default is "Full Control”
for everyone, which means that every user can do anything with any
file or directory. You click on the Permissions button to define the
access to the share and not the underlying directory. This is
a subtle difference that we use to our advantage.
By default, all shares are accessible by everyone, which we leave
that way (in most cases). We then define access to the specific
directories. This allows us to define access permissions on a per
directory basis even though they are all part of the same share.
Although it would be an extra level of security to set the
permissions on the share, we have found that it is really only
necessary in the case of system directories. The reason we find this
is necessary is because the permissions are usually set when the AFPS
is installed and second, a lot of damage could be caused if
underlying permissions are not correct.
Full control means just that. The person/group with this permission
can do anything to the file, including take ownership of it. Others
are self explanatory: list means to list contents, which is the same
as read perms on a directory in UNIX. Although the permissions are
additive, but, here too, no control always means that: NO CONTROL. If
there is any way no control can be applied it will. If you are
owner and full control, but your group has no control, you have no
When files and directories are created they "inherit" the
permissions of the directory where they were created. Whoever created
the file is the owner, but you can take ownership if you have that
permission. Contrast this to UNIX where the owner has to give up
ownership explicitly. In addition, you can have the ability to change
the permission, although you are not owner. Again, a contrast to
One useful trick is to use a dollar sign at the end of a share
name. This makes that share invisible to the user when scanning the
server for directories (called browsing). We do this with home
directories, and then automatically connect them via the login
scripts mentioned earlier. In this way, the browser list is not
filled up with shares and other users don't have any reason for
accessing those shares. If we know that such a share exists, we can
still input the share name by hand, even if it does not appear in the
One tip I need to give you is that you need to be sure you
know what accesses you are actually giving. We have found that the
easiest administration effort is to set permissions based on groups
not users. Normally, we create a group based on the access that we
are defining. For example, we have many people that use MS-Word. We
therefore have a group specifically for MS-Word and change the
permission on the Word executable so that it is only accessible by
these users. We also have a directory containing information that is
just for our shipping department. We have a group called shipping and
set the permissions so that only this group has access to the
directory. If someone gets hired for shipping department and needs
access to MS-Word,. they are put in each group (word and shipping)
and we don't need to worry about looking for each file or directory
that they need to access.
Sharing printer resources is generally the same as directories. The
physical resource needs to be set-up in advance. For example, Ports
need to be defined on the SCO side (parallel or serial) and the
printer needs to be set up with the SCO print manager. Note that by
default, the serial and parallel ports are not defined on the SCO
system. You therefore need to run the hardware manager to configure
One nice thing is that sharing printers on the AFPS machine is easier
than sharing directories. When you create the printer on the AFPS you
have the option of sharing it with Windows machines or not. If you
choose to share it, it will automatically be available.
Since printers are not like files or directories, the access
permissions are very simple, either you can print to it or you can't.
There is no issue of being able to write to it, but not read from it.
Managing the Server
There are two aspects of managing an AFPS server that the server
tools can help you with. The first is the Server Manger that we
already talked about. So, let's go a little more into detail
If you look at the computer menu in the Server Manager, there are
several more options that we haven't talked about. The
properties menu will bring up the window we see in Figure 0-14. In
the Usage Summary, we see general information about the connection to
the AFPS server. In this case, I am the only one connected, so there
is only one session, although I am actually connected to several
0-14 Server Properties
If we click the users button, we see the window in Figure 0-15. This
tells us what users are connected and what resources they are connect
to. This provides a good overview of what is in use. The "In
Use” button will show us exactly what files are currently open.
This is useful in several instances. For example, if you need to
shutdown the server. You can see what users are using what files and,
if necessary, send them a message before you pull the plug on them.
(Messages can be sent using the "Send Message” option in
the Computer menu.)
0-15 AFPS Server Manager - Connected Users
The "Shares” button shows you the same information, but
from the perspective of the shares. Whereas the "Users”
button tells you what resources a particular user is using, the
"Shares” button will tell you which users are using a
particular resource. We have had cases where one user has no programs
open, but is shown in the Server Manager as using a particular
resource. We can then use the "Disconnect” button to
force the system to disconnect him.
Replication is the process by which files are automatically sent from
one server to another. This has limited functionality in the AFPS as
you can only copy to/from a single directory.
Although discussing Replication goes beyond the scope of this book,
one aspect of this window I would like to address is at the bottom of
the window whereis an input box labeled "Logon Script Path”
is found. This , which defines the script the system will run
automatically when any user logs into the system, and defaults to the
very long path
In this directory there are two scripts. Which one is executed
depends on what operating system you are logging in from. If it is
Windows NT, the script will be netlogon.cmd.
If from Windows 95, WFWG or DOS, it will be netlogon.bat.
Be default, there is nothing there other than a welcome
Actually, it is better to say that these are the scripts that should
be executed. In the Server Manager, you defined where the scripts are
located, but in the User Manager (using the Profile button) you
defined exactly what script should be run.
At first, I though it was odd that the directory for the login
scripts was not defined along with the other user information.
However, think about where it is. It is stored along with the
replication information. By replicating the login script from one
central server to another, everyone in the entire company can have
the same script. We have several domains and in some cases several
servers within each domain. We replicate all of the login scripts so
that the login is standard throughout the company.
Going back to the Computer menu, there is an entry for Services. This
list the services on your AFPS. Services under NT (and therefore
AFPS) are similar to daemons under UNIX, in that they run in the
background and perform various functions for the system. For example,
the Computer Browser service is what provides the list of computer
names and resources that you see in the browser. The Net Logon
service is what takes your username and password, and gives you
access to the resources on that server. Configuration of system
services is a complicated matter and is left for another book.
Also in the Computer menu is the entry "Synchronize Entire
Domain”. Selecting this option will have the primary domain
controller compare it's databases with the BDC in the domain.
This is useful in many cases, primarily when changes are made to the
primary and need to be propagated immediately to the BDCs. For
example, someone from a remote office calls to say that they get a
message that their account is disabled (for example, when they forget
their password and try to login unsuccessfully too many times). When
we change their password on the PDC, it will take several minutes
before the change is propagated. By selecting "Synchronize
Entire Domain”, we can force the update.
You will also see the menu item "Promote to Primary Domain
Controller”. In my case, this option is grayed out as my AFPS
server is already the primary. This is very useful when the primary
crashes and you can designate another server to take over
In the Computer menu, you also have the option to specifically add or
remove a computer from the domain. We have only found it necessary to
intentionally add a machine when the server database no longer
recognizes it as being a member.
You will also see the "Select Domain” option which allows
you to run the Server Manger on a server within another domain. The
functions are the same as for the local domain. This is only possible
if a trust relationship exists between the domain and you are a
member of the Administrators group in the other domain. This is
usually accomplished by making each domain administrator a member of
the Domain Admins global group, and then making the Domain Admins
group a member of the local Administrators group. Since group
membership is transitive, you are then a member of the other Domain's
Another tool that is useful to manage your server is the Event
Viewer. As it's name implies, it is used to view events on the
server. When you start it, you will see something similar to Figure 0-16.
There are three areas that the Event View will provide you
information about: System, Security and Applications. System events
cover most of the system and include such mundane things as printing
or the fact that the Event Viewer Started
0-16 AFPS Event Viewer
Security events are those dealing with (what else) system security.
By default, not much is recorded. However, under the "Policies”
menu in the User Administrator, you can define things to be audited.
Some of the more useful events are unsuccessful logins,
creation/deletion of users or changes to the security policy.
Application events deal with specific applications. Since you do not
have any real NT applications running on the AFPS, such as NT backup,
this will probably be empty.
Events come in five types: information, warning, error, success
audit, and failure audit. The first three deal with the system and
application logins and the last two are only concerned with security
. Informational events are just that. They usually have little effect
on your system. These are indicated by a blue circle with a white ‘i'
in the middle. Warnings are slightly more dramatic and are indicated
by an exclamation mark. Errors are shown as stop signs. A key shows a
successful audit event (you were given permission to do what you want
to), and a lock shows an failed audit event (you were denied access).
One very useful aspect of the Event Viewer is the ability to filter
the events. This is done through the View menu. You have a wide range
of choices and you can select what events to view by their category,
what component generated the message, the user involved (if any),
date and time, etc. Filtering is very useful when you have a lot of
messages and are interested in only one specific aspect (e.g.,
eErrors or audit failures). Going into more detail about filtering is
beyond the scope of this book, so I refer you to the on-line doc.
SCO Doctor is an automated tool for monitoring as well as optimizing
system performance. The version that is provided on the CD is a
"lite" version, which has less functionality. Another
product, SCO Doctor for Networks, provides that same functionality as
the standard version, but allows you to manage systems across the
One of the key differences between SCO Doctor and a tool like sar,
is that SCO Doctor not only has the ability to monitor your system,
but to take action based on the problems it encounters. (You can find
out details by looking at the sar(ADM)
In this section, we will talk about the basic functionality of
SCO Doctor. The key difference between the version on the CD and the
full version is that in order to obtain automatic diagnosis, tips,
and kernel tuning, and to extend SCO Doctor to meet your
requirements, you need to use the unrestricted SCO Doctor product
(wWhich includes SCO Doctor for Networks).
One thing I would like to point out is that even if you did
have the full version of SCO Doctor, which can make recommendations
for changes, you really need to understand what is being said by SCO
Doctor. That is, you should not just blindly follow recommendations
without knowing what it means. As good place to start is Chapter 5,
The Operating Systems and Its Environment in the first book. This
will give you a good background for understanding the concepts behind
SCO Doctor. Another good place is the Performance Guide in the SCO
All versions of SCO doctor consist of four basic components or
Views and Reports are the way in which SCO Doctor presents its
information to the system administrator. By default, there are over
180 views that show various aspects of the system. If these are not
enough, all products allow you to add new views to monitor those
aspects of the system that you need to.
Alerts are essentially messages to the system administrator
indicating that a certain event has occurred. This event could simply
be a defined value has been exceeded (like the percentage of the hard
disk used) or it could be an action (like the system being
Action programs are run when certain alerts are generated. Not all
alerts start an action program by default, but the same event could
start an action program if the system administrator decides.
The databases are where SCO Doctor stores it's information.
With the exception of SCO Doctor lite, information is stored at
regular intervals to give you an historical record of the system.
In addition, the network version also has the following
system monitoring, management, and reporting
support for SNMP
query information through the SCO Doctor
If you are running X, you will find the SCO Doctor icon in the
System Administration folder or you will find it in the main folder
of SCOAdmin. Clicking this icon starts an xterm and runs the
/bin/doctor program. If
you are on a character terminal, you can start the SCO Doctor
yourself by either entering scoadmin
sco doctor or just doctor.
SCO Doctor is a character-based application, so even if you do start
it from X, you will get the same screen.
The first time you run SCO Doctor, you have the chance to run a quick
tutorial of the SCO Doctor. This is an easy way to get an overview of
what the SCO Doctor can do. Although I have found SCO Doctor very
easy to use, the tutorial is a good way of learning about all the
different features. Plus, the tutorial is run on the live system so
you can see how all of the different options work with your own
system. When you get to the actual program for the first time, you
see a screen similar to Figure 0-17.
Figure 0-17 SCO Doctor Start
As you can see at the bottom of the screen, you access the menus by
pressing the F10 key. You will notice that certain letters in the
menu are in red (assuming that you have a color screen or bold
otherwise). Normally, these are the first letter of the menu or menu
entry. You move around the menu either by pressing the letter in red
or with the arrow keys. There are also several hot keys to help you:
F3 - Display a popup
F6 - switches to
F10- Move to or from
CTRL-D Move to and
from main menu
-Step-by-by input in a dialog box
Depending on what version you have of the SCO Doctor (like the one
provided on the CD) you will notice that certain menus are all in
black. This means that either the function does not make sense in the
current view or it is not available in the version you have.
Views are SCO Doctor's way of making the information it collects
available to you. When you first start up SCO Doctor you are in the
"System Overview" view, which you see in Figure 0-17.
Information is provided to you in various forms, such as bar graphs,
time lines, file area graphs and tables. Depending on the view
selected SCO Doctor selects a format (or presentation) that is "most
natural" for the view. For example, information that changes
fairly regularly like disk load is presented in a bar graph, while
information that remains comparatively static (disk space usage) is
presented in a table. In most cases you have the choice of deciding
which format the output should be presented to you.
The views are a key part of the entire SCO Doctor product. Using the
various views, you can zero in on trouble areas on your system.
Another key aspect is the ability to store the information, either
for later view or to compare current behavior with sometime in the
past. This enables you to home in on events that may have caused
changes in the system's performance.
View are selected from the "View" menu. (Where else?)
Underneath the Views menu are several items that allow to specify the
view. These are:
Each of these menu items has a sub-menu (called a sub-view) in which
you select the actual view you want to see. Because you may approach
a particular piece of information different than another
administrator, SCO Doctor will bring you to a particular view from
more than more direction. For example, If you want to find out about
disk configuration, you can either go through the Configuration menu
to the Disks sub-menu or through the Disks menu to the configuration
sub-menu. You can see what this looks like in Figure 0-18.
0-18 SCO Doctor Menus
Moving through the views menu is like moving through the other menus,
using both the arrow keys or the menu letters. If the default
appearance is not to your liking this can be changed with the
Presentation entry in the Format menu. However, some Views, like the
System Overview, do not allow display in other formats. As in other
instances, this menu item is grayed out (black in a scoterm).
However, if we chose the DiskŗConfiguration
view, we can change the way it is displayed. Here we have a choice
displaying it as a table, horizontal bar graph or vertical bar graph.
If you select the presentation entry under the Format menu, you will
see that the format type "line" (for time line) is grayed
out. This means that you cannot display the disk configuration as a
line graph. This makes sense as a line graph has two axis. Now select
the Disks sub-view under Load Factors. We can not select a line
graphic as this is a value that is measured over a specific time
interval. Others, such as the software configuration are only
available as a table. If you have decided that the default
presentation of a particular view is not to your liking, you can save
the selected presentation by choosing "Save Format" in the
By default, the views are shown with values (such as percentages)
shown at regular intervals (e.g. every 10%). By selecting the
"Numeric" entry under the Format menu, you can display the
actual numeric value. Figure 0-19 shows you the view for process CPU
usage without the specific numeric values and Figure 0-20 shows you
the same view with the numeric values displayed.
0-19 SCO Doctor View
0-20 SCO Doctor View with Numeric Value
The "System Overview" View shows you some basic system
information like the name of the system, the number of users and
processes as well as the last alert it recorded. This is the view
that first comes up when SCO Doctor is started. However, this is just
the default and can be changed with the Preferences entry under the
On the right side of the screen is a chart, listing some of the more
important indicators of your system performance. Each of the factors
is listed in percent as you can see on the bottom of the chart. The
bars indicate the follow information:
system: a weighted average of the sub-systems which can have
the greatest impact on system performance. Each is weighted
according to their impact.
cpu: CPU Load
and would be the average of all CPUs if you had a system with
memory load. In general, up to 80% is fine, but after that the
system will start to page.
load on the system
swapping/paging load. This is a percentage of the maximum reasonable
Resource usage. This is an average of the usage for all tunable
parameters monitored by the doctor. You will also see that on the
left side there is an entry labeled tunables. This is a
"description" of the state of your configurable
parameters. This ranges from "too many" where the system
has a large excess of tunable parameters to "critical"
where the system is running dangerously low.
Total filesystem space usage for all disks.
There are approximately 180 predfined views, but if one does not fit
your needs you can access the underlying data. At the bottom of the
Views menu is the database entry. Here you can select the database
you want and then the underlying tables. Also in the Views menu is an
entry Other. This allows you to select the predefined view by name
without having to go through the menus. If you want, you can also
specify tables within the database.
TIME LINE CHART
The time line is used to display the view over a given time period.
This can be anywhere from just a few seconds (so the display is being
updated as you watch) or you can specify times over longer periods of
time if you want to monitor trends.
As you can see in Figure 0-21, the time interval is along the bottom
(horizontal, x-axis) and the value is on the left (vertical, y-axis).
The time scale is changed in the Format menu under the entry "Time
Scale". Here you can specify a scale in interval on anywhere
from seconds to years. When you select an interval, the scale along
the x-axis will change to match the value you input. For example if
you select 10 minutes, the period covered by the x.axis will be that
0-21 SCO Doctor Time View
As time progresses, you will see that the time line moves to the
left. That is, the right end of the time line will always be
approximately the current time (or in the future depending on the
scale.) For example, if we selected a 10 minute interval, the time
line might start out showing the time from 10:42 to 10:52. Two
minutes later, it will show the time 10:44 to 10:54. Two minutes
after than 10:46 to 10:56.
In addition to changing the delay, you can also change the frequency
in which the information is updated. This is done with the Delay
entry under the Format menu. Keep in mind that the lower the value
the more often SCO Doctor is checking the system. If this value is
too low, the program itself may be influencing the data it is
reading. For example, if you were measuring CPU usage and set the
value to 1 second, that means that every second the sco doctor would
run to read the data. This would definitely have an effect on the
values you see. The SCO doc recommends no less than 5 seconds.
The reason you need to be careful of this is that SCO Doctor is
running as a process, like any other. It needs the same kind of
resources (such as memory, time on the CPU) that other processes
need. If the delay is too small, the SCO Doctor process will be
running more often. First this effects other processes in that they
do not get to run as long or as often. Second, the more the SCO
Doctor process runs, the more it will be measuring it's own
influence on the system.
The default appearance of the line graph is to show the values as
series of dots across the window. For views that only have one or two
values, this is not much of a problem. However, if your have several
different values the dots become indistinguishable. Not that they
overlap, but rather the color of the dots is often hard to recognize.
SCO doctor solves this with the "Fill Area". This is an
entry under the Format menu that toggles the fill area on and off.
When on, vertical bars are used instead of the dots. This makes the
values much more easily recognized.
Another option is "Smoothing", which you will also find
under the format. This allows you to "smooth" out
irregularities in the data, such as spikes. A factor of 0 means not
smoothing and 99 means maximum smoothing. The default is 45.
Part of SCO Doctor's monitoring is the ability to send an alert. This
is simply a notification that something has occurred on the system
that you want to be informed of. Different actions can be defined for
each alert, so depending of the severity of the alert the system will
queue them, display them or even start an external program such as
email or a pager. In fact, you can start any program.
Supplemental to the alert notification are Action Programs. Whereas
the programs defined in the alerts are there to warn you of potential
problems, the Action Programs are designed to take action based on
the alert. Although the set of Action Programs provided use the TCL
programming language, as with the alerts you can run any program you
Working with alerts
SCO Doctor has approximately 30 redefined "alert routines"
stored in a "Knowledge Module". You can add alerts that
monitor any of the system parameters stored within a management
database. These alerts are grouped into what is called the "Alert
When a particular value is reached or surpassed, an alert is
triggered. This is then displayed as a pop-up window on your SCO
Doctor screen. This you can see in Figure 0-22. In the top half of
the window are five pieces of information relevant to this alert. The
first is the system name. If you do not have the Network version,
then this will always be the name of the local system.
0-22 SCO Doctor Alert
Next is the priority of that alert. This can be either info, warning,
error, or critical, and can be configured for each alert. In this
case, it is just a warning. The name is the name of the alert which
you define when the alert is created (here: memory). If we select the
Alerts entry in the Intelligence menu, we can see the details of the
The description is a brief description of the alert. This should be
fairly descriptive of what the alert means. In this case ("Memory
resource low”) it is fairly straight forward. The Action is
what action should be or will be taken. In this case, nothing will be
done other than trigger the alert.
In the lower half of the screen are the details of the alert. In our
example we see that the number out of 32MB of physical memory, there
is only about 440KB left. If we look at the alert definition for the
memory alert, we will see that it is configured to trigger an
alert if more than 96% of physical memory is used (the threshold).
Creating alerts is a fairly straight forward process and is done from
the Alerts entry in the Intelligence menu. This brings you a list of
your currently defined alerts. If you use the arrow keys to select an
alert and then press enter, you will be shown the "Modify Alert"
window where you can change, or simply view, the details of that
alert .Figure 0-23 and Figure 0-24 show you the "Modify Alert"
window for the memory alert. If you look at the bottom of the
screen, you see here the word "More". If you tab down to
the bottom row and select "More" you will see the window
"More Alert Details", which, as the name applies provides
more details about the alert.
0-23 Modify SCO Doctor Alert Form - Page 1
0-24 Modify SCO Doctor Alert Form - Page 2
The values are as follows:
name: The name of the alert Description: A description of the
function of this alert
the alert is enabled or not.
interval between invocations of this alert.
database to be used to store the information gathered.
the table within the database to store this information.
the column within the table to store this information.
Priority of the alert.
Specifies the relationship to the threshold value that should be
used when determining if the alert is triggered. This is a
comparison, such as greater-than (GT), equal (EQ),
less-than-or-equal (LE), for exampleetc.
The value that is reached or exceeded to trigger the alert.
On the next screen you have:
type: The type of action that is to be take. Normal specifies a
normal UNIX command and TCL specifies an embedded TCLC program in
The name of the program to run when the alert is triggered. If a
UNIX command is specified, this will be the full path to the command
and any arguments or options. If a TCL program, this will contain
the path to the TCL script.
Notify by email:
A list of people to be notified by email when the alert is
Notify by pager:
A list of pagers to be dialed when the alert is triggered.
Notify by SNMP:
A list of SNMP management stations to be notified when the alert is
long to wait after an alert of this type is triggered before the
next one is sent. This prevents the system from being flooded by
identical alert notices.
many alerts of this type should be ignored before a notice is sent.
This is useful in case a threshold value might be passed for a brief
instant and then goes back to "normal."
schedule in cron format of when the alert should run.
If you select the Insert entry under the Edit menu, you will be given
a window very similar to that of "Modify Alert”, the
difference being that none of the fields are filled in.
Additionally, you may have selected a table that has several rows,
for example, the filesystem space. You may have both a root
filesystem and a /u
filesystem. They may be different sizes so percent free space has
different meaning. For example, if the root filesystem is 200MB and
the /u filesystem is 2GB,
10% free space on the root filesystem is 20MB, but 200MB on the /u
filesystem. This is the total size of the root filesystem.
Since having only 20MB might be an issue of concern to you, you may
want to set an alert for the root filesystem at 10%, but at 5% for
the /u filesystem. The
only way to do this is to have two alerts, one for each filesystem.
Another aspect of the configuration is when the alerts should
trigger. For example, you might have a system that has interactive
users during the day, but does a lot of batch processing at night.
You might then want a different set of alerts running at these
Monitoring of the alerts can also be done through an SNMP console.
You can configure each alert to send different traps to different
SNMP consoles, if necessary. However, this all requires that SNMP be
configured properly, which is beyond the scope of this book.
The Alert Library
As I mentioned earlier, the Alert Library contains all the alerts
that are defined for the database that is currently opened. The
alerts that system provides by default cover a wide range of areas
and are sufficient in most cases. Only when the system has
demonstrated problems or abnormalities is it really necessary to
change these. However, this depends on your unique set of
Be default the following alerts are configured; the name of the alert
is in parenthesis:
Alert - (alive) Notifies the Central Management Station
(CMS) that the system is alive.
Back Up Run Alert
- (backuprun) Runs the system back up and issues an alert
Alert - (bigdir) Determines when a directory is too big.
(MORE THAN 254 entries)
CPU Alert -
(cpu) Detects a CPU bottleneck. Trigger is set on the average
CPU. Note that the period should set long enough so that occasional
peaks do not trigger alerts.
- (daemon) To run the Daemon Action Program. Determines if
all required daemons are running and restarts them if not.
Disk Alert -
(disk) Determines if the system has a disk bottleneck. The
current disk throughput is measured and compared to the to the
maximum throughput. The threshold is then a percentage of the
maximum. Note that the maximum is determined by a sustained read of
the hard disk. This is not normally the case, so even disk loads as
"low" as 40% can be considered significant.
Disk Usage Alert
- (diskusage) determines when file system free space
is exhausted. Triggered when the used space in a particular
filesystem exceeds the threshold. What is acceptable is dependent on
the size of the disk as well as what kind of activity the disk sees.
Files Alert -
(files) Similar to diskusage, this alert is triggered when
the percentage of inodes used exceeds the trigger value.
- (license) This alert runs the License Action Program
that checks for software license conformance.
- (maintenance) Performs maintenance on the system
such as trimming log files.
- (manage) Detects managed systems that have not been
contacted, triggered whenever a managed system has not been
contacted for a period of time exceeding the threshold value.
- (memory) Detect a memory bottleneck. Triggered
whenever memory consumption exceeds the threshold.
Need Reboot Alert
- (need_reboot) Ddetects if a system should be rebooted.
Certain internal values will overrun if the system is kept up too
long. Therefore the system should be rebooted at least every 248
Print Jam Alert
- (print_jam) Detects when a printer queue has stopped
processing queued jobs. The term "jam" might be a misnomer
as this alert is triggered if a job has been waiting in an enabled
printer queue for too long. Often the cause is a printer jam,
but it might be due to something else.
Print Queue Alert
- (print_queue) Detects when a printer queue is too full.
Triggered when a print queue contains more than the specified number
-(reachable) Detects unreachable remote systems.
Triggered when a remote system is not reachable by ping.
Read Cache Alert
-(rcache) Detects a poor read buffer cache hit ratio.
Triggered when the average hit ratio drops below the threshold for
the specified period.
- (reboot) Detects a system reboot. When the system
starts, this alert is run immediately to see if the system was
shutdown properly or not. Note that SCO Doctor's definition of
"cleanly" might be different from yours. I have noted that
when I do a reboot instead of a shutdown, an alert is generated.
Rogue Process CPU
Alert - (rogue_process_cpu) Detects if a single process
is consuming too much CPU resource. Triggered when a single process
uses more than the defined percentage of the available CPU resource.
This is not always as it seems, particularly if you are the only one
on the system. Since there are no other user processes, it makes
sense that yours would get so much CPU time.
Memory Alert - (rogue_process_mem) Detects if a single
process is using too much memory resource. Here, too, a single user
process has a good chance of exceeding the threshold if it is the
only process on the system.
SMP Balance Alert
- (smpbal) To detect an imbalance in CPU usage in SMP
systems. Triggered when the difference between average CPU among
multiple processors exceeds the threshold value. The system "should"
ensure that the load is balanced. The period should be set long
enough so that normal "spurts" do not trigger an alert.
Swap Alert -
(swap) Detects a swapping or paging bottleneck. The number of
block paged or swapped is measured as a percentage of the maximum
disk throughtput. If too high, an alert is triggered. Like the disk
alert, this should be set low as any significant amount of paging or
swapping can be very detrimental to your system.
- (tunable) Identifies tunable parameters which are
configured too low. Triggered when a tunable system parameter gets
too low. This should be set high enough so that you aren't jumping
through the ceiling every five minutes, but low enough that you have
time to catch it. The SCO doc recommends 85% and I have never found
a reason to put any other value.
Write Cache Alert
- (wcache) Detects a poor write buffer cache hit
ratio. Like rcache, but for cache writes.
- (zombie) Identifies processes that have not been
cleaned up by the operating system. If the system has two many
zombies running around, there is a problem as the system is not
cleaning them up properly.
SCO Doctor Architecture
SCO Doctor is actually composed of two programs. The one that you
will be working with most of the time is the user interface, called
simply "doctor". The other part is the "agent",
and runs in the background collecting information as your system goes
about it's business. The bulk of the work is done by the agent,
which, among other things, does the following:
Records the necessary information and keeps in memory a database of
up to date information
"snapshots" of the system to disk. This creates the
Runs the alert
routines and action programs
Provides the doctor
interface with the requested information
The SCO Agent is made up of several different components. These
components perform the following tasks:
Alert Manager - Runs the Alert Routines.
Action Programs -
Programs run when specified alerts are triggered
Manager - Runs the Action Programs
Command Manager -
Runs the management commands from SCO Doctor
Manager - Responsible for communications between hosts.
Although not really a component, the configuration of SCO Doctor is
an important aspect of how it behaves. The configuration is provided
by text files, which allows you to add new data sources, rules,
alerts, and so on.
Because of the design of SCO Doctor, data collection can be extended
to include third party sources as well as on a per-table or
per-column basis. In addition, you can configure the system so that
data is collected on a specific times, at regular intervals, or
within a particular time window. This allows you to monitor different
activity at different times. (For example, during the day with
interactive users and at night with only batch jobs.)
Any data that is in a fairly regular format can be accepted by SCO
Doctor, which uses TCL as its input parser. As a result, any
application that can be configured to output in a regular format can
be used. This means, for example, if your database application can
output a report to a text file, then that output can be processed by
SCO Doctor. See the SCO Doctor Technical reference in the on-line
help for details.
The SCO Doctor stores its data in relational databases which contain
information about over 180 system parameters. By default SCO Doctor
will report on information about the active (live) system. However,
you can open up other databases to review historical information.
Perhaps the most powerful aspect of SCO Doctor is the ability to
diagnose problems that it has encountered. In many cases, SCO Doctor
can even make recommendations on what you can do to improve
performance. Unfortunately, this functionality is not available on
SCO Doctor Lite.
To interpret the live or active data, select the view you want and
then select "Interpret Views" under the "Intelligence"
menu. You can also interpret historical data by reading in another
database. Databases are opened from the "Open" entry in the
"File" menu. Note that if you have the lite version of SCO
doctor you cannot access any historical data.
SCO Doctor Configuration Files
The primary directory for the SCO Doctor configuration files is
/usr/lib/doctor. This contains several sub-directories where the
specific configuration information is stored, include alerts,
reports, action, and so on.. There are two basic files that you will
find in various sub-directories, based on their function. The
configuration file end with .cf and the TCL script files and in
*.tcl. Table 0421 shows the sub-directories and their function. Note
that what directories you have on your system will depend on whether
you installed SCO Doctor Lite, SCO Doctor or SCO Doctor for Networks.
Alert configuration files.
Computer based training files.
Desktop configuration files.
Sample modem dialers.
Inference Engine configuration.
Contains packages for remote software
Report configuration files.
User configuration files.
View configuration files.
Primary SCO Doctor Configuration Directories
The basic configuration information, such as what view is show by
default and how your printers are configured are stored in the
configuration files in /usr/lib/doctor/cf.
Table 0422 shows you the SCO Doctor configuration files.
General agent configuration.
Definitions for agent.cf.
Product directory and TCP/IP service
Definitions for "display.cf".
General doctor configuration.
Serial number and activation key licensing
Pager dialing configuration.
Definitions for printer.cf.
Network systems configuration.
General SCO Doctor Configuration Files
SCO Doctor has a spool directory like the printer and UUCP. This is
where SCO Doctor keeps the working files of the local system as well
as any remote system it communicates with. Table 0-3 shows a list of
the spool directories and their function. Note here as well that what
directories you have on your system will depend on whether you
installed SCO Doctor Lite, SCO Doctor or SCO Doctor for networks.
In-box for transferred files.
Directory for program log files.
Out-box for transferred files.
In-box for files received from SYSTEM_NAME.
Out-box for files to transfer to
Database files. There will be a sub-diretory
for each system.
Historical database directory for the system
Various status files.
Table 0-3 SCO Doctor Spool Directories
The SCO Doctor binary is kept in /bin /(/bin/doctor), but there are
several other programs that SCO Doctor users. These are kept in
/usr/lib/doctor/bin. Table 0-4
shows a list and their primary function. Once again, which SCO Doctor
Files will depend on your version.
Agent data collection program.
The cf configuration file access program.
Program to merge historical databases.
Library of shell script procedures.
File transfer utility
Remote command execution utility
SNMP trap generation program.