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.6.0):
Fixes to known bugs in the V4.6.0 release
Additional tasks for Kernel, File and Directory, Job Scheduling, Device, and TCP/IP
Windows 2000 is a supported environment for CommandPoint Admin V4.6.1.
ATTENTION Upgrading from CommandPoint Admin V4.4.0 or V4.6.0 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.1 is compatible with the following software products running on NUMA 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.1 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 system to run CommandPoint Admin.
If you plan to use the Windows NT-compatible client to administer your NUMA 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.
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.
254306 Modify Cron Job does not work.
254280 User and Group - Add User fails with Invalid Login Region error.
254278 References to Sequent in error messages should be changed to IBM.
254281 Validate Password displays nothing if there are any inconsistencies.
254263 Why does cpadmin log a major error when starting its daemon?
254100 Add User -> Browse for Secondary Groups does not copy all selected entries.
254094 Del Cron Job & Rm Cron Permission does not remove the job.
253963 Need to make CPA scripts UNIX98 Shell compliant.
253953 Kernel Mgt clean up of TESTDIR,TESTROOT.
253931 Create I/O Opt Region: should print Memory Sharing Policy=hard.
253932 Create I/O Opt Region: text does not apply and should be removed.
253852 Display Network Memory Statistics -> Streams needs scroll bar.
253855 Help Exeption intermittently occurs causing Help to not work.
253853 TCP/IP -> Display * Statistics need horizontal scroll bars.
253851 Usability: TCP/IP Display Trace Route needs format clarification.
253850 Usability: TCP/IP Del Route needs text for next step.
253816 Install VTOC should have Enable checkbox checked by default.
253821 Filesystem Specific Options modal dialog help buttons missing.
253805 Find should accept wildcard for Starting location directory.
253792 Modify Group--Update Delete Group label as it takes multiple entries.
253793 Sys Env -> Display should be first in the task order.
253786 Delete At Jobs gives errors for deleted jobs.
253781 Some tasks leave behind a busy cursor - task termination problem.
253762 Dialog titles sometimes wrong for those allowing multiple selection.
253765 Delete Events needs more text.
253753 Find should accept multiple Start location directories.
253755 EES Viewer should move to the end of list when initialized.
253683 Kern Copy creates a directory with bad permissions.
253685 Kern Compile Status always says Not Compiled when dialog opens.
253656 Passwd Expiration days max number allowed of 100 too low.
253606 CP Launcher displays non-default port numbers.
253604 Enhc: CPAServer -q should show servers running on all ports.
253570 Display Sizes should show files when recursive option selected.
253536 Delete At Job stays busy when last job deleted.
253467 UNIX: help dialogs inside dialogs cannot be closed first.
253463 Display Cron Jobs should not allow multiple selection.
253464 Detect Devices Browse dialog should not allow multiple selection.
253465 List of Cron users different in Add Cron Job than Modify Cron Job.
253428 DelCronJob & ModifyCronJob do not remove their TMP_FILEs.
253422 Display trace route field does not validate for special characters.
253425 Usability: Device Tree -> Find Device button should move to Right.
253426 Display Route Table filter fields not validating special characters.
253399 Display Cron Table should have Tasks for Delete & Modify.
253403 Spinner - cannot click on up/down arrows sometimes.
253375 Create Region resets policies when moving between steps.
253307 At/cron permissions do not manage cron.deny or at.deny.
253260 Add At Job, cannot type over the Year field with a valid year.
253257 Add At/Cron Permission does not have Denied in Browse.
253265 Disk(s) field in Disable Partition Devices does not validate for special characters.
253279 Add Cron Job, sets * for Day of the Week when it is not selected.
253253 GID calculating algorithm in Add Group should become like Add User.
253214 Find Files -> the numeral 1 in the number 10 appears enabled in spinners when not selected.
253189 File/Dir applet errors print Usage messages from CPA scripts.
253191 Back button should be disabled in step 2 until task is done.
253171 Modify Group: Errors appear to accumulate with Apply or Modify.
253172 Modify Group: Cannot delete nonexistant members from groups.
253152 Display Sizes Owner and Group fields do not validate for values.
253143 Validate Group displays nothing when there are no inconsistencies.
253065 Need display for at and cron user task.
252782 Grid column widths resize to equal sizes when grid resized a lot.
252752 Display warning messages when violated guidelines for optimal region.
252759 Process Display With Filter does not have PID filter.
252758 Display Processes shows too many data in the table.
252754 Some of the windows show garbled tables when subjected to resize.
251235 Set Account Defaults, Passwd defaults wrong for 'Never expires.'
250891 Sorting problem with Region Name Browse dialog in Add RQ.
247016 Usability: Display Region Statistics hard to read.
244112 EFS filesystem option incompatible with read-only.
243115 View Group Member has a selected blank grid if no members.
243051 "Display group members" shows incomplete list of group members.
242425 "Select a Directory" dialogs should show the entry currently set.
242297 Delete Group should support multiple deletes.
241674 Page Down & Up should work in Displays.
241478 Multiple file selection in FileBrowseEdit bean would be good.
254590 License Agreement for NT Install of CPAdmin is no longer required.
254493 CPAdmin client starts for the first time in DRY RUN mode set.
254380 Usability:Saving cpadmin client user preferences for subsequent launches.
254379 Usability: There has to be a file and directory explorer in File & Directory application.
254381 Usability: Commands must be printed in the View Commands window.
254365 License Agreement shows some junk characters.
254367 Location of View Command window is not being set properly.
242404 CP Admin server does not run properly on audited systems.
254817 Set New Acct Defaults: Login regon invalid error when no region specified.
The number that appears in parentheses in problem report titles is the 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 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.
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.
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.
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.