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 compares the data layout the new server writes, recorded in the release's descriptor when the release was built, with the one the installed server writes, recorded beside the binaries when they were installed, and refuses a new server that cannot open the installed data. Neither server is run to find out: a node installed before 8.9.0 has no such record and its server is asked once (syngod info --json), and one that does not answer is taken to write the layout every server from 7.0.0 to 8.7.x wrote, the conservative reading. A new server that writes a newer layout raises the stamp of a store only when the store gains something that needs it, never by merely opening it, so a rollback after a failed update is decided from the stamp the stores actually carry (asked from the running server) against what the previous server opens, not from the layouts the two servers could write. 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.