This section describes the mechanism by which Geographic Edition handles password properties, when the entity added to a protection group (for example, an Oracle Data Guard or script-based plug-in configuration) requires a password property.
The password properties are read during the execution of the geopg command. These password properties are recognized by their conformance to the pattern *_password. When geopgi (a back-end program called by the geopg command) parses the protection group properties list, it looks for such arguments. If the password has been supplied in cleartext, as shown in the following example, then geopg warns the user that the password is insecure, but continues processing the password.
… -p sysdba_password=password …
For any password properties that have been specified, the geopgi program enters non-echo mode and prompts for these passwords, as shown in the following example:
… -p local_service_password= -p remote_service_password= …
Once all the arguments have been processed, these pairs are written into an internal password file on the local node, which is root readable only. A separate internalPasswordFile argument is inserted into the properties list with the value hostname:filename.
Once in the core Geographic Edition Java code, the internalPasswordFile argument is unpacked, and the file is read remotely through an internal common agent container to common agent container call. For security, the passwords are then converted into the hexadecimal representation of their character codes before they are written to the Oracle Solaris Cluster CCR, if the rest of the properties are correct and complete, and the validation succeeds.
When required, the passwords can be queried and converted back from the CCR and supplied to the appropriate programs to achieve the relevant switchovers, takeovers, or status queries.