Package com.iizix.server.tools


package com.iizix.server.tools
  • Class
    Description
    The flavour of a distribution (CC-FIX-DIST-NO-ICU, the owner's rulings of 2026-10-14 and 2026-10-23, DN-1 and DN-3): which applications the package carries, and so which installation a package may update.
    The keep list of a server update (CC-SERVER-RESTART-UPDATE-V5, after NetPhantom's keep.lst): which paths of the installation an update leaves alone while it mirrors the trees of the package.
    What the list says of a path.
    Installs an update package into a STOPPED server installation (CC-SERVER-RESTART-UPDATE-V5, the owner's rulings of 2026-10-11 17:36 and 18:06): a separate process, run by the supervisor after the server exited with 101, or by an operator through bin/iiziServer-update.
    The Java service wrapper of a Windows service (CC-SERVER-RESTART-UPDATE-V5, after NetPhantom's StartService with its defects fixed): installed by bin\ntservice\is.bat as the process SrvAny runs, it starts the server and supervises it with the exit-code contract of com.iizix.server.ServerExit as Windows reads it, the same as iiziServer.bat: 0, 8, 9: no relaunch, the wrapper exits with the server's code (SrvAny reports it); 100: relaunch at once; 101: the updater first (ServerUpdater, from this very jar: the updater copies it to a temporary file itself), honouring its exit code - 0 updated, 1 refused or rolled back (the previous version is relaunched and the log says so), 2 or more the rollback failed: the wrapper exits 1 and the installation needs the operator; anything else, a crash, and 1 as well: on Windows a JVM crash (hs_err), an uncaught OutOfMemoryError and a kill (TerminateProcess, Task Manager's End task) all end the process with 1, which on POSIX is the code of a fatal error (measured on JDK 8 to 26, CC-NP-UPGRADE-FOLLOWUP NP-F-1; CC-FIX-WRAPPER-RELAUNCH): a relaunch after 10000L ms, at most 5 times within 300000L ms, then the wrapper exits with the last code (SrvAny reports a clean stop whatever the code, so the Windows recovery never triggers: the back-off is here, D-7).
    Verifies an update package - the signed iiziServer-distribution-V.B.jar - right before the updater writes anything (CC-SERVER-RESTART-UPDATE-V5, survey section 6, the owner's ruling of 2026-10-11 18:41 point 5): every entry is signed, and by ONE chain (an entry altered after the signing fails to read, an entry added after it has no signer); the leaf's public key equals one of the AT MOST TWO keys the running build pins (old and current, current and new, or only current): a package signed by a key the build does not know is refused, and the administrator must download a newer build of the server, which knows the new certificate - no override; the chain validates (PKIX) to the trust store - the JDK's cacerts - at the date of the signature's timestamp (TSA), so that a package signed while the certificate was valid still verifies after its expiry; the package's build is newer than the installed one (a downgrade only with the explicit offline flag); the expected top-level directories are there and exactly one lib/com.iizix.standardserver-*.jar; no entry with .., an absolute path or a drive letter (zip slip); the package's flavour, read from its server jar (DistributionFlavour: customer, mindus or mls), is the installation's - a customer package never updates a Mindus installation, nor the reverse (CC-FIX-DIST-NO-ICU, the owner's ruling DN-1 of 2026-10-23); the installation's disk has room for the stage and the rollback copy.
    What the verification found.