Jim Mohr's SCO Companion

Index

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 http://www.linux-tutorial.info/

Basics of SCO UNIX


There are many SCO systems around where the user does not even know that it is an SCO system. Many company have point-of-sales systems hooked up to an SCO host. For the users at the cash register, they never see what is being run. Therefore, there is really no need for you to go into details about your system for any other reason than pure curiosity. Assuming you find out that you are running on an SCO system.

On the other hand, if you do have access to the command line or interact with the system by some other means, knowing how the system is put together is useful information. Knowing how things interact helps expand your knowledge. Knowing what's on your system is helpful in figuring out just what your system can do.

That's what this is chapter is about: what's out there. We're going to talk about what makes up the SCO Open Desktop and Open Server products. Part of this includes the different components that make up each product. The components are related to the different processes that go on in a computer system, such a printing and accessing a network.

Each of these components is composed of individual files and programs. What each of these programs is and what it does may provide you with new tools to make your life easier. This goes for both the user and the administrator.

What SCO is All About

A Guided Tour

Unless you are on familiar ground, you usually need a map to get around any large area. To get from one place to another, the best map is a road map (or street map). If you are staying in one general area and are looking for places of interest, you need a tourist map. Since we are staying within the context of SCO and we're looking for things of interest, what I am going to give you now is a tourist map of SCO UNIX directories.

In later chapters, we'll go in detail about many of the directories that we are going to encounter here. For now, I am going to briefly describe where they are and what their function is. As we later get into different sections of the book, it will be a lot easier to move and know how files relate around if we already have an understanding of the basic directory structure.

The top-most directory is the root directory. In verbal conversation, you say "root directory," whereas it may be referred to in text as simply "/". Under root, there are several sub-directories with a wide range of functions. shows the key sub-directories of /. This representation does not depict every sub-directory of /, just the more significant ones. In subsequent diagrams I will continue to limit myself to the most significant directories in order to keep from loosing perspective.

Figure 0-1 The root directory

In order to talk about the root directory, we actually need to talk about two directories at the same time. With ODT 3.0, the programs needed to boot and load the operating systems were located in the root directory. OpenServer changed that with the introduction of the /dev/boot filesystem. The programs needed to boot are now located here. Rather then repeating this explanation for every file, I will simply refer to them without any path. Unless otherwise noted, these files are in / on ODT 3.0 and in /stand on OpenServer.

One of these files, one could say, is the single most important file: unix. This file is the operating system proper. It contains all the functions that make everything go. When referring to the file on the hard disk, one refers to /unix whereas the in-memory, executing version is referred to as the kernel. On OpenServer this file resides in /stand, but there is a symbolic link to it in /.

The next file is actually accessed before unix. This is the boot program. For those of you who are familiar with SCO UNIX systems, it is the boot program that presents the now famous Boot: prompt. It is this program that reads the unix file from the hard disk into memory and begins executing it. We'll get into more details about how the system gets to the boot program and the entire boot process in the section on booting your system.

The dos file can be used to boot the system, as well. Rather than booting UNIX, the dos program finds the primary DOS partition on your system (if you have one) and boots that.

New to the /stand directory are two programs: link and bootos. The /stand/link program is used to install boot-time loadable drivers into your system (these are drivers that normally come with third party products that are needed when booting your system). The /stand/bootos program is used to boot other operating systems. This not only includes DOS as in previous versions, but also Microsoft Windows NT and OS/2. Lastly there is the sfmt program. This is used to low-level format hard disk connected via an OMTI controller. For more details see the respective man-pages.

In addition to the programs needed to boot the operating system, there are many files located in the root directory that are used by the root user (the system administrator). This is because the / directory is the root user's home directory. This is where these files reside. Since the root user does not login until well after the system has booted, there is no need to have these files in /stand. Therefore, on both ODT 3.0 and OpenServer, they only exist in /.

The first directory we get to is /bin. Its name is derived from the word binary. Often the word binary is used to refer to executable programs or other files that contains non-readable characters. The /bin directory is where many of the system related binaries are kept, hence the name. Although several of the files in this directory are used for administrative purposes and cannot be run by normal users, everyone has read permission on this directory, so you can at least see what is here.

The /dev directory contains the device nodes. As I mentioned in our previous discussion on operating system basics, device files are the way both the operating system and users gain access to the hardware. Every device has at least one device file associated with it. If it doesn't, you can't access it. or more details on what each of the individual device files is, take a look at chapter 5.

The /etc directory serves as sort of a dumping ground for programs that don't seem to belong anywhere else. Its name comes from the common abbreviation etc for etcetera. This means "and so on." Normal users do not normally execute programs in /etc. Although there are a few programs there that can be executed by normal users, most of what is kept here is generally for system or administrative use.

Under /etc, are several sub-directories of varying importance to both administrators and users Figure 0472 shows what the sub-directories of /etc would look like graphically.

Figure 0282 Sub-directories of /etc

The /etc/auth sub-directory contains security or authorization related information. The name "auth" comes from "authorization." Normal users do not have access to this directory (for obvious reasons). However, if you'd like to take a peek at its insides, take a look at chapter 4.

Although normal users can move around inside of it, the /etc/conf directory is primarily of use to the system administrator. The name "conf" is short for "configuration." Underneath /etc/conf are several more sub-directories. Combined with a few programs scattered around the system, these directories are collectively called the link kit. These are the files and programs used to add new devices to the system, change system parameters and combine them all into a new copy of the operating system, /unix. (/stand/unix on OpenServer)

One sub-directory that is of importance to both users and administrators is the /etc/default directory. As its name implies it contains default information. In general, the files in this directory are readable by everyone, so the users on a system can take a look at the defaults themselves. Most of the files in this directory either have their own man-page or are associated with programs that do.

The /etc/fscmd.d directory is another one that is of interest only to administrators. The name "fscmd" is from "filesystem commands" and the ".d" at the end is a standard convention to indicate a directory. In practice, even administrators do not need to go into here. This is where the filesystem specific programs exist, which are actually called by their generic namesakes. For example, the program used to clean (ensure the integrity of) a filesystem is called fsck. When invoked by the system administrator, the fsck program first determines what type of filesystem is being cleaned, then executes the appropriate program in /etc/fscmd.d. Rather than having one monolithic program that contains the code for all the filesystems, there is one, small front-end that calls the others.

When you run the ps (process status) command, rather than hunting through several system files, it simply reads the information in the files in the /etc/ps directory. If you have write permission in this directory (for example, as an administrator) you can remove these files and see how much longer the ps command takes to run as it must first gather the information stored in /etc/ps.

In the /etc/perms directory are files containing lists of all the files that come with the installed products. Sort of a packing list, you might say. In addition to file and directory names and where they end up, there is also the name of the owner, group and default permissions on each file. The name "perms" comes from "permissions." In OpenServer, the /etc/perms directory is not used in the same way. We go into more details about that later. For more information, see both the custom(ADM) and fixperm(ADM) man-pages.

The /etc/rc.* directories contain files that the system uses when starting up or shutting down. Which files are read depends on whether the system is being started or shutdown. We'll talk more about these directories and their associated files in the section on starting up and shutting down the system.

Moving back up to the root directory, we next find the /lib directory (for library). If the SCO Development System has been installed on your system then this directory will contain the libraries needed for program development. Hence the directory name "lib." In addition, there are usually some of the programs necessary for a kernel rebuild.

The /shlib directory contains the shared libraries used by the system. For those of you who are not programmers, a shared library is a means of providing uniformity across programs as well as saving space. For example, almost all of the programs that users and administrators use accept input from the keyboard and write output to the screen. Rather than each program having copies of the necessary functions to do this, a single copy is stored in a shared library. Since the code for performing this I/O is not in the program itself, the program can be smaller and thereby saving space. If ever this code needs to get changed, it can be changed in one place and you don't run the risk of forgetting to change it somewhere.

The /tcb directory is used in conjunction with the /etc/auth directory. TCB is an abbreviation for Trusted Computing Base. Whereas the /etc/auth directory contains just data files, the /tcb directory contains both data files and the support programs used to manage and administer system security. We will be covering system security in a lot more detail in chapter 4.

The /usr directory contains many user-related sub-directories. Note the 'e' is missing from "user". In general, one can say that the directories and files under /usr are used by and related to users. There are programs and utilities here that users use on a daily basis. Unless changed, /usr is where users have their home directory. Figure 0473 shows what the sub-directories of /usr would look like graphically.

Figure 0283 Sub-directories of /usr

Whereas /bin contains programs that are used by both users and administrators, /usr/bin contains files that are almost exclusively used by users. (However, like everything in unix, there are exceptions.) Here again, the bin directory contains binaries.

The /usr/adm directory contains mostly administrative data. The name "adm" comes from "administration." The name There are three key files stored here. The first is the messages file that contains all the system service, kernel and device driver messages. Next is the hwconfig file. This is where the hwconfig program gets its information. Last, is the syslog file. This is where the system logs messages from the syslogd daemon. For more information, see the respective man-page.

There is also an important directory here: sa (system activity reporter). This is were the sar utility gets and writes its information. Many of the files in this directory are data files, so you really can't go looking through them with a text editor. Check out the sar(ADM) man-page for more details.

The /usr/include directory and its various sub-directories contain all the include files. For a normal user and even most system administrators, the information here is more a place to get one's curiosity satisfied. However, for me that is enough. This directory, and its various sub-directories contain information that both the kernel needs when being re-created and programs need when being compiled. (For those of you who know that this is dramatic over-simplification, all I can say is that you already know what this directory is for anyway)

Many system parameters and values are stored inside the files underneath /usr/include. Because of the information provided in many of the files, I will be making reference to them through the book. Rather than spelling out the full path of the directory I will make a reference to the files relative to the /usr/include directory, the same way that is done in C source code. For example, when I refer to something like <sys/proc.h>, I mean the full path /usr/include/sys/proc.h. When you see something enclosed in the angle brackets like this, you can make the expansion yourself.

The /usr/lib directory is difficult to explain. Without belittling its significance, I have to say that it's pretty much a dumping ground for things that don't fit elsewhere. (didn't I say that about /etc?) We could say that it contains the user related library files (based on its name). However, that still does not accurately describe the complete contents. One thing it contains is the library files that are less general than those you find in /lib. These include the libraries for cross compilation in DOS and OS/2. shows what the sub-directories of /usr/lib look like graphically.



Figure 0284 Sub-directories of /usr/lib

A little known aspect of SCO UNIX is that it has built-in (albeit limited) abilities to do system accounting. You can keep track of system resources on the system on a per user basis and charge them for that usage. All the associated files are kept in /usr/lib/acct. The name "acct" comes from "accounting."

The /usr/lib/cron directory contains the data files that the cron, at, and batch utilities use when running non-interactive jobs. Not only does it contain the commands to be run and the schedule to adhere to, but it also contains configuration information for the jobs as they run. This is also where the access lists for the three utilities are stored.

For a normal user, the /usr/lib/custom directory is of little value. It contains information, which custom uses when installing or removing software packages. In addition is contains a history file (/usr/lib/custom/history) that list all the software that has been added or removed using the custom utility. Here you will also find all the removal scripts for the installed packages.

Every time you run passwd to try to change your password, the system determines if your password is "good." "Good” is determined by both the /etc/default/goodpw file and the files in /usr/lib/goodpw. It is possible through configuring the files in this directory to restrict it far beyond the defaults. For more details see the goodpw(ADM) man-page.

The /usr/lib/keyboard directory contains files that are used to configure the system console keyboard. Through these files, you can configure your keyboard to accommodate one of several different languages. You can even configure them for dialects of the same language, such as the German keyboard as used in Switzerland or Germany. You can also change these files to create some totally new keyboard layout, such as the Dvorak. For more details see the keyboard(F) man-page.

In keeping with the internationalization theme, we next look at the /usr/lib/lang directory. Here we have the file used to determine language specific things such as the collation sequence, decimal and thousand's separator, or the names of the months and days of the week. For more details on this, look at the locale(C) man-page.

The /usr/lib/mkdev is normally only of interest to system administrators. The name "mkdev" comes from "make device" and the scripts in this directory are used to add devices to your system. Adding devices to the system is done by using the /etc/mkdev utility. The argument passed to it is the name of the device that you want to add, which turns out to be the name of one of the scripts in this directory. The scripts then ask the necessary questions to install that device and may relink the kernel. We'll talk a lot more about adding devices in chapter 5.

The /usr/lib/mkuser directory is usually never accessed directly. Instead, the files here are used every time you run the system administration shell (sysadmsh in ODT or scoadmin in OpenServer). The files in here are accessed when you add or "make" a user. Hence, the name. Along with the information in the /etc/default/authsh file, the system creates user accounts based on the values input in the sysadmsh. We'll talk more about these files in chapter 4..

The /usr/lib/sysadm directory contains information used by the system administration shell. Here the data files are located that are used to create all the menus as well as other programs that the sysadmsh calls to actually get the work done. Keep in mind that if you are running SCO OpenServer, the sysadmsh has been replaced with scoadmin.

The /usr/lib/terminfo directory contains both the source files and compiled versions of the terminfo database. Terminfo is the mechanism by which the system can work with so many different types of terminals and know which key is being pressed. For more information, see the terminfo(M) man-page.

When configuring UUCP, all the necessary files are contained in the /usr/lib/uucp directory. Not only are the configuration files here, but this is also home for most of the uucp programs. UUCP (Unix-to-Unix Copy) is a package that allows you to transfer files and communicate with remote systems using serial lines. We'll talk in more details about this directory in the section on Networking.

One directory that I didn't mention above requires special attention: /usr/lib/sh. It contains a single file and that file is a gold mine. Well, it's a gold mine if you are a shell programmer. It contains a dozen shell functions that can be used in many different circumstances. If you are a shell programmer, take a look at this file and you will learn a load of new tricks. I'll talk more about this file and those tricks in the section on shells and shell programming.

Moving back up to the /usr directory, we find the /usr/local sub-directory. This may or may not contain anything. In fact, there are no rules governing its contents. It is designed to contain programs, data files, and other information that is specific to your local system, hence the name. There is often a bin directory that contains local programs and a lib directory that contains data files or libraries used by the programs in /usr/local/bin.

Also in the /usr directory is /usr/man. This is where the man-pages and their respective indices are kept. This directory contains the index files, which you could search through to find a command you are looking for. You can also create and store your own manual pages here.

The /usr/mmdf directory contains all the programs and configuration files for MMDF. MMDF is SCO UNIX's default mail system, which we will get into details about MMDF in later chapters. By default the sub-directories in here are readable by everyone, so you can poke around a little and see what it's all about.

The /usr/spool directory is the place where many different kinds of files are stored temporarily. The word "spool" is an acronym for simultaneous peripheral operation off-line. This is the process whereby jobs destined for some peripheral (printer, modem, etc) are queued to be processed later.

There are several sub-directories that are used as holding areas for the applicable programs. For example, the /usr/spool/cron directory contains the data files used by cron and at. The /usr/spool/lp directory not only contains the print jobs as they are waiting to be printed, it also contains the configuration files for the printers.

As you might guess, since MMDF is SCO's primary mail system, the /usr/spool/mmdf directory contains mail messages that are being processed, waiting to be sent. The same thing applies for /usr/spool/uucp. The two directories /usr/spool/uucplogins and /usr/spool/uucppublic are used by UUCP when communicating with other systems via UUCP. We'll talk about them later in chapters 10 and 13.

Lastly is a pair of directories that work together: /opt and /var/opt. Although these directories did exist in ODT 3.0, they were essentially empty. However, these two directories are one of the key components of OpenServer. These directories are used by the Static Storage Objects (SSOs), which I will talk about in a moment.

Okay, so that's about it. There were many directories that I skipped (As I said I would at the beginning of this section). Think about the comparison that I made to a tourist map. We visited all the museums, 200-year-old churches and fancy restaurants, but I didn't show you where the post office sub-stations were. Granted that such offices are necessary for a large city, but you really don't care about them when touring the city. Just as there are certain directories and files that are not necessary for an appreciation and understanding of the SCO UNIX directory structure.

What is SCO UNIX made of?

There are many aspects of the SCO UNIX operating system that are difficult to put labels on. We can refer to individual programs as either utilities or commands, depending on the extent of their functions. However it is difficult to label collections of files. Often the labels we do try to place on these collections do not accurately describe the relationship of the files. However, I am going to try.

If you have been working with an SCO system for a while, there are certain aspects of the operating system that you may have heard of, but not fully understand what they do. In this section we're going to talk about functions that the system performs some of the programs and files that are associated with these functions. We're also going to talk about how many of the system files are grouped together into what are referred to as "packages" and discuss some of the more important packages.

In our tour of the SCO UNIX directory structure, I talked about the /etc/perms directory and described it as sort of a packing list. It is here in the files of the /etc/perms directory that the packages are defined. Each file in /etc/perms has a name that reflects its function and the packages it contains. I will go into more detail about the contents of these files in the section on installing your system. However, I need to talk about some of these packages in order to set the stage for many of the topics I will be covering later.

Why is it important to know the names of the different packages? Well, for the average user, it really isn't. However, the average user logs on, starts an application and has very little or no understanding of what lies under the application. The mere fact that you are reading this book says to me that you want to know more about the operating system and how things work together. Since these packages are the building blocks of the operating system (at least in terms of how it exists on the hard disk), knowing about them is an important part of understanding the whole system. First, let's talk about how the packages are broken down in ODT. You can get the names of all the packages by running this command:

grep '#!' /etc/perms/*

In order to be able to do any work on an SCO UNIX system, you have to first install software. Most people think of installing software as adding a word processing program or database application, but any program on the operating system needs to be installed at one time or another. Even the operating system itself was installed.

Earlier, I referred to the SCO UNIX operating system as all the files and programs on the hard disk. For the moment, I want to restrict the definition of "operating system" to just those files that are necessary for "normal" operation. SCO has defined that set of programs and files as the Run-Time System or RTS. Although there are many files in the RTS that can be left out to have a running system, this is the base set that SCO installs.

The list of the files that compose the RTS package are in two files: /etc/perms/rts and /etc/perms/rtsmd. If you examine these files, you see a major separation in functionality. Whereas both contain very basic programs, the /etc/perms/rtsmd contain files and programs that are related to the hardware or the machine itself. These are dependent on the machine, or machine dependent, hence the name /etc/perms/rtsmd (RTS Machine Dependent). (Note that these files do not change if you have a different machine or architecture, but rather the files are, for the most part, directly related to the hardware.)

Perhaps the next most significant package is the extended utilities, or EXT package. These cover a wide range of areas such a printing, mail, backups and adding users. Like the RTS, the extended utilities have two files, /etc/perms/ext and /etc/perms/extmd. Also like the RTS, the file /etc/perms/extmd contains machine dependent (machine related) programs and files. The /etc/perms/rtsmd file contains only the link kit, which is the collection of files used to create a new kernel. We will talk about the link kit in much more detail later.

SCO has defined a set of files that it considers the base set of extended utilities. This package is called BASE and contains such things as an unlimited precision calculator (bc), a calendar (cal) and a disk copying program (diskcp).

Figure 0285 SCO product units

One would be hard pressed to find an SCO system where users don't print. Printing is one of the more common operations on a system. If one is talking about the act of printing, the files and programs that allow users to print are collectively called the "print spooler." If one is talking about the files and programs themselves, these files are referred to as "the LPR package." This is what we will talking about here.

Contained within the LPR package are the programs that the system uses to manage the printing process. These include the program that schedules specific print jobs for specific printers: the print scheduler; as well as the programs that actually send the files to the printers. There are, of course, other programs that check the status of the print process, stop and start the print schedule, etc. We'll be talking in more detail about all of this in the section on printing.

Another commonly used package is MAIL, which contains the files used to communicate between users via electronic mail (what else). This includes the mail program itself and its related programs, but it also contains the MMDF files. Although MMDF, is actually part of the MAIL package, it is often (although incorrectly) referred to as a package on it's own.

Saying that the MAIL package contains just the files for communication between users via electronic mail is not entirely true. The MAIL package also contains a few other programs (write, hello, and mesg) that are used to communicate directly between users. This shows how files are sometimes just lumped together in somewhat arbitrary packages. For more information see the respective man-pages.

Similar terminology applies to the UUCP package. It contains more than just UUCP. The UUCP (UNIX-to-UNIX copy) package can be used in conjunction with mail, but can also be used on it's own to transfer files between systems. This package also contains the modem configuration and access files (referred to as "dialers" as they dial the phone). However, the UUCP package contains more than just programs to copy file between systems. There is also the ability to start programs on the remote system (uux), as well as a simple terminal program (cu).

The SYSADM package contains system administration programs. This, however, does not contain the system administration shell, which is considered part of the RTS package.

What the SYSADM package does contain is "supplemental" administrative tools. This includes programs like last which reports on the last time a user was logged in, or ncheck, which can be used to find out what file is associated with a particular inode. The package also contains the tunesh or Tune-Shell program.

The BACKUP package, like the SYSADM package does not contain most of the files that do the actual backup, but rather contains supplemental files, such as those used for scheduling backups. The "real" backup programs, such as tar and cpio are part of the RTS.

There are other packages that are less obvious, such as DOS, which contain programs to access DOS disks; or CSH, which contains the C-shell and it's support files.

Is that all? No, on an ODT or OpenServer system with the SCO Development system installed, there are well over a hundred packages. Many are rarely used. Many contain just a few files and are related to a single entity such as the VI package that contains only vi and it's related files.

Administering over a hundred packages is a big task. To make things a little simpler, the packages themselves are grouped into larger units called Service Components. These components are then grouped into Services. Whereas the separation of files into packages occurs in the files in /etc/perms, the separation of packages into services and service components happens in the files in /etc/perms/bundle.

Except for the entire Operating System or the RTS, each of these services, service components and packages can be removed from or installed on the system. The officially supported way to remove these files is by using the custom utility. It is important to use custom to remove the files in a package, service components or service. If they are removed or installed by hand, inconsistencies can develop making it impossible to add or remove anything without completely corrupting your system.

The newest shipping SCO operating system, OpenServer, has a redesigned product organization. Some of the changes help in cutting down software piracy, while others were implemented to help in remote distribution of software. In this new organization, there is still the basic concept of a "product." This is the unit of software that you buy such as SCO OpenServer and has its own version number.

Each product is broken down into components. This is the largest unit of functionality. TCP/IP cannot be (or rather is not) broken down further for sale. However, it could be sold as a stand-alone product, as it was before. Like products, components have their own version number. Smaller than the component is the package. This is the smallest unit of software that can be installed or removed (not counting single files).

Software Storage Objects- SSO

Under OpenServer, the central concept of the new product structure is the Software Storage Object (SSO). SCO designed the SSO structure based on its concept of software management, which covers installing, updating, removing and administering already installed software packages. The files that make up a product can be separated into those that remain unchanged (such as binaries) and those that do change (such as configuration files). Each represents a particular package and since there is one, unique SSO for each package, you can have copies of different versions of the same software. Which is used is dependent on the configuration and the connection to the SSO is made through the use of what are called symbolic links. (More on those later)

Although divided into products and components like ODT, in OpenServer they take on greater significance in view of the importance of the SSO. It is these components that are the "objects" of the SSO. Because of the design of the SSO architecture, it is even more important that components be more "self-contained" units than in previous releases.

These components are broken down even further, like ODT and previous releases. This is the concept of the package. These packages may contain files or other packages. New to the SSO model is the idea of a parcel. This is used for more complex products, where breaking them into components and packages does not provide enough "granularity." Therefore, a parcel is a unit of the product smaller than the package. However, the distinction of what a parcel is not as clear cut. There is the OpenServer Enterprise product, which contains the Graphics parcel, for example. It is also possible for parcels to cover portions of multiple components. For example, the man-pages and other documentation may be thought of as a parcel.

An SSO is essentially broken down into two parts. There is a part that is shared and other machines have access to it. These are kept under the /opt directory. The other part belongs to one specific client and is not accessed by other machines. These are kept in /var/opt. Here a client is any machine that uses the SSO, including the local machine.

Files within the SSO have several characteristics. A shared file is one that clients can read only. The only copy of a shared file is in the original location within the /opt directory. Why make copies when they aren't going to get changed anyway? As you might guess, non-shared files are ones that can be modified by the client. To keep these separate from the shared files, these files are copied into /var/opt. These files now belong to the client.

Public files are visible and accessible outside of the SSO. These are made available to the rest of the world (users and other SSOs) as links. Almost exclusively, these are symbolic links, which have grown to become one of the primary administrative tools in OpenServer. These links make the real location of the file transparent to the system and applications. Private files are only visible to that SSO.

This provides a very important advantage. Let's first consider files that are not modified by the clients, that is, the shared files. These generally consist of the programs (versus data or configuration files) belonging to a particular package. Every client with a particular version of a package will be using the same programs and utilities. The non-shared files are the data and configuration files. These are the aspects of that package that are applicable only to that particular client. Why should other clients have access or even care what is in these files?

By keeping these two separate, all you need to do when updating a package is to update the program portion and leave the data portion alone. This essentially eliminates problems with updating packages where configuration files would often get overwritten during the update. Since only the program files are getting update, there is less fear of overwriting the data files.



Shared

Non-shared

Private

Reside in /opt. Not linked to an external directory.

Copied to /var/opt on each client. Not linked to an external directory.

Public

Reside in /opt. Linked to an external directory.

Copied to /var/opt on each client and linked to an external directory.

Table 0.1 Relationship of Static Storage Object Properties

This is one reason why things are done with symbolic links. Like a regular link, a symbolic link is just another name for a given file. However, symbolic links do not need to point to anything "real." It is not until the file is accessed that something needs to be there. We can then overwrite the real file, without the symbolic link being effected. In addition, this scheme allows us to backup the data components without having to backup the programs files.

Okay, so we now have an idea of how everything works, now let's take a look at where everything is. To find where the actual files you need to dig deep. To help let's take look at a road map. The program files for a particular component are found in:

/opt/K/VendorCode/ComponentCode/ComponentVersion

The data files are found in:

/var/opt/K/VendorCode/ComponentCode/ComponentVersion

This directory is called a component's SSO root. For example, the SSO root for the SCO Operating System, version 5.0.0d, is /opt/K/SCO/UNIX/5.0.0d.

So, what's with the K and P? Well, the single letters were chosen in order to keep the names as short as possible. Second, P refers to both products and packages. As for the K, well that stands for component. Originally, this was a C, which was often confused with the C programming language. Instead they used K. Urban legend has it that one of the members of the SCO SSO development team is Norwegian and "Komponent" is the Norwegian spelling of "component."

In order to allow different vendors to use the same component name without conflicts, the vendor code defines a unique vendor. In this case, the vendor code is SCO as we are referring to SCO products. The component code is used to uniquely identify a component. The version number is, as one might guess the version of that particular component. By including version numbers in this scheme, it is possible for different versions of the same component to exist.

What SCO UNIX Does

On any operating system there is a core set of tasks that are performed. On mutli-user or server systems such as SCO UNIX these tasks include adding and configuring printers, adding and administering users, and adding new hardware to the system. Each of these tasks could take up an entire chapter in this book. In fact, I do cover all of these, and many others, in a fair bit of detail later on.

However, I think it's important to briefly cover all of the basic tasks that an administrator needs to perform in one place. There are a couple of reasons for this. First, many administrators of SCO UNIX systems are not only novice administrators, they are novice users. They get into the position as they are the only ones in the company or department with computer experience. (They've worked with DOS before) By introducing the varied aspects of system administration here, I hope to lay the foundation for later chapters. I first tell you that a car has a motor, brakes, a steering wheel and a transmission. Then, I tell you how each works.

Second, the average user may not want to get into the details that the later chapters provide. So here, I give an overview of the more important components. Hopefully, this will give you a better understanding of what all goes into an operating system as well as just how complex the job is that your system administrator does.

One of the first things that gets done is that users are added to the system. Access is gained to the system only through user accounts. Although it may be all that a normal user is aware of, these accounts consist of substantially more than just a name and password. Each user must also be assigned one of the shells, a home directory and a set of privileges in order to access system resources.

Although the system administrator could create a single user account for all users to login as, it ends up creating more problems than it solves. Each user has their own password and home directory. If there were a single user, everyone's files would be stored in the same place and everyone would have access to everyone else's data. This may be fine in certain circumstance, but not in most.

Users are normally added to the system through the system administration shell (sysadmsh in ODT ) or the Account Manager portion of scoadmin in OpenServer. Here, when adding a user, you can input that user's default shell, their home directory as well as their access privileges. Should you need to change any of that for a particular user, this is also done through the sysadmsh/SCOAdmin. In addition, they are also used to "retire" or remove a user.

One of the key aspects of a user account on an SCO UNIX system is the concept of privileges. Starting with SCO UNIX 3.2.4.0, there are four levels of security that, among other things, specifies the range of tasks the user is authorized to do. The higher the security level, the less a user can do by default. If the security level does not allow access to a particular function by default and the user must have access, the system administrator has the ability to change this through the sysadmsh or the Account Manager.

Another very common function is the addition and configuration of system printers. This includes determining what physical connection the printer has to the system, what characteristics the printer has (in order to choose the appropriate model printer) as well as making the printer available for printing.

Adding a printer is accomplished in three ways. As you would guess, the first is through the system administration shell. The second is by running the command /usr/lib/sysadm/lpsh or mkdev lp on ODT 3.0 or running the Printer Manager or mkdev lp on OpenServer. Why so many different ways? Well, both lpsh and mkdev lp are the same under ODT 3.0 and mkdev lp and the Printer Manager are the same on Open Server. The program that is called in the end is the same one every time. It is simply to make things easier for administrators who may have come from older systems without the new front-ends.

What happens when you want to remove a file and inadvertently end up removing the wrong one (or maybe all of them)? If you are like me with my first computer, you're in big trouble. The files are gone, never to show their faces again. I learned the hard way about the need to do backups. If you have a good system administrator, he or she either has already learned the lesson and makes regular backups of your system.

There are several ways of making backups and several different utilities for doing them. Which program to use and how often to make backups is completely dependent on the circumstances. The system administrator needs to take into account things like how much data needs to get backed up, how often the data is changed, how much can be lost, and even how much will fit on the backup media.

Using the versioning capabilities of SCO OpenServer, even the hassle of restoring from backups has been eliminated. With versioning turned on, you can undelete files that you have removed as well as automatically save multiple copies (versions) of files.

There are things that an administrator may need to accomplish at regular intervals such as backups, cleaning up temporary directories or calling up remote sites checking for incoming mail. The system administrator could have a check list of these things and a timer that goes off once a day or every hour and he or she could do all these chores by hand.

Fortunately, you don't have to. One of the basic utilities in every UNIX version is cron. Cron (the 'o' is short) is a program that sits in the background and waits for specific times. When these times are reached, it starts pre-defined programs to accomplish various, arbitrarily defined tasks. These tasks can be set to run at intervals ranging from once a minute to once a year, depending on the needs of the system administrator.

Cron 'jobs' (as they are called) are grouped together into files, called cron tables or crontabs, for short. There are several that are created by default on your system and many users and even system administrators can go quite a long time before they notice them. These monitor certain aspects of system activity, clean up temporary files, and even check to see if you have UUCP jobs that need to be sent.

What about a program that you only want to run one time at a specific time and then never again? SCO UNIX provides a mechanism: at. Like cron, at will run a job at a specific time, but once it has completed, the job is never run again.

There is a third command that relates to cron and at. This is the batch command. This differs from the other two in the fact that batch gets around to running the job you submit, whenever it has time. That is when the system load permits.

What goes with SCO UNIX?

Throughout this book, we are going to be talking a great deal about what makes up the SCO UNIX operating system. Up until the newest release it could be purchased as a single product under the name SCO UNIX System V/386 Release 3.2 Operating System Version 4.2. This product contains, the run-time system and the extended utilities (including UUCP, MMDF, LPR, etc).

For many companies or businesses, that's enough. You may have a single computer with several serial terminals attached, running a word processor, database or some other application. However, when a single computer is not enough, the SCO UNIX product does not provide you everything that you need.

Suppose you want to be able to connect all the computers in your company into a computer network. The base SCO UNIX product does provide them with a certain networking capability with UUCP. However, this is limited to exchanging files, remotely executing programs, and simple terminal emulation. However, for the most part, this is limited to serial lines and the speed data can be transferred is also limited.

So it was in dark recesses of ancient computer history. Today, products exist that allow simultaneous connection between multiple machines with substantially higher performance. One such product is SCO's TCP/IP (Transmission Control Protocol/Internet Protocol). So, if a company decides it needs an efficient network it might decide to install TCP/IP, which has become the industry-standard for connecting not only UNIX Systems, but other systems as well.

The SCO TCP/IP Runtime System allows users log into remote systems, transfer files, use printers anywhere on the network, as well as send and receive electronic mail. Plus, the group of protocols that composes TCP/IP serves as the bases for many other programs and products.

There is a problem with TCP/IP that many companies run into. Suppose you want everyone in the company to be able to access a specific set of files. With TCP/IP you could devise a scheme that copies the files from a central machine to the others. However, if the files need to be changed, you need to ensure that the update files are copied back to your source machine. This is not only prone to errors, but it also inefficient.

Instead, why not have a single location where the source files themselves can be edited? That way, changes made to a file are immediately available to everyone. The problem is that TCP/IP by itself has nothing built in to allow you to share files. You need a way to make a directory (or set of directories) on a remote machine appear as if it was local to your machine.

Like many operating system vendors, SCO provides an answer: NFS (Network File System). With NFS, directories or even entire filesystems can appear as if they are local. One central computer can have the files physically on its hard disk and make them available via NFS to the rest of the network.

Soon you discovered the wonders of a graphical user interface (GUI). Maybe at home you use Microsoft Windows or have a Macintosh and are used to being able to point and click or having multiple sessions or terminals on the screen at the same time. SCO provides a solution in the form of X-Windows. This was available separately as the X-Sight product. However, the new OpenServer has X bundled with every version of it.

Since you just switched to SCO UNIX, you still have quite a few DOS applications that you can't live without. Rather than making you junk all of your DOS applications, SCO provides a solution: SCO Merge.

SCO Merge actually runs MS-DOS 5.0 in ODT and 6.2 in OpenServer. Each of these is licensed directly from Microsoft. Merge can support most character-based MS-DOS applications on terminals or the system console, as well as graphical MS-DOS applications on the system console or X11 graphics terminals. Since it behaves like a real MS-DOS machine, SCO Merge provides access to thousands of MS-DOS applications, even many that bypass MS-DOS and access the hardware directly.

The only limitation is that since it is a software emulation, SCO Merge cannot run programs in 386 protected (enhanced) mode. This includes running MS-Windows in enhanced mode. However, this isn't a problem as you can run it under Merge in standard mode just fine. In fact, you can start SCO Merge from within X-Windows and then start MS-Windows. You end up with windows within windows.

Okay, you bought the operating system. Soon you discovered that was not enough, so you got TCP/IP and then NFS. A short time later, you wanted the best of both worlds so you got X-Windows and SCO Merge. Each time you had to lay out several hundred dollars.

After running for a few months, you discovered that SCO offers all of these products together in a package called Open Desktop. You're annoyed that you had to install everything individually, but when you see how much you could have saved by buying everything at once in the form of Open Desktop, you get angry.

Phone calls to your distributor and then to SCO have little effect. You bought separate products, each with their own price so it only makes sense that you pay the price for separate products. Just as power steering costs more when you get it installed after you have the car than it would if it came equipped with it.

You got penalized for not considering all the options when you first purchased your system. That's the nature of the business. That's the nature of any business. If you buy more at once, it usually comes out being cheaper. At least that was the way it was originally.

Well, SCO thought that was wrong. By "forcing" you to buy something you may not need just because you can get it cheaper is great for business, but only for short term business. It looks good on paper, but when your customers never come back because your "hard sell" put them off, you lose in the long run. Instead, SCO came up with a way of allowing you to let your system grow as your needs change, without having you lose any money.

When you purchase the SCO UNIX operating system on tape or CD-ROM, the media already comes with the other products. If you purchase one set of products and later discover you need more, you can easily purchase the missing components for only the difference between the product you have and the product you want. You don't pay for what the products would cost separately.

One company might only need the networking capabilities so there is no need to by X-Windows or SCO Merge. So, SCO created the "Network Bundle" that contains only the network products such as TCP/IP and NFS. Perhaps a user needs a workstation capable of running X-Windows across a network. The solution is ODT Lite, which contains only X-Windows and TCP/IP. If you decide that you need everything including the kitchen sink, there is the SCO Open Server Enterprise System. (Including your choice of Captain Kirk or Picard) With the right kind of trickery you could pull off the components that you want but didn't pay for. However, there are some problems with this. First, it's software piracy. It would be the same as if you copy software from someone else. You are using software that you didn't pay for.

Second, you won't get support for it. SCO can tell what product was purchased and what components that product has. Suppose you bought the Network Bundle and figure out a way to extract the files to make it the Open Server. If you call into SCO Support for help, they will know what is going on.

Lastly, you can't. The serial number and activation key are matched to the product you have. If you purchase the Network Bundle and try to install X-Windows, for example, you can't. The serial number and activation key you have won't work with X-Windows. Also if you try to use that same serial number on a machine that just has the operating system in an effort to get TCP/IP, that won't work either.

SCO's newest product line can be broken down into three separate products. Although the base operating system is the same in each case, the components each has is based on the intended purpose. The Host System product is intended for "turnkey" solutions as well as other situations were networking is not required. An example of this would be a point-of-sales system. Despite the lack of networking, the Host System contains full X-Windows capabilities.

Next is the Desktop System. As its name implies, this system is intended to sit on your desktop and is designed as a single-user workstation. It does contain full networking and graphical support. One added feature of SCO Open Server is their new Desktop filesystem. In this a compressed filesystem that allows up to 1 Terabyte (A Mega-Megabyte) of data!

At the top of the line is the Enterprise System. Due to the recent and long overdue demise of his predecessor, this version of the Enterprise System only comes in the Picard version. (Okay, the joke's getting old) This is a superset of the tools and functionality of the Host System. In addition, it has built-in networking in the form of TCP/IP, NFS, IPX/SPX, Netware Gateway, as well as LAN Manager Client support. The Enterprise System also enables you to do network installs. That means the actual files used for an installation exist on a server on your network and are copied to the machine you are installing on.

A major change since ODT 3.0 is the distribution media. For those of you who still only have a 5.25" floppy, you are out of luck. None of the new SCO products are available on 5.25". In fact, the only one that is available even on 3.5" floppies is the Host System. Although you do get a single 3.5" to boot from, both the Desktop System and the Enterprise System are available only on CD-ROM or 150MB cartridge tape. Earlier releases fit on 60Mb cartridge tape. However, even with compressing things, the operating system no longer fit on the 60Mb tapes.

SCO has also decided to reduce the number of printed manuals that come with the system. Each product will be shipped with both Release Notes and the SCO OpenServer Handbook. However, the remainder of the documentation is shipped on-line. This is all written in the Hypertext Markup Language (HTML). Hypertext is the concept whereby you click on many of the words and phrases, which then jumps you to other parts of the documentation or even other documents.

The basic format of the on-line documentation reader is the same as MOSAIC, which many net surfers are familiar with. This provides not only a history mechanism, but allows you to define "bookmarks" that you can use to immediately jump to places that you access regularly. The only major shortcoming is its searching abilities. Although you can search, as of this writing they are limited to single words, so you need to be careful with what you search for. We'll talk more about the documentation reader in the section on SCO documentation.

If, like me, you find that you cannot live without hardcopy documentation most of the on-line documentation is available in printed format in two sets. The first set contains the Operating System User's Guide and the System Administrator's Guide. The second set contains the man-pages.

Another major change that I find particularly neat is the fact that many add-on products are included on your distribution media. This includes: SCO Symmetrical Multiprocessing (SMP-The successor to MPX), SCO Virtual Disk Manager, SCO Merge, SCO Windows Application Binary Interface (Wabi) and the SCO OpenServer Development System. Some, like SCO Wabi and the SCO Development System, contain additional on-line doc.

At first this seem odd to me. Without even asking for it, let alone paying for it, SCO provides you the software for all sorts of wonderful tools. They will even allow you to install it. However, having it run is a different matter. This is all accomplished by the SCO License Server.

The SCO License Server is a set of programs that runs on you system and "allows" other programs to run. Each system has a license database that allows licensed (purchased) products to run. All the licenses are all contained in a database. When a program starts, it first checks the license server to see if it is licensed. If so, all is well. If the product is not licensed, the system will tell you and won't allow you to run. A single license server can manage multiple machines, thereby allowing licenses to be used where needed and not restricted to single machines.

Each product has a License Number, which is a unique number identifying each SCO product. There is a License Code, which is used to activate the product. The third piece of information provided with your license is your License Data. This is not always present on the Certificate of License and Authenticity and is, therefore, not required in those cases.

One disadvantage I see with the License Server is something that could have been left out. However, the marketing people have a very strong voice in any company the size of SCO. As a result, you are now required to register your product within a predefined grace period. If you don't, you get annoying messages when you login that says the software is unregistered.

As the system boots, you will get a message saying that you have to register and that the reason is to prevent software piracy and keep you informed on updates, etc. Although, you are not actually forced to register, if you don't, "reminders" will continue to appear at system start-up and even after you have logged in. Generically this is referred to as "nag-ware."

When your system is installed, a SCO System ID is generated. This is a unique number, specific to your machine and is used to identify your SCO OpenServer installation. Since it is generated each time your system is installed, a new SCO System ID is generated, if you reinstall your SCO OpenServer system. You can find out your system ID by running the License Manager.

When you register, the Registration Center will issue you a Registration Key for each product. Another very annoying feature is that The Registration Key is tied to the SCO System ID and therefore you must re-register your SCO products if you reinstall your SCO OpenServer system.

Next: Reading all about it — SCO Documentation

Next Chapter: Shells and Basic Utilities

Index

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 http://www.linux-tutorial.info/