[root@octopus ~]# ls -al /var/stasher/clusters/objrepo.example.com
total 20
drwx------ 2 daemon daemon 4096 Mar 17 16:12 .
drwxr-xr-x 3 root root 4096 Mar 17 16:12 ..
-rw-r--r-- 1 daemon daemon 4396 Mar 17 16:12 1332015126008193.crt
-rw-r--r-- 1 daemon daemon 1968 Mar 17 16:12 1332015126008193.key
[root@octopus ~]# stashermg --nodekey --generate --name=octopus /var/stasher/clusters/objrepo.example.com
Created /var/stasher/newnodes/octopus...
Generating new key...
...+++++
....+++++
Warning: server not running, certificates are installed locally.
Certificate installed, connecting to server
Server is not running
The second step created a new node certificate. Each node in the cluster has a unique name, or a label. The node name does not have to be the same name as the machine where the node is running, but, for simplicity, it should be.
The stashermg command provides default values for most
configuration settings, including the directory it creates for the new
node. The default directory location comes from the default configuration
of stasher. --name gives the new node's name name, and the
name of the creates directory takes the
cluster's name by default. See stashermg(1) for more
information.
Each node's server process must be started by the userid that owns the directory. Different nodes in the same cluster on different machines can use different userids, but each server process must be started by the userid that owns its directory. When started by root, the server immediately drops root and sets its userid to the directory's owner, so the server process can be started by root, or by the directory's actual owner.
[root@octopus ~]# ls -al /var/stasher/newnodes/octopus
total 36
drwxr-xr-x 4 daemon daemon 4096 Mar 17 16:13 .
drwxr-xr-x 3 root root 4096 Mar 17 16:13 ..
-rw------- 1 daemon daemon 6285 Mar 17 16:13 cert.pem
drwxr-xr-x 2 daemon daemon 4096 Mar 17 16:13 data
drwxr-xr-x 2 daemon daemon 4096 Mar 17 16:13 logs
-rw-r--r-- 1 daemon daemon 348 Mar 17 16:13 properties
-rw-r--r-- 1 daemon daemon 4396 Mar 17 16:13 rootcerts.pem
The ownership of the newly-created directory can be
chown-ed, if so desired. However care must be taken
to preserve the file permissions, as shown in the above example. The
certificate file, cert.pem gets used to
authenticate the node to the cluster, and should not be world readable,
but everything else can be world readable (including
rootcerts.pem, which contains only the public
keys).
The properties file keeps the node's internal
server configuration. It should not be edited manually.
Server logs get written to logs. The default
server configuration rotates log files daily, and purges log files
after seven days.
The objects in the repository get stored in the
data subdirectory.
All nodes in the object cluster repository should have the same
amount of free disk space. Putting data on a
separate partition is recommended. When any node in the object
repository cluster runs out of free disk space, no more objects can be
added or modified in the repository.
The object repository server process switches to a failsafe
mode before available free disk space runs out completely;
the server process keeps a small fudge factor in reserve, to account
for random background noise.