General Meeting 0.0 Aug 2014
Where: Rutland Arms
When: 6:30pm (2014-08-05)
- 1 Action items
- 2 Next Meeting
- 3 Why are we doing this?
- 4 How is the group being organised?
- 5 Who are we? (please add names below)
- 6 Infrastructure
- 7 How much do we want to spend?
- 8 Hosting
- 9 Who has what experience?
- 10 Name / domain
- 11 How is the group going to be organised?
- 12 Next steps
- 13 How do we evaluate software choices?
write/steal written constitution -- discuss further on IRC
- http://ox.compsoc.net/about/constitution/ !? https://www.webarch.net/rules ?! (or some stock co-op thing)
wiki (hosted elsewhere) for bootstrapping -- caolanm
mailing lists (1 initially) for bootstrapping -- committee etc lists later -- graphiclunarkid
IRC channel (non-sheffgeeks) -- jkg
schedule meeting to define provisioning/documenting etc (devops shiz) - this is the playing field on which we build all the various services
when: wednesday, 13th Aug 2014 - 6:30pm, rutland arms (TBC)
name / domains
Why are we doing this?
using hosted services currently and would rather not
many of us are self-hosting things and sharing maintenance could make things easier
makes difficult things possible (eg email) if we help each other
we have actually shared resources to host (eg, sheffgeeks, git repos)
jkg: interested in doing this again with new tech available (eg, chef, puppet, docker...)
To learn how to self-host things and to teach the same skills to others?
just providing vms has been done already - providing applications / alternatives to online services is what we're looking at
How is the group being organised?
- jkg: wonky: completely concensus driven - every decision made by paying members (there are non-paying members that don't vote) - seems to work (group-size: 5 members, dozen users)
- earth.li - has a benevolent dictator for life - nobody else has root
who handles the money?
- in the example case of wonky - jkg sends out bi-monthly-ish accounts (very ish)
- require a treasurer and a (bi-)monthly report
How formal an org structure do we need -- i.e. limited co, co-op/association with proper documentation, or just a casual arrangement and trust
do we want a bank account? YES unanimous
roles (at least):
- people can volunteer for leading projects
- Community manager? (To facilitate projects). Or can the chair perform this role to start with?
- role for security / root (more than one person)
Who are we? (please add names below)
- James Green (jkg)
- Richard King (graphiclunarkid)
- Edward Saxton (ejs)
- Gary Martin (allegary)
- Caolan McMahon (caolanm)
- Mat Booth (mbooth) - maybe
What infrastructure do we need today? (can be bootstrapped on other's vms for now)
- wiki to document deployments
- mailing lists
- etherpad for meetings (currently hosted with caolanm)
- simple static hosting (nginx obviously :P) - can host sheffgeeks event page and anyone's static site they may want to move off github pages
How much do we want to spend?
- wonky example: ~ 9 GBP / month each
- we're thinking about 10 GBP / month
Is this actual expected cost or just a guess? - in a sense this is a guess as we have not costed up all that we need. We are expecting there to also be an initial setup cost
What do we want to host?
I think at the pub meet-up people should order this list in terms of value. Let's build the most valuable things first! +1, also we should focus on things which let individuals / subgroups build things (e.g.. decide on our general handling of traffic on 80 and 443, so that people can run wikis, etherpad and other stuff behind it). Could we use a shared Trello board for this?
- an instance of etherpad
- Tor hidden services for comms servers
- Tor relay? (Only if we have the data transfer capacity)
- XMPP server
- IRC server
- Owncloud https://owncloud.org/
- I understand this provides next) Calendar? Yes.
- I am not so keen on the big solution for everything thing though
- one note: if OwnCloud is what I think it is, it's not very valuable in an environment where multiple people have root
- Listing the features we want out of owncloud is probably better than specifying owncloud - if it fits it may still be chosen of course
- Hmm, owncloud appears to be in Fedora
- Calendar (CALDAV)
- consider something that Flock can use as a server - https://whispersystems.org/blog/flock/
- gitlab/gitorious or similar
- irc bouncers (e.g: bip/znc)
- a reverse-proxying web server I can run PSGI-based apps behind
- burritobot??? - I expect so
- email (with a very conservative, slow, switchover ;) forwarding emails first? for reference, wonky.org uk offers email for local accounts and forwarding for domains (incl. forwarding into local accounts) which works OK for us
- mailing lists
- Consider mailman3/hyperkitty -- https://lists.stg.fedoraproject.org/archives/ it is a modern interface for good old fashioned mailing lists that has actually had input from real live user experience people
- also, I generally agree with this post on mailman's security policy: http://www.jwz.org/doc/mailman.html - debian uses smartmail I think, would need a web frontend for archives though
- rss reader
- For authenticating all these services
- Shared or private contacts lists.
- Full identity management? http://www.freeipa.org/page/Main_Page
- Community self-documentation (how we built this, how it all works)
- For projects
- Mediawiki seems a bit heavy duty -- is there anything a bit lighterweight? If you want something for projects maybe a Bloodhound/Trac instance would be ideal? While I would love to be able to recommend bloodhound, that might also be considered heavyweight for a wiki if that is all that is wanted - would gitlab or similar also have there own ticket system? (How heavy duty is mediawiki anyway?) I have no idea, but isn't it PHP? Who wants to maintain a PHP service? ;-) - it has a sqlite adapter which might be nice for resource usage (less overhead when not in use, perhaps)
- Ikiwiki doesn't suck too badly (as software goes)
- (I could go on)
- dokuwiki is a thing I heard of once
- http://gitit.net/ - written in haskell with markdown and git backed storage, nice ;)
- Static sites for local user groups?
Where do we want to host it?
Not in the UK or the US.
Iceland is good for privacy & freedom of speech - but expensive
Germany is cheap - and not in the 5eyes coalition...
- I've had good experiences with Hetzner.de (Likewise, +1 Hetzner)
- Hetzner's best-value offering is bare-metal only, so if we wanted to run multiple VMs, we'd have to manage all that ourselves. Extra sysadmin work but cheaper for >2 VMs.
- Auction machines are good value: http://serverboerse.de/en/
- on reflection I wouldn't mind avoiding hetzner, to reduce my dependence on them as a sole provider
If it must be in the UK I can recommend either Bitfolk (in which case can I have the referrer props? ;-) or Bytemark (seconded) (+1 Bytemark) supporting localish companies might be nice if we are going with UK (particularly if that gives us the possibility of visiting)
- Bitfolk (http://bitfolk.com) has very generous data-transfer allocations (400GiB out / 800GiB in per month) and good shared services (DNS secondaries, backup, Spamassassin, apt-cacher)
- Bytemark BigV (https://www.bigv.io/) has easy provisioning of basic services for many users (like accounts, email addresses, web hosting) and I think more disk space and RAM for the same cash. (and a spam filtering service)
What does the overall thing look like?
- one big machine running everything
- lots of VMs
- I suggest two VMs: one for hosting "stable" stuff and one on which to develop new services that can be brought over to "production" when they're ready. staging and production?
- We may also wish to split things up according to resources required. E.g. running Spamassassin / Clam AV requires lots of RAM; Tor / Bittorrent requires lots of data transfer capacity; email needs lots of disk space. A single VM with all these could prove expensive.
- It would be great to use something like Puppet/Ansible/SaltStack/Docker to make things portable/repeatable in case of disaster/wishing to move to alternative hosting.
- Config files should be kept under source control so we can roll back mistakes
- I'd expect some services to be classified as important enough to separate onto their own VM and the number of available VMs to change over time
Who has what experience?
Perl :-) and deployment thereof. Ubuntu/debian stuff. Stuff and things. Also I currently do all the sysadmin and money stuff for a similar group...
- Exim/Dovecot for mail
Fedora/RHEL/CentOS expertise, Java, shell script, rpm -- mbooth (I'd be surprised if I can help I am not really a webby person -- noting down just in case)
- One thing that may come in useful that I *can* do: If there is something not in the distro that you want to be able to "yum install" -- I can help with that
Python and some debian stuff and burritobot
I have also been involved in running a similar initiative in the past: a shared server for a bunch of geeks in Sheffield.
Debian & derivatives.
- I host my own web (nginx), email (postfix / dovecot), DNS (Bind), XMPP (ejabberd), SIP (kamailio), Mumble, Tor relay and Bittorrent (transmission) servers.
Debian - Node/CouchDB hosting - I host nginx, TinyTinyRSS, GitLab, SoGo (groupware: calendar + mail) and email with dovecot/postfix/clamav/spamassasin on Bytemark - with monit and haproxy
Name / domain
are we hipster enough for .io
Avoid .com, .net, .org and .uk as the countries that control these TLDs are prone to claiming rights over subdomains, cutting them off arbitrarily.
sheffield.is and sheffieldtech.is are both available (Iceland)
How is the group going to be organised?
Who gets root? Kevin
Who looks after money?
How do we relate to other similar groups?
How do we avoid single points of failure?
- Only one person has access to $SYSTEM / knows how $ESSENTIAL_THING works.
- Nobody can do anything without the say so of $PERSON
- Somebody is being a dick and nobody knows how to get rid of them / make them stop
Cake or death or beer but mostly beer
The cake may be a lie
The beer is not a lie
Profit! - I don't want any profit
Tough. Eat your profit.
How do we evaluate software choices?
eg, must be Open source +1 (+ Free not as in beer - um - libre) [but let's not go all DFSG-strict about this] what particular problems would DFSG-strict bring us? the constraints are theoretically excellent but sacrifice some pragmatism; I'm not hugely interested in being puritanical about non-editable clauses in bash documentation or the branding of mozilla products -- not that it's a deal breaker
choose also on ability to migrate to alternative choices (standards compliance, etc if relevant)
Must support strong cryptography for communication (preferably we'd enforce this by only exposing services via encrypted protocols).