welcome: please sign in

Diff for "ClintonEbadi"

Differences between revisions 22 and 23
Revision 22 as of 2013-01-08 07:56:48
Size: 4417
Editor: ClintonEbadi
Comment: actually did some stuff
Revision 23 as of 2013-01-08 08:43:50
Size: 6326
Editor: ClintonEbadi
Comment: adjust timelines... some things bumped back, others forward. Not too far behind schedule.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
I am Clinton Ebadi. 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:
 * October 2012: New website online, navajos and bog both up with new members using them
 * October 2012->
January 2013: Big push for new members. New website should make us seem more alive, we've finally fixed about 3/4 of the "temporary" hacks from when we first moved to Peer1, etc. In the background, prioritize getting rid of mire (less work: we just have to get people off of it), but also work toward getting rid of deleuze. Web services first (low hanging fruit), even if it means punting on fully converting to domtool managed sites (at least packaged and documented). AFAICT other than those we're just left with:
 * January 2013: New website online, navajos and bog both up with new members using them
 * February 2013->December 2013:
Big push for new members. New website should make us seem more alive, we've finally fixed about 3/4 of the "temporary" hacks from when we first moved to Peer1, etc. mire is gone (less work: we just have to get people off of it), but also work toward getting rid of deleuze. Web services first (low hanging fruit), even if it means punting on fully converting to domtool managed sites (at least packaged and documented). AFAICT other than those we're just left with:
Line 21: Line 21:
 * April 2013: Election and hopefully 150 members. Mire has been turned off for at least a month at this point.
 * Summer 2013: Assuming 150+ members, more disk space and perhaps more bandwidth are in order. Deleuze should be safe to turn off by now at the latest.
 * Late Summer 2013: Catch the sales on the last generation Dell 2U/2-socket machines and create a clean counterpart to fritz
 * March 2013: Catch the sales on the last generation Dell 2U/2-socket machines and create a clean counterpart to fritz.
Line 26: Line 24:
     * For the first time, this is realistic: all of those months packaging our configuration pay off by sparing future-me from herculean efforts.
   * Fritz becomes the last-generation backup server (secondary dns + kdc + MX + xmpp + load balancing with apache? + automagic database replication for members + ???)
     * For the first time, this is realistic: all of those months packaging our configuration pay off by sparing future-me from herculean efforts. And SteveKillen, BtTempleton, and I are probably available for a road trip to Peer1.
 * March 2013->July 2013: Transition remaining services off of deleuze onto KernelVirtualMachine``s on new kvm host
 * April 2013: Election and hopefully 120 members. Mire has been turned off for at least a month at this point.
 * Winter 2013: Assuming 150+ members, perhaps more bandwidth is in order. Deleuze should be safe to turn off by now at the latest.
Line 29: Line 29:
   * IPv6, mediagoblin, diaspora, gitorious, xmpp works again (and ability to use vanity domains), ...
Line 56: Line 57:
 * Change SPF for `hcoop.net` to mandate that all mail come from `mail.hcoop.net`.
   * And something like `addHcoopSPF` for members to set the same record if they want to forward through us
 * x Change SPF for `hcoop.net` to mandate that all mail come from `mail.hcoop.net`.
   * x And something like `addHcoopSPF` for members to set the same record if they want to forward through us
Line 59: Line 60:
 * Don't generate backscatter when spammers send mail to users forwarding offsite  * ? Don't generate backscatter when spammers send mail to users forwarding offsite
Line 62: Line 63:
 * https://support.google.com/mail/bin/answer.py?hl=en&answer=175365
   * Inform members what they can do...
   * It appears we actually bounce to the local postmaster so we might be OK
 * x
https://support.google.com/mail/bin/answer.py?hl=en&answer=175365
   * x Inform members what they can do...
Line 82: Line 84:
== domtool plans ==
Line 83: Line 86:
 * Feature backlog
 * SSL improvements (SNI, intermediate certificates, ...)
 * Networked domtool-tail
 * FastCGI
   * Seems like the most straightforward of the fancy CGI to persistent server replacement to gets working, and has wide support. MoinMoin can use it... and it's a lot less tricky for members to get working than proxied servers on another host.
   * Ideally, support wsgi and whatnot later, assuming they can do suexec
 * `default CSymbol = Value` for binding default environment variable settings
    * Expands the scope of extensions that can be written in pure DomTool, slight flexibility gains
 * Improve `fwtool` as needs become clearer
   * `fwtool regen` without node to regen all nodes, `fwtool verify` and possibly something akin to `visudo`
   * Programmitic interface to adding/removing/etc rules?
     * At least need a way to kill rules when destroying the user, ideally just disabling them? (existing code ignores users who do not exist, so it sort of works to ignore it, but cleanliness of the rules file will become a problem).
   * "Proper" parser. Read rules into typed structure using the magic of SML, and work on that form (more natural, type safe, etc.)
   * groups or similar for common ports
     * We need a way to grant users who just want general net access a reasonably unrestrictive firewall, without needlessly opening things for members who don't use our shell services extensively. Since we can't restrict socket permissions generally, defining groups that provide common firewall rules seems like an ok solution.

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.

  • January 2013: New website online, navajos and bog both up with new members using them
  • February 2013->December 2013: Big push for new members. New website should make us seem more alive, we've finally fixed about 3/4 of the "temporary" hacks from when we first moved to Peer1, etc. mire is gone (less work: we just have to get people off of it), but also work toward getting rid of deleuze. Web services first (low hanging fruit), even if it means punting on fully converting to domtool managed sites (at least packaged and documented). AFAICT other than those we're just left with:

    • DomTool dispatcher

    • Master DNS
    • Exim
    • IMAP (might have to patch courier-authdaemon)
    • A few straggling openafs volumes (+ AFSDB records?)
    • Backups
    • MailMan

    • The portal
  • March 2013: Catch the sales on the last generation Dell 2U/2-socket machines and create a clean counterpart to fritz.
    • 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. And SteveKillen, BtTempleton, and I are probably available for a road trip to Peer1.

  • March 2013->July 2013: Transition remaining services off of deleuze onto KernelVirtualMachines on new kvm host

  • April 2013: Election and hopefully 120 members. Mire has been turned off for at least a month at this point.
  • Winter 2013: Assuming 150+ members, perhaps more bandwidth is in order. Deleuze should be safe to turn off by now at the latest.
  • Spring 2014: Ponies for everyone.
    • IPv6, mediagoblin, diaspora, gitorious, xmpp works again (and ability to use vanity domains), ...

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)

4. Websites

5. Admin Stuff

5.1. Terrible Things

Since we are having a roll call soon, we need to deal with these.

  • phpVersion needs to change

5.1.1. Mail

  • Change DefaultAlias to false in the vain hope it makes gmail like us more. Side effect is less spam for everyone.

    • Really need to support $user+$local addresses for this to work well
    • Ideally we could drop spam and whatever, but that's a lot of work and possibly not the right thing
  • x Change SPF for hcoop.net to mandate that all mail come from mail.hcoop.net.

    • x And something like addHcoopSPF for members to set the same record if they want to forward through us

    • "-all" spf for mire/navajos/fritz/hopper.hcoop.net ? Possibly no, need to figure out rewriting to make sure no mail gets out with the hostname
  • ? Don't generate backscatter when spammers send mail to users forwarding offsite
    • Really not sure how to do this and not violate various RFCs
    • Looks basically impossible for gmail, best strategy is to mitigate spam sent to them in the first place
    • It appears we actually bounce to the local postmaster so we might be OK
  • x https://support.google.com/mail/bin/answer.py?hl=en&answer=175365

    • x Inform members what they can do...
      • Add receipt address to send as, exim filter rule to nuke spam, ...
      • Can we add SPAM to the subject of all messages going to gmail that are marked as such by SA?

Immediate steps:

  • x Change SPF records for hcoop.net and define addDefaultSPF (mx -all, making it effectively universal)

  • x Recommend DefaultAlias = false

  • x Point members at google forwarding docs
    • x Directly suggest "send as..." change
    • Don't forward spam if possible (solicit an exim rule from a member...)
  • Fix exim TLS certificate (deleuze instead of mail)

DONE Update docs with warnings for gmail users about steps they need to take to avoid having all hcoop mail rejected:

5.2. domtool plans

  • Feature backlog
  • SSL improvements (SNI, intermediate certificates, ...)
  • Networked domtool-tail
  • FastCGI
    • Seems like the most straightforward of the fancy CGI to persistent server replacement to gets working, and has wide support. MoinMoin can use it... and it's a lot less tricky for members to get working than proxied servers on another host.

    • Ideally, support wsgi and whatnot later, assuming they can do suexec
  • default CSymbol = Value for binding default environment variable settings

    • Expands the scope of extensions that can be written in pure DomTool, slight flexibility gains

  • Improve fwtool as needs become clearer

    • fwtool regen without node to regen all nodes, fwtool verify and possibly something akin to visudo

    • Programmitic interface to adding/removing/etc rules?
      • At least need a way to kill rules when destroying the user, ideally just disabling them? (existing code ignores users who do not exist, so it sort of works to ignore it, but cleanliness of the rules file will become a problem).
    • "Proper" parser. Read rules into typed structure using the magic of SML, and work on that form (more natural, type safe, etc.)
    • groups or similar for common ports
      • We need a way to grant users who just want general net access a reasonably unrestrictive firewall, without needlessly opening things for members who don't use our shell services extensively. Since we can't restrict socket permissions generally, defining groups that provide common firewall rules seems like an ok solution.


CategoryHomepage

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