Adjust server readme

server/README.md

@@ -16,48 +16,36 @@ We only keep the basic user journey working.
 
 ## What we keep working
 
+Anything that breaks the following user journey is not acceptable:
+
+- The user can connect with the SSH key as `root`.
 - The prompt: `root@khaos-im-kiez:~#`, which `~/.zshrc` sets.
 - The home directory the user ends up in: `/home/root`. They cannot change where it is, and they cannot delete it.
 - `cat README`, `cat README.en`, `cat CODE_OF_CONDUCT` and `cat CODE_OF_CONDUCT.en` always work. The four files
   are always there and always regular text files.
-- The website can log in: the key it uses is in `~/.ssh/authorized_keys`. That key gets access to the `root` user
-  only, never to the Administrator account.
 
-Modifying the four files is allowed; the next cleanup undoes it. Deleting them is not possible: the home directory
-and the files that have to stay in it belong to the administrators, so the user cannot remove them. The files the
-user creates are their own; they may change and delete them.
+So in summary running `ssh root@nowhere.wirs.ing cat README` must always succeed and display the contents of the file.
 
-The user may add keys of their own to `authorized_keys`; they stay. The key of the website is put back, so that the
-site keeps working.
+Anything thats not specified above (like the content of README for example) is NOT part of the user journey.
 
 ## What we do not keep working
 
-Everything else. If the user breaks the shell, the packages, the disk or the connection, we fix that by hand or
-throw the box away. The cleanup does not try.
+As long as the user story above does not break, we do not guarantee the functionality of anything else on the server. However the cleanup task should still try to best-effort restore everything to a working condition.
 
-Two things that the user cannot break: the entry in `/etc/passwd` with the home directory and the shell, because
-`/etc` is read-only for them, and the host keys in `/etc/ssh`, which the website pins. The sshd runs as SYSTEM, so
-the user cannot restart it with a different key either.
+## The cleanup task
 
-## The cleanup
+The scheduled task `KiK restore shell files` runs every 30 minutes and at every startup, as SYSTEM. The user cannot stop it. Cleanup has two jobs:
 
-The scheduled task `KiK restore shell files` runs every 30 minutes and at every startup, as SYSTEM. The user cannot
-stop it: the task, its script and the copies it restores from are readable and writable only by SYSTEM and the
-administrators. Neither the setup nor the cleanup ever runs as the `root` user.
+1. Act as a secondary safeguard to restore the essential files for the user journey above.
+2. Revert any other mockery the user did that might affect the system.
 
-It creates `/home/root` if it is gone, and puts the copies from `C:\ProgramData\kik-restore\files` back into the
-home directory: the shell configuration, the keys and the four text files. Anything that is not a regular file is
-replaced, so that the files cannot become anything but text. It also sets the permissions of the home directory and
-of those files, so that the user cannot delete them.
+The second job should also be able to restore a new server to the expected state.
 
 ## Installing the cleanup on the server
 
+To deploy the cleanup task an the server, run:
+
     server/scripts/deploy.sh
 
 The script logs in as `Administrator` - whose shell is a Windows one - copies the scripts and the resources to the
-Administrator's home directory and runs the installer there, with the personal key of the deployer. The key of the
-website never gets administrator rights. `--uninstall` removes the task again.
-
-The installer can also be run by hand, in an elevated PowerShell on the server:
-
-    powershell -ExecutionPolicy Bypass -File .\scripts\install_restore_task.ps1
+Administrator's home directory and runs the installer there.