Hello and Welcome!
There are a few things you should check out:
- Our Tech group on Loomio. (Join our main Loomio group here, then ask to join the tech group here, it should also be visible in the side-bar when you're on our main group)
- Join one of our meetings which should be listed on the Calendar.
- Look at the group's running notes document which records meeting discussion which also get posted to Loomio
- Our GitLab group on git.coop. (If you're reading this you've probably done this already, but if not see here)
- Our matrix chat channels:
- The public social.coop channel (for general chat, but I suggest we use it as a rendezvous point when we notice an issue we need to coordinate on, this way everyone on the channel can check the situation)
- The socialcoop-tech for technology specific discussion.
- There was a private, encrypted tech group as well, but as of March 2023 it doesn't seem to be active. It's hard to tell because it is invite only.
Passwords and other secrets!
See the our pass repository for details about how our passwords and other secrets are managed. We use the pass utility to manage them in git.
Git.coop, GitLab and Git
Hopefully you will already know a bit about these, but it should suffice to say:
- Git is a distributed version control system
- GitLab is an open source web user interface built on top of it
- Git.coop is the instance of GitLab which the Web Architects Co-op host for their members.
Documentation
The project whose wiki you're currently viewing is where we keep our internal documentation. The wiki is backed by a Git repository, like the project's main repository but separate. The GitLab wiki has a slightly different user interface which makes it more wiki-like than the main repository's user interface.
The pages are all editable via the web user interface, or by directly editing files in the repository and pushing the changes back to the GitLab server. The documentation is mostly in GitLab-flavoured Markdown, but other formats are supported (for instance, emacs org-mode mark-up). Markdown is meant to about as hard as formatting a plaintext email message, but you should see a link to a cheat-sheet about this at the bottom of the edit box when modifying a page in the web UI.
Supporting files and scripts can go in the main repository (see the link on the left-hand side bar of the GitLab UI).
Issues
Also in the left-hand sidebar is a link to the GitLab issues database for this project. We use this to:
- keep track of problems we need to, or are in the process of resolving, as well as
- an ideas bucket and
- a wish-list.
In the tech group at least, there are a set of labels which can be used to prioritise and categorise issues. There's a description here.
Recurring tasks
We also have some recurring tasks which need to be done to maintain the servers, the organisation and documentation of which are a work-in-progress. The ambition is to have one or two people responsible for each one. Initially, we will need volunteers also to clarify the processes and draft the documentation, so that the skills are transferable among us.
See here for the document outlining these tasks.
Outage
When there is a server outage, I recommend:
- Checking who is on the case already, if anyone, in the matrix channels (see links above).
- FIXME: We don't currently have a means to announce these externally, but perhaps we should
- Creating an issue for it labelled ~"Outage!", describing the initial problem and the time it occurred
- FIXME: We don't currently have a guide for fixing outages, but we do kinda need one.
I'd propose that everyone involved in resolving the issue keeps a record of what they did in the issue: i.e., steps taken, and where possible console commands and their output. Besides being a record, I hope this will create a common resource of prior-art and diagnostic tips and clues for the group, and especially newcomers. My aim is to be able to use this to condense down guides and how-tos which are easier to navigate. (They can later be found by searching for closed issues with the ~"Outage!" label. Some examples so far: #13, #14.)
Datadog
We currently have a freebie Datadog account, which is a very useful tool for monitoring our cluster of Docker services and visualising the result. (Free plan includes 1 day's logs retention and 150+ turn-key integrations, whatever that means.)
If you need to diagnose an outage, ask the group about this, we can allocate (probably a limited number) of additional log-ins there. The log-in page is: