Sandbox admin guide

This topic describes how to manage a Sandbox system. It includes basic information on the structure of the system, as well as how to perform actions to manage the system and troubleshoot simple issues.

For details of User Account Definitions and Required Privileges, refer to the relevant section from the Sandbox Install Guide.

Basic reference architecture

The sandbox server is installed under the application user account, with the majority of q processed running under it and the Delta Control environment. The Sandboxes themselves are satellite daemon-only installations under the user's own UNIX account.

This multi-daemon install architecture is the reason changes to the /etc/hosts file are necessary. Each daemon must run under a distinct host, even though these hosts could be on the same IP.

Naming conventions

The Sandboxes follow a naming convention to identify themselves to the user:

refinery_sbx_<HOST>_<USER>

Stop/start of full system

Management of full system reboot is identical to a standard KX Refinery system. You can stop and start the system using the CLI.

Stop/start of specific user sandbox

Individual users have the power to restart their own Sandbox processes using the UI. Sandbox users will only be able to view their own Sandbox process upon logging into delta control.

  • Log into Delta Control UI
  • Search refinery_sbx in the instance column of the process library status
  • Right click on the Sandbox and navigate to stop
  • Shut down Q process will gracefully terminate the process

Alternatively, the Sandbox Administrator may use the CLI with refinery sandbox commands 

Description: Sandbox start / stop

    --start                Start a Sandbox of a specified user
        --user *user*      The username of the user's sandbox to start

    --start-all            Start all sandboxes in the system

    --stop                 Stops the specified user's sandbox
        --user *user*      The username of the user's sandbox to start

    --stop-all             Stops all sandboxes

Enabling cross user sandbox access

If Sandbox users wish to have direct access to another user's Sandbox, they can do so by being permissioned to the process. The sharing of on-disk data can be managed with standard UNIX permissions by the UNIX administrator. However, if the user wishes to transfer in memory data or functions, they will need to be able to log into the process.

The image below shows user sbxUsr1 being given permission to log into the Sandbox of user sbxUsr with the steps:

  1. Double click on the user to grant permissions in the left navigation panel
  2. Under User Entity Permissions, search for the target Sandbox process you have permissions for
  3. Select the instance and click the right arrow
  4. Save the configuration

The user will now be able to log into their own, as well as to the newly permissioned Sandbox process.

Data population

Initial data loading

Upon first install the system will have no data. If a PROD Refinery install already exists, HDBs can be directly copied into the corresponding directories. For example, the entire system's databases could be transferred via:

rsync –rv  /prodMachine/delta-data/DaaSData/hdblog /sandboxServer/delta-data/DaaSData/

Note

HDB processes will require a reload before correct operation. Either restart them or wait for end of day for it to happen automatically.

Note

Due to the enumeration, data can only be directly copied if there is no pre-existing database.

Daily automated transfer from prod

For a Sandbox that is running in parallel to a production Refinery system, automated nightly data copy can be configured. This means that once data is persisted in the KX Refinery production system, it will automatically transfer and merge into the Sandbox database.

Note

It is required that SSH keys are set up from the PROD machine to the Sandbox machine, so that a command such as scp testFile.txt sandboxServer:/sandboxInstall/testFile.txt would execute without password or known host prompt.

To configure the automated transfer, the Sandbox server must be entered into .daas.cfg.dataCopyTargets on the production (data source) machine. The KX Refinery administrator must log into PROD KX Refinery and configure it as shown below:

The dropLocation must be the filestore/hdbDrops location for the data to be automatically ingested. Data will now be automatically transferred nightly. Each night a zip of the previous day's data is received by the sandbox server, which is then handled by the daas_processingDaemon and subsequently the daas_mergeDaemon.

Real-time capture

The Sandbox system can also capture real-time data in the same manner as a production install if required.

Troubleshooting

User errors

The Sandbox will report specific errors to the user in the event there are any issues with the query. The Sandbox will return the same errors that an application would receive; i.e. issues with the parameter input into the API function. These are all self-descriptive and can be resolved by changing the argument set. For these errors, refer to the Server-side API Guide.