|
Size: 4659
Comment:
|
Size: 6404
Comment: rm duplication
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from BtTempleton | |
| Line 3: | Line 4: |
| == 2011 Board Statement == | HCoop member since 2005; served as Secretary 2011--2018, 2022--present |
| Line 5: | Line 6: |
| I have been a member of HCoop since 2005; I wrote the Domtool Emacs mode, was involved in the 2009 migration project, started the hcoopstatus Identica group, and am [[http://hcoop.net/~bpt/hcoop/portal.html|redesigning the member portal]]. My platform: | == Contact == |
| Line 7: | Line 8: |
| * Expand to 150–250 members during the next year and end the pledge system. | * IRC: `robin` on Libera Chat * Email: `robin@terpri.org` * Mastodon: `@lispwitch@toot.cat` |
| Line 9: | Line 12: |
| * Move HCoop accounts to the National Cooperative Bank or a similar credit union. | == Admin notes == |
| Line 11: | Line 14: |
| * Implement a strong environmental policy when we are financially able to; purchase carbon offsets to compensate for our use of nonrenewable energy. | Useful commands: |
| Line 13: | Line 16: |
| * Document development processes for our custom software. Recruit more volunteers for system administration tasks. Consider applying to be a mentoring organization for Google Summer of Code 2012. | * `pts membership $USER`: show AFS group membership * `DOMTOOL_USER=hcoop domtool ...`: domtool "sudo" * `git add -p`: interactively stage hunks (no magit) * `cd ~hcoop/hcoop-wiki; PYTHONPATH=$PWD moin ...`: MoinMoin CLI (see HelpOnMoinCommand) |
| Line 15: | Line 21: |
| * Last but not least, I will print HCoop T-shirts, finishing the project that NathanKennedy began in 2005. (: | == Admin changelog == |
| Line 17: | Line 23: |
| == 2010 Board Statement == | Website performance (2026-02): Dynamic websites (e.g., webmail) performed very poorly, with slow responses and occasional timeouts. We already suspected that it was related to gitweb and poorly-behaved crawlers. (ClintonEbadi had previously blocked many UAs and IP ranges, but that didn't stop everyone.) I logged in to our main web server, ServerShelob, to investigate. `ps aux` and `top` confirmed that gitweb processes were responsible. `~hcoop/.logs/apache/shelob/git*.hcoop.net*/access.log` showed that there were a lot of requests for blobdiffs (diffs of a file between two arbitrary commits), an expensive operation. How expensive? `nproc` shows the number of logical CPU cores. `uptime` shows the 1-, 5-, and 15-minute running load average; 1.0 = one core fully utilized. `nproc`: 8. `uptime`: 17:49:36 up 177 days, 22:48, 2 users, load average: 127.39, 61.01, 33.24. I think the CPU load was actually noticeable over SSH at some points. User hcoop runs the wiki, so I edited `~hcoop/.domtool/hcoop.net` and added `rewriteRule "/blobdiff/" "-" [forbidden];` to the `publicVhost "git"` block. (Translation: match any request matching the PCRE regexp `/blobdiff/`; `-` is an "identity" rewrite as we just want to apply the flag; and the `forbidden` flag causes Apache to send a 403 Forbidden response instead of serving the request normally.) I ran `DOMTOOL_USER=hcoop domtool hcoop.net` to apply the changes, and checked that blobdiff rule was being blocked with an URL from the access log. Now the load average is down to 7.29, 29.50, 46.29 and things are subjectively much better. (The load average spiked again, with a bot spamming URLs with a specific substring, which I also blocked, so this will be an ongoing process unless we block more of gitweb or apply some form of rate limiting.) |
| Line 19: | Line 25: |
| I have been a member of HCoop since 2005; I wrote the Domtool Emacs mode, was involved in the 2009 migration project, started the hcoopstatus Identica group, and am redesigning the member portal. My platform: | == Tasks == |
| Line 21: | Line 27: |
| * Plan to expand to 150--250 members during the next year and then end the pledge system once we can do so without increasing dues significantly. | {{{ <robin> i will personally commit to making a tinkerable "hcoop-in-a-box" in 202[45], depending on the work situation [...] }}} |
| Line 23: | Line 31: |
| * Move HCoop accounts to the National Cooperative Bank or a similar credit union. * Implement a strong environmental policy when we are financially able to; purchase carbon offsets to compensate for our use of nonrenewable energy. * Document development processes for our custom software and recruit a fourth admin. Also consider making it possible for admins to delegate certain tasks to trusted non-admins. * Last but not least, I will have HCoop T-shirts printed, finishing the project that NathanKennedy began in 2005. (: == OpenID server == Would it make sense for HCoop to be an [[http://openid.net/|OpenID]] provider? [[http://pypi.python.org/pypi/gracie/0.2.6|Gracie]] is a server that authenticates users using PAM, and it's in Debian. We could allow users to register their identity URIs using domtool, as well as supporting `http://hcoop.net/~user` automatically. |
* Try out account renaming * Jitsi Meet support * ActivityPub-based libre social networking system (e.g., Mastodon, Pleroma/Akkoma, misskey, etc.; there are other AP-based services like bookwyrm, * Matrix or a similar libre text-chat system (maybe; at least we have IRC and XMPP) * Finish HCoop packaging for Guix to make it easier for non-sysadmins to experiment * ''in progress:'' Implement client-side HCoop integration under Guix System (openafs package and service completed) * Help resolve the WikiReplacement2021 situation * Automagic LetsEncrypt integration: ideally make it entirely automatic and enabled by default |
| Line 37: | Line 42: |
| Gitweb URIs: Repo.or.cz uses cleaner URIs than gitweb's defaults -- for example, `/w/foo.git/commit/abcdef` for viewing an individual commit. We should patch our gitweb script to provide something similar. It might also be useful to host hgweb and darcsweb instances. At least one user wants to host mercurial repositories, and several of us use darcs. Next meeting: sign the [[http://www.internetdeclaration.org/|Declaration of Internet Freedom]]. Also probably register as a stakeholder in GNU/consensus -- it's unclear what direction it will take but GNU-approved social networking projects are probably worth tracking Sometime this year: start a Planet HCoop again! ([[http://intertwingly.net/code/venus/]]); set up an independent MeetBot instance Fix moinmoin headings somehow. Many pages use H1 for section titles which makes the outline (in the html5 sense) nonsensical and contradicts w3c recommendations Fix defaults that lead to serving the same resource from multiple URIs. In particular, don't serve files from `public_html` from domains by default, and use permanent redirects from the `www` subdomain to the bare domain name or vice versa Poll members about what they would like to do with free social networking services (e.g., ostatus, mediagoblin); what approaches they would prefer for vanity domains vs. central installations; use by non-members (e.g. will their friends want to use their installations, would their friends join hcoop, etc.); semi-managed installations vs. manual individual administration; ... Policy/guideline ideas: Licensing policy: (A)GPLv3-compatible for software, the usual free content licenses for other things? We may want an exception for logos, or just protect them as trademarks like Debian does. The content license(s) should ideally be GPL-compatible since we probably have some "content" that is GPL (like domtool docstrings). Relicensing the wiki may be difficult, but there are probably not many (15, 20?) contributors of substantial amounts of currently-relevant text, excluding homepages. Internal writing guidelines: use gender-inclusive language; promote only FreeSoftware officially, and ask that people consider FreeSoftware principles and the SevenPrinciples when officially recommending a service or organization; write "GNU/Linux" instead of "Linux" when referring to the entire OS |
* Registrar recommendation update: gandi is still good (imo) but now overpriced; namecheap, porkbun, and ssl2buy have been suggested by hcoop and systemcrafters ppl * Allow use of GNU Guix on HCoop. Evaluate resource requirements, consider ways to calculate "space quotas" fairly (or even define what that means with guix). It works well with Debian and allows highly customized setups that are nevertheless "transparent" to sysadmins, as shared service usage is * Informally federate with other hosting coops and collectives? Perhaps go further and informally federate with workers coops as well? Start with a cleaned-up OtherGroups... * Better domtool usability; perhaps eldoc integration, a GUI/form-based interface to (a subset) of the language, etc. Maybe Dhall could help if the type systems are at all compatible * Become a small-scale domain reseller? (easy "buy and add a domain" system for portal) * Better voting system for board elections (ranked-choice or similar)? Purely a theoretical issue right now * Try out some gitweb alternatives, like sourcehut, gitile, .... Minimally a nicer gitweb-type browser (cgit or the guile one) would be good * Kerberos 2FA support? istr an experimental extension on github a few years ago * Single sign-on for hcoop.net services? (not kerberos-based due to lack of browser support under typical configurations, although that's theoretically possible, perhaps with a WebExtension...) (see systemcrafters note below) * Disable wiki captchas for logged-in users, or verified users in a particular group * Licensing policy (libre licensing for software and official documentation) * Contemplate new/adjusted logo design * Website design tweaks. General "refresh". Application link is not ''nearly'' obvious enough on the homepage. New framing. Slight update of general aesthetics (defaulting to some genre of 2024 website vs. 2010-era design) * Sieve support for roundcube. Probably entails moving to Dovecot which has its own advantages * Discuss possible uses of a surplus * Integricloud offers POWER9-based hosting (presumably with RaptorCS hardware), but is expensive and probably not a good candidate for several other reasons * Rethink VolunteerResponsePolicy: consider ntk's comment on admin vs. operational response times, also perhaps ''require'' sysadmins to take some time off periodically. Can we revive Sebastian's idea for hcoop volunteer days? * Idea: "deputy sysadmin" (idk) position allowing assistance to the real sysadmins without the full set of responsibilities * Evaluate other bug reporting/ticketing systems like osTicket and debbugs (the latter is used for both Debian and GNU packages). osTicket for service requests and maybe reserve debbugs, bugzilla, software forge ... for discussion of more serious/specific issues? * Apparently for email we should have not just SPF but also DKIM (which is way more complicated). Back MWL's book! * Review [[https://pad.drutopia.org/p/libresaas|LibreSaaS list]] and the project list linked in {{{#systemcrafters}}} a bit before 9 june 2024, incl. SSO systems * Debug wiki list CSS: links in items cause additional whitespace |
HCoop member since 2005; served as Secretary 2011--2018, 2022--present
Contact
IRC: robin on Libera Chat
Email: robin@terpri.org
Mastodon: @lispwitch@toot.cat
Admin notes
Useful commands:
pts membership $USER: show AFS group membership
DOMTOOL_USER=hcoop domtool ...: domtool "sudo"
git add -p: interactively stage hunks (no magit)
cd ~hcoop/hcoop-wiki; PYTHONPATH=$PWD moin ...: MoinMoin CLI (see HelpOnMoinCommand)
Admin changelog
Website performance (2026-02): Dynamic websites (e.g., webmail) performed very poorly, with slow responses and occasional timeouts. We already suspected that it was related to gitweb and poorly-behaved crawlers. (ClintonEbadi had previously blocked many UAs and IP ranges, but that didn't stop everyone.) I logged in to our main web server, ServerShelob, to investigate. ps aux and top confirmed that gitweb processes were responsible. ~hcoop/.logs/apache/shelob/git*.hcoop.net*/access.log showed that there were a lot of requests for blobdiffs (diffs of a file between two arbitrary commits), an expensive operation. How expensive? nproc shows the number of logical CPU cores. uptime shows the 1-, 5-, and 15-minute running load average; 1.0 = one core fully utilized. nproc: 8. uptime: 17:49:36 up 177 days, 22:48, 2 users, load average: 127.39, 61.01, 33.24. I think the CPU load was actually noticeable over SSH at some points. User hcoop runs the wiki, so I edited ~hcoop/.domtool/hcoop.net and added rewriteRule "/blobdiff/" "-" [forbidden]; to the publicVhost "git" block. (Translation: match any request matching the PCRE regexp /blobdiff/; - is an "identity" rewrite as we just want to apply the flag; and the forbidden flag causes Apache to send a 403 Forbidden response instead of serving the request normally.) I ran DOMTOOL_USER=hcoop domtool hcoop.net to apply the changes, and checked that blobdiff rule was being blocked with an URL from the access log. Now the load average is down to 7.29, 29.50, 46.29 and things are subjectively much better. (The load average spiked again, with a bot spamming URLs with a specific substring, which I also blocked, so this will be an ongoing process unless we block more of gitweb or apply some form of rate limiting.)
Tasks
<robin> i will personally commit to making a tinkerable "hcoop-in-a-box" in 202[45], depending on the work situation [...]
- Try out account renaming
- Jitsi Meet support
ActivityPub-based libre social networking system (e.g., Mastodon, Pleroma/Akkoma, misskey, etc.; there are other AP-based services like bookwyrm,
- Matrix or a similar libre text-chat system (maybe; at least we have IRC and XMPP)
- Finish HCoop packaging for Guix to make it easier for non-sysadmins to experiment
in progress: Implement client-side HCoop integration under Guix System (openafs package and service completed)
Help resolve the WikiReplacement2021 situation
Automagic LetsEncrypt integration: ideally make it entirely automatic and enabled by default
*scratch*
- Registrar recommendation update: gandi is still good (imo) but now overpriced; namecheap, porkbun, and ssl2buy have been suggested by hcoop and systemcrafters ppl
- Allow use of GNU Guix on HCoop. Evaluate resource requirements, consider ways to calculate "space quotas" fairly (or even define what that means with guix). It works well with Debian and allows highly customized setups that are nevertheless "transparent" to sysadmins, as shared service usage is
Informally federate with other hosting coops and collectives? Perhaps go further and informally federate with workers coops as well? Start with a cleaned-up OtherGroups...
- Better domtool usability; perhaps eldoc integration, a GUI/form-based interface to (a subset) of the language, etc. Maybe Dhall could help if the type systems are at all compatible
- Become a small-scale domain reseller? (easy "buy and add a domain" system for portal)
- Better voting system for board elections (ranked-choice or similar)? Purely a theoretical issue right now
- Try out some gitweb alternatives, like sourcehut, gitile, .... Minimally a nicer gitweb-type browser (cgit or the guile one) would be good
- Kerberos 2FA support? istr an experimental extension on github a few years ago
Single sign-on for hcoop.net services? (not kerberos-based due to lack of browser support under typical configurations, although that's theoretically possible, perhaps with a WebExtension...) (see systemcrafters note below)
- Disable wiki captchas for logged-in users, or verified users in a particular group
- Licensing policy (libre licensing for software and official documentation)
- Contemplate new/adjusted logo design
Website design tweaks. General "refresh". Application link is not nearly obvious enough on the homepage. New framing. Slight update of general aesthetics (defaulting to some genre of 2024 website vs. 2010-era design)
- Sieve support for roundcube. Probably entails moving to Dovecot which has its own advantages
- Discuss possible uses of a surplus
- Integricloud offers POWER9-based hosting (presumably with RaptorCS hardware), but is expensive and probably not a good candidate for several other reasons
Rethink VolunteerResponsePolicy: consider ntk's comment on admin vs. operational response times, also perhaps require sysadmins to take some time off periodically. Can we revive Sebastian's idea for hcoop volunteer days?
- Idea: "deputy sysadmin" (idk) position allowing assistance to the real sysadmins without the full set of responsibilities
- Evaluate other bug reporting/ticketing systems like osTicket and debbugs (the latter is used for both Debian and GNU packages). osTicket for service requests and maybe reserve debbugs, bugzilla, software forge ... for discussion of more serious/specific issues?
- Apparently for email we should have not just SPF but also DKIM (which is way more complicated). Back MWL's book!
Review LibreSaaS list and the project list linked in #systemcrafters a bit before 9 june 2024, incl. SSO systems
- Debug wiki list CSS: links in items cause additional whitespace