Add QNAP plain deployment mode

Prompts used since the previous commit:
- Doe maar
- De homedirectory voor mailcat moet zijn /share/homes/mailcat

Special observations:
- Added SERVICE_MANAGER=plain for QNAP-style NAS hosts without systemd.
- Plain mode installs start/stop/status scripts under /share/homes/mailcat/mailcat/bin and uses /opt/bin/python3 by default.
- Remote install now uses explicit absolute tool path variables supplied for the NAS.
- verplaats_log.json remains modified from the user's run and was intentionally not staged.
This commit is contained in:
2026-07-04 20:26:25 +02:00
parent c2909529d8
commit 90d97efa6c
3 changed files with 170 additions and 38 deletions
+13 -10
View File
@@ -11,7 +11,7 @@ The project started as an offline analysis of a local mailbox export and is bein
- Email is hosted at `australius.nl`.
- A VPS is available at `vps.austalius.nl`, but the user now wants to test automation first on a local home NAS instead of the VPS.
- The test mailbox is `backup@australius.nl`.
- The future automation should run on an always-on remote host, preferably via SSH deployment and an IMAP IDLE daemon. The current deploy path assumes a Linux/systemd target with sudo; if the NAS does not support that, adapt the run method to the NAS scheduler or container tooling.
- The future automation should run on an always-on remote host, preferably via SSH deployment and an IMAP IDLE daemon. The NAS is QNAP-like BusyBox Linux without systemd, so test deployment should use `SERVICE_MANAGER=plain`.
- The current end-to-end test uses the `backup` account as a disposable test target.
## Repository State
@@ -150,6 +150,10 @@ Remote/NAS deployment files:
- The deploy script requires `REMOTE_HOST` and `REMOTE_USER`. The old `VPS_HOST` and `VPS_USER` names still work as aliases. Optional overrides: `APP_USER`, `APP_DIR`, `SERVICE_NAME`, and `ACCOUNT`.
- The deploy script uploads a temporary remote shell script and runs it with `ssh -tt`, so remote `sudo` can prompt for a password on NAS systems that require a terminal. The remote script starts with `sudo -v`.
- The deploy script exports an explicit remote PATH before running install commands: `/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin` by default, overrideable with `REMOTE_PATH`. It searches both PATH and common absolute paths such as `/usr/local/bin/useradd`, `/usr/sbin/useradd`, and `/sbin/useradd`. If `useradd` is genuinely unavailable, it falls back to the existing SSH user and that user's primary group for service ownership.
- For the local NAS, use `SERVICE_MANAGER=plain`, `MAILCAT_HOME=/share/homes/mailcat`, and `PYTHON=/opt/bin/python3`. In plain mode, default paths are `APP_DIR=$MAILCAT_HOME/mailcat`, `STATE_DIR=$APP_DIR/state`, `LOG_DIR=$APP_DIR/log`, `RUN_DIR=$APP_DIR/run`, and `PID_FILE=$RUN_DIR/mailcat.pid`.
- QNAP path facts supplied by the user: `SUDO=/usr/bin/sudo`, `USERADD=/usr/local/bin/useradd`, `PYTHON=/opt/bin/python3`, `INSTALL=/usr/bin/install`, `SED=/bin/sed`, `TAR=/bin/tar`, `MKDIR=/bin/mkdir`, `CHOWN=/bin/chown`, `CHMOD=/bin/chmod`, and `RM=/bin/rm`. `nologin`, `python3`, `systemctl`, and `nohup` are not in the user's default PATH.
- The deploy script accepts absolute tool overrides for those commands and passes them into the remote script. In plain mode, the generated start/stop/status scripts also bake in absolute `MKDIR` and `RM` paths.
- In plain mode, the deploy script does not install systemd files. It writes executable scripts to `$APP_DIR/bin/start_mailcat.sh`, `$APP_DIR/bin/stop_mailcat.sh`, and `$APP_DIR/bin/status_mailcat.sh`.
- `systemd/mailcat-sort.service` is a template consumed by `deploy_vps.sh`; after placeholder replacement it runs `sort_mail_daemon.py --account backup --folder INBOX` and stores state/logs under `/var/lib/mailcat` and `/var/log/mailcat`.
- `config.json` remains ignored and must be created manually on the remote host with mode `600` before starting the service.
@@ -245,15 +249,14 @@ Latest live mailbox verification:
Recommended next work:
1. Ask the user for the NAS SSH hostname/IP, SSH username, and whether the NAS has Linux/systemd with sudo. If it is a Synology/QNAP-style NAS without systemd, adapt the run method to its scheduler or container tooling before deploying.
2. Before starting the service, ensure `/opt/mailcat/config.json` on the NAS contains the `backup` account credentials and has mode `600`.
3. Deploy to a Linux/systemd NAS with a command like `REMOTE_HOST=<nas-host> REMOTE_USER=<ssh-user> ./deploy_vps.sh`.
4. On the NAS, start and inspect the service:
- `sudo systemctl start mailcat-sort-backup.service`
- `sudo systemctl status mailcat-sort-backup.service`
- `sudo journalctl -u mailcat-sort-backup.service -f`
5. Send controlled test messages to `backup@australius.nl` for invoices, clear AI providers, a newsletter/service route, and unmatched mail; verify expected folder moves and daemon logs.
6. Add `List-ID` header support to mailing-list routing if live daemon tests show sender/domain matching is too coarse.
1. Deploy to the QNAP NAS with a command like `REMOTE_HOST=hades REMOTE_USER=Hel SERVICE_MANAGER=plain MAILCAT_HOME=/share/homes/mailcat ./deploy_vps.sh`.
2. Before starting the daemon, ensure `/share/homes/mailcat/mailcat/config.json` on the NAS contains the `backup` account credentials and has mode `600`.
3. On the NAS, start and inspect the daemon:
- `sudo -u mailcat /share/homes/mailcat/mailcat/bin/start_mailcat.sh`
- `sudo -u mailcat /share/homes/mailcat/mailcat/bin/status_mailcat.sh`
- `tail -f /share/homes/mailcat/mailcat/log/sort_mail_daemon.log`
4. Send controlled test messages to `backup@australius.nl` for invoices, clear AI providers, a newsletter/service route, and unmatched mail; verify expected folder moves and daemon logs.
5. Add `List-ID` header support to mailing-list routing if live daemon tests show sender/domain matching is too coarse.
## Persistent File Rule