welcome: please sign in

Diff for "ClintonEbadi"

Differences between revisions 72 and 73
Revision 72 as of 2017-01-31 02:54:19
Size: 15755
Editor: ClintonEbadi
Comment: ancient notes begone!
Revision 73 as of 2018-04-10 00:15:27
Size: 11933
Editor: ClintonEbadi
Comment: spring cleaning
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
I am Clinton Ebadi. I am the reluctant --(President)--Treasurer of the coop (someone has to do it), and the current lead sysadmin / DomTool maintainer / lo-fi AdamChlipala replacement. 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.
Line 11: Line 11:
 * July/August 2014: Catch the sales on the last generation Dell 2U/2-socket machines and create a clean counterpart to fritz.
   * See NewServerDiscussion2013
   * Minimal KVM host setup for base OS. We might run the KDC and OpenAFS on the bare metal, not entirely certain.
   * Create new wheezy based VMs, duplicating (and turning into master) services hosted in VMs on fritz
     * For the first time, this is realistic: all of those months packaging our configuration pay off by sparing future-me from herculean efforts.
 * March 2014->July 2014: (./) Transition remaining services off of deleuze onto KernelVirtualMachine``s on new kvm host
 * Winter 2014: Assuming 150+ members, perhaps more bandwidth is in order
 * Spring 2015: Ponies for everyone.
   * IPv6, mediagoblin, diaspora, gitorious, (./) xmpp works again (and ability to use vanity domains), ...
 * Summer 2018:
 * Spring 2019: Ponies for everyone.
Line 27: Line 20:
 * +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 31: Line 24:
 * 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 36: Line 31:
 * Old accounts clearing gunk
 * Migrate users to new hosting
Line 37: Line 34:
 * Old accounts clearing gunk
 * Finish general fastcgi support
 * email about disks for new server
 * document new server on wiki

   

 * --(Possible donations for new server)--
 * Backups (blocked by lack of hardware)
Line 62: Line 49:
   * ?: `FcgidFixPathinfo 1` to let php work properly (seems to not affect anything else)
Line 67: Line 53:
''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.
Line 71: Line 59:
=== Setup Plans ===

 * Suexec requires the `FcgidWrapper` to be owned by the user, generate a wrapper wrapping script for each user in afs space (`/afs/hcoop.net/common/httpd/fastcgi/u/us/username/fcgi-wrapper`?). Must be readable by `system:anyuser`
 * Create a `php5-fcgi-wrapper` that sets `FCGI_MAX_REQUESTS` appropriately and install to `/afs/hcoop.net/common/bin`
 * Set `fcgid-script` as the global handler for `.php .phtml .php5`. Also set default `FcgidWrapper` for the case of a non-suexec host that intentionally runs without tokens.
 * Have DomTool generate `FcgidWrapper "$user-wrapper-wrapper /afs/hcoop.net/common/bin/php5-fcgi-wrapper"` for php extensions in all SuExec enabled hosts
 * Add DomTool directives to set `FcgidWrapper`
   * `Config.Apache.fastcgi_wrapper_wrapper : user -> wrapper_path`, wrap all generated `FcgidWrapper` directives with the wrapper wrapper
     * 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?)
   * No analog for `cgiExtension` because we want to avoid extremely surprising behavior
   * `fastScriptAlias location -> your_path` = `scriptAlias location your_path` + set handler to `fcgid-script` and make `your_path` the fcgi wrapper for the directory
   * Allow `setFastCgiHandler program` in `[Location]` generally? Would `SetHandler` and also set the `FcgidWrapper` simultaneously

==== Actual Implementation Scratch Notes ====

php5 fastcgi works ok. May be a problem with zombie processes due to running under k5start. appears to have resolved after I execed php5-cgi instead of running it in a subprocess of the shell script wrapper.

`fastScriptAlias` ''works'' when combined with a `Location` + `SetHandler ...`. Major downside: aliases are totally ignored and everything under that path is processed with the script. This makes moin unhappy for example. '''Possible Fix''': Have `alias loc path` generate a `Location loc` + `SetHandler none`. Initial thoughts are this won't have any weird consequences... except perhaps wrt ordering of user-provided `Location` bits... will either go with that or making it a documented caveat if it looks like generally generating it would cause anything surprising/weird.

zzz
==== 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.
Line 93: Line 69:

=== The Problem ===
Line 101: Line 79:
     * e.g. `sslCertificateChainFile` is forced to soft-fail at run-time
   * `use_cert` takes a full pathname, it would be better to use a short name. There may be a case where a user may need to use a cert not in the primary store (is there?). If there can be no case made for domtool allowing certs to be stored outside of a single location, we can make `use_cert` just pass its argument through for transition. `sslCertificateChainFile` has no reason to take a full pathname and could directly take short names instead.
     * {{{
     * `use_cert` takes a full pathname, it would be better to use a short name. There may be a case where a user may need to use a cert not in the primary store (is there?). If there can be no case made for domtool allowing certs to be stored outside of a single location, we can make `use_cert` just pass its argument through for transition.
     * Intermediate certificate handling is awful
       * Abstractions (e.g. `moinMoin` and `wordPress`) that generate vhosts can't generically let you add an intermediate certificate chain
       * `sslCertificateChainFile` is forced to soft-fail at run-time instead of causing a type error at compile time
       * Surface issues might be mitigated with new environment variable `var SSLCertificateChain : [ssl_cacert] = []`, but allowing members to choose arbitrary intermediates instead of just bundling them with the main certificate no longer seems useful.

=== A possible solution ===

Replace `use_cert` and `sslCertificateChainFile` with a single `cert` function, and store key + cert + intermediates all in one file. May still need to split out the intermediates with Apache, but each certificate can just have its own copy that is automatically used (I suspect there's negative value to allowing members to use arbitrary intermediate certs that admins have to keep up to date and grant permissions to independently).

{{{
Line 105: Line 91:
extern val cert : your_cert -> ssl_cert_path;
(* SSL = use_cert (cert "mydomain.pem"); *)

or:

extern type your_cert;
extern val cert : your_cert -> ssl;
extern val use_cert : ssl -> ssl

extern type ssl_cacert;
extern val sslCertificateChainFile : ssl_cacert -> [Vhost];
(* sslCertificateChainFile "GandiStandadSSLCA.pem"; *)
}}}
    * Abstractions like `moinMoin' and `wordPress` do not allow you to set an intermediate certificate
      * New environment variable `var SSLCertificateChain : [ssl_cacert] = []`?
extern val cert : your_cert -> ssl
(* SSL = cert "mydomain.pem"; *)
}}}
Line 123: Line 98:
The portal page should allow Intermediate CA Cert permission and installation requests. Installed CA certs should be presented as a drop-down showing the subject CN and file name.

The portal request page should display all certs and cacerts a user is permitted to use already, their common name, and their expiration date.
Certificate requests should also include intermediates, ca scripts will need some updates as well.

The portal request page should display all certs a user is permitted to use already, their common name, and their expiration date.
Line 129: Line 104:
''Needs Updating'' Not very fleshed out, also does not consider how we're going to manage letsencrypt certs
Line 135: Line 112:
 * default DirectoryIndex does not include index.shtml, should this be changed?  * default Directory``Index does not include index.shtml, should this be changed?
Line 137: Line 114:
 * Basic `git-pbuilder` setup on DebianPackaging, noting that that makes it easy for ''anyone'' to create and test trivial backports and request they be pulled/built/installed to the official archive.
Line 146: Line 123:
   * Replace `000default` with something other than the hcoop web page?
Line 150: Line 126:
 * Give BtTempleton and LaurenMcNees write access as needed  * Give RobinTempleton access as needed
Line 160: Line 136:
 * (./) Enhance easy_domain `DefaultAlias` to default to `user -> user`, but also allow dropping all or catch-all.
 * (./) `default CSymbol = Value` for binding default environment variable settings
    * Expands the scope of extensions that can be written in pure DomTool, slight flexibility gains
 * (./) vmail helper for the portal `VMailPasswdChange $user $oldpass $newpass` (restricted to users with `vmailadmin` permissions)
Line 177: Line 149:


What I'll probably do: just copy the vhost from deleuze onto navajos and call it a day for the next year or two.
Line 217: Line 186:
== Major Sysadmin Tasks for 2014 ==

 * Acquire and install new server, cleaning up the back of the rack in the process
 * Get everything off of deleuze
 * Clean up keytabs (at least `$user.mail` for mail delivery, sync to as few nodes as needed, etc.)
 * Overhaul mail delivery
   * Revisit routing/transport; the current routing config has too many entry and exit points making changes extremely complicated (i.e. likely to break mail delivery)
   * Take advantage of new exim features like DKIM.
   * Secondary MX
Line 231: Line 190:
   * Board did approve this, but was never implemented :-\
Line 240: Line 200:

== kallithea ==

Following https://pythonhosted.org/Kallithea/installation.html

 * Grant write permissions to daemon principle for write directories:
{{{
cache_dir = %(here)s/data
index_dir = %(here)s/data/index
archive_cache_dir = %(here)s/tarballcache
}}}

== jessie preseed ==

 * grub asks for disk to install on at last step now, see if this can be set to all disk

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:
  • Spring 2019: Ponies for everyone.

3. Contact

  • <clinton at unknownlamer dot org> (Email)

  • unknownlamer (AOL Instant Messenger)
  • <clinton at hcoop dot net> (Jabber)

  • 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

5. Immediate Tasks

  • Old accounts clearing gunk
  • Migrate users to new hosting
  • Announce fastcgi php support

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

6.2.1. The Problem

  • We are not managing certificates well
    • e.g. we don't check and warn members when their certs are going to expire
    • You have to use bugzilla/irc/email to get an intermediate certificate installed
  • DomTool's SSL support leaves much to be desired

    • No abstraction for setting up an ssl-only vhost that redirects http -> https

    • No abstraction for creating an SSL+non-SSL host that serve the same content
    • SSL type is problematic
      • use_cert takes a full pathname, it would be better to use a short name. There may be a case where a user may need to use a cert not in the primary store (is there?). If there can be no case made for domtool allowing certs to be stored outside of a single location, we can make use_cert just pass its argument through for transition.

      • Intermediate certificate handling is awful
        • Abstractions (e.g. moinMoin and wordPress) that generate vhosts can't generically let you add an intermediate certificate chain

        • sslCertificateChainFile is forced to soft-fail at run-time instead of causing a type error at compile time

        • Surface issues might be mitigated with new environment variable var SSLCertificateChain : [ssl_cacert] = [], but allowing members to choose arbitrary intermediates instead of just bundling them with the main certificate no longer seems useful.

6.2.2. A possible solution

Replace use_cert and sslCertificateChainFile with a single cert function, and store key + cert + intermediates all in one file. May still need to split out the intermediates with Apache, but each certificate can just have its own copy that is automatically used (I suspect there's negative value to allowing members to use arbitrary intermediate certs that admins have to keep up to date and grant permissions to independently).

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

6.2.3. Portal

Certificate requests should also include intermediates, ca scripts will need some updates as well.

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

6.2.4. Managing Certificates

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

Upon installation, certificates should be recorded in a database that stores (filename, type, subject, expiration) (where type = user | intermediate). Removal, naturally, should remove the database entry and files from all web servers.

This information could then be used to present information on a member's certs on the portal page, and make requesting CA certs easier.

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

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 -> 

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.


CategoryHomepage

ClintonEbadi (last edited 2019-05-10 14:33:51 by ClintonEbadi)