In many cases, you might want to encrypt traffic between your client and the server. To do that, you can specify that the server should use the HTTPS protocol rather than HTTP.

ssl_ca = ca-cert.pem
ssl_cert = server-cert.pem
ssl_key = server-key.pem

ssl_cert = server-cert.pem
ssl_key = server-key.pem

These steps will help you generate the SSL certificates using the 'openssl' tool.

The server can use a Certificate Authority to verify the signature of certificates, but it can also work with just a private key and certificate (without the CA certificate).

openssl genrsa 2048 > ca-key.pem

To generate a self-signed CA (root) certificate from the private key (make sure to fill in at least the "Common Name"), use the following command:

openssl req -new -x509 -nodes -days 365 -key ca-key.pem -out ca-cert.pem

The server uses the server certificate to secure communication with the client. To generate the certificate request and server private key (ensure that you fill in at least the "Common Name" and that it is different from the root certificate's common name), execute the following commands:

openssl req -newkey rsa:2048 -days 365 -nodes -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Once completed, you can verify that the key and certificate files were generated correctly by running:

openssl verify -CAfile ca-cert.pem server-cert.pem

When your SSL configuration is valid, the following features are available:

• You can connect to the multi-protocol port (when no listener type is specified) over HTTPS and run queries. Both the request and response will be SSL encrypted.
• You can connect to the dedicated https port with HTTP and run queries. The connection will be secured (attempting to connect to this port via plain HTTP will be rejected with a 400 error code).
• You can connect to the MySQL port with a MySQL client using a secured connection. The session will be secured. Note that the Linux mysql client tries to use SSL by default, so a typical connection to Manticore with a valid SSL configuration will most likely be secured. You can check this by running the SQL 'status' command after connecting.

If your SSL configuration is not valid for any reason (which the daemon detects by the fact that a secured connection cannot be established), apart from an invalid configuration there may be other reasons, such as the inability to load the appropriate SSL library at all. In this case, the following things will not work or will work in a non-secured manner:

• You cannot connect to the multi-protocol port with HTTPS. The connection will be dropped.
• You cannot connect to the dedicated https port. The HTTPS connections will be dropped
• Connection to the mysql port via a MySQL client will not support SSL securing. If the client requires SSL, the connection will fail. If SSL is not required, it will use plain MySQL or compressed connections.

• Binary API connections (such as connections from old clients or inter-daemons master-agent communication) are not secured.
• SSL for replication needs to be set up separately. However, since the SST stage of the replication is done through the binary API connection, it is not secured either.
• You can still use any external proxies (e.g., SSH tunneling) to secure your connections.

Read-only mode for a connection disables any table or global modifications. Therefore, queries like create, drop, various types of alter, attach, optimize, and data modification queries such as insert, replace, delete, update, and others will all be rejected. Changing daemon-wide settings using SET GLOBAL is also not possible in this mode.

However, you can still perform all search operations, generate snippets, and run CALL PQ queries. Additionally, you can modify local (connection-wide) settings.

To check if your current connection is read-only or not, execute the show variables like 'session_read_only' statement. A value of 1 indicates read-only, while 0 means not read-only (usual).

Typically, you define a separate listen directive in read-only mode by adding the suffix _readonly to it. However, you can also do this interactively for the current connection by executing the SET ro=1 statement via SQL.

If you're connected to a VIP socket, you can execute SET ro=0 (even if the socket you are connected to was defined as read-only in the config and not interactively). This will switch the connection to the usual (not read-only) mode with all modifications allowed.

For standard (non-VIP) connections, escaping read-only mode is only possible by reconnecting if it was set interactively, or by updating the configuration file and restarting the daemon.

searchd {
...
    query_log = /var/log/query.log
    query_log_format = sphinxql # default
...
}

Two query log formats are supported:

• sphinxql (default): Logs in SQL format. It also provides an easy way to replay logged queries.
• plain: Logs full-text queries in a simple text format. This format is recommended if most of your queries are primarily full-text or if you do not need to log non-full-text components, such as filtering by attributes, sorting, or grouping. Queries logged in the plain format cannot be replayed. Note that queries processed through Buddy are not logged in this mode.

To switch between the formats, you can use the searchd setting query_log_format.

query_log_format = sphinxql # default

/* Sun Apr 28 12:38:02.808 2024 conn 2 (127.0.0.1:53228) real 0.000 wall 0.000 found 0 */ SELECT * FROM test WHERE MATCH('test') OPTION ranker=proximity;
/* Sun Apr 28 12:38:05.585 2024 conn 2 (127.0.0.1:53228) real 0.001 wall 0.001 found 0 */ SELECT * FROM test WHERE MATCH('test') GROUP BY channel_id OPTION ranker=proximity;
/* Sun Apr 28 12:40:57.366 2024 conn 4 (127.0.0.1:53256) real 0.000 wall 0.000 found 0 */  /*{
    "table" : "test",
    "query":
    {
        "match":
        {
            "*" : "test"
        }
    },
    "_source": ["f"],
    "limit": 30
} */

query_log_format = plain

[query-date] real-time wall-time [match-mode/filters-count/sort-mode total-matches (offset,limit) @groupby-attr] [table-name] {perf-stats} query

[Fri Jun 29 21:17:58 2021] 0.004 sec [all/0/rel 35254 (0,20)] [lj] [ios=6 kb=111.1 ms=0.5] test
[Fri Jun 29 21:17:58 2021] 0.004 sec [all/0/rel 35254 (0,20)] [lj] [ios=6 kb=111.1 ms=0.5 cpums=0.3] test
[Sun Apr 28 15:09:38.712 2024] 0.000 sec 0.000 sec [ext2/0/ext 0 (0,20)] [test] test
[Sun Apr 28 15:09:44.974 2024] 0.000 sec 0.000 sec [ext2/0/ext 0 (0,20) @channel_id] [test] test
[Sun Apr 28 15:24:32.975 2024] 0.000 sec 0.000 sec [ext2/0/ext 0 (0,30)] [test] {     "table" : "test",     "query":     {         "match":         {             "*" : "test"         }     },     "_source": ["f"],     "limit": 30 }

searchd {
...
    query_log = /var/log/query.log
    query_log_min_msec  = 1000
    # query_log_min_msec  = 1s
...
}

searchd {
...
    query_log = /var/log/query.log
    query_log_mode = 666
...
}