Release Notes

Installing

• Linux: bin/install-iiziServer.sh installs iiziServer from the signed distribution package as a systemd service under its own service account, after checking the package's signature, and never runs the service as root. It can also uninstall. Updates and going back use the updater, never the install script.
• Windows: iiziServer\bin\ntservice\is.bat installs the server as a Windows service on x64 and ARM64 with a code-signed service host, uses Windows' own sc.exe and regini.exe, works in an installation directory whose path holds spaces, refuses a service name that already exists, and stops the service before removing it.
• Launchers: bin/iiziServer.sh starts ServerAdmin only; further applications are defined in the configuration file or added on its command line. Every launcher runs the Java named by IIZI_JAVA when it is set, else the installation's own JDK, else java from the PATH.

Restart and update

• ServerAdmin's Dashboard has a Server section: Restart, Restart and update (the administrator's password asked again), Stop, the update packages of the server's updates directory, and the result of the last update. Before it restarts, updates or stops, the server tells every Browser page and iiziRun connected to it.
• An update package is verified before anything changes – its signature, a newer build, its content. The update is unpacked beside the installation; conf/, db/, logs/, updates/, jdk/ and bin/ntservice/ are kept, one rollback copy of the previous installation is kept, and a failed update is rolled back. bin/iiziServer-update.sh and iiziServer-update.bat update a server that is stopped.

Exit codes

bin/iiziServer.sh and iiziServer.bat run the server in a loop on these codes and end with 2 after a crash or a kill. The systemd unit iiziServer.service restarts the server on a failure. The Windows service runs it through IIZI's Java service wrapper, which restarts a crash after 10 seconds, at most five times in 300 seconds. A server started without a supervisor refuses a restart; iiziGo starts its development server again when it restarts, and that server refuses an update.

The server can write its errors and warnings, and on request its information lines, to the Windows Event Log (-ntEventLog on or info; is.bat's NTEVENTLOG [INFO]).

Applications and ports

• An application is defined in config.iiziServer, inside its environment: its jar, its aliases, a description, its groups and the port configurations it is served on. An alias opens the application as its ID does. An ID or an alias is unique among those of every environment: iiziGo marks a duplicate as an error, and a server does not start with one.
• -app <id>[:<alias>...] -appjar <file> on the command line adds a definition for that run, unless the file defines the application.
• Port configurations have names, and an application can be limited to named port configurations: on any other port it answers as an application that does not exist. An application with no list is served on every port.
• ServerAdmin's Applications page lists the applications of every environment and adds and edits their definitions; its Ports page names the port configurations. A change on the Applications, Ports, Environments, Settings or Domains page is written to config.iiziServer at once, and a deleted application leaves the server at once. iiziGo's Server Configuration editor has the same rows.

Mail senders

• ServerAdmin's Mail page lists every mail sender with its state and the mail waiting in it; adds, edits, renames and removes a sender; sends a test mail through any of them; and makes one the default. A sender's password is kept in the secrets store.
• The server's own mail goes through the sender marked as the default; with no sender marked, through the first.
• Mail queued while sending failed is sent at the next start and retried with a growing delay; mail that keeps failing is moved to the queue directory's failed folder, with one warning, instead of being lost. Queue directories that no sender uses any more are listed, and their mail can be moved to the default sender or deleted.

The secrets store

• Secret settings – passwords and keys of the server, its applications, their Push settings and the iiziRun build – can be kept in one secrets file per machine, readable by its owner only, instead of the configuration files. iizi-secrets.bat and iizi-secrets.sh in iiziServer/bin manage it. An application's Push Notification secrets are kept there only.
• A database password kept in the store as a password entry reaches the database connection. iizi-secrets set says what a key is for and takes --dbconf <directory> to name the database settings a password belongs to.

Logs

• Environment variables and -D values are no longer written to server.log or sent to clients; the request log masks password-like query members; the token of a password reset link reaches no log.
• A built server logs an expected failure in one line naming its cause – a client that closed its connection, an upload the client aborted, a refused sign-in, a failure of the file system, a database or a mail server, an unreachable network – and keeps stack traces for development mode and program errors.
• A WebSocket connection that ends by an idle time-out is logged at INFO as a broken link. The server sends its heartbeat on every tick of the interval (30 to 300 seconds, 45 by default); a link's idle time-out is twice the interval plus 15 seconds, at least 60 seconds; a link that answers three heartbeats in a row with nothing is closed and its session goes dormant, to be resumed by a reconnection.

Back to the IIZI 5.0 release notes