SingleStore Tools Issues

ISSUE: Getting Prompted for User’s sudo Password

The SingleStore Toolbox may show the following prompt when asking for the management user’s sudo password:

The target user alice on host host-01.example.net does not have the privileges to perform this action.
Please enter your password to proceed with sudo.  (For details, see https://docs.singlestore.com/toolbox-redir/sudo-prompt).
sudo password for alice@host-01.example.net:

The prompt appears when the management user (alice in this example) does not have sufficient privileges to perform the action requested on the host (host-01.example.net in this case). To try performing the action using sudo, enter alice’s sudo password at the prompt.

The following are some specific cases where this may apply:

• sdb-deploy install requires root privileges to perform package management.

• sdb-admin create-node requires write access to the node install directory.

• sdb-admin list-nodes requires read access to the memsqlctl state file.

usermod -a -G memsql alice

sdb-toolbox-config unregister-host --host host-01.example.net

Toolbox will perform the following actions:
  · Unregister host host-01.example.net

Would you like to continue? [y/N]: y
✓ Successfully unregistered 1 host
Operation completed successfully

sdb-toolbox-config register-host --host host-01.example.net --ssh bob@host-01.example.net

Toolbox is about to register the following host:
  · Host: host-01.example.net
  · Localhost: false

Would you like to continue? [y/N]: y
+---------------------+------------+-------------------------+---------------+
|   Host              | Local Host | SSH address             | Identity File |
+---------------------+------------+-------------------------+---------------+
| host-01.example.net | No         | bob@host-01.example.net |               |
+---------------------+------------+-------------------------+---------------+

ISSUE: We were unable to check whether this is an official version

A message similar to the following may be shown by sdb-report check:

✘ versionHashes ................................. [FAIL]
FAIL Get https://release.memsql.com/production/index/memsqlserver/6.7.14-fa416b0a53.json: dial tcp: lookup release.memsql.com on 8.8.4.4:53: dial udp 8.8.4.4:53: connect: network is unreachable
WARN MemSQL version 6.7.14 (commit hash fa416b0a536adcfcf95d0607be2d6086a0d58796) is present on all nodes
We were unable to check whether this is an official version
For more details, see https://docs.singlestore.com/memsql-report-redir/check-version

This check in sdb-report verifies two properties: 1. Every node in the cluster is using the same version of SingleStore. 2. That version of SingleStore was officially released publicly.

To do so, it connects to the internet and looks for version information in the SingleStore package index. If sdb-report cannot connect to the package index, it shows this message.

sdb-report check --only versionHashes --report-path /path/to/report.tar.gz\

If you expect to have internet access, this may be an intermittent network issue. Try running sdb-report check again. To perform only this check, use the following command, replacing /path/to/report.tar.gz with the path to your report:

sdb-report check --only versionHashes --report-path /path/to/report.tar.gz

If your machine is behind a firewall or inside an air-gapped environment, use a machine outside that environment to read the package information located at the URL in the message (https://release.memsql.com/production/index/memsqlserver/6.7.14-fa416b0a53.json in this example).

This is an example of official release metadata (with the "packages" value removed for size):

curl https://release.memsql.com/production/index/memsqlserver/6.7.14-fa416b0a53.json

{
  "releaseID": "722ce44d-6f95-4855-b093-9802a9ae7cc9",
  "version": "6.7.14",
  "commit": "fa416b0a536adcfcf95d0607be2d6086a0d58796",
  "packages": { ... }
}

This is an example of an unofficial hash (with irrelevant pieces removed for size):

curl https://release.memsql.com/production/index/memsqlserver/6.7.14-abcdef1234.json

<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>freya/production/index/memsqlserver/6.7.14-abcdef1234.json</Key>...</Error>

ISSUE: Failed to add user to the memsql group.

✘ Failed to add alice to the memsql group. See https://docs.singlestore.com/memsql-deploy-redir/memsql-group for more details.

This message appears during sdb-deploy install if it fails to add the management user to the memsql group.

During installation, the singlestoredb-server Debian and RPM packages create a memsql Linux system user and memsql Linux system group if they don’t already exist. These used to enforce filesystem permissions on node data and configuration.

The memsql user is allowed to create and delete nodes, start and stop nodes, and update node configuration. It is automatically part of the memsql group.

Users in the memsql group are allowed to list nodes, read node configuration, and run SQL statements on nodes.

When using sdb-deploy to install singlestoredb-server, it will automatically try to add the management user to the memsql group on each host. This allows the rest of the SingleStore Tools to manage SingleStore nodes without requiring elevated privileges. If this fails, the other tools (such as sdb-admin and sdb-report) may prompt for the management user’s sudo password when trying to run commands.

To avoid needing a sudo password for every command, add your management user to the memsql group on all hosts. For example, if the management user is alice, run the following command on each host:

usermod -a -G memsql alice

ISSUE: memsqlctl is configured to require that users be in the memsql group for read access

memsqlctl is configured to require that users be in the 'memsql' group for read access. Please rerun the command as a user in this group or the root user.

This message appears during any memsqlctl command if the current user is not in the configured management group.

The memsqlctl config file can be configured to restrict access to a single Linux user and that user’s primary group. When using singlestoredb-server Debian and RPM packages, this is set to memsql, which is the system user created by the package to run SingleStore.

There are multiple options for resolving this issue:

• Run the command again as the configured user (memsql in this example).

• Run the command again as root or with sudo.

• Change the management user by editing the memsqlctl config file and changing the owner of all SingleStore-related files and directories.