This chapter describes how to use the Automated Security Enhancement Tool (ASET) to monitor or restrict access to system files and directories.
This is a list of the step-by-step instructions in this chapter.
The Solaris 9 release includes the Automated Security Enhancement Tool (ASET). ASET helps you monitor and control system security by automatically performing tasks that you would otherwise do manually.
The ASET security package provides automated administration tools that enable you to control and monitor your system's security. You specify a security level—low, medium, or high—at which ASET will run. At each higher level, ASET's file-control functions increase to reduce file access and tighten your system security.
There are seven tasks involved with ASET, each task performs specific checks and adjustments to system files. The ASET tasks tighten file permissions, check the contents of critical system files for security weaknesses, and monitor crucial areas. ASET can also safeguard a network by applying the basic requirements of a firewall system to a system that serves as a gateway system. (See Firewall Setup.)
ASET uses master files for configuration. Master files, reports, and other ASET files are in the /usr/aset directory. These files can be changed to suit the particular requirements of your site.
Each task generates a report that notes detected security weaknesses and any changes the task has made to the system files. When run at the highest security level, ASET will attempt to modify all system security weaknesses. If ASET cannot correct a potential security problem, it reports the existence of the problem.
You can initiate an ASET session by using the /usr/aset command interactively. Or, you can set up ASET to run periodically by putting an entry into the crontab file.
ASET tasks are disk-intensive and can interfere with regular activities. To minimize the impact on system performance, schedule ASET to run when system activity level is lowest, for example, once every 24 or 48 hours at midnight.
ASET can be set to operate at one of three security levels: low, medium, or high. At each higher level, ASET's file-control functions increase to reduce file access and heighten system security. These functions range from monitoring system security without limiting users' file access, to increasingly tightening access permissions until the system is fully secured.
The following table outlines these three levels of security.
ASET does not change the permissions of a file to make it less secure, unless you downgrade the security level or intentionally revert the system to the settings that existed prior to running ASET.
This section discusses what ASET does. You should understand each ASET task (what its objectives are, what operations it performs, and what system components it affects) to interpret and use the reports effectively.
ASET report files contain messages that describe as specifically as possible any problems that were discovered by each ASET task. These messages can help you diagnose and correct these problems. However, successful use of ASET assumes that you possess a general understanding of system administration and system components. If you are a novice administrator, you can refer to other Solaris system administration documentation and related manual pages to prepare yourself for ASET administration.
The taskstat utility identifies the tasks that have been completed and the tasks that are still running. Each completed task produces a report file. For a complete description of the taskstat utility, refer to taskstat(1M).
This task sets the permissions on system files to the security level you designate. This task is run when the system is installed. If you decide later to alter the previously established levels, run this task again. At low security, the permissions are set to values that are appropriate for an open information-sharing environment. At medium security, the permissions are tightened to produce adequate security for most environments. At high security, they are tightened to severely restrict access.
Any modifications that this task makes to system files permissions or parameter settings are reported in the tune.rpt file. For example of the files that ASET consults when it sets permissions, see Tune Files.
This task examines system files and compares each file with a description of that file as it is listed in a master file. The master file is created the first time ASET runs this task. The master file contains the system file settings that are enforced by checklist for the specified security level.
A list of directories whose files are to be checked is defined for each security level. You can use the default list, or you can modify it, specifying different directories for each level.
For each file, the following criteria are checked:
Owner and group
Permission bits
Size and checksum
Number of links
Last modification time
Any discrepancies found are reported in the cklist.rpt file. This file contains the results of comparing system file size, permission, and checksum values to the master file.
This task checks the consistency and integrity of user accounts and groups as they are defined in the passwd and group files. This task checks the local, and NIS or NIS+ password files. NIS+ password file problems are reported but not corrected. This task checks for the following violations:
Duplicate names or IDs
Entries in incorrect format
Accounts without a password
Invalid login directories
The nobody account
Null group password
A plus sign (+) in the /etc/passwd file on an NIS (or NIS+) server
Discrepancies are reported in the usrgrp.rpt file.
During this task, ASET checks various system tables, most of which are in the /etc directory. These files are the following:
/etc/default/login
/etc/hosts.equiv
/etc/inetd.conf
/etc/aliases
/var/adm/utmpx
/.rhosts
/etc/vfstab
/etc/dfs/dfstab
/etc/ftpd/ftpusers
ASET performs various checks and modifications on these files, and reports all problems in the sysconf.rpt file.
This task checks how the PATH and UMASK environment variables are set for root, and other users, in the /.profile, /.login, and /.cshrc files.
The results of checking the environment for security are reported in the env.rpt file.
This task checks the value of the eeprom security parameter to ensure that it is set to the appropriate security level. You can set the eeprom security parameter to none, command, or full.
ASET does not change this setting, but reports its recommendations in the eeprom.rpt file.
This task ensures that the system can be safely used as a network relay. This task protects an internal network from external public networks by setting up a dedicated system as a firewall, which is described in Firewall Systems. The firewall system separates two networks. In this situation, each network approaches the other network as untrusted. The firewall setup task disables the forwarding of Internet Protocol (IP) packets and hides routing information from the external network.
The firewall task runs at all security levels, but takes action only at the highest level. If you want to run ASET at high security, but find that your system does not require firewall protection, you can eliminate the firewall task by editing the asetenv file.
Any changes that are made are reported in the firewall.rpt file.
ASET generates an execution log whether it runs interactively or in the background. By default, ASET generates the log file on standard output. The execution log confirms that ASET ran at the designated time, and also contains any execution error messages. The aset -n command directs the log to be delivered by electronic mail to a designated user. For a complete list of ASET options, refer to the aset(1M) man page.
ASET running at security level low Machine=example; Current time = 0325_08:00 aset: Using /usr/aset as working directory Executing task list... firewall env sysconfig usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: $/usr/aset/util/taskstat aset_dir Where aset_dir is ASET's operating directory, currently=/usr/aset When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt |
The execution log first shows the system and time that ASET was run. Then, the execution log lists each task as it is started.
ASET invokes a background process for each of these tasks, which are described in ASET Tasks. The task is listed in the execution log when it starts. This listing does not indicate that it has been completed. To check the status of the background tasks, use the taskstat command.
All report files that are generated from ASET tasks are stored in subdirectories under the /usr/aset/reports directory. This section describes the structure of the /usr/aset/reports directory, and provides guidelines on managing the report files.
ASET places the report files in subdirectories that are named to reflect the time and date when the reports are generated. This convention enables you to keep an orderly trail of records that document the system status as it varies between ASET executions. You can monitor and compare these reports to determine the soundness of your system's security.
The following figure shows an example of the reports directory structure.
This example shows two report subdirectories.
0124_01:00
0125_01:00
The subdirectory names indicate the date and time that the reports were generated. Each report subdirectory name has the following format:
monthdate_hour:minute
where month, date, hour, and minute are all two-digit numbers. For example, 0125_01:00 represents January 25, at 1 a.m.
Each of the two report subdirectories contains a collection of reports that are generated from one execution of ASET.
The latest directory is a symbolic link that always points to the subdirectory that contains the latest reports. Therefore, to look at the latest reports that ASET has generated, you can go to the /usr/aset/reports/latest directory. There is a report file in this directory for each task that ASET performed during its most recent execution.
Each report file is named after the task that generates it. See the following table for a list of tasks and their reports.
Table 21–1 ASET Tasks and Resulting Reports
Tasks |
Report |
---|---|
System files permissions tuning (tune) |
tune.rpt |
System files checks (cklist) |
cklist.rpt |
User and group checks (usrgrp) |
usrgrp.rpt |
System configuration files check (sysconf) |
sysconf.rpt |
Environment variables check (env) |
env.rpt |
eeprom check (eeprom) |
eeprom.rpt |
Firewall setup (firewall) |
firewall.rpt |
Within each report file, messages are bracketed by a beginning and an ending banner line. Sometimes, a task terminates prematurely; for example, when a component of ASET is accidentally removed or damaged. In such cases, the report file usually contains a message near the end that indicates the reason for the premature termination.
The following is a sample report file, usrgrp.rpt.
*** Begin User and Group Checking *** Checking /etc/passwd ... Warning! Password file, line 10, no passwd :sync::1:1::/:/bin/sync ..end user check; starting group check ... Checking /etc/group... *** End User And group Checking *** |
After you initially run or reconfigure ASET, you should examine the report files closely. Reconfiguration includes modifying the asetenv file or the master files in the masters subdirectory, or changing the security level at which ASET operates.
The reports record any errors that were introduced when you reconfigured ASET. By watching the reports closely, you can react to, and solve, problems as they arise.
After you monitor the report files for a period during which there are no configuration changes or system updates, you might find that the content of the reports begin to stabilize and that it contains little, if any, unexpected information. You can use the diff utility to compare reports.
ASET's master files, tune.high, tune.low, tune.med, and uid_aliases, are located in the /usr/aset/masters directory. ASET uses the master files to define security levels.
The tune.low, tune.med, and tune.high master files define the available ASET security levels. They specify the attributes of system files at each level and are used for comparison and reference purposes.
The uid_aliases file contains a list of multiple user accounts that share the same user ID (UID). Normally, ASET warns about such multiple user accounts because this practice lessens accountability. You can allow for exceptions to this rule by listing the exceptions in the uid_aliases file. ASET does not report entries in the passwd file with duplicate UIDs if these entries are specified in the uid_aliases file.
Avoid having multiple user accounts (password entries) share the same UID. You should consider other methods of achieving your objective. For example, if you intend for several users to share a set of permissions, you could create a group account. The sharing of UIDs should be your last resort, used only when absolutely necessary and when other methods will not accomplish your objectives.
You can use the UID_ALIASES environment variable to specify an alternate aliases file. The default file is /usr/aset/masters/uid_aliases.
The master files that are used by the systems files checks are generated when you first execute ASET, or when you run ASET after you change the security level.
The following environment variables define the files that are checked by this task:
CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH
The environment file, asetenv, contains a list of environment variables that affect ASET tasks. Some of these variables can be changed to modify ASET operation.
This section discusses how ASET is configured and the environment under which it operates.
ASET requires minimum administration and configuration, and in most cases, you can run it with the default values. You can, however, fine-tune some of the parameters that affect the operation and behavior of ASET to maximize its benefit. Before you change the default values, you should understand how ASET works, and how it affects the components of your system.
ASET relies on four configuration files to control the behavior of its tasks:
/usr/aset/asetenv
/usr/aset/masters/tune.low
/usr/aset/masters/tune.med
/usr/aset/masters/tune.high
The /usr/aset/asetenv file has two main sections:
A user-configurable environment variables section
An internal environment variables section
You can alter the user-configurable parameters section. However, the settings in the internal environment variables section are for internal use only and should not be modified.
You can edit the entries in the user-configurable section to do the following:
Choose which tasks to run
Specify the directories for the system files checks task
Schedule ASET execution
Specify a UID aliases file
Extend checks to NIS+ tables
Each task that ASET performs monitors a particular area of system security. In most system environments, all the tasks are necessary to provide balanced security coverage. However, you might decide to eliminate one or more tasks.
For example, the firewall task runs at all security levels, but takes action only at the high security level. You might want to run ASET at the high security level, but you do not require firewall protection.
You can set up ASET to run at the high security level without the firewall feature by editing the TASKS list of environment variables in the asetenv file. By default, the TASKS list contains all of the ASET tasks. To delete a task, remove the task-related environment variable from the file. In this case, you would delete the firewall environment variable from the list. The next time ASET runs, the excluded task will not be performed.
The following example shows the TASKS list with all of the ASET tasks.
TASKS=”env sysconfig usrgrp tune cklist eeprom firewall” |
The system files check checks the attributes of files in selected system directories. You define which directories to check by using these checklist path environment variables.
The CKLISTPATH_LOW variable defines the directories to be checked at the low security level. CKLISTPATH_MED and CKLISTPATH_HIGH environment variables function similarly for the medium and high security levels.
The directory list that is defined by an environment variable at a lower security level should be a subset of the directory list that is defined at the next higher level. For example, all directories that are specified for CKLISTPATH_LOW should be included in CKLISTPATH_MED, and all the directories that are specified for CKLISTPATH_MED should be included in CKLISTPATH_HIGH.
Checks performed on these directories are not recursive. ASET only checks those directories that are explicitly listed in the environment variable. ASET does not check their subdirectories.
You can edit these environment variable definitions to add or delete directories that you want ASET to check. Note that these checklists are useful only for system files that do not normally change from day to day. A user's home directory, for example, is generally too dynamic to be a candidate for a checklist.
When you start ASET, you can start it interactively, or use the -p option to request that the ASET tasks run at a scheduled time. You can run ASET periodically, at a time when system demand is light. For example, ASET consults PERIODIC_SCHEDULE to determine how frequently to execute the ASET tasks, and at what time to run them. For detailed instructions about setting up ASET to run periodically, see How to Run ASET Periodically.
The format of PERIODIC_SCHEDULE follows the format of crontab entries. See crontab(1) for complete information.
The UID_ALIASES variable specifies an aliases file that lists shared UIDs. The default file is /usr/aset/masters/uid_aliases.
The YPCHECK environment variable specifies whether ASET should also check system configuration file tables. YPCHECK is a Boolean variable; you can specify only true or false for it. The default value is false, which disables NIS+ table checking.
To understand how this environment variable works, consider its effect on the passwd file. When set to false, ASET checks the local passwd file. When set to true, the task also checks the NIS+ passwd file for the domain of the system.
Although ASET automatically repairs the local tables, it only reports potential problems in the NIS+ tables. ASET does not change them.
ASET uses the three master tune files, tune.low, tune.med, and tune.high, to ease or tighten access to critical system files. These master files are located in the /usr/aset/masters directory, and they can be modified to suit your environment. For additional information, see Tune Files.
The tune.low file sets permissions to values that are appropriate for default system settings. The tune.med file further restricts these permissions and includes entries that are not present in tune.low. The tune.high file restricts permissions even further.
Modify settings in the tune files by adding or deleting file entries. Setting a permission to a less restrictive value than the current setting has no effect. The ASET tasks do not relax permissions unless you downgrade your system security to a lower level.
When ASET is executed for the first time, it saves and archives the original system files. The aset.restore utility reinstates these files. This utility also deschedules ASET, if it is currently scheduled for periodic execution. The aset.restore command is located in /usr/aset, the ASET operating directory.
Changes that are made to system files are lost when you run the aset.restore command.
You should use the aset.restore command in the following instances:
When you want to remove ASET changes and restore the original system. If you want to deactivate ASET permanently, you can remove it from cron scheduling if the aset command had previously been added to root's crontab. For instructions on how to use cron to remove automatic execution, see How to Stop Running ASET Periodically.
After a brief period of experimenting with ASET, to restore the original system state.
When some major system feature is not working properly, and you suspect that ASET is causing the problem.
Generally, ASET is used in standalone mode, even on a system that is part of a network. As system administrator for your standalone system, you are responsible for the security of your system and for running and managing ASET to protect your system.
You can also use ASET in the NFS distributed environment. As a network administrator, you are responsible for installing, running, and managing various administrative tasks for all your clients. To facilitate ASET management across several client systems, you can make configuration changes that are applied globally to all clients, which eliminates the need for you to log in to each system to repeat the process.
When you are deciding how to set up ASET on your networked systems, you should consider how much you want users to control security on their own systems, and how much you want to centralize responsibility for security control.
A situation might arise where you want to set up more than one network configuration. For example, you might want to set up one configuration for clients that are designated with low security level, another configuration for those clients with medium level, and yet another configuration with high level.
If you need to create a separate ASET network configuration for each security level, you can create three ASET configurations on the server, one configuration for each level. You would export each configuration to the clients with the appropriate security level. Some ASET components that are common to all three configurations could be shared by using links.
Not only can you centralize the ASET components on a server to be accessed by clients with or without superuser privilege, but you can also set up a central directory on a server to collect all reports that are produced by tasks that run on various clients. For instructions on setting up a collection mechanism, see How to Collect ASET Reports on a Server.
Setting up the collection of reports on a server allows you to review reports for all clients from one location. You can use this method whether or not a client has superuser privilege. Alternatively, you can leave the reports directory on the local system when you want users to monitor their own ASET reports.
The following table lists the ASET environment variables and the values that they specify.
Table 21–2 ASET Environment Variables and Their Meanings
Environment Variable |
Value Specified |
---|---|
ASETDIR |
ASET working directory |
ASETSECLEVEL |
Security level |
PERIODIC_SCHEDULE |
Periodic schedule |
TASKS |
Tasks to run |
UID_ALIASES |
Aliases file |
YPCHECK |
Whether to extend checks to NIS maps and NIS+ tables |
CKLISTPATH_LOW |
Directory lists for low security |
CKLISTPATH_MED |
Directory list for medium security |
CKLISTPATH_HIGH |
Directory list for high security |
The environment variables that are listed in the following sections are found in the /usr/aset/asetenv file. The ASETDIR and ASETSECLEVEL variables are optional and can be set only through the shell by using the aset command. The other environment variables can be set by editing the file.
ASETDIR specifies an ASET working directory.
From the C shell, type:
% setenv ASETDIR pathname |
From the Bourne shell or the Korn shell, type:
$ ASETDIR=pathname $ export ASETDIR |
Set pathname to the full path name of the ASET working directory.
The ASETSECLEVEL variable specifies a security level at which ASET tasks are executed.
From the C shell, type:
% setenv ASETSECLEVEL level |
From the Bourne shell or the Korn shell, type:
$ ASETSECLEVEL=level export ASETSECLEVEL |
In these commands, level can be set to one of the following:
low |
Low security level |
med |
Medium security level |
high |
High security level |
The value of PERIODIC_SCHEDULE follows the same format as the crontab file. Specify the variable value as a string of five fields enclosed in double quotation marks, with each field separated by a space:
"minutes hours day-of-month month day-of-week" |
Variable |
Value |
---|---|
minutes hours |
Specifies start time in number of minutes (0–59) after the hour and the hour (0–23) |
day-of-month |
Specifies the day of the month when ASET should be run, with values from 1–31 |
month |
Specifies the month of the year when ASET should be run, with values from 1–12 |
day-of-week |
Specifies the day of the week when ASET should be run, with values from 0–6; Sunday is day 0 |
The following rules apply:
You can specify a list of values, each delimited by a comma, for any field.
You can specify a value as a number, or you can specify it as a range; that is, a pair of numbers that are joined by a hyphen. A range states that the ASET tasks should be executed for every time that is included in the range.
You can specify an asterisk (*) as the value of any field. An asterisk inclusively specifies all possible values of the field.
The default entry for the PERIODIC_SCHEDULE variable causes ASET to execute at 12:00 midnight every day:
PERIODIC_SCHEDULE=”0 0 * * *” |
The TASKS variable lists the tasks that ASET performs. The default is to list all seven tasks:
TASKS=”env sysconfig usrgrp tune cklist eeprom firewall” |
The UID_ALIASES variable specifies an aliases file. If present, ASET consults this file for a list of permitted multiple aliases. The format is UID_ALIASES=pathname, where pathname is the full path name of the aliases file.
The default is as follows:
UID_ALIASES=${ASETDIR}/masters/uid_aliases |
The YPCHECK variable extends the task of checking system tables to include NIS or NIS+ tables. This variable is a Boolean variable, which can be set to either true or false.
The default is false, which confines the checking to local system tables:
YPCHECK=false |
The three checklist path variables list the directories to be checked by the system files checks task. The following definitions of the variables are set by default. They illustrate the relationship between the variables at different levels:
CKLISTPATH_LOW=${ASETDIR}/tasks:${ASETDIR}/util:${ASETDIR}/masters: /etc CKLISTPATH_MED=${CKLISTPATH_LOW}:/usr/bin:/usr/ucb CKLISTPATH_HIGH=${CKLISTPATH_MED}:/usr/lib:/sbin:/usr/sbin:/usr/ucblib |
The values for the checklist path environment variables are similar to those values of the shell path variables, in that they are lists of directory names that are separated by colons. You use an equal sign (=) to connect the variable name to its value.
This section has examples of some ASET files, including the tune files and the aliases file.
ASET maintains three tune files. The following table describes the format of entries in all three tune files.
Table 21–4 Entry Format for Tune Files
Field Name |
Description |
---|---|
pathname |
The full path name of the file |
mode |
A five-digit number that represents the permission setting |
owner |
The owner of the file |
group |
The group owner of the file |
type |
The type of file |
The following rules apply when you edit the tune files:
You can use regular shell wildcard characters, such as an asterisk (*) and a question mark (?), in the path name for multiple references. See sh(1) for more information.
mode represents the least restrictive value. If the current setting is already more restrictive than the specified value, ASET does not loosen the permission settings. For example, if the specified value is 00777, the permission remains unchanged, because 00777 is always less restrictive than whatever the current setting is.
This process is how ASET handles mode setting, unless the security level is being downgraded or you are removing ASET. When you decrease the security level from what it was for the previous execution, or when you want to restore the system files to the state they were in before ASET was first executed, ASET recognizes what you are doing and decreases the protection level.
You must use names for owner and group instead of numeric IDs.
You can use a question mark (?) in place of owner, group, and type to prevent ASET from changing the existing values of these parameters.
type can be symlink (symbolic link), directory, or file (everything else).
Higher security level tune files reset file permissions to be at least as restrictive as they are at lower levels. Also, at higher security levels, additional files are added to the list.
A file can match more than one tune file entry. For example, etc/passwd matches the etc/pass* and /etc/* entries.
Where two entries have different permissions, the file permission is set to the most restrictive value. In the following example, the permission of the /etc/passwd file will be set to 00755, which is the more restrictive of 00755 and 00770.
/etc/pass* 00755 ? ? file /etc/* 00770 ? ? file |
If two entries have different owner or group designations, the last entry takes precedence. In the following example, the owner of /usr/sbin/chroot will be set to root.
/usr/sbin/chroot 00555 bin bin file /usr/sbin/chroot 00555 root bin file |
The aliases file contains a list of aliases that share the same user ID.
Each entry is in this form:
uid=alias1=alias2=alias3=...
uid |
Shared UID. |
aliasn |
User account that share the UID. |
For example, the following entry lists the UID 0 that is being shared by the sysadm and root accounts:
0=root=sysadm
This section describes how to run ASET either interactively or periodically.
Run ASET interactively by using the aset command.
# /usr/aset/aset -l level -d pathname |
level |
Specifies the level of security. Valid values are low, medium, or high. The default setting is low. For detailed information about security levels see ASET Security Levels. |
pathname |
Specifies the working directory for ASET. The default is /usr/aset. |
Verify that ASET is running by viewing the ASET execution log that is displayed on the screen.
The execution log message identifies which tasks are being run.
The following example shows ASET being run at low security with the default working directory.
# /usr/aset/aset -l low ======= ASET Execution Log ======= ASET running at security level low Machine = jupiter; Current time = 0111_09:26 aset: Using /usr/aset as working directory Executing task list ... firewall env sysconf usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: /usr/aset/util/taskstat [aset_dir] where aset_dir is ASET's operating directory,currently=/usr/aset. When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt |
If necessary, set up the time when you want ASET to run periodically.
You should have ASET run when system demand is light. The PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file is used to set up the time for ASET to run periodically. By default, the time is set for every day at midnight.
If you want to set up a different time, edit the PERIODIC_SCHEDULE variable in the /usr/aset/asetenv file. For detailed information about setting the PERIODIC_SCHEDULE variable see PERIODIC_SCHEDULE Environment Variable.
Add an entry to the crontab file by using the aset command.
# /usr/aset/aset -p |
The -p option inserts a line in the crontab file that starts ASET running at the time determined by the PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file.
Display the crontab entry to verify when ASET will run.
# crontab -l root |
Edit the crontab file.
# crontab -e root |
Delete the ASET entry.
Save the changes and exit.
Display the crontab entry to verify that the ASET entry is deleted.
# crontab -l root |
Become superuser.
Set up a directory on the server:
Change to the /usr/aset directory.
mars# cd /usr/aset |
Create a rptdir directory.
mars# mkdir rptdir |
Change to the rptdir directory, and create a client_rpt directory.
This creates a subdirectory (client_rpt) for a client. Repeat this step for each client whose reports you need to collect.
mars# cd rptdir mars# mkdir client_rpt |
The following example shows the creation of the directory all_reports, and the subdirectories pluto_rpt and neptune_rpt.
mars# cd /usr/aset mars# mkdir all_reports mars# cd all_reports mars# mkdir pluto_rpt mars# mkdir neptune_rpt |
Add the client_rpt directories to the /etc/dfs/dfstab file.
The directories should have read and write options.
For example, the following entries in the dfstab file are shared with read and write permissions.
share -F nfs -o rw=pluto /usr/aset/all_reports/pluto_rpt share -F nfs -o rw=neptune /usr/aset/all_reports/neptune_rpt |
Make the resources in the dfstab file available to the clients.
# shareall |
On each client, mount the client subdirectory from the server at the mount point, /usr/aset/masters/reports.
# mount server:/usr/aset/client_rpt /usr/aset/masters/reports |
Edit the /etc/vfstab file to mount the directory automatically at boot time.
The following sample entry in /etc/vfstab on neptune lists the directory to be mounted from mars, /usr/aset/all_reports/neptune_rpt, and the mount point on neptune, /usr/aset/reports. At boot time, the directories that are listed in vfstab are automatically mounted.
mars:/usr/aset/all_reports/neptune.rpt /usr/aset/reports nfs - yes hard |
This section documents the error messages that are generated by ASET.
ASET failed: no mail program found.
ASET is directed to send the execution log to a user, but no mail program can be found.
Solution:Install a mail program.
Usage: aset [-n user[@host]] in /bin/mail or /usr/ucb/mail.
Cannot decide current and previous security levels.
ASET cannot determine what the security levels are for the current and previous invocations.
Solution:Ensure the current security level is set either through the command-line option or the ASETSECLEVEL environment variable. Also, ensure that the last line of ASETDIR/archives/asetseclevel.arch correctly reflects the previous security level. If these values are not set or are incorrect, correct them.
ASET working directory undefined.
To specify, set ASETDIR environment variable or use command line
option -d.
ASET startup unsuccessful.
The ASET working (operating) directory is not defined, or it is defined incorrectly.
Solution:Use the ASETDIR environment variable or the -d command-line option to correct it, and restart ASET.
ASET working directory $ASETDIR missing.
ASET startup unsuccessful.
The ASET working (operating) directory is not defined, or it is defined incorrectly. This problem might be because the ASETDIR variable or the -d command-line option refers to a nonexistent directory.
Solution:Ensure that the correct directory, that is, the directory that contains the ASET directory hierarchy, is referred to correctly.
Cannot expand $ASETDIR to full pathname.
ASET cannot expand the directory name that is given by the ASETDIR variable or the -d command-line option to a full path name.
Solution:Ensure that the directory name is correct, and that it refers to an existing directory to which the user has access.
aset: invalid/undefined security level.
To specify, set ASETSECLEVEL environment variable or use command
line option -l, with argument= low/med/high.
The security level is not defined, or it is defined incorrectly. Only the values low, med, or high are acceptable.
Solution:Use the ASETSECLEVEL variable or the -l command-line option to specify one of the three values.
ASET environment file asetenv not found in $ASETDIR.
ASET startup unsuccessful.
ASET cannot locate an asetenv file in its working directory.
Solution:Ensure there is an asetenv file in ASET's working directory. See asetenv(4) for the details about this file.
filename doesn't exist or is not readable.
The file that is referred to by filename doesn't exist or is not readable. This problem can occur when you are using the -u option, where you can specify a file that contains a list of users whom you want to check.
Solution:Ensure that the argument to the -u option exists and is readable.
ASET task list TASKLIST undefined.
The ASET task list, which should be defined in the asetenv file, is not defined. This message can mean that your asetenv file is bad.
Solution:Examine your asetenv file. Ensure that the task list is defined in the User Configurable section. Also check other parts of the file to ensure that the file is intact. See asetenv(4) for the content of a valid asetenv file.
ASET task list $TASKLIST missing.
ASET startup unsuccessful.
The ASET task list, which should be defined in the asetenv file, is not defined. This message can mean that your asetenv file is bad.
Solution:Examine your asetenv file. Ensure that the task list is defined in the User Configurable section. Also check other parts of the file to ensure that the file is intact. See asetenv(4) for the content of a valid asetenv file.
Schedule undefined for periodic invocation.
No tasks executed or scheduled. Check asetenv file.
ASET scheduling is requested by using the -p option, but the environment variable PERIODIC_SCHEDULE is undefined in the asetenv file.
Solution:Check the User Configurable section of the asetenv file to ensure that the variable is defined and is in proper format.
Warning! Duplicate ASET execution scheduled.
Check crontab file.
ASET is scheduled to run more than once. In other words, ASET scheduling is requested while a schedule is already in effect. This message does not necessarily indicate an error if more than one schedule is indeed desired. In this instance, the messages servers only as a warning. If you want more than one schedule, you should use the proper scheduling format with the crontab command. For more information, see the crontab(1) man page.
Solution:Verify, through the crontab command, that the correct schedule is in effect. Ensure that no unnecessary crontab entries for ASET are in place.