Overview of Policy Editor
Policy Editor allows you to define policies in the policy repository. It is a Java swing application that acts as an X11 application on Solaris. As a result, it complies with and provides complete X11 functionality.
Key Mapping
Figure 18 shows the keyboard modifier map and key map table that Policy Editor uses to convert event code into key symbols (keysyms) in X11.
![]()
You generate this map by entering the following command in UNIX:
xmodmapTo customize your keyboard, the key mapping can be changed with standard X11 utilities.
Nonroot Users
Nonroot operators can access Policy Editor. The home directory for nonroot operators stores operator customization and log files.
The files and directories in pom_install_dir are not changed when various operators use Policy Editor. Nonroot operators who want to use Policy Editor must have read/write permission on files and directories in pom_install_dir. The Policy Editor default installation gives read/write permission to all users (that is, user, group, and others). The operating system commands are used to restrict access as required.
When Policy Editor is started, the directory POM_USER_DIR, which is <$HOME>/.UMC/pom, is used. The <$HOME> variable is the user's home directory. The <$HOME> directory must exist. The .UMC/pom directory path is created if it does not exist.
There are two subdirectories in POM_USER_DIR:
- etc—Contains the customization and configuration for this user
- var—Contains the log directory and file for this user
Exception Handling for the Directory
If Policy Editor detects a problem, such as a connection loss, when it accesses the directory, it displays a dialog box that describes the LDAP problem. If such a problem occurs, you can back up modified data to a different directory or to a file, or you can ignore the changes and open a different data source. You must either open or cancel the current operation.
The open operation opens the Open Directory Server dialog box, allowing you to change the connection parameters if it is necessary to connect to another directory.
Typically, there is one primary directory in the main office of the service provider and various secondary directories in regional centers. The service provider synchronizes policies between the master directory and the slave directories. As a result, changes to policies in each of the directories are controlled and propagated to the other required directories.
Providing Data Security
Policy Editor implements data security through:
Simple authentication occurs when Policy Editor sends the fully qualified distinguished name (FQDN) of the client and the client's clear-text password to the directory.
The directory supports access control that defines and monitors different clients' access privileges on LDAP entries.
Working with Policy Data Files
Policy Editor does not support the reading of policy data files produced with earlier versions of the SDX software. This feature may work under some circumstances; for example, when Policy Editor is used in JUNOSe mode.
Multi-User and Multi-Instance Concurrence
Multiple operators with multiple instances can use Policy Editor simultaneously. Concurrence control manages different instances or different operators while they perform operations on the same policy object at the same time.
Concurrence control is transparent; that is, the system does not notify you of simultaneous changes to the same object. However, be aware that, if multiple operators work on the same objects at the same time, the object properties that one operator configures can be overwritten by another operator; that is, the system stores the second operation in the directory.
Table 15 shows various concurrence control scenarios. In this table both operation 1 and operation 2 are performed on the same object by two different operators or application instances. The commitment of operation 2 is later than that of operation 1.
The object created by operation 2 is stored in the directory.
The modification made by operation 2 is stored in the directory.
The modification made by operation 2 is stored in the directory.
For the scenario of delete/delete, the object is deleted from the directory at the commitment of operation 1. When the same request is received from operation 2, it is silently ignored. For all other operations, operation 2 (that is, the latest operation) always prevails.
The directory ensures consistency for each entry but not across multiple entries. See SRC-PE Integration Guide, Chapter 2, Overview of LDAP Integration.
In summary, the directory does not maintain consistency among objects. To maintain consistency, all operators must be in contact with each other and agree on what the final state of the data should be.