Changing security keys with remote access

When working with GPFS file systems accessed by other GPFS clusters, it might be necessary to generate a new public/private access key. This can be done without disturbing existing connections, provided the following procedure is followed.

To accomplish this, the cluster that owns and serves the file system is made to temporarily have two access keys (referred to as the 'old key' and the 'new key'), which are both valid at the same time. The clusters currently accessing the file system can then change from the old key to the new key without interruption of file system access.

In this example, cluster1 is the name of the cluster that owns and serves a file system, and cluster2 is the name of the cluster that has already obtained access to this file system, and is currently using it. Here, the system administrator of cluster1 changes the access key without severing the connection obtained by cluster2.

On cluster1, the system administrator issues the mmauth genkey new command to generate a new public/private access key pair. The key pair is placed in /var/mmfs/ssl:
```
mmauth genkey new
```
After this command is issued, cluster1 will have two keys (referred to as the 'old key' and the 'new key') that can both be used to access cluster1 file systems.
The system administrator of cluster1 now gives the file /var/mmfs/ssl/id_rsa.pub (that contains the new key) to the system administrator of cluster2, who desires to continue to access the cluster1 file systems. This operation requires the two administrators to coordinate their activities, and must occur outside of the GPFS command environment.
On cluster2, the system administrator issues the mmremotecluster update command to make the new key known to his system:
```
mmremotecluster update cluster1 -k cluster1_id_rsa.pub
```
where:

cluster1

Is the real name of cluster1 as given by the mmlscluster command on a node in cluster1.

cluster1_id_rsa.pub

Is the name of the file obtained from the administrator of cluster1 in Step 2.

This permits the cluster desiring to mount the file system to continue mounting file systems owned by cluster1.
On cluster1, the system administrator verifies that all clusters desiring to access cluster1 file systems have received the new key and activated it using the mmremotecluster update command.
On cluster1, the system administrator issues the mmauth genkey commit command to commit the new key as the only valid access key. The old key will no longer be accepted once this command completes successfully:
```
mmauth genkey commit
```
Once the new public key has been committed, the old public key will no longer be accepted. As a result, any remote cluster administrator who has not been given the new key (see the preceding Step 2) and run mmremotecluster update (see the preceding Step 3) will no longer be able to mount file systems owned by cluster1.

Similarly, the administrator of cluster2 might decide to change the access key for cluster2:

On cluster2, the system administrator issues the mmauth genkey new command to generate a new public/private access key pair. The key pair is placed in /var/mmfs/ssl:
```
mmauth genkey new
```
After this command is issued, cluster2 will have two keys (referred to as the 'old key' and the 'new key') that can both be used when a connection is established to any of the nodes in cluster2.
The system administrator of cluster2 now gives the file /var/mmfs/ssl/id_rsa.pub (that contains the new key) to the system administrator of cluster1, the owner of the file systems. This operation requires the two administrators to coordinate their activities, and must occur outside of the GPFS command environment.
On cluster1, the system administrator issues the mmauth update command to make the new key known to his system:
```
mmauth update cluster2 -k cluster2_id_rsa.pub
```
where:

cluster2

Is the real name of cluster2 as given by the mmlscluster command on a node in cluster2.

cluster2_id_rsa.pub

Is the name of the file obtained from the administrator of cluster2 in Step 2.

This permits the cluster desiring to mount the file system to continue mounting file systems owned by cluster1.
The system administrator of cluster2 verifies that the administrator of cluster1 has received the new key and activated it using the mmauth update command.
On cluster2, the system administrator issues the mmauth genkey commit command to commit the new key as the only valid access key. The old key will no longer be accepted once this command completes successfully:
```
mmauth genkey commit
```