cccb-website-team/kik-website
Watch
0
0
Fork
You've already forked kik-website
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Keep the shell server working over a deployment

Browse source 
The server logs to a file that was overwritten on every start, so an outage left no
trace. It is appended to now, and rotated when it grows past a megabyte.

The cleanup job restarts the server when nobody is connected and when the server does
not listen at all: it comes back by itself if it died, it takes over a server that was
left behind, and it picks up the programs that were just restored. A session that is
open keeps the port and the runtime, so the server is not restarted then.

A deployment does not restart the server. It runs in a session, and that session keeps
the port, so a server that starts during a deployment cannot bind it. The deployment
only writes the configuration; the cleanup job applies it.

The runtime of the installation is not protected any more. A program and the shell
that starts it have to use the same runtime DLL, or the program does not run at all,
so the login path now uses the one in /usr/bin, next to the user's own programs. What
is protected instead is that it is the one the package says it is: pacman checks the
files of msys2-runtime and the cleanup job puts the package back if it was changed.

Only keys may log in over SSH now, and Remote Desktop needs network level
authentication. Only the administrator may log in over it: the user of the website is
in no group that may.

Co-Authored-By: Claude Opus <noreply@anthropic.com>
This commit is contained in:
Zebreus 2026-10-27 02:46:45 +01:00
commit 5f9796cc11
1 changed files with 139 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

22
server/README.md
View file

@ -46,6 +46,13 @@ The copy has to be the *same* MSYS2 installation, not a second one: `C:\msys2\op
runtime. A separate installation does not work - two runtimes in one process tree corrupt each other's file
descriptors and pacman cannot even lock its database.
The runtime itself is not among the protected copies. A program and the shell that starts it have to use the same
runtime DLL, or the program does not run at all - a second copy of it in one process is refused. The login path
therefore uses the one in `/usr/bin`, next to the user's own programs, and the user may replace and upgrade it.
What is protected instead is that it is the one the package says it is: pacman checks the files of `msys2-runtime`,
and the cleanup job puts the package back if it was changed - before it starts the server, which runs as SYSTEM and
would otherwise run code the user of the website wrote.
`/etc/passwd` (the login shell and home directory) and `/etc/ssh` (the host keys and config) are read-only to the
user as well; everything else in the installation is theirs.
@ -59,6 +66,21 @@ Two scheduled tasks run as SYSTEM, both at startup, and the user cannot stop eit
re-applies the permissions, and puts the home directory, the shell configuration, the website's key and the four
texts back. Its second job is to best-effort revert other mockery and bring a fresh server to the expected state.
The cleanup job also restarts the server when nobody is connected, and when the server does not listen at all:
it comes back by itself if it died, it takes over a server that was left behind, and it picks up the programs that
were just restored. A session that is open keeps the port, so a server that is started now could not bind it, and
the job never disturbs a session.
The deployment does not restart the server. It runs in a session, and that session keeps the port, so a server that
starts during a deployment cannot bind it. The new configuration and the restored programs therefore take effect
at the next run of the cleanup job, which happens within half an hour.
The server logs to `C:\ProgramData\kik-restore\sshd.log`. The log is appended to, not overwritten, because it is
the only trace of what the server did: a server that is restarted would otherwise take the evidence of an outage
with it. It is rotated when it grows past a megabyte.
Only keys may log in over SSH. The box stands in the open internet and both of its accounts have a password.
The files that have to stay belong to the administrators, so the user cannot delete them, and they cannot change the
shell configuration or the key the website logs in with either. The shell reads its configuration from `~/.zsh`, so
the startup files the user could write in the home directory are ignored.