CoreNodeSQL.Client 1.0.0.200

CoreNodeSQL

CoreNodeSQL is a networked SQLite server with a MySQL-like CLI and a .NET client library. It exposes SQLite over TCP for multi-client access with authentication, grants, and multi-database management. You can also import existing SQLite database files into the server.

Components:

• CoreNodeSQL.Server: .NET Worker Service (TCP server)
• CoreNodeSQL.CLI: interactive SQL shell
• CoreNodeSQL.Client: .NET client library (NuGet)
• CoreNodeSQL.UI: cross-platform desktop GUI
• CoreNodeSQL.Jdbc: JDBC driver for Java tooling (for example DBeaver, Rider DB view)
• CoreNodeSQL.C: native C driver
• CoreNodeSQL.C++: native C++ driver
• CoreNodeSQL.PHP: pure PHP driver
• CoreNodeSQL.Python: pure Python driver

Default port: 5433

Platform support:

• All CoreNodeSQL components are cross-platform and run on Windows, Linux, and macOS.
• Distributed CoreNodeSQL.Server, CoreNodeSQL.CLI, and CoreNodeSQL.UI binaries are self-contained and do not require a separate .NET installation on the target platform.
• CoreNodeSQL.Client is available as a NuGet package for .NET applications.
• CoreNodeSQL.Jdbc runs wherever a compatible Java runtime is available.
• CoreNodeSQL.C runs with a C toolchain (optional OpenSSL for TLS).
• CoreNodeSQL.C++ is intended for native integrations.
• CoreNodeSQL.PHP runs wherever PHP 7.4+ is available.
• CoreNodeSQL.Python runs wherever Python 3.8+ is available.

Server minimum OS requirements:

• Linux (x64/arm64): glibc >= 2.35 and OpenSSL 3 (libcrypto.so.3) available.
• Linux distro examples: Ubuntu 22.04+, Debian 12+, Raspberry Pi OS Bookworm+.
• Windows (x64): Windows 10/11 or Windows Server 2019+.

Production notes

• Use TLS or a private network/VPN. The protocol supports TLS but can run without it.
• On first start a default admin user is created with password admin.
• Change the admin password immediately after first start.
• Use least-privilege accounts for applications (readonly/readwrite).

Security hardening (recommended)

• Enable TLS and prefer a trusted certificate (set Tls.Enabled=true and CertificatePath).
• If you must use self-signed certs, pin the thumbprint on clients (CertificateThumbprint) and avoid TrustServerCertificate.
• Bind to a private interface or localhost where possible and restrict the port with a firewall.
• Create non-admin application users and grant only required permissions.
• Restrict file permissions for data/ and certs/ so only the service account can read them.

Server quick start

# Linux/macOS
./CoreNodeSQL.Server

# Windows (PowerShell/CMD)
CoreNodeSQL.Server.exe

These commands run the server in the foreground and are not persistent after logout/reboot. For persistent operation:

• Linux: use the shipped tar.gz package and install-linux.sh (see Linux service install/update below).
• Windows: use the CoreNodeSQL Server MSI to install/start the Windows service.

On first start, the server creates:

• data/_admin.db with users, grants, and databases
• a default database
• an admin user with password admin

Configuration

Server settings are persisted automatically in the server data directory. There is no separate runtime config file anymore. On first start, defaults are used and then persisted. Configure runtime settings in CoreNodeSQL.UI -> Settings -> Server. Bootstrap overrides are only used while no persisted settings exist yet:

• Linux service install/update: persisted settings are preferred; package installation is done via install-linux.sh
• Windows service: values written by the installer
• Windows MSI default paths: DataDirectory=<InstallLocation>\\data, backups in <InstallLocation>\\data\\backups After the first persisted startup, server settings are loaded from the admin database and bootstrap values are ignored.

TLS behavior:

• If CertificatePath points to a valid PFX, it is used.
• If missing and GenerateSelfSignedIfMissing is true, a self-signed PFX is created at SelfSignedPath (default certs/corenodesql-selfsigned.pfx).
• If the self-signed cert is close to expiration, it is automatically renewed.
• If Tls.Enabled=true and AllowUnencryptedClients=true (default), the TCP listener runs in mixed mode on the same port: TLS clients and plaintext clients are both accepted.
• If Tls.Enabled=true and AllowUnencryptedClients=false, TLS is required for all TCP clients.

Realtime behavior:

• Realtime.Enabled=true enables the WebSocket endpoint for server events/metrics.
• Realtime.Port=0 means "main TCP port + 1" (for example 5433 → 5434).
• Set Realtime.Port to a fixed value (for example 6100) to run realtime on an explicit port.
• Realtime.Path defaults to /ws/realtime.
• If TLS is enabled, realtime uses wss://; otherwise ws://.
• Realtime authentication currently requires an admin user.
• Event types:
  • metrics.updated for server/process/disk/database-size metrics.
  • schema.changed for schema mutations (UI reloads schema snapshot after this event).

Security audit behavior:

• SecurityAudit.Enabled=true persists brute-force/security login events for compliance/auditing.
• SecurityAudit.DatabasePath configures a dedicated SQLite file for audit events.
  • Relative path: resolved under DataDirectory.
  • Absolute path: used as-is.
• SecurityAudit.RetentionDays defines automatic retention/pruning (1..3650, default 90).
• SecurityAudit.MaxQueryRows caps one history query (10..10000, default 1000).
• Persisted event types include:
  • security.auth_failed
  • security.login_blocked
  • security.ip_blocked
  • security.ip_unblocked

Initial admin password:

• Default for first admin creation is admin.

SQLite durability (Synchronous):

• NORMAL (default): faster writes, but the last transactions can be lost on power loss or OS crash.
• FULL: stronger durability, slower writes.
• EXTRA: maximum durability, slowest writes.
• OFF: fastest, no durability guarantees.

SQLite journaling mode:

• Unencrypted databases use journal_mode=WAL.
• Encrypted databases use journal_mode=DELETE by default.
• Set EnableWalForEncryptedDatabases=true if your SQLite build fully supports WAL with encryption.

Backup directory (BackupDirectory):

• Default is backups (relative to DataDirectory).
• Backup/restore/list/purge commands operate inside this directory.
• Relative backup paths are resolved under this directory.
• SHOW BACKUPS returns paths relative to this directory.
• BACKUP DATABASE <db> without TO <path> creates a timestamped backup inside this directory.
• Backups are blocked if the source database is encrypted but currently unreadable (missing/wrong runtime key).
• Each backup gets a sidecar metadata file with stable DatabaseId binding.

System backup snapshots:

• System snapshots are stored under BackupDirectory/systembackup by default (or a custom subfolder set in the UI/API).
• A snapshot is a directory that contains backups of server system databases:
  • _admin.db (users, grants, metadata, schedules)
  • security-audit.db (if configured as a separate file)
• Restore of a system snapshot replaces those system databases on disk.
• Restore should be treated as a high-impact admin operation (users/permissions/audit history can change immediately).

Drop behavior (DeleteBackupsOnDrop):

• Default false: DROP DATABASE keeps backups unless explicitly requested.
• If set to true, dropping a database also deletes backups bound to that database id.
• CLI override: DROP DATABASE <db> WITH BACKUPS.

Backup scheduler:

• EnableBackupScheduler enables/disables background backup/prune execution (default true).
• BackupSchedulerPollSeconds controls how often schedules are checked (default 30 seconds).
• Schedules are persisted in the admin metadata database and executed in server local time.
• Database backup schedules and prune schedules behave as before.
• System backup schedules:
  • create a new system snapshot at the scheduled time.
  • then apply retention cleanup for that schedule (retentionDays) in the same system-backup subfolder.
  • for new/enabled schedules, first run occurs at the next due slot (not immediately at creation).

SQLite encryption (CoreNodeSQL SQLite build):

• The server initializes CoreNodeSQL.Native at startup and uses your custom SQLite library.
• No keys configured means normal unencrypted SQLite behavior.
• Keys are handled runtime-only via SQLite PRAGMA commands (key/rekey/hexkey/hexrekey).
• Existing unencrypted databases can be encrypted server-side via sqlite3_encrypt_database(...).
• Existing encrypted databases can be decrypted server-side via sqlite3_decrypt_database(...).
• The server stores known keys only in memory for the process lifetime.
• After restart, keys must be set again before accessing encrypted databases.
• Scheduled backups require a runtime-known key for the target database; if no key is known, no backup is executed and the schedule run is recorded with an error.
• On brand-new empty databases, PRAGMA key='...' is materialized immediately (probe write), so encryption becomes effective before first normal table reads.
• The server uses a persistent write connection per database engine to reduce connection churn for encrypted workloads.

Encrypted journal mode (EnableWalForEncryptedDatabases):

• true (default): encrypted databases use journal_mode=WAL (faster on write-heavy workloads if your SQLite build supports WAL+encryption correctly).
• false: encrypted databases use journal_mode=DELETE (safer fallback).
• Unencrypted databases continue to use journal_mode=WAL.
• If you change key state (PRAGMA key / clear key), the engine re-initializes connection state and journal mode.

SQL encryption commands:

• The server forwards SQLite PRAGMA commands, so you can use:
  • PRAGMA key = '...';
  • PRAGMA rekey = '...';
  • PRAGMA hexkey = '...';
  • PRAGMA hexrekey = '...';
• To clear the runtime key for the current database context, pass an empty key:
  • PRAGMA key = '';
  • PRAGMA rekey = '';
  • PRAGMA hexkey = '';
  • PRAGMA hexrekey = '';
• Clearing a runtime key removes only the in-memory key cache. It does not decrypt or rewrite the database file.
• After clearing the runtime key, encrypted database access fails until a valid key is set again.
• Existing DB encryption command (admin): ENCRYPT DATABASE <db> KEY <secret> or ENCRYPT DATABASE <db> HEXKEY <hex-secret>.
• Existing DB decryption command (admin): DECRYPT DATABASE <db> KEY <secret> or DECRYPT DATABASE <db> HEXKEY <hex-secret>.
• If you change keys at runtime via PRAGMA, set the key again after a server restart.
• PRAGMA key/PRAGMA hexkey should be executed before the first read access on a new connection to an encrypted DB.

When to use PRAGMA key vs. ENCRYPT DATABASE:

• Use PRAGMA key='...' for:
  • opening an already encrypted database for the current session/connection
  • initializing encryption on a brand-new empty database before first normal reads/writes
• Use ENCRYPT DATABASE <db> KEY ... for:
  • converting an existing plaintext database (especially with existing tables/data) to encrypted on disk
• Do not use PRAGMA key='...' as a replacement for ENCRYPT DATABASE on an existing populated plaintext DB.
• Always switch to the intended database first (USE <db>;) before running PRAGMA key, otherwise you set the runtime key on the wrong DB context.

Encryption troubleshooting:

• On startup, check which native library was actually loaded (log line: CoreNodeSQL.Native SQLite provider initialized (library=...)).
• ENCRYPT DATABASE ... performs strict verification: DB must be unreadable without key and readable with key.
• DECRYPT DATABASE ... performs strict verification: DB must be readable without key after decryption.
• If native sqlite3_encrypt_database(...) does not encrypt in your environment, the server automatically tries PRAGMA rekey fallbacks.
• For server-side file encryption, WAL is quiesced first (wal_checkpoint(TRUNCATE), journal_mode=DELETE), then -wal/-shm artifacts are cleaned up.
• If you still get Encryption verification failed: encrypted file header marker is missing, the loaded native build is not effectively encrypting for this runtime/build.
• On single-file deployments, native libs are extracted under a runtime cache path (for example /root/.net/CoreNodeSQL.Server/...); verify that exact file.
• SHOW TABLES reads schema metadata (sqlite_master) only; use real table reads and/or SHOW DATABASES encryption state to verify practical data access behavior.

Performance notes for encrypted databases:

• If EnableWalForEncryptedDatabases=false, write-heavy tests can be significantly slower due to DELETE journaling.
• If your SQLite build supports encrypted WAL safely, set EnableWalForEncryptedDatabases=true.
• For bulk insert/update test scripts, wrap many statements in explicit transactions to reduce fsync overhead.

Quick checks on Linux:

journalctl -u CoreNodeSQL -n 200 --no-pager
nm -D /path/to/libcorenodesql.so | grep -E 'sqlite3_(encrypt|decrypt)_database'
ldd /path/to/libcorenodesql.so

Known good sequence:

# 1) Encrypt an existing unencrypted database
ENCRYPT DATABASE Test KEY test123;

# 2) Restart server
systemctl restart CoreNodeSQL

# 3) Reconnect and verify access without key fails
USE Test;
SHOW TABLES;

# 4) Set runtime key for this session, then read succeeds
PRAGMA key='test123';
SHOW TABLES;
SELECT * FROM user;

# 5) Clear runtime key again; access should fail until key is set again
PRAGMA key='';
SHOW TABLES;

Expected:

1. Step 1 returns success.
2. Step 3 fails with an auth/encryption-related SQLite error (for example authorization denied).
3. Step 4 succeeds and returns tables/data.
4. Step 5 fails again with an auth/encryption-related SQLite error.

Server updates

CoreNodeSQL can install server updates directly from the desktop UI on supported Windows and Linux installations.

In the UI:

• open Updates
• optionally set or review:
  • Updates enabled
  • Channel
  • Feed URL
• use:
  • Status
  • Check for updates
  • Install update

Update behavior:

• Updates are only installable when the target server build is still within the included free-update period of the current license.
• If the running server build is already newer than the licensed update entitlement, the server falls back to Community mode.
• During installation the server service is restarted and active client sessions are disconnected.
• The Updates page also checks for newer desktop UI packages and can open the download for a newer UI version when one is available.

Requirements:

• admin privileges on the server connection
• a reachable update feed
• the local update helper installed together with the server package

Supported update packages:

• Windows x64: MSI
• Linux x64: tar.gz
• Linux arm64: tar.gz

Desktop GUI (CoreNodeSQL.UI)

Run the binary directly:

# Linux/macOS
./CoreNodeSQL.UI

# Windows
CoreNodeSQL.UI.exe

Packaged desktop UI distributions are also available:

• macOS: .app bundle and .dmg package
• Linux: .deb, Flatpak, and AppImage packages

What you can do in the GUI:

• Manage saved server connections (host/port/realtime-port/user/password, TLS options, connection tests).
• In Settings -> Server, manage persisted server parameters (network, limits, backup/realtime, TLS, security audit).
• In Settings -> Server, generate a self-signed TLS certificate or import a custom PFX certificate.
• In Updates, inspect entitlement-aware server update status, check the signed update feed, and start server updates.
• In Updates, the desktop UI also checks its own signed update feed and can open the download for a newer UI package.
• Manage brute-force guard settings and monitor persisted + live failed-login/block events, including immediate IP unblock actions.
• Browse databases, tables, columns, and indexes in the navigation tree.
• On each database node in the tree: set/clear runtime encryption key, encrypt plaintext databases, and decrypt encrypted databases.
• Create/update/delete tables and edit table data.
• Execute SQL in the SQL workspace with editor, line numbers, output, and result grid.
• Create/list/restore/delete backups and purge backups older than X days in Backup/Restore.
• In Backup/Restore, the "current database" filter uses DatabaseId matching (UUID-safe), not just database name.
• Create/list/enable/disable/delete backup and prune schedules in Scheduler.
• In Settings -> System Backup/Restore, create/list/restore/delete system snapshots for _admin.db + security-audit.db.
• In Settings -> System Backup/Restore, create/list/enable/disable/delete system backup schedules with retention (days).
• Manage users and grants, including admin password changes.
• Work with dark/light appearance settings and connection profiles.

Landing overview notes:

• Server stats and database size overview on the landing page require admin privileges.
• Stats can be refreshed manually from the landing page.
• The UI can also use the realtime endpoint for live metrics and security events.
• If realtime is unavailable, the UI falls back to periodic polling.

NuGet client (CoreNodeSQL.Client)

Install:

dotnet add package CoreNodeSQL.Client

Supported target frameworks:

• net8.0
• net10.0

Compatibility notes:

• Intended for projects targeting .NET 8 or newer.
• .NET Framework, netstandard, and older .NET targets are not supported by the NuGet package.

Quick start:

await using var conn = new CoreNodeSQLConnection(
    host: "127.0.0.1",
    port: 5433,
    database: "default",
    username: "admin",
    password: "YOUR_ADMIN_PASSWORD");
await conn.OpenAsync();

Connection string example:

await using var conn = CoreNodeSQLConnection.FromConnectionString(
    "Host=127.0.0.1;Port=5433;Database=appdb;Username=appuser;Password=secret;Tls=true");
await conn.OpenAsync();

Useful connection-string options:

• Tls=true or Encrypt=true
• TrustServerCertificate=true (accept any server cert)
• CertificateThumbprint=... (trust specific cert)

Microsoft.Data.Sqlite compatibility layer

CoreNodeSQL.Client provides a compatibility layer in the Microsoft.Data.Sqlite namespace. This lets you switch existing ADO.NET-style code to CoreNodeSQL with minimal code changes.

How to migrate existing code:

• Remove the explicit Microsoft.Data.Sqlite package reference from your project.
• Add the CoreNodeSQL.Client NuGet package instead.
• Keep your existing using Microsoft.Data.Sqlite; statements.
• Keep your existing SqliteConnection, SqliteCommand, SqliteDataReader, parameter, and transaction code.
• Change only the connection string when moving from local SQLite to a remote CoreNodeSQL server.

Connection string behavior:

• Local SQLite: Data Source=./data/app.db
• Remote CoreNodeSQL server: Host=127.0.0.1;Port=5433;Database=appdb;Username=appuser;Password=secret;Tls=true

What works without major code changes:

• SqliteConnection, SqliteCommand, SqliteTransaction, and SqliteDataReader
• Open, OpenAsync, Close, BeginTransaction
• ExecuteNonQuery, ExecuteScalar, ExecuteReader
• Parameters including AddWithValue(...)
• Existing using Microsoft.Data.Sqlite; source files

Compatibility notes:

• Standard ADO.NET operations are supported for both local SQLite and remote CoreNodeSQL.
• The provider auto-detects local SQLite vs remote CoreNodeSQL from the connection string.
• Provider-specific advanced SQLite features such as extensions, backup API, custom functions, and virtual tables are not implemented in the compatibility layer.
• CommandType.Text is supported; provider-specific edge-case parity is not the goal.

Migration example:

using Microsoft.Data.Sqlite;

// Existing local SQLite code
await using var local = new SqliteConnection("Data Source=./data/app.db");
await local.OpenAsync();

// Same API, switched to remote CoreNodeSQL by changing only the connection string
await using var remote = new SqliteConnection(
    "Host=127.0.0.1;Port=5433;Database=appdb;Username=appuser;Password=secret;Tls=true");
await remote.OpenAsync();

If you only target CoreNodeSQL servers and do not need local SQLite compatibility, you can also use CoreNodeSQLConnection directly.

Python driver (CoreNodeSQL.Python)

Further documentation for the Python driver is included in the README in the CoreNodeSQL.Python directory.

Quick start:

from corenodesql import CoreNodeSQLConnection

conn = CoreNodeSQLConnection("127.0.0.1", 5433, "default", "admin", "YOUR_ADMIN_PASSWORD")
conn.open()
count = conn.executeScalar("SELECT COUNT(*) FROM sqlite_master")
print(count)
conn.close()

PHP driver (CoreNodeSQL.PHP)

Further documentation for the PHP driver is included in the README in the CoreNodeSQL.PHP directory.

Quick start:

<?php

require_once 'CoreNodeSQL.php';

use CoreNodeSQL\CoreNodeSQLConnection;

$conn = new CoreNodeSQLConnection('127.0.0.1', 5433, 'default', 'admin', 'YOUR_ADMIN_PASSWORD');
$conn->open();
$count = $conn->executeScalar('SELECT COUNT(*) FROM sqlite_master');
var_dump($count);
$conn->close();

C driver (CoreNodeSQL.C)

Further documentation for the C driver is included in the README in the CoreNodeSQL.C directory.

C++ driver (CoreNodeSQL.C++)

Further documentation for the C++ driver is included in the README in the CoreNodeSQL.C++ directory.

JDBC driver (CoreNodeSQL.Jdbc)

Further documentation for the JDBC driver is included in the README in the CoreNodeSQL.Jdbc directory.

The JDBC driver lets you connect from tools like DBeaver or the Rider database view.

JDBC URL:

jdbc:corenodesql://127.0.0.1:5433/default?user=admin&password=YOUR_ADMIN_PASSWORD

TLS options:

• tls=true to enable TLS
• trustServerCertificate=true to accept any server certificate (use for self-signed)
• certificateThumbprint=... to pin a specific server certificate

Encryption options (for encrypted databases):

• key=... to auto-run PRAGMA key='...' right after JDBC connect
• hexkey=... to auto-run PRAGMA hexkey='...' right after JDBC connect
• key and hexkey are mutually exclusive

Example with TLS:

jdbc:corenodesql://127.0.0.1:5433/default?user=admin&password=YOUR_ADMIN_PASSWORD&tls=true&trustServerCertificate=true

Example with encrypted database key:

jdbc:corenodesql://127.0.0.1:5433/Test?user=admin&password=YOUR_ADMIN_PASSWORD&key=TopSecret

Manual alternative:

• You can also execute PRAGMA key='...' (or PRAGMA hexkey='...') explicitly after opening the JDBC connection.
• The key should be set before the first read access on the encrypted database.

DBeaver/Rider setup:

• Add a new driver (Generic/JDBC) and select the CoreNodeSQL JDBC jar.
• Driver class: com.corenodesql.jdbc.CoreNodeSQLDriver
• Use the JDBC URL format shown above.

CLI usage

CoreNodeSQL.CLI --host 127.0.0.1 --port 5433 --user admin --password YOUR_ADMIN_PASSWORD --database default --tls

Connection string mode:

# Local SQLite
CoreNodeSQL.CLI --conn "Data Source=./data/app.db"

# Remote CoreNodeSQL server
CoreNodeSQL.CLI --conn "Host=127.0.0.1;Port=5433;Database=default;Username=admin;Password=YOUR_ADMIN_PASSWORD;Tls=true"

Within the CLI you can use:

• HELP for the full command list
• ADMINPASS to change the admin password
• SHOW DATABASES, USE <db>, SHOW TABLES, etc.
• PRAGMA key = '' (or PRAGMA hexkey = '') to clear the runtime key for the current DB context
• ADD DATABASE [IF NOT EXISTS] <path> [AS <name>] to import a SQLite file
• BACKUP DATABASE <db> [TO <path>] to create a server-side backup file
• ENCRYPT DATABASE <db> KEY <secret> or ENCRYPT DATABASE <db> HEXKEY <hex> to encrypt an existing unencrypted DB
• DECRYPT DATABASE <db> KEY <secret> or DECRYPT DATABASE <db> HEXKEY <hex> to decrypt an existing encrypted DB
• SHOW BACKUPS to list available backups
• PURGE BACKUPS OLDER THAN <days> to delete old backups
• RESTORE DATABASE <db> FROM <backup> [REPLACE] [FORCE] to restore from a backup
• SHOW BACKUP SCHEDULES / SHOW PRUNE SCHEDULES to list scheduler entries
• CREATE BACKUP SCHEDULE ... and CREATE PRUNE SCHEDULE ... to add automatic jobs
• ALTER ... SCHEDULE <id> ENABLE|DISABLE and DROP ... SCHEDULE <id> to manage jobs

Example (path is server-side):

ADD DATABASE /srv/corenodesql/imports/app.db AS appdb;

Backups (server-side paths, relative to BackupDirectory):

BACKUP DATABASE appdb TO appdb-2026-02-13.db;
BACKUP DATABASE appdb;
ENCRYPT DATABASE appdb KEY MyNewSecret;
DECRYPT DATABASE appdb KEY MyNewSecret;
SHOW BACKUPS;
PURGE BACKUPS OLDER THAN 30;
RESTORE DATABASE appdb FROM appdb-2026-02-13.db REPLACE;
DROP DATABASE appdb WITH BACKUPS;

If an encrypted database is currently locked (runtime key missing/wrong), backup is rejected:

corenodesql[default]> BACKUP DATABASE appdb;
Error: Backup blocked: database 'appdb' is not readable with the current encryption key state. Load the correct key (PRAGMA key/hexkey) before creating a backup.

Fix (load the key first, then backup):

USE appdb;
PRAGMA key='MyNewSecret';
-- or: PRAGMA hexkey='...';
BACKUP DATABASE appdb;

Schedules:

CREATE BACKUP SCHEDULE FOR appdb HOURLY AT 0 ENABLED;
CREATE BACKUP SCHEDULE FOR appdb DAILY AT 00:00 ENABLED;
CREATE PRUNE SCHEDULE FOR appdb DAILY AT 21:00 RETENTION 5 DAYS ENABLED;
SHOW BACKUP SCHEDULES;
SHOW PRUNE SCHEDULES;
ALTER BACKUP SCHEDULE 1 DISABLE;
DROP PRUNE SCHEDULE 2;

Restore notes:

• REPLACE will terminate active sessions for the target database.
• For default, the database file is replaced in place.
• Restore verifies backup DatabaseId metadata against the target database id.
• If metadata is missing/mismatched, restore is blocked unless FORCE is provided (admin-only override).

Linux service install/update

The Linux tar.gz package includes:

• CoreNodeSQL.Server
• CoreNodeSQL.UpdateAgent
• CoreNodeSQL.UpdateHost
• install-linux.sh
• Dockerfile
• docker-entrypoint.sh
• README.CONTAINER.md

Recommended Linux installation/update flow:

tar -xzf CoreNodeSQL.Server.linux-x64.tar.gz -C /tmp/corenodesql
cd /tmp/corenodesql
sudo bash install-linux.sh --install-dir /opt/corenodesql

This script installs or updates:

• the server binaries
• the local update agent
• the local update host
• the systemd services

The extracted Linux package can also be used directly as a Docker build context. See the included README.CONTAINER.md inside the tarball or the Docker section below.

Installed services:

• CoreNodeSQL.service
• corenodesql-update-agent.service

Useful commands:

sudo systemctl status CoreNodeSQL.service --no-pager
sudo systemctl status corenodesql-update-agent.service --no-pager
sudo systemctl restart CoreNodeSQL.service
sudo systemctl restart corenodesql-update-agent.service

Legacy note:

• The server binary still contains Linux service helper commands such as --install, --update, --uninstall, --status, --start, --restart, and --stop.
• These are kept for compatibility.
• For customer installations, the packaged install-linux.sh workflow is now the recommended path.

Docker (CoreNodeSQL.Server)

The Linux tar.gz package includes the Dockerfile together with docker-entrypoint.sh and README.CONTAINER.md.

Build from an extracted Linux package:

tar -xzf CoreNodeSQL.Server.linux-x64.tar.gz -C /tmp/corenodesql
cd /tmp/corenodesql
docker build -t corenodesql/server:linux-x64 .

Run the container:

docker run -d --name corenodesql \
  -p 5433:5433 \
  -p 5434:5434 \
  -v corenodesql-data:/var/lib/corenodesql/data \
  -v corenodesql-certs:/var/lib/corenodesql/certs \
  corenodesql/server:linux-x64

Notes:

• Persistent server data lives under /var/lib/corenodesql/data.
• Persistent certificates live under /var/lib/corenodesql/certs.
• The packaged Linux tarball contains a README.CONTAINER.md with the same container-specific steps.

License and Notices

• EULA: https://www.corenodesql.com/eula.html
• Third-party notices: THIRD_PARTY_NOTICES.txt