Jim Mohr's SCO Companion


Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at https://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 itself.

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.

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 this chapter.

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.

Some Basics

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:

ls -la

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:

man man

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 like this:

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 enter:

scohttp start

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 "Help”.

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 startup.

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.

Key Directories

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 /etc/default directory. 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 sub-directory subsystems provides details about authorizations based on "subsystems” such as memory, printing, backups, etc. The system directory contains general system information. Coupled with this is the /tcb 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.

The /dev 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:

name=fpu vec=13 dma=- type=80387

name=serial base=0x3F8 offset=0x7 vec=4 dma=- unit=0 type=Standard nports=1

name=floppy base=0x3F2 offset=0x5 vec=6 dma=2 unit=0 type=135ds18

name=console vec=- dma=- unit=vga type=0 12 screens=68k

name=adapter base=0x330 offset=0x2 vec=11 dma=5 type=ad rev=01 ha=0 id=7 fts=s

name=pci base=0xCF8 offset=0x8 vec=- dma=- am=1 sc=0 buses=1

name=apm vec=- dma=- PM v1.2

name=e3E base=0x300 offset=0xF vec=15 dma=- 3Com EtherLink III, unit = 0

name=tape vec=- dma=- type=S ha=0 id=2 lun=0 bus=0 ht=ad

name=chey vec=- dma=- type=S ha=0 id=0 lun=0

name=disk vec=- dma=- type=S ha=0 id=0 lun=0 bus=0 ht=ad

name=Sdsk vec=- dma=- cyls=1170 hds=64 secs=32 fts=sb

name=disk vec=- dma=- type=S ha=0 id=5 lun=0 bus=0 ht=ad

name=Sdsk vec=- dma=- cyls=1317 hds=64 secs=32 fts=sb

name=disk vec=- dma=- type=S ha=0 id=6 lun=0 bus=0 ht=ad

name=Sdsk vec=- dma=- cyls=1317 hds=64 secs=32 fts=sb

name=Stp-0 vec=- dma=- Vendor=ARCHIVE Product=VIPER 150 21247

name=cd-rom 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 normal start-up,

(or 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 /etc/inittab. 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 haltsys. 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 it.

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 removed.

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 book.

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 users?

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 as well.

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 jimmo.

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 program files.

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:



Account Administrators

Administer domain users and groups


Administer the local machine

Backup Operators

Backup files

Domain Guest

Guest uses in the domain

Domain Users

All users in the domain


Guest on the local machine

Print Operators

Administer printers


Administer replication of files between machines

Server Operators

Administer servers


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:



No Access

No Access






Full Control

Add and Read


Full Control

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:

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 the owner.

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 gotten annoying.

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 actual authentication.

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 administrative reasons.)

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 know!)

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.

Sharing Resources

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 two

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 Software.

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.

INSERT: usrmgr3.jpg

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 Administrators group.

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 again.

Figure 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 one.

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.

Figure 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 you want..

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.

Figure 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 installed.

Figure 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.

Figure 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 control.

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 UNIX.

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 list.

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 Printers

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 them.

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 about this.

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 directories.

Figure 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.)

Figure 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 c:\usr\net\servers\lanman\shares\asu\repl\export\scripts.

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 message.

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 temporarily.

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 AdministratorÕs group.

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

Figure 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

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 network.

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) man-page.)

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 documentation.

All versions of SCO doctor consist of four basic components or elements:

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 rebooted).

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 functionality:

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 Screen

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:

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.

Available Views

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.

Figure 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 Format menu.

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.

Figure 0-19 SCO Doctor View

Figure 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 Config menu.

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:

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.


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 10 minutes.

Figure 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 want.

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 Library".

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.

Figure 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 alert.

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.

Figure 0-23 Modify SCO Doctor Alert Form - Page 1

Figure 0-24 Modify SCO Doctor Alert Form - Page 2

The values are as follows:

On the next screen you have:

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 different times

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 circumstances.

Be default the following alerts are configured; the name of the alert is in parenthesis:

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:

The SCO Agent is made up of several different components. These components perform the following tasks:

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.




Action programs.


Alert configuration files.


Binary programs.


Computer based training files.


Basic Configuration.


Database configuration.


Desktop configuration files.


Sample modem dialers.


Printer fonts.


Inference Engine configuration.


Contains packages for remote software deployment.


Report configuration files.


Subagent's location.


User configuration files.


View configuration files.

Table 0421 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 configuration.


Display configuration.


Definitions for "display.cf".


General doctor configuration.


GDI definition.


Postscript preamble.


Serial number and activation key licensing configuration


Pager dialing configuration.


Printer configuration.


Definitions for printer.cf.


Network systems configuration.

Table 0422 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.


Communication pipes.


In-box for files received from SYSTEM_NAME.


Out-box for files to transfer to SYSTEM_NAME.


Database files. There will be a sub-diretory for each system.


Historical database directory for the system SYSTEM_NAME.


Various status files.


Modem communication statistics.

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.


TCL script to kill all running programs.


Login shell for modem communications


Client/server daemon for modem communications


Program to communicate alert notices.


Returns the operating system type.


Program to dial pagers in response to alerts.


Primary removal script for doctor.


Displays version number program.

Table 0-4 Key SCO Doctor Programs

ARCServe/Open Lite

SCO ARCserve/Open is a full-featured backup suite that allows you manage backups on several different operating systems from a system console. The Lite version, provided on the CD, is only capable of backing up a single SCO system, but still contains most of the advanced features. Per the SCO documentation, features not supported by SCO ARCserve/Open Lite will be grayed out. However, this appears to not always be the case. The features supported include:

Starting ARCServe/Open

If the product was installed correctly, there will be an icon in the System Administration folder that you can double click on, or you can start it from the command line with arcserve. You are then shown the window in Figure 0-25.

Figure 0-25 SCO ARCServe/Open Start-Up Screen

Each of the six buttons accesses the same part of the program as you find under the Manager menu. The difference is the Utilities menu, which provides a couple of system utilities. Note that if you click on the Create Recovery Disk Set entry, you will get a message with ARCServe/Open Lite saying "Disaster Recover System: Not Licensed".

If your tape drive is already installed, then you should be ready to go. I would still suggest clicking on the "Device Management". On my system, the tape drive is not recognized by the kernel. However, ARCServe does see it correctly. Therefore, like all other backup systems, I would recommend that you do extensive tests to ensure that your data is written correctly and can be read from the tape later.

One thing I need to point out is that ARCServe does not keep track of already open windows. Therefore, if you are not careful, you could have several iterations of the same window open. For example, you might be monitoring the status of a job with the "Job Queue Manager" and iconify it to get it out of the way. A little while later, you click on the "Job Queue" button again to check on the status of the job and again you iconify it. Later, you again, click on the "Job Queue" button. You now have three copies of the Job Queue Manager running.

Backing up Your Data

Clicking on the Backup button or selecting Backup from the "Manager" menu brings you the window shown in Figure 0-26. Even though this screen shot was taken from the Lite version, there is still an option to select a remote host. Clicking this has no effect. The only choice that works is selecting the name of machine, or the arrow on the left that expands the tree of the machine, showing you all the files and directories in the root filesystem.

Figure 0-26 SCO ARCServer/Open Backup Manager

The window is broken into two halves. The top half is where you select the files you want to backup and the bottom half is where you select the destination device for the backup. At the top of the window are two menus. The file menu allows you to open a script file, which contains the specifics of previous back-up jobs. If you have configured a job, you can save it using the Save As entry. If the job is one that you had previously opened, the Save entry will write it back to disk.

The Backup menu lets you select the various options you want to set for the job. The Run entry will let you start the current job. Normally, you have several options here, such as scheduling the job for later. These are not active in the Lite version. Your only choice is to submit the job "on hold". This queues it, but it won't be run until you start it.

The Reporter entry allows you to save the activity of the backup to a file. You can report all activity or just errors. With the full version, you can even send an SNMP alert.

There are several sub-menus under the Options entry. The "Options -> Options" entry allows you to configure various this such as the verifications options, deleting files and recording the backup activity to the ARCServe database. Deleting files can be combined with the filtering mechanism. Other options are not available with the Lite version.

For example, in the full version, you can force other users off the system before the backup starts. This prevents inconsistencies when a user saves a files after it was backed up but before it was compared. However, it annoys a lot of users. The Clear Archive bit is useful if you are doing incremental backups. When the file is backed up the bit is set. If the file is not accessed between then and the next incremental, there is no need to back it up.

Finally there are the Source and Destination options. These are the same as the sources and destinations buttons, which we will get to shortly.

Underneath the menu are three buttons. The one that looks like a traffic light, brings up the same window as the Run entry in the Backup menu. The hand holding the print-out brings up the Reporter options. The check mark brings up the Options window.

The advanced options are not available in the Lite version on the CD. The "locked File Retry" option tells ARCServe how to react if the file it is trying to access is lock. The only option available in the lite version is to retry immediately. The "Access Deny Method" is only useful if you have Netware server and the options refer to the various "modes" that files can be in. The "Pre/Post Execution" allows you to specify commands (including shell scripts) that should be run before or after the backup runs.

The "Filter Options" entry give you a wide range of possibilities to filter the files to include in your backup or to exclude. Here you can select specific patterns or specific dates, such as the creation date or last date modified. Unfortunately, you cannot combine the two.

However, you do have a wide range of choices when selecting the times. For example, the criteria you select can be based upon the modification date, the creation date or the last access date. This is done with the "Files based on" pull-down menu. (See Figure 0-27.) Just below this is another pull-down menu where you specify the date in one of four ways. First you can say "On or Before" to specify a specific date. Next is "On or After", which is essentially the opposite of the previous option. This might sound redundant as you could combine these with include or exclude to get the files you wanted. However, consider this. For archiving purposes you want to include only the files before a specific date. You could then select remove files, so that they would no longer be on your system. Alternatively, you leave the files in place, but the next backup only gets the files that match the criteria after that date.

Figure 0-27 SCO ARCServer/Open Date Filter Window

Next, is "Between". Here you specify a pair of dates to match the criteria. Finally, is "Within". Here you don't specify a date, but rather a period of time. For example, you specify within 1 day. Therefore all files that have been changed, modified, or created within the last day will match. This goes from 1 day to 10 years.

The Node options refer to filesystem nodes and not network notes. Here, you have the option to traverse symbolic links, NFS mounts (only with the full version), reset the last access time, and turn off estimation of the backup size. In the case of ARCServe/Lite, the estimation option is of no use. If you had the full version and were backing up multiple systems, the client would send an estimate of how much is going to be backed.

At this point, no files have been selected. You can tell this by looking at the box to the left of the file and directories names. Since the boxes are empty, we know nothing has been selected. Clicking the box will fill it in. In the case of directories, this means that all of the files and directories underneath it are also selected. If we were to click on the /bin directory, the box next to it would be filled in. However, the one next to the name of the machine (which indicates the root directory) is only filled in half-way. This means that only some of the files underneath have been selected.

At the bottom of the window we select the destination device "group". A device group can consist of one of more tape drives. If you have multiple tape drives on your system, they can be configured into groups. This allows you to backup a system that is too large to fit onto one tape using "drive spanning". Or, you can speed up the backup process by backing up to more than one tape drive.

By default, groups are given the names of the planets which (apparently) correspond to the ID of the device (Excluding Earth). Since Mars is the third planet it gets the third SCSI ID (ID 2). Since my tape is set up on ID, the default group I have is MARS. For details on tape groups see the section on device configuration.

au: ID 2 OK in para above??

Yes. Counting goes 0,1,2…

Since I have no other tape drives, I have no other groups, so MARS is the only group I can select. However, clicking the Destination button brings me several options to choose from. At the top of the screen, we can input the name of the device group, along with the tape name and a session password. The tape name is the name the system will use when referring to this tape. When restoring, the system will be able to select the correct tape. The session password is used to add an additional level of security to your backups.

Next are the options I want to specify for the first tape in the group. Since I only have one tape, these will apply to that tape. Append to Tape will do just that. It will find the last session on that tape and begin writing from that point. The "Overwrite Same Tape, or Blank Tape" will overwrite the tape in the drive, but only if it has the same name or is blank. If a different tape is in the drive, the job will fail. Finally there is "Overwrite Same Tape, or Blank Tape first, then any tape."

You have similar options if you are spanning tapes. The key difference is that you cannot append to tapes with the second (or subsequent) tapes. Instead it must overwrite them. However, you do have the choice of whether ARCServe should only write to a tape of the same name, a blank tape, or whether it can write to any tape. If you have only one tape drive, the system will wait the number of minutes specified in "Span Tape Timeout".

At this point, you could start the job if you wanted, but instead, let's look at a couple of options. In the backup menu, there are five entries. The bottom two (Source and Destination) are the same as the buttons in the main part of the window.

Restoring Your Data

Restoring your data is as easy as backing it up. However, there are a few more options to be aware of. When you click on the Restore button, you are given the window shown in Figure 0-28. Like the Backup window, the Restore window is broken up into two halves. The top half is the source and the bottom half is the destination. As you might have guessed, the roles have been reversed. Now the tape drive is the source and the filesystem is the destination.

Figure 0-28 SCO ARCServer/Open Restore Window

At the top are two menus. The File menu has the same options are the same as for the Backup. Under the Restore menu, you will also see some similarities. The Run and Reporter entries serve the same function as with the backup.

Here, too, you also have an Options entry, but it serves a slightly different function. The first option allows you to create empty directories. The next two only apply to Novell filesystems. "Preserve Directory Space Restrictions" means that the system will assign the same "directory space" restrictions on the destination volume as there were on the source volume. The "Preserve User Space Restrictions'" means that same user restrictions on the source volume will be applied on the destination. Lastly, there is the option to execute a command before or after a job. In contrast to the pre/post execution for the backup, this seems to work! As with the backup, you also have the ability to filter the files to be restored.

In the choice of tape sources, you will see entries for each tape job that this database holds. In the example in Figure 0-28, you see that there are two tapes listed. Each time you overwrite a tape, the content will change, but the tape name/identifier will stay the same. This allows ARCServe to keep track of the tapes. Also, when you erase a tape, the tape is erased from the database.

If you double-click on the tape name, it will expand to show the sessions that are on the tape. In Figure 0-28, you can see that the first tape has two sessions on it, labeled Session1 and Session2. Following this is the name of the system that was backed up. In this case, junior. Finally, there is the base directory of the backup. In the first session, the /tcb directory was backed up and /stand in the second. Double-clicking on the session shows you the list of the files and directories that the backup contains.

Similar to when you make a backup, you can select directories or individual files to restore. Files and directories selected have a filled-in box to the left of them. Unselected files and directories have an empty box. Directories that contain selected files or sub-directories are half filled in. If we want to restore the entire backup, we just click the box next to the session name.

As the SCO doc indicates, you must always must always select a destination when restoring your data. Unfortunately, there does not appear to be a way to simply say "restore to it's original location." Instead, you have the option of selecting the filesystem you want to restore to. By clicking the Destination button, the "Destination Options" window (see Figure 0-29), where you can specify the directory structure during the restore. This allows you to recreate the directories (or not).

Figure 0-29 SCO ARCServer/Open Restore Destination Options

The first option (Do not Create the Base Directories) means that the files will be restored directly into the directory you specify in the destination window. For example, I wish to restore the Directory HTML, which contains two sub-directories and a few files. However, I want to restore them to a different location, for example /tmp. With this option, the files and sub-directories will be written directly into /tmp and the parent directory HTML will not be created.

If you select the second option (Create Directories from the Base), the parent director will be created starting from the destination directory. In the example above, the HTML directory will be created in /tmp.

Assume the full path to the directory was /usr/lib/HTML and you selecting the third option (Create Entire Path from Root). When you specify /tmp as the destination directory, the files are created in /tmp/usr/lib/HTML. Therefore, to restore them to their original location, you should select this option and the / as the destination.

In the lower half of the screen you have options for "File Conflict Resolution". This means you can select what ARCServe should do if it tries to restore a file that already exists. Here, you have the choice of overwriting the existing files, renaming the files you are restoring, skipping the files that exist, or only overwriting them if the ones on the tape are newer.

Aside from simply backing up and restoring files, there are several backup-related administrative functions that you can perform through ARCServe. Unlike command line backup programs like tar or cpio, you submit jobs to the SCO ARCserve/Open job queue. Like a cronjob, the ARCServe job contains information about the job, such as the time it should be executed and the owner. When the time is reached, the job is started.

With the Lite version (on the CD), jobs are submitted immediately. However jobs can be submitted "on hold", which the job won't actually start until you tell it to. To manage these jobs (as well as others if you have one of the other versions), SCO ARCServer/Open sees two types of users: Queue users and queue operators.

In general, a queue operator has complete control of ARCServe. The operator can overwrite tapes, manage the tape devices and groups, as well as have complete access to all of the files on all of the tapes. Root is the only default operator and is also the only default user.

The SCO Development System

Without turning this book into a one on C programming, there is not too much one can say about the SCO development system. You are provided with a wide range of programming tools, including (obviously) a C compiler, cb (code beautifier), lint, cflow (used to analyze the flow of your program), and a debugger.

In addition to the standard C libraries, the SCO Development System includes C++, networking, and X libraries, which allow you to create applications for any part of your system. In support of this is the Custom Distribution Mastering Toolkit (CMDT), which enables you to create product distributions that conform to the SSO structure that SCO uses.

Although the development system document is not intended as a C language tutorial, it includes very extensive on-line information that guides you through even the most basic issues. The documentation consists of three "books” and the on-line reference pages. The first book is "Developer's Topics” which concentrates more on the information needed during the actual coding. "Programming Tools Guide” describe the various tools that you can use when developing your programs and applications. This details the use of both the compiler and linker, as well the other tools such as the debuggers, profiler and make?. The "Network Programmer's Guide” provides more in-depth information on those topics that would be of interest to someone developing network applications.

Next: X-Windows


Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/