1.12 Upgrading From Graph Server and Client 20.4.x to 21.x

If you are upgrading from Graph Server and Client 20.4.x to 21.x version, you may need to create new roles in database and migrate authorization rules from pgx.conf file to the database. Also, starting from Graph Server and Client Release 21.1, TLS is enforced at the time of the RPM file installation.

One of the main enhancements of Graph Server and Client Release 21.1 is moving the graph access permissions from the pgx.conf file to the database. A new set of graph roles with default permissions are created automatically in the database, at the time of the PL/SQL packages installation. See Table C-1 in the appendix for more details on the default mappings.

In order to comply with this feature you must perform the database actions explained in the following sections:

Creating additional roles in the database

The roles in the database with additional privileges are created when you install the 21.x PL/SQL packages in your database as part of the upgrade. If you are not able to install the PL/SQL packages, for example if you are using an Autonomous Database, see User Authentication and Authorization for more information on manually creating these roles in the database with the default set of privileges.

Migrating authorization rules

You must execute database GRANTS for user-added mappings contained in the pgx.conf file when upgrading to 21.x.

The following examples explain the various scenarios where migration of authorization rules may or may not apply.

Example 1-2 Migrating user-added mappings to database

To migrate the following user-added mappings in pgx.conf file:

...
"authorization": [{
  "pgx_role": "GRAPH_DEVELOPER",
  "pgx_permissions": [{
    "grant": "PGX_SESSION_ADD_PUBLISHED_GRAPH"
  },
...

you must execute the following GRANT statement in the database used by 21.x:

GRANT PGX_SESSION_ADD_PUBLISHED_GRAPH TO GRAPH_DEVELOPER

Example 1-3 Migrating user-added file system authorization rules to database

To migrate the following user-added file system authorization rules in pgx.conf file:

...
"file_locations": [{
  "name": "my_hdfs_graph_data",
  "location": "hdfs:/data/graphs"
}],
"authorization": [{
  "pgx_role": "GRAPH_DEVELOPER",
  "pgx_permissions": [{
    "file_location": "my_hdfs_graph_data",
    "grant": "read"  
  },
...

you must execute the following GRANT statement in the database used by 21.x:

CREATE OR REPLACE DIRECTORY my_hdfs_graph_data AS 'hdfs:/data/graphs'
GRANT READ ON DIRECTORY my_hdfs_graph_data TO GRAPH_DEVELOPER

Example 1-4 User-added graph authorization rules for preloaded graphs

Note:

No migration required for user-added graph authorization rules for preloaded graphs.

You must not migrate user-added graph authorization rules for preloaded graphs (as shown in the following code) as these rules continue to be configured in pgx.conf file.

"preload_graphs": [{
  "path": "/data/my-graph.json",
  "name": "global_graph"
}],
"authorization": [{
  "pgx_role": "GRAPH_DEVELOPER",
  "pgx_permissions": [{
    "preloaded_graph": "global_graph",
    "grant": "read"
  },
...

Self-signed TLS certificate now generated upon RPM installation

In Graph Server and Client 21.x the RPM installation generates a self-signed certificate into /etc/oracle/graph, which the server uses to enable TLS by default.

According to security best practices, access to the certificate is restricted to the oraclegraph operating system user. The implication of this is that you no longer can start the graph server via the /opt/oracle/graph/pgx/bin/start-server script, even if your user is part of the oraclegraph group. Instead, manage the lifecycle of the graph server via systemctl commands. For example:

sudo systemctl start pgx

Another possible option is to change the ownership of the certificate as shown:

sudo chown <youruser> /etc/oracle/graph/server_key.pem

Turning off TLS is not recommended as it reduces the security of your connection. However, if you must do so, see Disabling Transport Layer Security (TLS) in Graph Server for more details.