domtool-public: workaround mailman plugin deficiencies The mailman plugin only generates mailman_domains.cfg on the server that also runs the mailman web interface, so there's no way for a secondary mail server to know which addresses need to be relayed to the exim server that runs mailman. Reworking the mailman plugin would be a bit involved, and it's fairly low priority so work around for now by setting /var/domtool/mailman_domains.cfg immutable on the affected servers, and ignoring if the touch during redo_exim() fails. If/when the plugin is updated, there is a secondary issue of copying the mailmandb to all nodes since it is generated locally on the mailman server. Lists could be managed by domtool, or even just a new command to trigger an rsync of the mailmandb to afs and then to all mail nodes when lists are changed should work (IIRC, it is only changed when lists are added or removed).
apache: remove php5-cgi support, always generate php config Only fastcgi php is supported going forward since suphp has long been deprecated. Config.Apache.defaultPhpVersion has been removed; since PhpVersion will always be specified, there is no reason for domtool not to explicitly generate config instead of relying on the ambient apache config to set default handlers for php. The kerberos/afs fastcgi wrapper is suppressed on non-waklog systems, but ONLY when php is configured from PhpVersion in the vhost as a whole; the phpVersion and fastScriptAlias actions don't have access to the node they are being generated on, and can't detect that waklog is not supported. Will need to be fixed eventually...
fwtool: initial ipv6 support and puppet integration Not the prettiest, but it works. Just duplicates the firewall between ipv4 and ipv6, making sure to filter out any hostnames that aren't resolvable in each domain. ProxiedServer doesn't work over IPv6 yet due to nodes not having that information, will need to be fixed for proxied web services to work. domtool-publish has a new action, firewallpuppet, that will reload the firewall for our new setup (and fall back to just reloading ferm on the current one). Further work is required for puppet; we are purging unmanaged chains and will need to move all rules into a single chain instead of jumping to a different chain per user.
systemd service files for server/slave Welcome to the future, whether we like or not. Service files should provide functionality similar to the current init scripts. Current no service monitoring is implemented (if possible, regularly `domtool-admin ping'ing service and restarting if no response would be nice). /var/log/domtool.log is gone, replaced by use of the system journal.
Add vmail command for changing password when you know the current password Not 100% sure if this the best way, but the members portal was tied to *the* mail node, which is not good to begin with, and breaks when there are multiple mail nodes. * Replaces vmailpasswd.c, which is an awful program (passed password on the command line revealing it to `ps' and only supports a local filesystem userdb). * Restricted to users with the priv `vmail' for now, and only used by the portal. Not much worth in exposing generally it seems (vmail users cannot login to any shell machines, at least at hcoop) * Includes helper python program to run crypt() (better than C at least...) * New function to parse the userdb into a StringMap (a better approach is possible, similar to the Vmail.list). Will be used to compile the database for Dovecot later. * New binary `domtool-portal' to expose replacement vmailpasswd command
Disentangle vmail from the mail node, Prepare for dovecot support * Use new Slave.run and Connect.commandWorker where possible * Always reload vmail db in worker, never in dispatcher * Move non-courier-specific configuration variables to Config.Vmail. The master userdb is still managed using courier-authlib-userdb. * Manage vmail db in afs, syncing as needed.
Fix domtool-addcert for when user running is not in `wheel' Domtool on deleuze assumed admin users would be in group `wheel'. This is no longer true. Instead, make the CA readable only by root, generate the new keys and certs into a non-afs temp directory, and then move everything into afs afterward.
domtool-addcert: use domtool-config, support non-afs cert/key dirs Removed `chown -R domtool.nogroup' calls since they are meaningless in afs and incorrect on normal file systems. chown -R the key dir to the user.nogroup unless `-unsafe' is passed, which allows the creation of useless keys (the user running the script can read the key instead of the intended user, which is ok for development). Still needs improvement.