wiki: add SELinux vmail and gitea-runner articles; update indexes

- New: SELinux Fixing Dovecot Mail Spool Context (/var/vmail)
  Corrected fix — mail_spool_t only, no dovecot_tmp_t on tmp/ dirs.
  Includes warning and recovery steps for the Postfix delivery outage.
- New: Gitea Actions Runner Boot Race Condition Fix
  network-online.target dependency, RestartSec=10, /etc/hosts workaround.
- Updated SUMMARY.md, index.md, README.md, 05-troubleshooting/index.md
- Article count: 37 → 39; MajorWiki-Deploy-Status updated

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

05-troubleshooting/selinux-dovecot-vmail-context.md

@@ -0,0 +1,103 @@
+# SELinux: Fixing Dovecot Mail Spool Context (/var/vmail)
+
+If Dovecot is generating SELinux AVC denials and mail delivery or retrieval is broken on a Fedora/RHEL system with SELinux enforcing, the `/var/vmail` directory tree likely has incorrect file contexts.
+
+## Symptoms
+
+- Thousands of AVC denials in `/var/log/audit/audit.log` for Dovecot processes
+- Denials reference `var_t` context on files under `/var/vmail/`
+- Mail delivery may fail silently; IMAP folders may appear empty or inaccessible
+- `ausearch -m avc -ts recent` shows denials like:
+  ```
+  type=AVC msg=audit(...): avc: denied { write } for pid=... comm="dovecot" name="..." scontext=system_u:system_r:dovecot_t:s0 tcontext=system_u:object_r:var_t:s0
+  ```
+
+## Why It Happens
+
+SELinux requires files to have the correct security context for the process that accesses them. When Postfix/Dovecot are installed on a fresh system and `/var/vmail` is created manually (or by the mail stack installer), the directory may inherit the default `var_t` context from `/var/` rather than the mail-specific `mail_spool_t` context Dovecot expects.
+
+The correct context for the entire `/var/vmail` tree is `mail_spool_t` — including the `tmp/` subdirectories inside each Maildir folder.
+
+> [!warning] Do NOT apply `dovecot_tmp_t` to Maildir `tmp/` directories
+> `dovecot_tmp_t` is for Dovecot's own process-level temp files, not for Maildir `tmp/` folders. Postfix's virtual delivery agent writes to `tmp/` when delivering new mail. Applying `dovecot_tmp_t` will block Postfix from delivering any mail, silently deferring all messages with `Permission denied`.
+
+## Fix
+
+### 1. Check Current Context
+
+```bash
+ls -Zd /var/vmail/
+ls -Z /var/vmail/example.com/user/
+ls -Zd /var/vmail/example.com/user/tmp/
+```
+
+If you see `var_t` instead of `mail_spool_t`, the contexts need to be set. If you see `dovecot_tmp_t` on `tmp/`, that needs to be corrected too.
+
+### 2. Define the Correct File Context Rule
+
+One rule covers everything — including `tmp/`:
+
+```bash
+sudo semanage fcontext -a -t mail_spool_t "/var/vmail(/.*)?"
+```
+
+If you previously added a `dovecot_tmp_t` rule for `tmp/` directories, remove it:
+
+```bash
+# Check for an erroneous dovecot_tmp_t rule
+sudo semanage fcontext -l | grep vmail
+
+# If you see one like "/var/vmail(/.*)*/tmp(/.*)?" with dovecot_tmp_t, delete it:
+sudo semanage fcontext -d "/var/vmail(/.*)*/tmp(/.*)?"
+```
+
+### 3. Apply the Labels
+
+```bash
+sudo restorecon -Rv /var/vmail
+```
+
+This relabels all existing files. On a mail server with many users and messages, this may take a moment and will print every relabeled path.
+
+### 4. Verify
+
+```bash
+ls -Zd /var/vmail/
+ls -Zd /var/vmail/example.com/user/tmp/
+```
+
+Both should show `mail_spool_t`:
+```
+system_u:object_r:mail_spool_t:s0 /var/vmail/
+system_u:object_r:mail_spool_t:s0 /var/vmail/example.com/user/tmp/
+```
+
+### 5. Flush Deferred Mail
+
+If mail was queued while the context was wrong, flush it:
+
+```bash
+postqueue -f
+postqueue -p   # should be empty shortly
+```
+
+### 6. Check That Denials Stopped
+
+```bash
+ausearch -m avc -ts recent | grep dovecot
+```
+
+No output = no new denials.
+
+## Key Notes
+
+- **One rule is enough** — `"/var/vmail(/.*)?"` with `mail_spool_t` covers every file and directory under `/var/vmail`, including all `tmp/` subdirectories.
+- **`semanage fcontext` is persistent** — the rules survive reboots and `restorecon` calls. You only need to run `semanage` once.
+- **`restorecon` applies current rules to existing files** — run it after any `semanage` change and any time you manually create directories.
+- **New mail directories are labeled automatically** — SELinux applies the registered `semanage` rules to any new files created under `/var/vmail`.
+- **`var_t` context is the default for `/var/`** — any directory created under `/var/` without a specific `semanage` rule will inherit `var_t`. This is almost never correct for service data directories.
+
+## Related
+
+- [Linux Server Hardening Checklist](../02-selfhosting/security/linux-server-hardening-checklist.md)
+- [Docker & Caddy Recovery After Reboot (Fedora + SELinux)](docker-caddy-selinux-post-reboot-recovery.md)