1. Underway
buster upgrade on shell and webserver this weekend - buster upgrade mail/xmpp server
- upgrade mysql to 5.7 on gibran
change default PhpVersion to 7.4
- upgrade openafs servers to 1.8
Procedure for creating KeyFileExt to replace rxkad
- upgrade outpost to buster
- test bind first on ServerBusted
- upgrade lovelace to buster after making sure things are stable with outpost upgrades
- start dealing with increasing the krbtgt strength (just adding stronger ciphers and removing the weakest ciphers initially + re-generating high value service principals)
- upgrade gibran to buster
- reimplement multiple postgres instance support, upgrade to latest (on port 5432 again finally...)
- Enter old bills into the portal and reconcile everything so we can implement FinancialReservePolicy
Time permitting, squeeze in setting up /JitsiMeet if tests prove it's feasible for us to host
2. Medium term
As of this writing, this means "hopefully before the end of 2020"
Grant members all on $db.* in mysql now that we have backups so if they manage to drop their database it's not fatal anymore. Will make default mysql experience much saner.
Opt all members and vmail accounts into spam checking, automatically move spam to ~Maildir/.Junk, (pending discussion) auto delete mail in Junk (see TODO DaemonAdmin/SpamAssassin)
- Letsencrypt integration into domtool
3. Longer Term
Probably during 2021
- Managing data when members depart better
- Useful, member accessible backups
3.1. Centralize apache logging
domtool-tail is broken, and supporting it is challenging in a multi-server environment. Instead, we could like just use syslog to write logs to either nfs or afs in real time.
DomTool would generate a syslog-ng config snippet to monitor each user log file and write to the final destination
AFS:
Write directly to ~/.logs/apache/SERVER/DOMAIN/...
- Downside: Unless we want to run a bunch of syslog instances, there would have to be a shared syslog principal that could write to all member log directories
NFS:
Syslog would just write logs to another directory on the server, and set permissions to the user the log really belongs to (can't do this directly with the apache logs as anyone who can write to the log can do bad things, in theory, so directly mounting /var/log/apache2 is impossible).
- Exported directories from each host would be mounted on the member login server
- Regular UNIX permissions would be used to control access, since we control the user database for both machines and know UIDs will match
Logs would be regularly rsynced to afs storage (using USER.daemon credentials) as is done now for longer term storage
In either case, might be a good idea to move logs to a dedicated volume? And maybe introduce USER.log principles ... is there any reason we would want to allow USER.daemon access to the log directory by default? Only case I could see would be members using daemon roles to automatically process logs, in which case presumably they would be able to handle granting the required permissions manually.