Thursday Aug 07, 2014

HA-LDOM live migration in Oracle Solaris Cluster 4.2

Most Oracle Solaris Cluster resource types clearly separate their stopping and starting actions. However, the HA-LDom (HA Logical Domain / HA for Oracle VM for SPARC data service) agent has a capability of performing live migration, in which an entire switchover of the resource is performed while the cluster framework is stopping the resource. Suppose that the LDom resource starts out on node A and the administrator executes a switchover to node B. While the cluster framework is stopping the resource on node A, LDom live migration is actually migrating the LDom from node A to node B.

The problem (which previously existed) with this approach arose if another resource group declared a strong negative (SN) affinity for the LDom resource's group or if load limits were in use. The LDom is actually migrating onto the target node before the cluster framework knows that it has started there, so the cluster framework will not have had a chance to evict any resource group(s) due to strong negative affinities or load limits. There will be an interval of time in which the hard loadlimit or strong negative affinity will be violated. This may cause overload of the node, and consequent failure of the LDom live migration attempt.

With Oracle Solaris Cluster 4.2 we eliminate the above said problem by providing a mechanism in the cluster framework by which excess workload can be migrated off of the target node of the switchover before executing the live migration of the LDom. This is accomplished by making use of the following two enhancements:

  1. A new resource property Pre_evict which ensures seamless live migration of LDom. The Pre_evict property allows the cluster framework to move excess workload off of the target node before the switchover begins, which then allows the live migration to succeed more often.

  2. A new scha_resourcegroup_get query tag SCHA_TARGET_NODES which allows a data service to perform the live migration by informing it of the target node to be used for the migration.

For the convenience of the users / administrators, the HA-LDom agent in Oracle Solaris Cluster 4.2 has the Pre_evict set to True by default and the agent is enhanced to take advantage of these new API (Pre_evict and SCHA_TARGET_NODES query) features.

For more information, refer the following links

- Harish Mallya
Oracle Solaris Cluster 

Tuesday Aug 05, 2014

Using Oracle Solaris Unified Archives to Replicate an Oracle Solaris Cluster 4.2 Cluster

Oracle Solaris Automated Installation (AI) was first supported in Oracle Solaris Cluster 4.0 software to install and configure a new cluster from IPS repositories. With Oracle Solaris Unified Archive introduced in Oracle Solaris 11.2 software, the automated installation of Oracle Solaris Cluster 4.2 software with the Oracle Solaris 11.2 OS is expanded with the following added functionality:

  1. Install and configure a new cluster from archives. The cluster is in the initial state, just like one created using the standard method of running scinstall(1M) on the potential cluster nodes.

  2. Restore cluster nodes from recovery archives created for the same nodes, due to hardware failures on the nodes.

  3. Replicate a new cluster from archives created for the nodes in a source cluster. The software packages and the cluster configuration on the new nodes will remain the same as in the source cluster, but the new nodes and some cluster objects (such as zone clusters) can have different system identities.

This document shows how to replicate a new cluster from the Oracle Solaris Unified Archives.

Replicating clusters can greatly reduce the effort of installing the Oracle Solaris OS, installing Oracle Solaris Cluster packages, configuring the nodes to form a cluster, installing and configuring applications, and applying SRUs or patches for maintenance. All of this can be done in one installation.

At first, the source cluster needs to be set up. This effort cannot be omitted. However, for use cases such as engineered systems, archives can be created for the source cluster nodes as master images, and can be used to replicate multiple clusters, as many as one wants, using this feature in Oracle Solaris Cluster 4.2 software. The more clusters you replicate, the more effort it saves.

The procedure to replicate a cluster includes the following steps:

  • Set up the source cluster and create archives for each source node.
  • Set up the AI server and the DHCP server.
  • Run scinstall on the AI server to configure the installation of the new cluster nodes, and add the new nodes to the configuration of the DHCP server.
  • Boot net install the new cluster nodes.

These same steps also apply to configuring a new cluster and restoring cluster nodes. The only difference is that, when running scinstall on the AI server, the menu options and inputs are different.

Requirements of the new cluster

When replicating a new cluster from a source cluster, the new cluster needs to have the following similar hardware configuration as the source cluster:

  • Same number of nodes.
  • Same architecture.
  • Same private adapters for cluster transport.

As for the archives used to install the new cluster nodes, they must be created for the global zone, not from a non-global zone; do not mix using clone and recovery types of archives; and exclude datasets on shared storage when creating archives and migrate the data separately.

Currently, Oracle Solaris Unified Archive only supports ZFS, therefore other file systems and volume managers that are configured in the source cluster are not included in the archive. They can be migrated using the corresponding methods of those types.

If quorum servers or NAS devices are configured in the source cluster, the cluster configuration related to these objects are carried to the new cluster. However, the configuration on these hosts is not updated. Manual intervention is needed on these systems for them to function in the new cluster.

Set up the source cluster and create an archive for each node

The source cluster can be set up with any of the existing supported methods. Let’s use a two-node cluster (host names source-node1 and source-node2) with HA for NFS agent and a zone cluster as simple examples just for illustration purpose. This source cluster has a shared disk quorum device.

The zone cluster myzc is configured, installed, and booted online, and the two zone cluster nodes have host name source-zcnode1 and source-zcnode2.

# clzonecluster status

=== Zone Clusters ===

--- Zone Cluster Status ---

Name Brand Node Name Zone Host Name Status Zone Status

---- ----- --------- -------------- ------ -----------

myzc solaris source-node1 source-zcnode1 Online Running

source-node2 source-zcnode2 Online Running

The HA for NFS resource group (named nfs-rg) contains a logical-hostname resource nfs-lh, an HAStoragePlus resource hasp-rs, and a SUNW.nfs resource nfs-rs. The local mount point for the NFS file system is /local/ufs as shown using clresource show.

# clresource list -v

Resource Name Resource Type Resource Group

------------- ------------- --------------

nfs-rs SUNW.nfs:3.3 nfs-rg

hasp-rs SUNW.HAStoragePlus:10 nfs-rg

nfs-lh SUNW.LogicalHostname:5 nfs-rg

# clresource show -v -p HostnameList nfs-lh

=== Resources ===

Resource: nfs-lh

--- Standard and extension properties ---

HostnameList: source-lh-hostname

Class: extension

Description: List of hostnames this resource manages

Per-node: False

Type: stringarray

# clresource show -p FilesystemMountPoints hasp-rs

=== Resources ===

Resource: hasp-rs

--- Standard and extension properties ---

FilesystemMountPoints: /local/ufs

Class: extension

Description: The list of file system mountpoints

Per-node: False

Type: stringarray

On each node in this source cluster, create an unified archive for the global zone. The archive can be of clone type or recovery type. A clone archive created for the global zone contains multiple deployable systems. Non-global zones are excluded from the global zone, and each non-global zone is a single deployable system. A recovery archive created for the global zone consists just one single deployable system. Installing from a global zone recovery archive installs the global zone as well as the non-global zone that it contains. Check the Unified Archive introduction blog for more details.

Since there is a zone cluster in the source cluster, create a recovery archive for each node so that the zones will get installed.

As an example, we use archive-host as the name of the host that is mounted under /net and exports a file system to store the archives.

source-node1# archiveadm create -r /net/archive-host/export/source-node1.sua

source-node2# archiveadm create -r /net/archive-host/export/source-node2.sua

Note even though the recovery archive contains multiple boot environment (BE), only the current active BE is updated to function in the new cluster.

Set Up the AI server and the DHCP server

The new cluster nodes must be networked with a designated AI server, a DHCP server, and the host for storing the archive files. The AI server must have static IP and be installed with Oracle Solaris 11.2. The archive files created for the source cluster nodes must be accessible from the AI server as well. The archive location can be an autofs mount point mounted via /net/host, an http, or an https URL.

On the AI server, install the Oracle Solaris Cluster installation package ha-cluster/system/install. Do not install other Oracle Solaris Cluster packages. Installing this package also installs the Oracle Solaris installadm package and the Internet Systems Consortium (ISC) DHCP package service/network/dhcp/isc-dhcp, if they are not yet installed.

# pkg publisher


solaris origin online F

ha-cluster origin online F

# pkg install ha-cluster/system/install

Run scinstall on the AI server to configure the installation

The tool to configure the AI installation of the new cluster nodes is /usr/cluster/bin/scinstall. As the same tool to configure a new cluster in the non-AI method, it gives a different menu when it runs at the AI server. Use the interactive method (running the scinstall command without any options) instead of the command line options method, as it gives help texts and prompts.

An archive must be created for the global zone of each source cluster node, and one archive file can only be specified to install just one node in the new cluster. This 1:1 mapping relationship must be maintained.

To avoid using the same host identities in both the source and the new clusters, the tool prompts for a host identity mapping file. It is a text file that contains 1:1 mapping from host identities used in the source cluster to the new host identities in the new cluster. The host names of the physical nodes do not need to be included in this file. The host names or IPs configured for zone clusters, non-global zones, and logical-hostname or shared-address resources can be included. Hosts used in name services for zones can be included too.

The file can contain multiple lines, and each line has two columns. The first column is the host name or IP used in the source cluster, and the second column is the corresponding new host name or IP address that will be used in the new cluster. “#” at the beginning of a line marks the comment lines.

# cat /net/archive-host/export/mapping_new_cluster.txt

# zone cluster host names

source-zcnode1 new-zcnode1

source-zcnode2 new-zcnode2

# ha-nfs logicalhost resource host name

source-lh-hostname new-lh-hostname

The scinstall tool provides menus and options, and prompts for the following user inputs, as shown with examples in the following table.



Example Values

Root password

Password for root account to access the nodes upon installation completes

Cluster name

Name of the new cluster


Node names and MACs

Node names in the new cluster and their MACs

new-node1 00:14:4F:FA:42:42

new-node2 00:14:4F:FA:EF:E8

Archive locations

Archive location for each node in the new cluster

new-node1: /net/archive-host/export/source-node1.sua

new-node2: /net/archive-host/export/source-node2.sua

Network address and netmask (optional)

Network address for private network and netmask

Network address:


Host ID mapping file (optional)

A text file for 1:1 mapping from the old host identities in the source cluster to new host identities


After confirming all the inputs, scinstall creates the install service for the new cluster, named as cluster-name-{sparc|i386}, creates manifest files and sysconfig profiles for each new node, and associates each node as clients to this install service.

The output from running scinstall also contains the instructions for adding the new cluster nodes as clients to the DHCP server. Installing Oracle Solaris 11.2 Systems has every detail about setting up the ISC DHCP server and adding clients to the DHCP configuration.

Boot net install the new cluster nodes

Boot the nodes from network to start the installation. For SPARC nodes,

Ok boot net:dhcp – install

For x86 nodes, press the proper function key to boot from the network.

After the installation completes, the nodes are automatically rebooted three times before joining the new cluster. Check the cluster nodes status with the /usr/clutser/bin/clquorum command. The shared disk quorum device is re-created using a DID in the freshly populated device name spaces.

# clquorum status

=== Cluster Quorum ===

--- Quorum Votes Summary from (latest node reconfiguration) ---

Needed Present Possible

------ ------- --------

2 3 3

--- Quorum Votes by Node (current status) ---

Node Name Present Possible Status

--------- ------- -------- ------

new-node1 1 1 Online

new-node2 1 1 Online

--- Quorum Votes by Device (current status) ---

Device Name Present Possible Status

----------- ------- -------- ------

d1 1 1 Online

The zone cluster has updated host names. Its zone status is Running but its cluster status is Offline. Check its configuration for any manual updates to perform in the new environment. If the new configuration looks fine, using the clzonecluster reboot command to bring the zone cluster to Online cluster status.

# clzonecluster status

=== Zone Clusters ===

--- Zone Cluster Status ---

Name Brand Node Name Zone Host Name Status Zone Status

---- ----- --------- -------------- ------ -----------

myzc solaris source-node1 new-zcnode1 Offline Running

source-node2 new-zcnode2 Offline Running

# clzonecluster reboot myzc

The private network address is changed to the one specified during running scinstall.

# cluster show -t global | grep private_



The nfs-rg and its resources are in offline state as well with updated host name for the logical-hostname resource.

# clresource show -v -p HostnameList nfs-lh

=== Resources ===

Resource: nfs-lh

--- Standard and extension properties ---

HostnameList: new-lh-hostname

Class: extension

Description: List of hostnames this resource manages

Per-node: False

Type: stringarray

Since the archive does not contain the UFS file systems used in resource group nfs-rg, the mount entry (I.e., /local/ufs) for this UFS file system is commented out in the /etc/vfstab file. Update /etc/vfstab to bring it back on all the nodes. Then on one node, create the file system on that shared disk. Finally bring the resource group nfs-rg online using the clresourcegroup online command. The files in this file system in the source cluster can be copied over, or just start with the new file system.

# grep '/local/ufs' /etc/vfstab

/dev/global/dsk/d4s6 /dev/global/rdsk/d4s6 /local/ufs ufs 2 no logging

# cldevice list -v d4

DID Device Full Device Path

---------- ----------------

d4 new-node2:/dev/rdsk/c1d4

d4 new-node1:/dev/rdsk/c1d4

# format /dev/rdsk/c1d4s2

# newfs /dev/did/rdsk/d4s6

newfs: construct a new file system /dev/did/rdsk/d4s6: (y/n)? y

# clresourcegroup online nfs-rg

# clresource status

=== Cluster Resources ===

Resource Name Node Name State Status Message

------------- --------- ----- --------------

nfs-rs new-node1 Online Online - Service is online.

new-node2 Offline Offline

hasp-rs new-node1 Online Online

new-node2 Offline Offline

nfs-lh new-node1 Online Online - LogicalHostname online.

new-node2 Offline Offline

At this stage, this newly replicated cluster and the agent are fully functional.

- Lucia Lai <>
Oracle Solaris Cluster 

Friday Aug 01, 2014

Oracle Solaris Cluster 4.2 - Agent development just got better and easier

Agent or data service development allows you to deploy your application within the Oracle Solaris Cluster infrastructure. The Generic Data Service (GDS) has been designed and developed by Oracle Solaris Cluster Engineering to reduce the complexity associated with data service development so that all you need to do is to supply the GDS with a script to start your application. Of course, other scripts can also be used by the GDS to validate, stop and probe your application. Essentially, the GDS is our preferred data service development tool and is extensively deployed within our fully supported data service portfolio of popular applications. If we do not have a data service for your application then the GDS will be your friend to develop your own data service.

With Oracle Solaris Cluster 4.2 we are delivering a new version of the GDS. If you are familiar with data service development within Oracle Solaris Cluster then you will be pleased to know that we have kept the consistent behaviour that makes the GDS a trusted and robust data service development tool. By delivering a new and enhanced version of the GDS, data service development within Oracle Solaris Cluster is now much more flexible.

We have included some enhancements which previously required somewhat awkward workarounds when using the original GDS resource type SUNW.gds. For example, previously your application was always started under the control of the Process Monitor Facility (PMF) and now with the new version of the GDS, using the PMF is optional by setting the extension property PMF_managed=TRUE or FALSE. As you may be aware, when starting an application under the control of the PMF your application had to leave behind at least one process for the PMF to monitor. While most applications will do this, you may want your GDS resource to execute a script or command that does not leave behind any processes. Setting the extension property PMF_managed=FALSE for your GDS resource will inform the GDS to not start your script or command under the control of the PMF, instead your script or command is just executed. This is very useful if your GDS resource performs some task that does not leave behind a process.

We have also enhanced the GDS probe's behaviour so that you can ensure that your probe command will always be executed even on a system that is heavily loaded, potentially eliminating a probe timeout. We have bundled a new resource type so that you can proxy a service state as well as providing you with the ability to subclass this new version of the GDS. Subclassing allows you to use the new version of the GDS but have your own resource type name and new or modified extension properties. In fact there are over 20 improvements with this new version of the GDS.

While it is not practical to showcase all the capabilities of the new version of the GDS within this blog, the capability of the new version of the GDS is significant if you consider that new extension properties and other improvements, such as subclassing, can all be combined together. Furthermore, the new version of the GDS will validate your configuration and inform you if your configuration has a conflict. Consequently, the new version of the GDS has enough functionality and flexibility to be our preferred data service development tool.

The original GDS resource type SUNW.gds still exists and is fully supported with Oracle Solaris Cluster 4.2. The new version of the GDS includes two new resource types, ORCL.gds and ORCL.gds_proxy. It is possible to use your existing SUNW.gds start/stop and probe scripts with ORCL.gds. However, if you included workarounds within your scripts you should consider removing or disabling those workarounds and instead use the new extension property that delivers the same behaviour.

Oracle Solaris Cluster 4.2 delivers enterprise Data Center high availability and business continuity for your physical and virtualised infrastructures. Deploying your application within that infrastructure is now better and easier with ORCL.gds and ORCL.gds_proxy. Comprehensive documentation, including demo applications, for the new version of the GDS can be found within the Oracle Solaris Cluster Generic Data Service (GDS) Guide.

Additionally, further links are available that describe data services from the Oracle Solaris Cluster Concepts Guide, all our data service documentation for Oracle Solaris Cluster 4.2 and finally our Oracle Solaris Cluster 4 Compatibility Guide that lists our fully supported list of data services.

Neil Garthwaite
Oracle Solaris Cluster Engineering

Thursday Jul 31, 2014

Oracle Solaris Cluster 4.2 is out!

Oracle Solaris Cluster 4.2 has been released today, together with Oracle Solaris 11.2, Oracle’s flagship operating system! This latest version offers maximized availability and orchestrated disaster recovery for enterprise applications, leveraging Oracle Solaris 11.2's latest virtualization and software life-cycle technologies.

It delivers:

  • Extreme availability for virtualized workloads and applications

    Oracle Solaris Cluster 4.2 adds support for Oracle Solaris Kernel Zones with an updated failover zone agent which provides monitoring, automatic restart and failover as well as warm migration of kernel zones. It combines resiliency with the flexibility offered by kernel zones to have independent kernel versions and patch levels.

    Two new agents, for Oracle JD Edwards EnterpriseOne and GoldenGate have been added to the portfolio, offering application specific monitoring and recovery policies, providing increased application up-time to these Oracle solutions.

    This new release also offers support for Oracle 12.1 RAC database options such as Oracle Multitenant, service agents, policy managed database as well as new versions for a set of applications such as Oracle Business Intelligence, Siebel, ...

  • Fast and reliable disaster recovery for multi-tiered services

    The new orchestrated disaster recovery manages the automated and synchronized recovery of multiple applications and their respective replication solution across multiple sites, offering significant gains in terms of reliability, speed of recovery and reduced risk.

  • Agile deployments with Oracle Solaris lifecycle management

    The new Oracle Solaris Unified Archives format can now be used with Oracle Solaris Cluster to recover or clone easily and rapidly either physical clusters or virtual clusters. Also with the support for the new secure Automated Installer, cluster deployments can leverage Oracle Solaris end-to-end secure provisioning.

  • Simplified administration with new GUI

    The new browser based graphical user interface offers a single point access to status, configuration and management capabilities. Its topology, tree and table views offer easy navigation inside cluster instances both in local or multi-cluster configurations facilitating operations, monitoring, and diagnostics.

  • Flexible and easy integration for custom applications with the new GDSv2

    Agent (or data service) development allows you to deploy your application within the Oracle Solaris Cluster infrastructure. The Generic Data Service (GDS) has been designed and developed by Oracle Solaris Cluster engineering to reduce the complexity associated with data service development. GDS v2 further increases flexibility, ease of use and security of this already trusted and robust development tool.

  • Designed and tested together with Oracle hardware, infrastructure software and applications to deliver best time to value

    Oracle Solaris Cluster is engineered from the ground up to support the stringent requirements of a multi-tier mission critical environment. It is thoroughly tested with the Oracle servers, storage and networking component and integrated with Oracle Solaris. And last but not least it delivers the application high availability framework for Oracle Optimized Solutions and Oracle SuperCluster, Oracle's premier general purpose engineered system.

If you are interested to know more stay tuned: we have planned a series of posts going into much more details. In the mean time download the software and the documentation and try it out !

Looking forward to your comments,
Eve and the Oracle Solaris Cluster engineering team

Monday Mar 31, 2014

Enhanced Oracle Solaris Cluster Security Framework

Enhanced Oracle Solaris Cluster Security Framework

Besides providing high availability (HA) & reliability to the applications, Oracle Solaris Cluster data services (agents) strive to provide a very secure HA environment by leveraging some of the salient security features implanted in the Oracle Solaris Cluster software. Oracle Solaris Cluster Resource Group Manager (RGM) callback methods such as Start, Stop or Validate execute with a high level of privilege and must be protected against modification by a non-privileged user. These callback methods in turn might execute application programs that often do not require elevated privilege. If an application program is to be executed with elevated privilege, it must similarly be protected against modification by an unprivileged user.

In summary, an agent developer needs to do ownership/permission checks on programs to be executed with elevated privilege; and we want to facilitate the reduction of privilege for executing such programs. For these purposes, several enhancements were introduced in the Oracle Solaris Cluster 4.1 software:

1) New checks on the ownership and permission of RGM callback method executable files.

2) A new Application_user standard property to provide a standard hook for the end user to specify a non-root username for execution of application programs.

3) A new scha_check_app_user command, which implements ownership and permission checks on application executable files.

4) A new cluster property, resource_security, to control the new ownership and permission checks.

This blog will brief you on these enhancement features.

Invoking applications with limited privilege using data services in Oracle Solaris Cluster software

The security enhancement features mentioned above allow Oracle Solaris Cluster software to follow the principle of least privilege and limit any damage that might happen due to accidental or deliberate misuse of unlimited access right bestowed to superuser (root). Oracle Solaris Cluster data services adhere to the principle of least privilege while invoking the applications running in HA mode on Oracle Solaris Cluster software. Since the resource methods that are responsible for interacting with the applications always run with superuser privilege, it is highly recommended from a security perspective that this privilege level be dropped down to the minimum while executing the application program.

It is therefore crucial that the Oracle Solaris Cluster agent methods should run all external programs using a wrapper, to ensure that the external program is executed with the correct username and privileges.

Oracle Solaris Cluster software implements this concept by providing the scha_check_app_user command and properties like Application_user and resource_security. Agent developers can use the Application_user property and the scha_check_app_user command to enforce least-privilege for their own applications. The behaviour of the scha_check_app_user command highly depends on the values of the two properties and The entire picture will be clearer when we visualize this with the help of a simple example described in further text.

For fine details about these features, refer to the man pages for scha_check_app_user(1HA), r_properties(5) and resource_security in cluster(1cl). Meanwhile let us take a quick tour to explore these features by creating a very simple application (referred as "My Example App" in this article) and a minimal skeleton of an agent to bind this application with the Oracle Solaris Cluster HA environment. However, the complexity of agent code is much higher when all the perspectives of an HA environment are taken into consideration. Our goal here is just to understand how to use these security features and hence, only the minimal modules required to bind an application to a resource and start/stop the application/program have been described.

Application_user example: My Example App

Oracle Solaris Cluster software supports myriad applications with its high availability environment and many of them are pretty complex, too. ‘My Example App' on the other hand is a concise sample shell script and will serve as an example of the usage of the Application_user property and the scha_check_app_user command.

My Example App performs the job of sending mail notification to a cluster administrator in scenarios of failover/switchover. Although short, this application can be effectively used to permit a cluster administrator to check emails on a smartphone and see whether a necessary action might be required if a critical resource or resource group goes up/down. The admin can put the My Example App resource in the same resource group of another important resource that needs to be monitored for this purpose.

Please note that this agent doesn't cover all the modules and it's not recommended to run this on a production box.

My Example App modules

- Online module (executes when resource goes up)

/opt/myexapp/online.ksh (Executable permissions: 755 owned by user app_user)

- Offline module (executes when resource goes down)

/opt/myexapp/offline.ksh (Executable permissions: 755 owned by user app_user)

Note: app_user is the UNIX user expected to execute the application. There should be a valid mapping of app_user on all the nodes on which the resource is planned to be configured.

Agent development for My Example App

To create a minimally functional agent for My Example App, we will at least require the Resource Type Registration file, start script and stop script.

 - myexapp RTR file

/opt/myexapp/myexapp.rtr is a Resource Type Registration (RTR) file for this agent. All resources of type myexapp will directly inherit the properties from this file.  

 - Start script

myexapp_start will serve as the start script and will be executed every time the resource goes up.


- Stop script

myexapp_stop will serve as the stop script and will be executed every time the configured resource goes down.


Resource configuration for My Example App

- Register the RTR file:

# /usr/cluster/bin/clresourcetype register -f /opt/myexapp/myexapp.rtr myexapp

- Create the resource group and the resource :
# /usr/cluster/bin/clresourcegroup create myexappRG

# /usr/cluster/bin/clresource create -g myexappRG -t myexapp myexappRS

This completes the configuration phase of the application to be run on Oracle Solaris Cluster software. Now, let us dive deeper to understand the behaviour of the scha_check_app_user command when it is invoked in different scenarios. Refer to scha_check_app_user(1HA) man page for more details.

Behaviour of scha_check_app_user in various scenarios

The following are the descriptions of the most prominent scenarios.

Note: The following guidelines apply to all the example scenarios:

- The user specified as Application_user should be present on all the participating nodes of the cluster.

- The user specified with the -U option is taken as application user ignoring the configured Application_user, file owner or resource_security value.

This completes a comprehensive case study for use of the scha_check_app_user command in a sample application running on Oracle Solaris Cluster software. Now, let us explore one more important feature that helps in storing sensitive information across an Oracle Solaris Cluster configuration.

Handling passwords and sensitive information across Oracle Solaris Cluster

The Oracle Solaris Cluster 4.1 software provides a secure and easy to use mechanism for storing passwords and other sensitive information through private strings. A private string is identified with a unique name, and has an encoded value that can only be obtained by using the scha_cluster_get command.

The clpstring command manages Oracle Solaris Cluster private strings. Private strings are used by resources to store and retrieve private values securely. A typical use might be for an internal password used by an agent. The clps command is the short form of the clpstring command.

Let’s say our agent uses a password string. In order to harness the private strings feature of the Oracle Solaris Cluster security framework for this agent, we are required to bind the private strings with the data service resource.

# /usr/cluster/bin/clpstring create -b RS1 -v pw_str

Enter string value:

Enter string value again:

Private string pw_str is created for the global cluster and is bound to the resource RS1.

Private strings are never exposed to non-privileged users in either obfuscated or clear text form. However, privileged users can then retrieve the private strings by using the scha_cluster_get query as follows:

# /usr/cluster/bin/scha_cluster_get -O PSTRING pw_str

For more detailed information on the clpstring command, refer clpstring(1 CL) man page.

Although the Oracle Solaris Cluster 4.1 software supports these security enhancements, it’s important to note that not all agents are currently using these new features. Some existing agents might execute application programs with elevated privileges, for example, they might be executed as root. So it’s judicious to take necessary steps in validating the contents of such programs installed on a cluster, and to make sure that they are installed with ownership & permissions that prevent a non-privileged user from modifying them.

Posted By:
Tapan Avasthi
Data Services, Availability Engineering, Oracle Solaris Cluster


Oracle Solaris Cluster Engineering Blog


« October 2015