CommandPointTM Admin is a Java®-based graphical user interface (GUI) product that provides administrative capabilities for DYNIX/ptx® systems. A DYNIX/ptx system runs the server portion; you can run the client either on a PC running Windows NT® or on DYNIX/ptx via a PC running eXceed®. Features of CommandPoint Admin include the following:
Easy to learn, easy to use administrative interface.
Java-based graphical front-end that is platform independent. Use it as an X application or a Windows NT application.
Consistent Look & Feel on all platforms.
Easy task navigation.
Learning environment for inexperienced users by means of the following:
View Commands mode that shows the back-end commands that are running.
Dry Run Mode that allows you to specify an action, but not have the action executed on the server.
ATTENTION You can invoke both View Command and Dry Run Mode from CommandPoint Admin's View menu.
Ability to execute multiple tasks concurrently.
Ability to launch CommandPoint Clusters (if ptx/CLUSTERS and CommandPoint Clusters are installed) or CommandPoint SVM (if ptx/SVM and CommandPoint SVM are installed) from the CommandPoint Admin Launcher.
Context sensitive on-line help.
Control over access by user or group to administrative tasks (see the Configuring Tasks and Access section of these release notes).
Ability to access multiple DYNIX/ptx hosts and their system management applications via the CommandPoint Admin Launcher.
Logging of all administrative operations to a common per-system event log (using the Error and Event Subsystem).
CommandPoint Admin supports the following administrative functions:
File and Directory Management
User and Group Management
Job Scheduling
EES (Error and Event Subsystem) Administration
Filesystem Management
System Environment
Application Region Management
Run Queue Management
Process Management
TCP/IP Management
Device Management
Kernel Management
CommandPoint Admin is targeted towards providing the following benefits for new to experienced system administrators:
These Release Notes contain the following information:
Differences from the Previous Version
Compatibility information
Installation instructions
Security
Getting Started instructions, including Navigation Tips
Documentation
Problem reports
Configuring Tasks and Access administration
The following list shows the differences from the previous version of CommandPoint Admin (V4.5.1):
Fixes to known bugs in the V4.5.1 release
Additional tasks for Kernel, File and Directory, Job Scheduling, Device, and TCP/IP
ATTENTION Upgrading from CommandPoint Admin V4.4.0 or V4.5.1 causes existing permissions in the TDF files to be lost. If you are upgrading, you will need to redo the TDF permissions, which are further described in the Configuring Tasks and Access section of these release notes.
CommandPoint Admin V4.6.0 is compatible with the following software products running on NUMA-Q® systems:
DYNIX/ptx V4.6.x or later (required)
CommandPoint Base V4.6.0 or later (required)
ptx/LAN V4.8.0 or later (required)
ptx/TCP/IP V4.7.0 or later (required)
ptx/XWM V4.6.2 or later (required)
ptx/NFS® V4.8.0 or later (optional)
CommandPoint Admin V4.6.0 is compatible with the following software products running on a PC:
Windows NT 4.0 (required)
eXceed V5.1.3.0 or V6.0.1.15 (required if you are running the client on DYNIX/ptx)
ATTENTION Do not use the VCS console on a NUMA-Q system to run CommandPoint Admin.
If you plan to use the Windows NT-compatible client to administer your Sequent® system, then the following minimum requirements apply to the PC that you will be using. (These requirements are in addition to the DYNIX/ptx requirements listed in the previous section.)
ATTENTION The minimum configuration will allow you to run all three CommandPoint products simultaneously. However, the performance will be better if you use the recommended hardware configuration.
Whichever configuration you choose to use, the performance of the system will be impacted by the number and size of the applications that you run simultaneously.
The minimum hardware requirements are:
The recommended hardware requirements are:
400MHz (Pentium III) (or faster) CPU
128 MB Memory
1280x1024 Video
21" Display
CD-ROM drive
Network Interface Card
You can run the CommandPoint Admin client on DYNIX/ptx (using ptx/XWM) or on Windows NT.
Refer to the DYNIX/ptx and Layered Products Software Installation Release Notes for installation procedures. The product to select for installation is: cpadmin.
The DYNIX/ptx installation process installs both the CommandPoint Admin server and the (DYNIX/ptx) client.
As shipped, CommandPoint Admin is pre-configured to allow members of group cpadmin and group cpgroup to run CommandPoint Admin and the other CommandPoint products respectively.
As root, you need to create the group cpadmin (and cpgroup if you are going to run other CommandPoint products) and add your "normal" login (not root's login) to the group(s).
To change the default configuration, refer to the Configuring Tasks and Access section of these release notes.
ATTENTION We recommend that you refer to the Configuring Tasks and Access section of these release notes for more information on TDF configuration prior to starting CommandPoint Admin.
Next, you need to start the CPAServer (CommandPoint Admin server). The CommandPoint Admin server must be started in order for the CommandPoint Admin clients (be they DYNIX/ptx or Windows NT) to be able to administer the DYNIX/ptx system.
To start the CPAServer, as root enter:
/etc/init.d/CPAServer start
ATTENTION CommandPoint Admin requires 6MB of free disk space.
To load the CommandPoint Admin client software on a Windows NT system, load the Systems Management Software CD in your E drive and click on cpadmin\setup.exe.
Follow the standard installation.
During the Windows NT installation of CommandPoint Admin, you will be prompted to respond to a licensing query. In order to install CommandPoint Admin you will need to agree to the terms of the electronic license by clicking on the Yes button which will allow the installation to proceed. (If you answer No, the installation will stop).
Answering Yes allows you to install and use the Windows NT Client component of CommandPoint Admin on one or more workstations which will be used for the purpose of administering NUMA-Q systems. In this regard, the Windows NT Client component is an exception to Paragraph 1.2 of the Software License Agreement for CommandPoint Admin.
To install the CommandPoint Admin client software on Windows NT via ftp, perform the following steps:
ATTENTION You must set the ftp file transfer type to binary to support binary image transfer. Do not use ascii file transfer type.
ftp from the host where CommandPoint Admin is installed the file /opt/commandpoint/cpadmin/CommandPointAdmin.exe to a temporary directory on your system.
Double click on the CommandPointAdmin.exe file in the temporary directory; the installation wizard will complete the installation.
In order for CommandPoint Admin to run as an applet, you need to install a web server on the DYINX/ptx host system. The following steps will guide you in setting up the web server so that it serves the CommandPoint Admin applet html page.
Install the web server on the host system.
2. In the "root directory" of the web server, create a symbolic link named cpadmin to the following: /opt/commandpoint/cpadmin.
(For Example: The "root" directory for the Apache Web Server is located at /usr/local/apache/htdocs.) This will allow users to type the following in their respective browsers to start the CP Admin applet:
http://hostname/cpadmin
The following steps show you how to configure the Java Plug-in software to allow the CommandPoint Admin applet full access on your local system. These steps will allow the CommandPoint Admin applet originating from the host system to access resources on your local system.
If you have already installed the Java Plugin on your machine, then skip the Installing the Plugin section below, and jump to the Configuring the Plugin section. If, however, you do not have the plugin installed (or are not sure whether it is installed), then perform the steps in Installing the Plugin section first, and then the Configuring the Plugin steps.
Once you are done with these steps, you can find CP Admin at:
http://hostname/cpadmin
ATTENTION You need to perform these installation steps once for each client.
To begin with, start your browser and point it to:
http://hostname/cpadmin.
Click the appropriate button on the resulting CommandPointAdmin page that appears in your browser. This will start the CommandPoint Admin Applet. If you do not have the Java Plugin installed on your client, then you will be offered a chance to download and install it from an external web site. Proceed with this step. It will automatically download and install the appropriate plugin on your client machine.
ATTENTION You need to perform these installation steps for all hosts that are to be managed.
After installing Java Plug-in, run the PolicyTool.exe application present in the bin directory under the Java Plug-in installation directory. For Example, if the Java Plug-in software is installed in C:\Program Files\JavaSoft directory, then the PolicyTool.exe can be found in C:\Program Files\JavaSoft\JRE\1.2\bin directory
When the PolicyTool is invoked for the first time, it complains of a missing file. Note down the name of the file, and click OK to continue.
Click on the Add Policy Entry button. This will bring up a Policy Entry dialog.
In the CodeBase: field, enter:
http://hostname/cpadmin/jars/*
In the above step, host_name refers to the host against which you want to run the CommandPoint Admin in applet mode.
Click on the Add Permission button, which will bring up the Permissions dialog.
Click on the Permission: drop down list, and select All Permission from the list. Click on the OK button to dismiss the dialog.
Click on the Done button to dismiss the Policy Entry dialog.
Select Save As from the File menu in the Policy Tool main dialog. In the File Name field of the Save As dialog, enter the name you noted down in step 2 above.
You may now close the Policy Tool dialog by clicking Exit under the File menu.
CommandPoint Admin uses the following authentication mechanisms:
The client user must have an account on the server DYNIX/ptx machine.
The user name and password are authenticated on the server prior to allowing access on the client. (If a valid user name is entered with an invalid password, after 3 tries the user will be locked out for 1 hour.)
Both the UNIX crypt algorithm and the DES encryption algorithm are used.
During authentication, the clear-text password is not sent over the network.
Only root can make changes to the TDF tree located in /opt/commandpoint/cpadmin/tdf as described in the Configuring Tasks and Access section. (Entries in the TDF tree allow or deny access to tasks in CommandPoint Admin. Once a user is authenticated, only tasks that he or she is allowed access to, as defined by the TDF tree, will be visible to that user. Tasks that he or she does not have permission to access will not be displayed.)
Direct root login is not allowed in order to preserve traceability (other than for Configuring Tasks and Access where root login is allowed).
ATTENTION In the Configuring Tasks and Access section of these release notes, we recommend that you not grant open access to all in the TDF tree, as this could be an administrative problem. Rather, carefully consider who or what group(s) you want to perform various CommandPoint tasks.
Once you have installed the software, you can start CommandPoint Admin. The following sections describe how to start CommandPoint Admin for both Windows NT and DYNIX/ptx users.
To start the CommandPoint Admin client click on the Start-->Programs-->CommandPoint-->CommandPoint Admin Launcher shortcut. (This path assumes that you have use the default value provided in the Select Program Folder dialog during installation.)
ATTENTION Before starting the client, you must correctly set your DISPLAY environment variable.
To start the client on DYNIX/ptx enter:
/usr/bin/cpadmin
The CommandPoint Admin online help contains "helpful hints" on the following user-interface topics:
Navigating: What appears in the two-pane window
Sorting: How to click on a column header
Selecting: How to use single-click (used everywhere except folder icons)
Dialog buttons: What are the differences between OK, Apply, Update, and so on
Status indicators: How task status is available on the task tabs
Refer to the online help for more information on these topics.
ATTENTION CommandPoint Admin was developed using the Sun® Swing and JDK (Java Development Kit) tools. Navigation and other interaction may be different from what you are used to with Windows® applications. We encourage you to refer to the CP Admin Main Window Interface topic in the online help. (To see the "helpful hints" online help, select Help-->CP Admin Help Topics from the CommandPoint Admin menu; then click on CommandPoint Admin Main Window Interface.)
The following tips should also be noted:
Press the TAB key to cycle through fields to reach a desired button. In some dialogs you need to press Enter to initiate the button action; in others you can click on the OK button.
When you click on OK, task success is indicated by the task tab disappearing with no error or warning. The tab will remain if there are any problems.
Once the client software is running, you will see the CommandPoint Launcher window. Click on File-->Add a New Host. Enter a Host Name or host IP address, Login, and Password. Click OK. Next you will see the Connecting to Server window. This window reports the status of the connection: Verifying server version, Authenticating, Registering with the server. You can click on the Cancel button in case you are trying to connect to a hung or slow server.
If the connection to the server fails, you will see an error message as the CommandPoint Admin Launcher cannot work with older versions of the CommandPoint Admin Server. If you try to connect to a host which is running an incompatible version of the CommandPoint Admin server, the CommandPoint Admin Launcher will display an error dialog and will not connect to the host. In order to run CommandPoint Admin on the host which is running the incompatible version of CommandPoint Admin server, you should run an instance of CommandPoint Admin Launcher which is compatible with the server. The following options apply:
If you are running the PC client, you can always run the client on the UNIX system you are trying to administer, as an X application (if you have eXceed installed on your PC).
If you are running the X version already, then you can just run the client off of the "incompatible" system.
Once the connection is complete, you will see the host name in the left pane of the CommandPoint Launcher window and the CommandPoint Admin icon in the right pane.
ATTENTION Only the applications (CommandPoint Admin, CommandPoint SVM, or CommandPoint Clusters) or tasks (Add a User, Mount a Filesystem and so on) to which a user has access (as defined by the TDF) will appear in the right pane.
Double click on the CommandPoint Admin icon. The following Management Tasks will appear (as defined by the TDF tree on the server) in the left pane:
Error and Event
Filesystem
Process
Application Region Manager
Run Queue
User and Group
File and Directory Management
Job Scheduling
System Environment
TCP/IP Management
Device Management
Kernel Management
These options contain the following functionality:
File and Directory: Display Sizes, Find, Copy, Create, Modify Attributes, Move, Rename, Delete
Job Scheduling
Error and Event
Filesystem
System Environment: Modify System Node Name, Broadcast Message, Display Admin Accounts, Modify Admin Account, Modify Passwd Hashing, Display System Environment, Modify System Date/Time
Process: Display, Display with filter, Send Signal, Reassign Region, Reassign Run Queue, Modify Priority, Display Current Logins
Application Region Manager: Activate, Create, Create I/O Optimized RegionDeactivate, Delete, Display, Modify, Display Statistics, Validate Region Registry File
Display Active Interfaces: Add, Modify, Delete
Display IP Addresses: Add, Modify, Delete
Display Routing Configuration: Add, Delete
Display Configuration Files
Display Configuration Delta
Validate Configuration File
Display Route Table
Display Trace Route
Display Enpoint Table
Ping Network Host
Display Network Memory Statistics
Display Protocol Statistics
Display Routing Statistics
Device
Kernel: Display Memory Pool Info, Configuration
Run Queue: Add, Delete, Display, Modify
User and Group
To expand the task tree in the left pane of CommandPoint Admin to see User and Group tasks, for example, double click on User and Group.
To see the Group tasks, double click on Group Accounts.
To start a task (such as Display Groups), double click on the task.
The task tree can also be expanded by single clicking on the dots next to each application in the left pane.
If you want to add additional hosts, return to the Command Point Admin Launcher window.
To reconnect to a previously connected host, select Log On from the File menu of the CommandPoint Admin Launcher and click on CommandPoint Admin to start again.
ATTENTION Hosts that are added will be present each time CommandPoint Admin Launcher is started.
To delete a host, go to the CommandPoint Admin Launcher window, click on the host name, and select File-->Remove Selected Host.
You can run CommandPoint Clusters and CommandPoint SVM as either stand-alone Windows NT applications or from the CommandPoint Admin Launcher. If CommandPoint Clusters and CommandPoint SVM Windows NT clients are not installed, then they will start via eXceed as X applications using CommandPoint Admin Launcher.
If you want to launch CommandPoint Clusters or CommandPoint SVM from CommandPoint Admin, you need to allow access for yourself to the Clusters or SVM portion of the TDF tree or you will not see those applications when you run CommandPoint Admin. Refer to the Configuring Tasks and Access Administration for CommandPoint Clusters or CommandPoint SVM section for instructions on how to make changes for the Clusters or SVM portions of the TDF tree. (Refer to the Configuring Tasks and Access section for more information about TDF in general.)
If you install CommandPoint Clusters or CommandPoint SVM after CommandPoint Admin is installed, you will need to restart the CPAServer (/etc/init.d/CPAServer restart) or run the /opt/commandpoint/cpadmin/tdfcli/updateTDF command-line utility so that Launcher sees the new applications (assuming that you have granted yourself access to the TDF tree).
If CommandPoint Admin is installed after CommandPoint Clusters or CommandPoint SVM, then these applications will show up automatically in Launcher when the CPAServer is started (/etc/init.d/CPAServer start).
When CommandPoint Clusters or CommandPoint SVM is installed, a single TDF file is placed in the /opt/commandpoint/cpadmin/tdf directory; a cpclusters2_3_0.tdf file or a cpsvm2_3.tdf file respectively. As described in the Configuring Tasks and Access section, this file contains the task name (Cluster Administration or Volume Management), product name, and a list of who can and cannot perform the task. For CommandPoint Admin, you can allow or deny access to specific tasks within the TDF tree. However, for CommandPoint Clusters or CommandPoint SVM, you can only allow or deny access to the top level of the tree, meaning a user or group can either access or not access CommandPoint Clusters or CommandPoint SVM.
The following examples show how to configure the TDF tree for granting access to CommandPoint Clusters or CommandPoint SVM using both the graphical user interface and the commandline.
To allow access to CommandPoint Clusters for herself, an administrator named Evie would do the following:
Graphical User Interface:
Verify that user Evie already exists.
From CommandPoint Admin Launcher, select Tools--> Configure Tasks and Access.
Click on Cluster Administration in the left pane. The right pane should show Access for Cluster Administration.
Select Tools-->Add User.
Enter the user name Evie.
Click on OK.
Click on the Allowed box to grant access to Evie. (A check in the box means that access is allowed; an empty box means that access is not allowed.)
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for Evie is not shown, click on Change User/Group and enter Evie. All tasks for which Evie has access will have an icon next to the task name, with a green checkmark in it. (If she was denied access to a task(s), the icon next to the task(s) would have a red circle with a white X in it.)
Click on Close.
Select File -->Save and Update Server.
Commandline:
To allow access to CommandPoint Clusters for herself, an administrator named Evie would enter (as root):
# cd /opt/commandpoint/cpadmin/tdf
# ../tdfcli/add_acl -a -u evie cpclusters2_3_0.tdf
# ../tdfcli/updateTDF
This command would append Evie's name to the cpclusters2_3_0.tdf file and would instruct the server to read the TDF tree.
To allow access to CommandPoint SVM for herself, Evie would do the following:
Graphical User Interface:
Verify that user Evie already exists.
From CommandPoint Admin Launcher, select Tools--> Configure Tasks and Access.
Click on Volume Management in the left pane. The right pane should show Access for Volume Management.
Select Tools-->Add User.
Enter the user name Evie.
Click on OK.
Click on the Allowed box to grant access to Evie. (A check in the box means that access is allowed; an empty box means that access is not allowed.)
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for Evie is not shown, click on Change User/Group and enter Evie. All tasks for which Evie has access will have an icon next to the task name, with a green checkmark in it. (If she was denied access to a task(s), the icon next to the task(s) would have a red circle with a white X in it.)
Click on Close.
Select File -->Save and Update Server.
Commandline:
To allow access to CommandPoint SVM for herself, Evie would enter (as root):
# cd /opt/commandpoint/cpadmin/tdf
# ../tdfcli/add_acl -a -u evie cpsvm2_3.tdf
# ../tdfcli/updateTDF
This command would append Evie's name to the cpsvm2_3.tdf file and would instruct the server to read the TDF tree.
To allow access to CommandPoint Clusters to a group named clustadmin, Evie would enter (as root):
Graphical User Interface:
Verify that group clustadmin already exists.
From CommandPoint Admin Launcher, select Tools--> Configure Tasks and Access.
Click on Cluster Administration in the left pane. The right pane should show Access for Cluster Administration.
Select Tools-->Add Group.
Enter the group name clustadmin.
Click on OK.
Click on the Allowed box to grant access to clustadmin. (A check in the box means that access is allowed; an empty box means that access is not allowed.)
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for clustadmin is not shown, click on Change User/Group and enter clustadmin. All tasks for which group clustadmin has access will have an icon next to the task name, with a green checkmark in it. (If clustadmin was denied access to a task(s), the icon next to the task(s) would have a red circle with a white X in it.)
Click on Close.
Select File -->Save and Update Server.
Commandline:
To allow access to CommandPoint Clusters to a group named clustadmin, Evie would enter (as root):
# cd /opt/commandpoint/cpadmin/tdf
# ../tdfcli/add_acl -a -g clustadmin cpclusters2_3_0.tdf
# ../tdfcli/updateTDF
This command would append the clustadmin group name to the cpclusters2_3_0.tdf file and would instruct the server to read the TDF tree.
To allow access to CommandPoint SVM to a group named svmadmin, Evie would do the following:
Verify that group svmadmin already exists.
From CommandPoint Admin Launcher, select Tools--> Configure Tasks and Access.
Click on Volume Management in the left pane. The right pane should show Access for Volume Management.
Select Tools-->Add Group.
Enter the group name svmadmin.
Click on OK.
Click on the Allowed box to grant access to svmadmin. (A check in the box means that access is allowed; an empty box means that access is not allowed.)
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for svmadmin is not shown, click on Change User/Group and enter svmadmin. All tasks for which group svmadmin has access will have an icon next to the task name, with a green checkmark in it. (If svmadmin was denied access to a task(s), the icon next to the task(s) would have a red circle with a white X in it.)
Click on Close.
Select File -->Save and Update Server.
Commandline:
To allow access to CommandPoint SVM to a group named svmadmin, Evie would enter (as root):
# cd /opt/commandpoint/cpadmin/tdf
# ../tdfcli/add_acl -a -g svmadmin cpsvm2_3.tdf
# ../tdfcli/updateTDF
This command would append the svmadmin group name to the cpsvm2_3.tdf file and would instruct the server to read the TDF tree.
The CommandPoint Admin documentation consists of these release notes and the online help.
This section contains a list of problems fixed since the previous release.
The following options are incompatible when mounting an EFS filesystem read-only: log, delaylog, tmplog, nolog, mincache, convosync, blkclear, datainlog, and nodatainlog. The mount command will fail if one of these options is selected.
Adding an EES filter from a file always returns success even if the file is a directory name or a badly formatted file.
The Add User Account task does not append the user login name to the home directory listed in the Home Directory field of the Add User Account form. However, the user's account is created.
The text-field portion of numeric spinners in CommandPoint Admin will not allow the use of backspace key to clear the field so that a new value can be typed. When the backspace erases the last remaining digit in the field, that digit is restored automatically.
Several tasks of the Filesystem applet sometimes display //SWAPVOL as a choice in Browse dialogs tables or lists. This may occur in Check Filesystem, Mount Filesystem, or other Filesystem management tasks. SWAPVOL should not appear in these tables or lists since operations are not supported for this path.
The Help button inside of the Error message dialogs doesn't work.
The Task Tool Tips are missing for Filesystem-->Operations-->Umount FS and Process-->Reassign Run Queue.
The application region subsystem includes a "borrow" memory policy that allows you to specify the minimum and maximum amounts of memory for a region. The minimum amount is guaranteed to be available to the region. Additional memory up to the maximum is borrowed from the free pool maintained by the system. Because of a scheduling problem in the DYNIX/ptx V4.5 implementation, the additional memory cannot be borrowed, restricting a region's memory usage to the minimum level specified.
If the user puts commas between PIDs (instead of the expected spaces), the error message from rqadmin -assign says "Invalid run queue ID"; the message should say "Invalid PID."
In the Set Account Defaults dialog, the passwd defaults are incorrectly set if you choose "Never expires."
Modify Run Queue may display incorrect information about options.
The Device Browse dialog (addfstab), displays /dev/vx/dsk/ROOTVOL as a valid device to add to /etc/vfstab; this will cause a problem at reboot time.
Regions do not currently support memory sharing. Although CommandPoint Admin allows you to specify a "borrow" policy for memory when adding or modifying a region, the command will fail and return an error if you attempt to set the policy to "borrow."
The Display Filesystem tasks for Unmount displays the wrong mount directory if it is an NFS filesystem.
The UNIX cpadmin client may display an "Exception..." error message after exiting.
The number that appears in parentheses in problem report titles is the Sequent Problem Tracking System number assigned to the report. These problems will be corrected in a future release unless otherwise noted.
A defect in Java generates a fatal error and prevents CommandPoint Admin from running when it is started on Microsoft Windows NT 4.0 Terminal Server Edition. The problem is documented in the Sun Microsystems Java Bug Database under Bug ID 4193603. The problem is caused by a flaw in the way Java accesses font information in the Terminal Server environment.
Workaround: Edit the batch file that starts CommandPoint Clusters and insert text to define the location of the fonts on the NT system, as follows:
Using the Windows NT Explorer, find the file named CPAdmin.bat (if CommandPoint Admin was installed in the default installation location, the files should be located in C:\Program Files\CommandPoint\CPAdmin\CPAdmin.bat).
Using the "Properties" option, deselect the "Read-only" option, and then apply the change.
Edit the file CPAdmin.bat and insert the following line near the middle of the file:
"SET JAVA_FONTS=C:\wtsrv\fonts"
Set the drive letter as appropriate for your system and verify the location of the wtsrv\fonts directory.
Save the changes to the file.
When running the CommandPoint Admin client via eXceed, some text may not be visible. This may be a problem with the display of certain fonts and is seen only when the Windows NT "Color Palette" is set to greater than 256 colors.
Workaround: Go to the Control Panel ("Start-->Settings-->Control Panel). Double click on the "Display" icon; in the "Display Properties" dialog, select the "Settings" tab, and set the color palette to use 256 colors. Click "Ok" or "Apply".
The "Delete Cron Job" and the "Remove Cron Permissions" tasks remove the file that contains the cron commands, but the cron daemon does not flush the jobs from its memory cache.
Workaround: Restart cron.
The I/O Optimized Region Set Memory Policy may return the following error message if the task fails:
No space left on device.
Workaround: The message means that there was not enough memory available to activate the region. To workaround the problem, try the following: 1) Open the CommandPoint Admin Modify Region task. Use Browse to select the region name. 2) Click Next. 3) Click Next again. 4) Look at the value in the Minimum memory field. It should be in a format such as 1:600. In this example, the 600 means that 600 MB of memory will be used by the region. Edit the value to make it smaller by 5%. For example, 1:570 means use 570 MB of memory instead of 600 MB of memory. 5) Click Apply and verify that the region was modified correctly. 6) Open the CommandPoint Admin Activate Region task. Use Browse to select the region name. 7) Click Apply. If the Activate region completes successfully, then the workaround is complete. If you see the "No space left on device" message, then repeat this workaround to further reduce the Minimum memory value.
In the User and Group >> Group Account >> Modify Group task, you cannot delete nonexistant memebrs from groups.
Workaround: None.
The OK, Apply, and Close buttons are accessible while the kernel compilation task is running; they should not be accessible.
Workaround: Do not press the OK, Apply, or Close button while the kernel compilation task is running. If you press any of those buttons, kernel compilation will not successfully complete.
The Copy (Ctrl + C) option in View Commands does not work on the DYNIX/ptx client.
Workaround. None.
If, for example, you enter an invalid host in the Mount NFS dialog and click on Browse for the Device, the background command /etc/showmount will fail, but an empty Browse dialog will still be displayed.
Workaround. None.
You can enter a valid login, in the Delete Members field, that does not belong to the selected group. The command will complete successfully.
Workaround. Refer to the Modify Group online help for further information.
If you have password aging enabled and your password expires, you will not be able to log in to CommandPoint Admin. The error message, however, does not say that your password has expired.
Workaround. Manually log on to the host and change your password.
The Add New Filesystem-->Display Browse dialog in Add New Filesystem lists all possible devices, with the exception of devices used for swap, SVM subdisks, and mounted filesystems. These devices are excluded because the operations would fail if they were used. However, this does not mean that all of the other devices can be used safely. For example, you would not want to create a new filesystem over a raw partition that contains a database. It is not possible to exclude all these cases from the dialog list so it is important to verify the device's state before adding a new filesystem.
Workaround. None. The online help for this dialog includes this same bug text. (This bug is related to 243168.)
The External Log Devices Browse dialog in EFS Mount Options lists all possible devices, with the exception of devices used for swap, SVM subdisks, and mounted filesystems. These devices are excluded because the operations would fail if they were used. However, this does not mean that all of the other devices can be used safely. For example, you would not want to create a new filesystem over a raw partition that contains a database. It is not possible to exclude all these cases from the dialog list so it is important to verify the device's state before adding a new filesystem.
Workaround. None. The online help for this dialog includes this same bug text. (This bug is related to 243185.)
If there are two entries for the same mount points on different devices and you choose to remove one of them, delfstab should provide a warning.
Workaround. Press Update (to update the table) and then press Apply.
The list of users in the Display Group form contains only the users specified in the /etc/group file for the selected group. It does not show the logins of users for whom the selected group is the primary group.
Workaround. None.
Typing or using browse dialogs to enter a long list (over 1024 characters) in a text field on any of the CommandPoint Admin forms may result in failure of the command on the server due to a limitation on the maximum number of characters on a command line. The error message will not specifically indicate that the failure was caused by too many characters on the command line.
Workaround. Limit the number of characters of input in text fields to less than 1024 characters.
CommandPoint Admin does not run properly on audited systems. It cannot be started via drestart, therefore the setup of the vector privileges fails.
Workaround. None.
If the CFS Filesystem is mounted without going into the CFS Specific Options dialog and entering a log device, you will get an error message.
Workaround. Enter a log device in the CFS Specific Options dialog.
The Filesystem Check dialog does not allow fsck options.
Workaround. Manually run fsck options.
A user could log into a node and not see a CommandPoint Admin icon in Launcher's right pane. This is a tdf (task description file) permission problem.
Workaround. Refer to the Configuring Tasks and Access section of these release notes or to the tdfcli(1) man page for details on the usage of the tdf command line utilities.
Group Add does not support the -o option. This option on the UNIX command line allows creation of a new group using a group ID that is already used in an existing group.
Workaround. Use the UNIX command line.
Sorting of lists or columns in tables which contain date entries are not sorted in correct date/time order.
Workaround. None.
CommandPoint Admin's Launcher comes up blank when invoked on a Sun SPARC station (this was observed on a Sun NetraTM and an Ultra SPARC 2).
Workaround. Resize the Launcher window.
The Validate Passwd File and Validate Group File dialogs report inconsistencies in the /etc/passwd and /etc/group files, when in fact there are no errors.
Workaround. The errors are generated by the /etc/pwck and the /etc/grpchk commands. As noted in the /etc/pwck man page, the error occurs because some entries (such as checkfsys) are longer that 8 characters. As noted in the /etc/grpchk man page, the operating system includes a group called other that contains no users. Both of these events cause an error to be generated that can be ignored.
During Display Regions, with one of the regions selected in the table, clicking the 'tasks' button on the Display Regions dialog exposes a list of tasks that can be performed on the selected task. If the selected region is inactive, the 'tasks' menu includes a "Deactivate" choice -- (this choice should be disabled for inactive regions). If the Deactivate choice is clicked, a Deactivate Region task will be initiated in a new tab in CommandPoint Admin, and the name of the inactive region will be shown in the Deactivate Region text field. If Apply or OK is then clicked, the command will fail and an error message will be displayed.
Workaround. Ignore the Deactivate choice on the 'tasks' menu on the Display Regions dialog.
There are two closely related problems: 1) A region created with no user-specified memory resources can't be modified to user-specified memory resources while the region is active. This is normal behavior. The bug is that the RegionModify3 form should not allow the user to attempt to change to user-specified resources. 2) A region created with user-specified memory resources can't be set back to 'no user specified memory resources'.
Workaround. None.
CPAdmin Region Create and Region Modify tasks report "out of memory" errors. (This occurs on Windows NT workstations.)
Workaround. If out of memory errors become frequent, close CommandPoint Admin and restart it. Also close other applications on the Windows NT workstation.
Task Description Files (TDFs) are text files that represent an on-disk database of tasks that can be performed with CommandPoint Admin. TDFs contain information such as the name of the task and who can and cannot perform the task. The tasks that appear in the CommandPoint Admin Launcher are created by the system reading the TDF tree; there is one file in the TDF tree for each task you see in the CommandPoint Admin Launcher. The primary area you need to make changes to in the TDF tree is the access control information, which controls which users or groups can access various CommandPoint Admin tasks. You decide which users or groups can access the various tasks.
As described in the Installation section, CommandPoint Admin is pre-configured to allow members of group cpadmin and group cpgroup to run CommandPoint Admin and the other CommandPoint products. As root, you should have already created the group cpadmin (and cpgroup if you are going to run other CommandPoint products) and added yourself to the group(s). Next, you need to decide which users or group can have access to the CommandPoint Admin tasks.
This section describes how to configure the TDF tree for granting access to users and groups using both the graphical user interface and the commandline. There are also examples that show you how to add or deny access for other users or groups to tasks listed in the TDF tree.
CommandPoint Admin's TDF tree provides the following features:
Very granular control over who is given access to which tasks. As shipped, no one (except the groups cpadmin and cpgroup) has access to CommandPoint Admin's administrative tasks until they (or their group) are given access to tasks in the TDF tree.
Ability to configure access in a large variety of ways in order to meet the needs of different operating environments.
Ability to tailor CommandPoint Admin to your site's administrative policies.
Ability to control on either a user-by-user basis or a group-by-group basis, or a mix of both.
TDF administration can be administered by means of a graphical user interface that is part of CommandPoint Admin. This interface is called Configure Tasks and Access and can be accessed from Launcher's Tools menu.
In Configure Tasks and Access, you will see a folder name for each group of tasks (such as Error and Event) and a file for each CommandPoint Admin task, such as Copy Events. If you have installed CommandPoint Clusters or CommandPoint SVM, you will also see a task group for each of them listed.
To add access for a user to the Error and Event Add Filter task, for example, you would do the following:
Click on Add Filter.
Click on Add User.
Enter the user's login name. You can use the Browse button if you don't remember the user's login name.
Click on OK.
From the File menu, select Save and Update Server.
More examples are available later in this section.
Details on the menu options of Configure Tasks and Access are available in the online help.
TDF administration can be administered by means of a command-line interface.
In each branch of the TDF tree, there is a _name.tdf file, where name corresponds to a branch of CommandPoint Admin such as: Filesystem, EES, or UserGroup. Also contained in each directory are files that describe each task you see in CommandPoint Admin for that administrative function.
For example, in the /opt/commandpoint/cpadmin/tdf/CPAdmin/UserGroup/Group directory, you will see a _Group.tdf file and files for tasks such as groupadd.tdf or groupmodify.tdf (tasks to add a group and modify a group respectively). When you add an entry to a tdf file, the user name or group name is appended to the file.
TDFs have a hierarchy structure; allowing access to the top file (tdf/_tdf.tdf) automatically grants access to all sub-tasks in the TDF tree. This means that in order to give, for example, access at the lowest level of the tree, you need access at each level above it. For example, to have access to the Add User task, you need access in following files:
tdf/_tdf.tdf
tdf/CPAdmin/_CPAdmin.tdf
tdf/CPAdmin/UserGroup/_UserGroup.tdf
tdf/CPAdmin/UserGroup/User/add.tdf
Refer to Configuring Tasks and Access Examples for more examples.
The TDF files are located in /opt/commandpoint/cpadmin/tdf. The command-line utilities are in /opt/commandpoint/cpadmin/tdfcli and their output should be written to the /opt/commandpoint/cpadmin/tdf directory tree.
In order to set up the TDF permissions and see tasks in CommandPoint Admin, you need to do the following:
Become root on the server system.
Grant access to the TDF directory for yourself (as described in the Installation section of these release notes).
Decide which user or group should have access to each task.
ATTENTION We recommend that you not grant open access to all in the TDF tree, as this could be an administrative problem. Rather, carefully consider who or what group you want to allow access to perform various CommandPoint Admin tasks.
Add or deny access in the TDF tree to users or groups for each task. Examples are provided later in this section.
The command you will use most is add_acl. You will most likely not need to use other TDF commands.
The add_acl script adds an entry to the access control list for a specified TDF. This entry either allows or denies access to a particular task. The name refers to the user or group account names on the server. The user may enter multiple user and/or group names per command. The file refers to the TDF file that gets modified.
Refer to the tdfcli(1) man page for more information on all the TDF commands.
After making any changes to the TDF tree using add_acl or other TDF commands, you should update the CPAServer (if it is already running); if the CPAServer is not running, start it. Changes you make to the TDF tree do not become effective until the server re-reads the TDF tree. To instruct the server to read the TDF tree, enter the following command which dynamically updates the server:
#/opt/commandpoint/cpadmin/tdfcli/updateTDF
If you need to start the CPAServer, enter the following:
#/etc/init.d/CPAServer start
If you need to stop the CPAServer, enter the following:
#/etc/init.d/CPAServer stop
If you need to restart the CPAServer, enter the following:
#/etc/init.d/CPAServer restart
(This command stops the CPAServer, then restarts it; when the CPAServer starts, it reads the latest TDF tree.)
ATTENTION The CPA Server is linked in /etc/rc2.d for automatic start up and shutdown.
The following scenarios show how you can use the TDFs to further enhance the security of your system administrative tasks and to tailor the task access to fit the policies of your site. Each scenario shows how to use both the graphical user interface and the commandline.
ATTENTION All TDF commands need to be run as root.
ATTENTION The TDF scripts do not check that the user or group names you enter on the command line are valid names. You need to manually verify their validity prior to their use.
In scenario 1, "Lucy" is the primary administrator for a single DYNIX/ptx system, with responsibility for administering all facets of the system. In this scenario, Lucy should be given complete access to the CommandPoint Admin task hierarchy. All others will automatically be denied access to all tasks, unless she explicitly grants them access.
Graphical User Interface:
Verify that user Lucy already exists.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add User.
Enter the user name Lucy or use the Browse button to find the group.
Click on OK.
Click on the Allowed box to grant access to Lucy. (A check in the box means that access is allowed; an empty box means that access is not allowed.)
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for Lucy is not shown, click on Change User/Group and enter Lucy. All tasks for which Lucy has access will have an icon next to the task name, with a green checkmark in it. (If she was denied access to a task(s), the icon next to the task(s) would have a red circle with a white X in it.)
Click on Close.
Select File -->Save and Update Server.
Commandline:
As described in the Installation section, as long as Lucy is a member of cpadmin and/or cpgroupgroup, she can access all branches of TDF tree. However, if you wanted to give Lucy complete access, without adding her to cpadmin or cpgroup, follow these steps:
# cd /opt/commandpoint/cpadmin
# ./tdfcli/add_acl -a -u lucy tdf/_tdf.tdf
# ./tdfcli/updateTDF
Result: Because the tdf/_tdf.tdf file is the highest level of the TDF hierarchy, Lucy's access in the _tdf.tdf file will percolate down to all sub-directories, thereby granting access to all tasks.
In scenario 2, a subset of administrators needs to do User and Group administration on multiple DYNIX/ptx systems. If these administrators are members of a UNIX group (such as ugadmin group), the simplest configuration would be to allow access to the CommandPoint Admin User and Group tasks for that group (ugadmin). Alternatively, each individual administrator could be explicitly allowed. This configuration must be done on each system.
Graphical User Interface:
In Configure Tasks and Access, Lucy would do the following to allow access to the top level of the TDF tree for group ugadmin, but then deny access to the EES and Filesystem branches of the tree:
Verify that group ugadmin already exists.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add Group.
Enter the group name ugadmin or use the Browse button to find the group. (Group ugadmin must already be created.)
Click on OK.
Click on the Allowed box to grant access to group ugadmin.
Click on Error and Event in the left pane.
Select Tools-->Add Group.
Enter the group name ugadmin or use the Browse button to find the group.
Leave the Allowed button unchecked.
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access ugadmin is not shown, click on Change User/Group and enter ugadmin. All Error and Event tasks should have an icon with a red circle with a white X in it next to the task names, meaning group ugadmin cannot access those tasks.
Click on Close.
Click on Filesystem in the left pane.
Select Tools-->Add Group.
Enter the group name ugadmin or use the Browse button to find the group.
Click on OK.
Leave the Allowed button unchecked.
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access ugadmin is not shown, click on Change User/Group and enter ugadmin. All Error and Event and Filesystem tasks should have an icon with a red circle with a white X in it next to the task names, meaning group ugadmin cannot access those tasks.
Select File -->Save and Update Server.
Commandline:
Lucy (as root) would execute the following commands to allow access to the top level of the TDF tree for group ugadmin, but then deny access to the EES and Filesystem branches of the tree:
# cd /opt/commandpoint/cpadmin
# ./tdfcli/add_acl -a -g ugadmin tdf/_tdf.tdf
# ./tdfcli/add_acl -d -g ugadmin tdf/CPAdmin/EES/_EES.tdf
# ./tdfcli/add_acl -d -g ugadmin tdf/CPAdmin/Filesystem/_Filesystem.tdf
# ./tdfcli/updateTDF
Result: When any user in ugadmin group invokes CommandPoint Admin, they will only see User and Group tasks and nothing else. They will, however, have full access to all tasks in User and Group.
ATTENTION Because adding access for group ugadmin in the _tdf.tdf file automatically gave the group members access to all sub-tasks, an explicit deny for EES and Filesystem tasks is necessary.
Tip: Using UNIX group names to allow or deny access to tasks is a good idea. If the system administrative staff at your site changes, all you need to do is to modify the UNIX group. You will not need to update the CommandPoint Admin TDF files.
In scenario 3, assume again that all of the administrators belong to a UNIX group (such as ugadmin), but specific individuals in that group are explicitly denied access to a task, such as adding a user.
Graphical User Interface:
In Configure Tasks and Access, Lucy would do the following to allow access to the top level of the TDF tree for group ugadmin, but deny access to the add.tdf file (for the Add a User task) for users Fred, Sally, and George:
Verify that group ugadmin and users Fred, Sally, and George already exist.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add Group.
Enter the group name ugadmin or use the Browse button to find the group. (This group must already be created.)
Click on OK.
Click on the Allowed box to grant access to group ugadmin.
Click on User and Group-->Add User in the left pane.
Select Tools-->Add User.
Enter the user names of Fred, Sally, and George, separated by spaces.
Click on OK.
Leave the Allowed button unchecked.
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for Fred, Sally, or George is not shown, click on Change User/Group and enter the user names individually. The Add User task should have an icon with a red circle with a white X in it next to the task name, meaning neither Fred, Sally, nor George can access that task.
Click on Close.
Select File -->Save and Update Server.
Commandline:
Lucy (as root) would enter the following commands to allow access to group ugadmin, but deny access to the add.tdf file (for the Add a User task) for users Fred, Sally, and George:
# cd /opt/commandpoint/cpadmin
# ./tdfcli/add_acl -a -g ugadmin tdf/_tdf.tdf
# cd tdf/CPAdmin/UserGroup/User
# ../../../../tdfcli/add_acl -d -u "fred sally george" add.tdf
# ../../../../tdfcli/updateTDF
Result: Fred, Sally, and George will not see the Add User task, while others in group ugadmin will.
In scenario 4, the administrators belong to distinct UNIX groups (such as admin and asstadmin). The admin group needs access to all tasks, while the asstadmin group can only access "display" tasks in the Group Accounts branch.
Graphical User Interface:
In Configure Tasks and Access, Lucy would do the following to allow access to the top level of the TDF tree for groups admin and asstadmin, but deny access to the modification tasks for group asstadmin in the Group Accounts branch:
Verify that groups admin and asstadmin already exist.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add Group.
Enter the group names admin and asstadmin(separated by spaces) or use the Browse button to find the group. (These groups must already be created.)
Click on Close.
Click on the Allowed boxes to grant access to groups admin and asstadmin.
Click on User and Group-->Add Group in the left pane.
Select Tools-->Add Group.
Enter the group name asstadmin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Delete Group in the left pane.
Select Tools-->Add Group.
Enter the group name asstadmin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Modify Group in the left pane.
Select Tools-->Add Group.
Enter the group name asstadmin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Validate Group File in the left pane.
Select Tools-->Add Group.
Enter the group name asstadmin.
Click on OK.
Leave the Allowed button unchecked.
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for asstadmin is not shown, click on Change User/Group and enter the group name. The Group Account tasks should have an icon with a red circle with a white X in it next to the task names, meaning group asstadmin cannot access that task.
Select File -->Save and Update Server.
Commandline:Lucy (as root) would enter the following commands to allow access to all tasks for groups admin and asstadmin, then would deny access to modification tasks for group asstadmin group in the Group Account branch:
# cd /opt/commandpoint/cpadmin
# ./tdfcli/add_acl -a -g "admin asstadmin" tdf/_tdf.tdf
# cd tdf/CPAdmin/UserGroup/Group
# ../../../../tdfcli/add_acl -d -g asstadmin groupadd.tdf
# ../../../../tdfcli/add_acl -d -g asstadmin groupdelete.tdf
# ../../../../tdfcli/add_acl -d -g asstadmin groupmodify.tdf
# ../../../../tdfcli/add_acl -d -g asstadmin groupvalidate.tdf
# ../../../../tdfcli/updateTDF
Result: Users in the asstadmin group will only see the Display Groups task under the Group Accounts. They will not see other tasks such as Add, Delete, Modify, or Validate Group.
Scenario 5 describes a situation where a site has multiple DYNIX/ptx systems, where one machine is chosen to host a "master" copy of the User and Group files and changes are made (such as adding or removing users) only on the "master" system. On a periodic basis, the "master" files (such as /etc/passwd and /etc/group) are copied to all of the other ("non-master") DYNIX/ptx systems. In this case, CommandPoint Admin should be configured, via the TDFs, such that approved administrators on "non-master" systems are only allowed to view the User and Group information, but are not allowed to modify it. On the master system, CommandPoint Admin should be configured such that the approved administrators can both view and modify User and Group information.
Graphical User Interface:
In Configure Tasks and Access, Lucy would do the following to allow access to the top level of the TDF tree on system1for group admin, but deny access to the User and Group branches on system2 and system3, except for the Display tasks:
Log on to system1.
Verify that group admin already exists.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add Group.
Enter the group name admin or use the Browse button to find the group. (This group must already be created.)
Click on OK.
Click on the Allowed boxes to grant access to group admin.
Select File -->Save and Update Server.
Log on to system2.
Verify that group admin already exists.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add Group.
Enter the group name admin or use the Browse button to find the group. (This group must already be created.)
Click on OK.
Click on the Allowed boxes to grant access to group admin.
Click on User and Group-->Add Group in the left pane.
Click on User and Group-->Delete Group in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Modify Group in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Validate Group File in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Add User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Deactivate User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Delete User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Modify User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Reactivate User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Set Account Defaults in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Validate Password File in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for admin is not shown, click on Change User/Group and enter the group name. The modification tasks in Group Accounts and User Accounts should have an icon with a red circle with a white X in it next to the task names, meaning group admin cannot access those tasks.
Click on Close.
Select File -->Save and Update Server.
Log on to system3.
Verify that group admin already exists.
Click on Launchable Tasks in the left pane. The right pane should show Access for Launchable Tasks.
Select Tools-->Add Group.
Enter the group name admin or use the Browse button to find the group. (This group must already be created.)
Click on OK.
Click on the Allowed boxes to grant access to group admin.
Click on User and Group-->Delete Group in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Modify Group in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Validate Group File in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Add User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Deactivate User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Delete User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Modify User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Reactivate User in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Set Account Defaults in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Click on User and Group-->Validate Password File in the left pane.
Select Tools-->Add Group.
Enter the group name admin.
Click on OK.
Leave the Allowed button unchecked.
Select Tools-->Show Access Tree for User/Group to verify the changes.
If access for admin is not shown, click on Change User/Group and enter the group name. The modification tasks in Group Accounts and User Accounts should have an icon with a red circle with a white X in it next to the task names, meaning group admin cannot access those tasks.
Click on Close.
Select File -->Save and Update Server.
Commandline:
Lucy (as root) would enter the following commands on system1 (the "master" system) for group admin to allow access to all branches:
# cd /opt/commandpoint/cpadmin
# ./tdfcli/add_acl -a -g admin tdf/_tdf.tdf
# ./tdfcli/updateTDF
ATTENTION The tdfcli/add_acl command in the example for system1 also allows group admin to not only display, but also modify EES and Filesystem information. If you want to exclude group admin from those branches, you need to explicitly deny access to each branch. The next set of commands shows you how to deny access for modifications to the Group and User branches.
Lucy (as root) would enter the following commands on system2 and system3 to deny access to the User and Group branches:
#cd /opt/commandpoint/cpadmin
# tdfcli/add_acl -a -g admin tdf/_tdf.tdf
#cd tdf//CPAdmin/UserGroup/Group
# ../../../../tdfcli/add_acl -d -g admin groupadd.tdf
# ../../../../tdfcli/add_acl -d -g admin groupdelete.tdf
# ../../../../tdfcli/add_acl -d -g admin groupmodify.tdf
# ../../../../tdfcli/add_acl -d -g admin groupvalidate.tdf
#cd ../User
# ../../../../tdfcli/add_acl -d -g admin add.tdf
# ../../../../tdfcli/add_acl -d -g admin deactivate.tdf
# ../../../../tdfcli/add_acl -d -g admin delete.tdf
# ../../../../tdfcli/add_acl -d -g admin modify.tdf
# ../../../../tdfcli/add_acl -d -g admin reactivate.tdf
# ../../../../tdfcli/add_acl -d -g admin setdefaults.tdf
# ../../../../tdfcli/add_acl -d -g admin validatepwd.tdf
#/opt/commandpoint/cpadmin/tdfcli/updateTDF
Result: Approved administrators can both view and modify User and Group information on the master system. Approved administrators can only view (and not modify) User and Group information on the "non-master" systems.
The following TDF precedence rules apply:
You cannot deny access at a high level in the TDF tree, then allow access below.
User will always take precedence over group.
For example, assume that user Mike is a member of group oper. If group oper is denied access at a level and Mike is allowed access at the same level, then Mike will be allowed access since the user specification always takes precedence over group.
Deny access takes precedence over allow at the same level of the TDF tree, unless the user takes precedence over group.