4269
Comment: decruft
|
12280
overhaul thoughts on ssl, remove some obsolete bits
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
I am Clinton Ebadi. = 2010 Board Statement = == Hardware == We have procured a new machine and, after some delays, are near to having it online as our primary file and database server. This will allow us to handle our (finally) growing membership gracefully. My primary hardware goal for 2010 is to make our central services redundant. At the very least allowing mail delivery, databases, and read-only AFS volumes for all users to continue functioning in case of the failure of one machine. == System Administration == A year ago DavorOcelic was more or less our only admin, and I knew next to nothing about our setup and could perform only menial tasks under his supervision. After a year I have become competent enough with the software HCoop uses to provide actual assistance to Davor, thus giving us two primary admins. RichardDarst has also joined the admin team and has been quite helpful with physical hardware visits and is now in our sysadmin group. This puts us in a tolerable situation, but this is still less than ideal. Currently we are without a maintainer for DomTool or the portal as AdamChlipala (after many years of volunteering) has decided to step down from software maintenance. Over the next year we will need to bring at least one more person onto the admin team and find a new maintainer for our custom software. == Financial == This year I was able to convince the board that $7/month dues were reasonable, and we've managed to bring HCoop to a reasonably stable financial position. We are within 20 members of being able to phase out of the dues system (intended as a temporary measure, but relied upon for far too long to keep us afloat). My goal of expanding membership to ~300 was unrealistic last year, but now that services have stabilized and our sysadmin situation is better we have been slowly increasing membership month to month. Expanding to 200 members in 2010 would be reasonable without much effort; if we attempted to attract new members we might well hit 300 (and we have the infrastructure in place now to handle this many). With even 200 members we will be in a position to replace our aging hardware and thus expand the available services to all members. = 2009 Board Election = == Hardware == We should take stock of our current hardware, get hopper online soon, and see if it is worthwhile getting xanadu online for shell access. == Financial == Right now our financial situation is untenable; we have 134 members with base expenses of over $750 per month and are only able to operate because of members with multiple pledges. The active members of the coop should attempt to get a friend or two to join, and we should address any issues that would prevent someone familiar with UNIX from joining. A goal of expanding membership to around 300 by next year seems reasonable given the hardware we own, and would put us in a position to explore things like having a part-time paid sysadmin and expanding a bit more aggressively six months to a year from now. == System Administration == The main volunteer system administrator pool should be expanded from three to four in order to replace mwolson and remove some task burden from docelic. If no one else wishes to volunteer, I should be able to assist, but it has been quite a while since I've done any system adminstration for anything other than my personal machine. Setting up a firewall and user limits similar to what we used on fyodor is essential to expanding beyond our current membership; right now we have resources to spare and ports a plenty, but I suspect that with 300 or so members we'll be close enough to our hardware limits on at least mire that we'll need to prevent the occasional runaway process from interrupting service for other users. |
I am Clinton Ebadi. I am the reluctant President of the coop (someone has to do it), and the current lead sysadmin / DomTool maintainer / lo-fi AdamChlipala replacement. = Board Statements = See [[/BoardStatements]] = General Coop Goals = Unstructured musing on when/what I think the coop ought to be. * Summer 2018: Shiny new ''servers'' (achieved! in Winter 2018) * Spring 2019: Ponies for everyone. |
Line 94: | Line 17: |
* unknownlamer (AOL Instant Messenger) * <<MailTo(clinton at hcoop dot net)>> (Jabber) |
* <<MailTo(clinton at hcoop dot net)>> (XMPP) |
Line 97: | Line 19: |
* +1 443 538 8058 (Phone, SMS preffered) | * +1 443 538 8058 (Phone, SMS preffered as I will ignore your call if I don't have your number already and check voicemail approximately once per century) |
Line 101: | Line 23: |
* http://unknownlamer.org '''Personal Homepage''' | * https://unknownlamer.org '''Personal Homepage''' * [[My Journal|https://journal.unknownlamer.org]] is a bit less dusty * http://demoncat.org |
Line 103: | Line 27: |
= Immediate Tasks = * Old accounts clearing gunk = Admin Stuff = == fastcgi setup notes == Notes to self about configuring fastcgi for at least php http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html === Packaging === * Depend on `libapache2-mod-fcgid` * `a2enmod fcgid` in postinst (the package seems to enable itself, but en/dis anyway) * Need to install our own `mods-available/fcgid.conf` * Do NOT enable `fcgid-script` script hander by default, require use of `fastCgiExtension` in DomTool * Need to configure process limits (expire fairly quickly to prevent issues with tokens/memory exhaustion) === Problems with openafs === ''Old Content'': This section is from before fastcgi was implemented. Leaving so I might remember one day to try the idea of adding an suexec hook to apache. The mod_fcgid spawner runs in its own process pool and therefore without tokens or the ability to acquire tokens for processes it launches. Thus, all fcgi processes must be wrapped to avoid surprising behavior. The `FcgidWrapper` directive is not very expressive: the "wrapper" is the fastcgi application that is launched and then passed any files matching the extension using `SCRIPT_NAME`. A wrapper wrapping script is needed to grab tokens before launching the actual wrapper, and just using `{Add,Set}Handler fcgid-script` won't work as expected (users could of course arrange for programs run that way to grab tokens manually). mod_wsgid and mod_cgid have identical problems. Inspecting the apache source code makes it appear that it would be possible to fix the situation generally by adding a pre/post suexec hook. The process managers for mod_cgid/mod_fcgid/mod_wsgid are forked from the primordial apache process which I understand has all modules loaded. Modules like mod_auth_kerb and mod_waklog could then inject tickets/tokens/etc. into the environment from which external processes were spawned using the suexec hooks. ==== Actual Implementation Notes ==== `create-user` generates wrapper scripts per user. If we turned off suexec uid/gid checking, there could be a single wrapper-wrapper (perhaps implement `SuExecForceUserGroup {on|off}` as a global server config option?) php5 fastcgi works fine and will be mandatory for debian stretch servers. `fastScriptAlias` works for the case of a single fcgi program handling an entire path, and uses Directory + Files internally. == Improve SSL Experience == * We are not managing certificates well * we don't check and warn members when their certs are going to expire * requesting certs via the filesystem is clunky for most users, we should support upload via the portal instead * Need to add letsencrypt support * We might want to keep the key separate from the cert itself * letsencrypt for example provides fullchain.pem and the privkey separately, and if you are receiving a cert from anywhere your key is going to be separate anyway === 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. === 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. === 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: * Certs that are not owned by any member in domtool * Permissions to certs that don't exist * Expired or soon to expire certs (should exponentially back off notice until expiration date changes, like quotacheck does for low space), emailing the member as well as admins@ 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). == etc. == * default Directory``Index does not include index.shtml, should this be changed? * `vhostDefault` makes configuring the default vhost slightly unpleasant. Extend `host` with `host_default` token and eliminate? == Website == (create Website bugzilla product and move these there) * Convert hcoop.net into domtool config (looks trivial, a few rewrites... except for userdir support?) * On the topic of user dirs: allow members to register a redirect for hcoop.net/~foo?) * Perhaps: Move userdirs to `http://users.hcoop.net/~foo` (302ing from `hcoop.net/~foo`) * Replace facebook links with other "get to know the members" text * Inspire members to join the planet * Make the locations tool usable again (something we can use with Openstreetmap). * Give RobinTempleton access as needed === Wiki === * [[http://moinmo.in/MacroMarket/ChildPages|child pages macro]] for listing the section of the member manual in the sidebar? == domtool plans == * Feature backlog * Networked domtool-tail * Improve `fwtool` as needs become clearer (FirewallTool) === 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. === 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 -> }}} === 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. = Board Stuff = * What address should we be using for the "owner" of hcoop services? It's a mix of the current treasurer, registered agent, and data center right now... is the registered agent correct? Do we need to get a PO Box or something? * Possible policy change: pro-rate the first month of dues for new members. It seems a bit unfair to make folks pay an entire month of dues, especially if they join near the end of the month. * Board did approve this, but was never implemented :-\ * Do we need a private wiki of some sort for filing sensitive information like welcome emails for services and various credentials... is it safe enough to do that using the public moin and acls? I'm not sure sure... = etc = Barely formed sentences. == tt-rss at hcoop == Our postgresql does not use passwords. The installer needs a single tweak to remove the required attribute of the database password to install. |
I am Clinton Ebadi. I am the reluctant President of the coop (someone has to do it), and the current lead sysadmin / DomTool maintainer / lo-fi AdamChlipala replacement.
1. Board Statements
See /BoardStatements
2. General Coop Goals
Unstructured musing on when/what I think the coop ought to be.
Summer 2018: Shiny new servers (achieved! in Winter 2018)
- Spring 2019: Ponies for everyone.
3. Contact
<clinton at unknownlamer dot org> (Email)
<clinton at hcoop dot net> (XMPP)
unknown_lamer on freenode (IRC) in #hcoop
- +1 443 538 8058 (Phone, SMS preffered as I will ignore your call if I don't have your number already and check voicemail approximately once per century)
4. Websites
https://unknownlamer.org Personal Homepage
https://journal.unknownlamer.org is a bit less dusty
5. Immediate Tasks
- Old accounts clearing gunk
6. Admin Stuff
6.1. fastcgi setup notes
Notes to self about configuring fastcgi for at least php
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
6.1.1. Packaging
Depend on libapache2-mod-fcgid
a2enmod fcgid in postinst (the package seems to enable itself, but en/dis anyway)
Need to install our own mods-available/fcgid.conf
Do NOT enable fcgid-script script hander by default, require use of fastCgiExtension in DomTool
- Need to configure process limits (expire fairly quickly to prevent issues with tokens/memory exhaustion)
6.1.2. Problems with openafs
Old Content: This section is from before fastcgi was implemented. Leaving so I might remember one day to try the idea of adding an suexec hook to apache.
The mod_fcgid spawner runs in its own process pool and therefore without tokens or the ability to acquire tokens for processes it launches. Thus, all fcgi processes must be wrapped to avoid surprising behavior. The FcgidWrapper directive is not very expressive: the "wrapper" is the fastcgi application that is launched and then passed any files matching the extension using SCRIPT_NAME. A wrapper wrapping script is needed to grab tokens before launching the actual wrapper, and just using {Add,Set}Handler fcgid-script won't work as expected (users could of course arrange for programs run that way to grab tokens manually).
mod_wsgid and mod_cgid have identical problems. Inspecting the apache source code makes it appear that it would be possible to fix the situation generally by adding a pre/post suexec hook. The process managers for mod_cgid/mod_fcgid/mod_wsgid are forked from the primordial apache process which I understand has all modules loaded. Modules like mod_auth_kerb and mod_waklog could then inject tickets/tokens/etc. into the environment from which external processes were spawned using the suexec hooks.
6.1.2.1. Actual Implementation Notes
create-user generates wrapper scripts per user. If we turned off suexec uid/gid checking, there could be a single wrapper-wrapper (perhaps implement SuExecForceUserGroup {on|off} as a global server config option?)
php5 fastcgi works fine and will be mandatory for debian stretch servers.
fastScriptAlias works for the case of a single fcgi program handling an entire path, and uses Directory + Files internally.
6.2. Improve SSL Experience
- We are not managing certificates well
- we don't check and warn members when their certs are going to expire
- requesting certs via the filesystem is clunky for most users, we should support upload via the portal instead
- Need to add letsencrypt support
- We might want to keep the key separate from the cert itself
- letsencrypt for example provides fullchain.pem and the privkey separately, and if you are receiving a cert from anywhere your key is going to be separate anyway
6.2.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.
6.2.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.
6.2.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:
- Certs that are not owned by any member in domtool
- Permissions to certs that don't exist
- Expired or soon to expire certs (should exponentially back off notice until expiration date changes, like quotacheck does for low space), emailing the member as well as admins@
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).
6.3. etc.
default DirectoryIndex does not include index.shtml, should this be changed?
vhostDefault makes configuring the default vhost slightly unpleasant. Extend host with host_default token and eliminate?
6.4. Website
(create Website bugzilla product and move these there)
- Convert hcoop.net into domtool config (looks trivial, a few rewrites... except for userdir support?)
- On the topic of user dirs: allow members to register a redirect for hcoop.net/~foo?)
Perhaps: Move userdirs to http://users.hcoop.net/~foo (302ing from hcoop.net/~foo)
- Replace facebook links with other "get to know the members" text
- Inspire members to join the planet
- Make the locations tool usable again (something we can use with Openstreetmap).
Give RobinTempleton access as needed
6.4.1. Wiki
child pages macro for listing the section of the member manual in the sidebar?
6.5. domtool plans
- Feature backlog
- Networked domtool-tail
Improve fwtool as needs become clearer (FirewallTool)
6.5.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.
6.5.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 ->
6.5.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.
7. Board Stuff
- What address should we be using for the "owner" of hcoop services? It's a mix of the current treasurer, registered agent, and data center right now... is the registered agent correct? Do we need to get a PO Box or something?
- Possible policy change: pro-rate the first month of dues for new members. It seems a bit unfair to make folks pay an entire month of dues, especially if they join near the end of the month.
- Board did approve this, but was never implemented :-\
- Do we need a private wiki of some sort for filing sensitive information like welcome emails for services and various credentials... is it safe enough to do that using the public moin and acls? I'm not sure sure...
8. etc
Barely formed sentences.
8.1. tt-rss at hcoop
Our postgresql does not use passwords. The installer needs a single tweak to remove the required attribute of the database password to install.