Chapter 1. Getting Started with Data Grid CLI
The command line interface (CLI) lets you remotely connect to Data Grid Server to access data and perform administrative functions. Complete the following procedures to learn basic CLI usage such as creating users, connecting to Data Grid, and navigating resources.
1.1. Creating and modifying Data Grid users
Add Data Grid user credentials and assign permissions to control access to data.
Data Grid server installations use a property realm to authenticate users for the Hot Rod and REST endpoints. This means you need to create at least one user before you can access Data Grid.
By default, users also need roles with permissions to access caches and interact with Data Grid resources. You can assign roles to users individually or add users to groups that have role permissions.
You create users and assign roles with the user
command in the Data Grid command line interface (CLI).
Run help user
from a CLI session to get complete command details.
1.1.1. Adding credentials
You need an admin
user for the Data Grid Console and full control over your Data Grid environment. For this reason you should create a user with admin
permissions the first time you add credentials.
Procedure
-
Open a terminal in
$RHDG_HOME
. Create an
admin
user with theuser create
command.Add a user assigned to the
admin
group.bin/cli.sh user create myuser -p changeme -g admin
Use implicit authorization to gain
admin
permissions.bin/cli.sh user create admin -p changeme
Open
user.properties
andgroups.properties
with any text editor to verify users and groups.$ cat server/conf/users.properties #$REALM_NAME=default$ #$ALGORITHM=encrypted$ myuser=scram-sha-1\:BYGcIAwvf6b... $ cat server/conf/groups.properties myuser=admin
1.1.2. Assigning roles to users
Assign roles to users so they have the correct permissions to access data and modify Data Grid resources.
Procedure
Start a CLI session with an
admin
user.$ bin/cli.sh
Assign the
deployer
role to "katie".[//containers/default]> user roles grant --roles=deployer katie
List roles for "katie".
[//containers/default]> user roles ls katie ["deployer"]
1.1.3. Adding users to groups
Groups let you change permissions for multiple users. You assign a role to a group and then add users to that group. Users inherit permissions from the group role.
Procedure
-
Start a CLI session with an
admin
user. Use the
user create
command to create a group.-
Specify "developers" as the group name with the
--groups
argument. Set a username and password for the group.
In a property realm, a group is a special type of user that also requires a username and password.
[//containers/default]> user create --groups=developers developers -p changeme
-
Specify "developers" as the group name with the
List groups.
[//containers/default]> user ls --groups ["developers"]
Assign the
application
role to the "developers" group.[//containers/default]> user roles grant --roles=application developers
List roles for the "developers" group.
[//containers/default]> user roles ls developers ["application"]
Add existing users, one at a time, to the group as required.
[//containers/default]> user groups john --groups=developers
1.1.4. User roles and permissions
Data Grid includes a default set of roles that grant users with permissions to access data and interact with Data Grid resources.
ClusterRoleMapper
is the default mechanism that Data Grid uses to associate security principals to authorization roles.
ClusterRoleMapper
matches principal names to role names. A user named admin
gets admin
permissions automatically, a user named deployer
gets deployer
permissions, and so on.
Role | Permissions | Description |
---|---|---|
| ALL | Superuser with all permissions including control of the Cache Manager lifecycle. |
| ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR, CREATE |
Can create and delete Data Grid resources in addition to |
| ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR |
Has read and write access to Data Grid resources in addition to |
| ALL_READ, MONITOR |
Has read access to Data Grid resources in addition to |
| MONITOR |
Can view statistics via JMX and the |
1.2. Connecting to Data Grid Servers
Establish CLI connections to Data Grid.
Prerequisites
Add user credentials and have at least one running Data Grid server instance.
Procedure
-
Open a terminal in
$RHDG_HOME
. Start the CLI.
Linux:
bin/cli.sh
Microsoft Windows:
bin\cli.bat
Run the
connect
command and enter your username and password when prompted.Data Grid Server on the default port of
11222
:[disconnected]> connect
Data Grid Server with a port offset of
100
:[disconnected]> connect 127.0.0.1:11322
1.4. Shutting down Data Grid Server
Stop individually running servers or bring down clusters gracefully.
Procedure
- Create a CLI connection to Data Grid.
Shut down Data Grid Server in one of the following ways:
Stop all nodes in a cluster with the
shutdown cluster
command, for example:shutdown cluster
This command saves cluster state to the
data
folder for each node in the cluster. If you use a cache store, theshutdown cluster
command also persists all data in the cache.Stop individual server instances with the
shutdown server
command and the server hostname, for example:shutdown server <my_server01>
The shutdown server
command does not wait for rebalancing operations to complete, which can lead to data loss if you specify multiple hostnames at the same time.
Run help shutdown
for more details about using the command.
Verification
Data Grid logs the following messages when you shut down servers:
ISPN080002: Data Grid Server stopping ISPN000080: Disconnecting JGroups channel cluster ISPN000390: Persisted state, version=<$version> timestamp=YYYY-MM-DDTHH:MM:SS ISPN080003: Data Grid Server stopped
1.4.1. Data Grid cluster restarts
When you bring Data Grid clusters back online after shutting them down, you should wait for the cluster to be available before adding or removing nodes or modifying cluster state.
If you shutdown clustered nodes with the shutdown server
command, you must restart each server in reverse order.
For example, if you shutdown server1
and then shutdown server2
, you should first start server2
and then start server1
.
If you shutdown a cluster with the shutdown cluster
command, clusters become fully operational only after all nodes rejoin.
You can restart nodes in any order but the cluster remains in DEGRADED state until all nodes that were joined before shutdown are running.