Running the xgtd
server
The server component of the xGT application is called xgtd
.
It is a daemon process launched automatically at boot.
You can examine and control the xGT server using standard linux utilities:
sudo systemctl status xgtd
sudo systemctl stop xgtd
sudo systemctl start xgtd
sudo systemctl restart xgtd
Logging
When running xgtd
using the using the strategy described above, the events are
written into a log file named /var/log/xgtd.log
.
Data considerations
When using the xgtd://
protocol for reading and writing data, xGT will look for relative pathnames in the /srv/xgtd/data
directory.
For example, xGT would look for the path xgtd://folder/file
in /srv/xgtd/data/folder/file
.
To learn more about loading and saving, read the data management guide.
Configuring xgtd
Some parameters of xGT can be configured with a JSON-formatted configuration file xgtd.conf located in the computer where the user is running the server process.
The folowing variables for configuring xGT are supported:
worker_threads
: unsigned integer - Controls the number of worker threads xGT uses. Defaults to the number of cores in the system.io_threads
: unsigned integer - Controls the number of io threads xGT uses per file. Defaults to the worker thread count. The default will cap at 16.pin_threads
: true/false - Controls whether the worker threads are pinned to a specific core. This means they won't be able to move around. Defaults to false.max_memory
: unsigned integer - Controls the maximum amount of memory (in bytes) that xGT will use. Defaults to the available system RAM.locale
: string - Locale for comparing strings. Defaults to C.aws_access_key_id
: string - Used for S3 authentication if an.aws/credentials
file does not exist for the profile. Example:AKIAIOSFODNN7EXAMPLE
.aws_secret_access_key
: string - Used for S3 authentication if an.aws/credentials
file does not exist for the profile. Example:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
.
Example xgtd.conf
file:
{
"worker_threads" : 4,
"pin_threads" : false,
}
To configure xGT on AWS, login to the server and create the file /etc/xgtd.conf
or the file /home/xgtd/.xgtd.conf
. The system will first look for the file /home/xgtd/.xgtd.conf
, and if unsuccessful, it will look for the file /etc/xgtd.conf
.
Then you would restart the xGT server:
sudo systemctl restart xgtd
S3 credentials
When loading a file using the load
method and an s3:
protocol prefix, xGT will check the /home/xgtd/.aws/credentials
file for the two variables aws_access_key_id
and aws_secret_access_key
. The online AWS Access Keys document explains what these keys are and contains references to learn how to create and manage them. (These values may also be specified at runtime in user code by passing them to a Connection
object.)
When reading the /home/xgtd/.aws/credentials
file, xGT also supports profile selection via the AWS_PROFILE
environment variable.
If no environment variable is found, xGT will use the default
profile.
Using an SSL secure channel
By default xGT uses an insecure channel, but an admin can enable a secure channel using SSL certifcates. To run a secure server, pass the flags -s
(or --ssl
) and -d
(or --ssl_root_dir
) when starting the xgtd
executable. The ssl_root_dir
argument should be the path to the root directory that holds the server's SSL certificates and private keys. xGT expects the following directory structure:
.
├── certs
│ ├── ca-chain.cert.pem
│ └── server.cert.pem
└── private
└── server.key.pem
To connect to an xGT server using SSL, the client needs to pass the following flags to the xgt.Connection()
method: ssl
, ssl_root_dir
, and ssl_server_cn
. The ssl
flag needs to be set to true. The ssl_root_dir
flag should be set to the root directory containing the SSL certificates and private keys. The ssl_server_cn
flag should be set to the common name for the server listed on the server side SSL certificate. The xGT client expects the following directory structure for SSL certificates and private keys:
.
├── certs
│ ├── ca-chain.cert.pem
│ └── client.cert.pem
└── private
└── client.key.pem