The SyngoDB service
Every node runs its own SyngoDB database service (ss-syngod). The product talks to it over the database protocol on the loopback address, and the service also serves a small web UI of its own. Neither is meant to be reachable from the network.
Listeners
The configuration file (cfg-ssrv.yaml in the data directory) names two listeners:
| Setting | Default | Purpose |
|---|---|---|
listenAddress | 127.0.0.1:41415 | The database protocol the Web/REST service and the workers use |
webUISettings.listenAddress | 127.0.0.1:41173 | The SyngoDB web UI and its login |
Installations created before version 8.3.1 shipped the web UI bound to all interfaces (0.0.0.0:41173), guarded by an allow list that admitted the loopback address only. From 8.3.1 the shipped configuration binds it to the loopback address, and the allow list guards the login endpoint as well as the rest of the API, so no source outside the list can obtain a token. A configuration file that already exists is not changed by an update (a repair installation does overwrite it); if you want the old bind back, set webUISettings.listenAddress yourself.
Reaching the web UI from another machine
Set webUISettings.listenAddress to an address of the node, add the administrator's address or network to webUISettings.ipAllowList, and restart ss-syngod. The allow list decides by the address of the direct peer; the X-Forwarded-For and X-Real-IP headers are honoured only from addresses listed in webUISettings.trustedProxies.
Transport security
Both listeners speak TLS 1.2 and 1.3 only, and on TLS 1.2 offer authenticated encryption cipher suites with forward secrecy only. The certificate is generated by the installer with the node's host name and addresses as subject alternative names; replace it with one of your own by pointing tlsCertFile and tlsKeyFile at it.
Updates
From 8.4.0 the SyngoDB service is updated together with the Web/REST and worker services, whether the server updates itself or the setup program runs: the updater stops it last, swaps its binary (keeping the previous one as a rollback slot), reconciles its service definition and starts it first, then runs the per node database tasks before the other services come back. Before anything is touched it asks both the installed and the new server (syngod info --json) for the data layout they write, and refuses a new server that cannot open the installed data. When the data layout changes, no automatic rollback is promised, because the new server may have migrated the store on its first start. See Keeping the server current.
Logs
The logConfig block names the log directory, rotation and retention, and from 8.3.1 the mode of the log files (logFileMode, an octal string). See Protected files on a node for what the mode means on an existing installation.