Admin Stuff

1. Improve SSL Experience

1.1. Domtool

Replace use_cert cert function that just takes the final name instead of the full pathname, providing the full pathname is kind of clunky. 

extern type your_cert;
extern val cert : your_cert -> ssl
(* SSL = cert "mydomain.pem"; *)

We also need to support letencrypt, perhaps like so: 

extern type your_letsencrypt_cert;
extern val letsencrypt : your_letsencrypt_cert -> ssl
(* SSL = letsencrypt "my.domain"; *)

Which would find the certs in the standard location used by certbot... or we could use symlinks there from our location.

1.2. Portal

We should allow submission of certs / keys through the web interface. Can use an insert-only afs dir to securely allow hcoop.daemon to write certs without being able to access them, which would then be installed manually by an admin using ca-install.

The portal request page should display all certs a user is permitted to use already, their common name, and their expiration date.

1.3. Managing Certificates

Needs Updating Not very fleshed out, also does not consider how we're going to manage letsencrypt certs

Since we no longer need to support explicit intermediate certs (everything nowadays accepts the chain in the main certificate file), we can just use domtool's cert permission to track things.

A cron should check for things like:

Certificate CN and validity dates should be shown on the portal ssl page; ssl check cron should cache this somewhere the portal can read it.

destroy-user needs to nuke certs for leaving members ... we need to overhaul this generally and stash all member data in one location when destroying for later removal / restoration (if they return in the 30 day deletion window).

1.4. Managing Member Data Better

Trying to hash out how we can better manage user data when they depart; right now we reply on someone (me...) to go in 30 days after removing a member to remove all of their non-afs data manually, which is prone to error and needs to be managed better if we want to comply with things like GDPR (although I don't think it applies to us directly as a US corporation, it would be nice to do so since we really don't want to be retaining data longer than needed anyway, and the US will likely have stringent privacy laws aimed at facebook/google that will punish all the same for failing to remove data immediately too...).

Not personal data, but things we should clear for housekeeping in general:

We already manage mail and $HOME data fine, both are easy to clear (delete the volumes, done).

One aspect of the solution I've been thinking about that would also make it easier for members to export their data in general: we could set up a backups.$user volume, and store dumps of data we hold on behalf of the data there: database backups, mailing list archives, an exported dump of their ejabberd roster, maybe even copies of their ssl certs.

We also need a registry of data we keep on behalf of members that can't immediately be identified based on their username: at least ssl certs and mailing lists (those might be it though... and certs are already tracked with domtool perms so maybe just adding a "list" perm would be adequate, which could then be used to maybe allow members to perform some list management through a domtool program). And we need to store things like domtool permissions when destroying (might be able to achieve some of this by first freezing members before removing them), so that we can use them later when performing the final purge of data after the retention period ends (important to keep a brief retention period for those "oh right, I have to actually pay dues" moments...).

2. etc.

3. Website

(create Website bugzilla product and move these there)

3.1. Wiki

4. domtool plans

4.1. restricted modules for apache

Inspiration: hcoop.net's vhost is non generated by domtool, and only because it enabled mod_userdir

Idea: have a set of restricted modules that can only be used by superusers. Easiest to just have another ad-hoc list setting in config for domtool. ACL example: hcoop priv www, www priv overloaded to also allow use of restricted module.

Problems: no way currently to restrict access to actions or lib files.

Deficiences: priv www is a blunt instrument. priv system in general is mediocre. It might be nice to be able to do something like hcoop priv www apache-module/userdir mail/hopper.hcoop.net (i.e. access to all www nodes, access to the userdir module only, access to hopper). Keys gain some hierarchy polluting the purity of the triples db, but it is already a bit polluted... is there any difference between adding hierarchy to priv keys and the existing implicit hierarchies in domains and paths?

Solution: might be overkill just for mod_userdir, if it looks like minimal additional code is required perhaps implement hierarchical privs (extending www and mail privs to support limiting to particular admin hosts) and restricted apache modules.

4.2. Pattern Matching and New Types

A vague idea that may prove to be unworkable. I think at least implementing list matching in domtool would be quite useful. Abstraction syntax would be need to be improved to support multiple clauses. case would also be needed to make it useful. Syntax would be easy enough to add except for having to deal with runtime non-exhaustive match exceptions (perhaps requiring exhaustive matches and living with the limitation). Ambitious, probably time consuming, might require adding tail call optimization to the interpreter. Example: 

(* A map operator *)
val map = \action -> \list -> 
  case list of head::tail =>
    begin
      action head;
      map action tail;
    end
     | [] => Skip;
(* Alias a list of email addresses to *)
val multiAlias = \sources -> \target -> map (\source -> emailAlias source target) sources;

I probably lack the skill/willpower in the short term... alternative idea, just implement a loop primitive in SML and magic the types away by making it a primitive construct (defining its type on DomTool/LanguageReference). Maybe implement polymorphic actions if adding then is secretly easy: 

extern val map : (('a -> 'b) -> ['a]) -> [^Root];

(* Alias a list of email addresses to *)
val multiAlias = \sources -> \target -> map (\source -> emailAlias source target) sources;

Most of the gain, none of the pain.

New types: even more ambitious. Supporting at least tuples or named records, and perhaps a construct for querying the domtool acl database. Idea would be to use it for something like the firewall, where only primitive "generate one firewall rule" constructs would be needed, and then user firewalls could be constructed by querying the ports available to each user and matching/looping.

One pattern that has recurred in domtool is that of a special purpose client + server commands that operates on a simple database. E.g. spamassassin prefs, vmail users, firewall rules, and the domtool acl database. It would be useful to have a generalized serialize/unserialize sets of sml records library, perhaps with a generalized/queryable tuples database built on top of the primitive raw-records database. Even better would be to allow databases to be exposed to domtool, and simple queries performed on them. Maybe. 

val writeRecord' : [('record ->

4.3. ip / ipv4 / ipv6

There are a few places (mostly apache) where it would be great to be able to interchange ip and ipv6 addresses. But there's no way to subtype in domtool (except for refining base int and string).

It's been shoehorned in for now (always requiring a node to have an ipv6 address), but this can be a bit awkward (e.g. webAtIp requires that an ipv4 and ipv6 address be provided).

Also might make sense to be able to pass an array of IPs in a few spots instead of just fixing it at one ipv4 and one ipv6 address per WebPlace. you can just pass more than one WebPlace already.