Create a static HTML page at: status.torproject.org

The idea here is for TPO to have a status page where we can post status problem we know about so the world can learn if problems are known to the Tor team.

A great example would have been the v3 outtage recently where we could have put out a small FAQ right away (go static HTML!) and then update the world as we figure out the problem but also expected return to normal.

I propose a static website at the moment in order to have this page going very soon and easily editable by many of us namely likely the network health team and we could also have the network team to help out.

We can then over time think of better automated way to get status on that page like automatic reports of sensors/metrics we have and so on. But for the moment, just a DNS + static HTML would be grand.

Thanks!

Update, next steps:

• brainstorm/discuss requirements (see goals)
• prototype cstate (@anarcat, people seem happy with it)
• basic theming (thanks @duncan!)
• rush deployment on static site network (@anarcat)
• basic documentation (see service page)
• grant access to other teams
• setup a mirrored repo in gitolite (allow access to the same members as here!)
• setup CI in Jenkins @hiro
• figure out which categories we want? (update as needed)
• document the new git workflow for updates (@hiro)

wow! yes, for sure it is time for a status page.

added Next label

Here are the top 3 color choices for the bikeshed:

status.torproject.org
status.torproject.net
tor.network

I really like this idea.

i really like that idea, and even started planning for it in the roadmap (#40105 (closed)) as this was a request by one survey respondent: communicate better when we (i guess TPA?) have a downtime.

so if I would make a request here is to be able to piggyback TPA services here as well. i would also strongly argue to make a static website and keep it static. there's nothing worse than having your status page down because it's too complicated.

in the roadmap brainstorm, i suggested we try cstate: it's a static site generator, based on hugo, that is exactly designed to make cute status pages. it's already used by the https://sr.ht website (see a https://status.sr.ht/) so it has got to mean something good! (this would break policy a bit: we currently use lektor for static websites, but i think we do use hugo for some others, and i'm not aware of a good "out of the box" system like this in lektor).

this project could be managed through gitlab at first, and deployed with gitlab CI (and, why not, gitlab pages! or just be in the normal static mirror system), with a contingency plan on how to deploy it elsewhere if that fails. many teams could have access to it, so that it has minimal friction.

i would suggest status.torproject.org unless we want to have a different TLD. we have briefly looked at other TLDs in #40121 and (sorry @pastly), tor.network does not seem to be available. but it would be great to have a distinct TLD because attacks against infrastructure have this pesky tendency to attack TLDs as well. this is why many status pages sit on completely unrelated domain names than their primary services.

but maybe we can start simple here and just take status.torproject.org (which i would argue could be linked from check.tpo as well).

now i'm excited! :)

We do have control over tor.network just that it has a complicated story where every time we use/mention it, somehow a very angry confused person is summoned from the Internet and we get some backlash. Also, that person gave us that domain in the first place ;).

I do think status.tor.network would be glorious but at this moment, I'm personally more looking to get that page rather than bikeshedding the name. I guess we can have the easy status.tpo in the meantime and argue later for a better improved domain.

Awesome @anarcat! Thanks for your help! Whatever static HTML tech you want to use, I'm behind it :).

Pointing this thread to @tpo/network-health

something that @arma mention on IRC is that this might have originally been targeted at only the network team, or at least the network-health stuff. i do think the status page should encompass all teams, to reduce the confusion (wait, do i want network.status.torproject.org? or tpa.status.torproject.org? or metrics.tpa.torproject.org? now i'm confused, and that is bad). so I would make only one grand status page.

but it's something we can discuss. in particular, @arma was worried about being able to filter past events so that "when folks start doing performance experiments" we can ask questions like "wait what was going on in january", and I'm assuming "only on the network health stuff". this might be something that cstate can do because it supports tagging issues, but it's something to keep in mind.

i'd also warn that I would keep this thing super simple. one git repo, one command to build, plain HTML, no interaction, no hooks, no automation. maybe RSS feeds. it's a manually curated site, to be used in emergencies, so it needs to get out of our way and just work. no thinking, just dump and run.

so if I would make a suggestion here: no ponies. simplest thing possible.

oh, and sorry for flooding this issue, but what I would typically do next is create a service page detailing the requirements (as brainstormed here) and possible implementations. then people can comment on that and add/remove stuff... makes sense?

see for example the videoconferencing study and the template it is based on.

Sounds good to me.

I'm very in the "no ponies, KISS" camp so the sooner the better I would say and we could run the "service page" in parallel for improvements?

At the moment, I believe the health and network team should have access because they are the likely ones noticing network issues first.

Yes, I agree with that. I am in the "no ponies" camp for the whole web, so definitely for that status page. :)

Thanks for getting this started @dgoulet! I'd love to see this page up and running sooner than later for network-health parts at least (and I am in the pro tor.network camp, too).

alright, here's the spec: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#discussion

see if the "Goals", in particular, are up to your requirements, and clarify if any are missing. i'll try to build a cstate prototype next.

assigned to @anarcat

unassigned @anarcat

added Network health label

removed Network health label

added For Network Health Team label

assigned to @anarcat

@duncan can you keep an eye on this ticket for when people have something up? Your input would be greatly appreciated.

Sure thing, thanks @gaba.

@duncan what do you think? https://paste.anarc.at/publish/2021-01-19-F1FqM7gOq8-0BGmVGzc5ttOLyT44le1-kioBq25tLgk/

@tpo/network-health @tpo/core here's a first prototype, based on the cstate example:

https://paste.anarc.at/publish/2021-01-19-F1FqM7gOq8-0BGmVGzc5ttOLyT44le1-kioBq25tLgk/

don't publicise too widely, that's my home server, litterally hosted in my basement. :p

obviously, the service list and categories must be tweaked a bit more (that's in config.yaml).

@duncan i didn't really try to theme this, other than changing the logo from the frontpage. some theming seems to happen inside config.yaml.. but i'm not super familiar with hugo theming, let me know if you get stuck. i'd say don't go crazy theming this just yet too, maybe we won't pick this tool if people don't like it...

source code:

https://gitlab.torproject.org/anarcat/test-status-site

to build, just:

sudo apt install hugo
hugo

... the magic will be in the public/ directory. push that to a webserver, or you can also run one locally with:

hugo serve

nice, no?

added Doing label and removed Next label

Good stuff! I am not sure why I am supposed to enable JavaScript given that this should be a simple, static website but overall looks nice.

Good stuff! I am not sure why I am supposed to enable JavaScript given that this should be a simple, static website but overall looks nice.

uh! that's annoying, i hadn't noticed... we should probably just remove this thing...

well that was easy... https://gitlab.torproject.org/anarcat/test-status-site/-/commit/ab04a7043dc00d26da4ed62f16093333096cea34 fixed!

Sweeeet.

So basically, this would be a git repo, we edit it, push and then the status page would get updated type of idea?

Exactly, yes. You can also just build locally and push wherever, in an emergency.

Thanks @anarcat, it looks good! I spotted the noscript on TB Safest too but nothing looks to have broken.

There are some basic customization options in config.yml (header, color) but beyond that it's probably not worth customizing it any further. The CSS is pretty scattered and the developer seems to frown upon it.

Alternatively (or for v2 of the status page) we could take a regular content template from tpo.org and add a style for statuses, which would be more on brand, could include the normal site header/footer, and would be relatively straightforward to integrate into lektor and add other components like FAQs.

mentioned in issue gitlab#29 (closed)

Thanks @anarcat, it looks good! I spotted the noscript on TB Safest too but nothing looks to have broken.

Yeah, that should be fixed now.

There are some basic customization options in config.yml (header, color) but beyond that it's probably not worth customizing it any further. The CSS is pretty scattered and the developer seems to frown upon it.

Could you provide a patch to improve on those colors?

Alternatively (or for v2 of the status page) we could take a regular content template from tpo.org and add a style for statuses, which would be more on brand, could include the normal site header/footer, [...]

There are already ways to add a custom header/footer and tabs to link to other places. if you look at the index.html upstream template, you'll see:

  {{ partial "footer" . }}

... which includes layout/partials/footer.html, which then has hooks for custom header/footer stuff:

{{ if .Site.Params.enableCustomHTML }}
  {{ partial "custom/above-footer" . }}
{{ end }}
[...]
{{ if .Site.Params.enableCustomHTML }}
  {{ partial "custom/below-footer" . }}
{{ end }}

the "partials" can be overridden without patching the theme: just drop files in layout/partials/ in our own git repo as i did in https://gitlab.torproject.org/anarcat/test-status-site/-/commit/ab04a7043dc00d26da4ed62f16093333096cea34

and would be relatively straightforward to integrate into lektor and add other components like FAQs.

so i have no idea what i'm doing here, to be really honest. :p i'm just masquerading as a web designer, but obviously, my skills are not that developed on that front. :)

maybe there's a way to do all of this in lektor - i'd be happy either way. but i really like the way you have all that "category/system" stuff which allows us to quickly file issues against categories. i was also pleasantly surprised to see that it calculates average downtimes and all that stuff for us. it's pretyy neat...

either way, i'd be happy to let the web people handle things from here on. as long as I have a git repo i can push to and some magical HTML comes out of that with one command, i'm happy. i can handle the CI/deployment side of things of course.

just let me know. :)

maybe there's a way to do all of this in lektor - i'd be happy either way. but i really like the way you have all that "category/system" stuff which allows us to quickly file issues against categories. i was also pleasantly surprised to see that it calculates average downtimes and all that stuff for us. it's pretyy neat...

No problem. I'm sure everyone wants to get this up quickly too, so I'll just go ahead and fix the colors :)

Thanks @anarcat!

Here's the patch too: https://gitlab.torproject.org/anarcat/test-status-site/-/merge_requests/1

awesome thanks

it seems people are happy with cstate as a solution so I went ahead and made that project a little more official:

https://gitlab.torproject.org/tpo/tpa/status-site

now of course, we need to think about deployment. i see three options:

1. deploy on gitlab pages (requires setting up gitlab pages, and therefore probably first fix #40121 )
2. deploy on the static mirror network, with Jenkins (ugh)
3. deploy on the static mirror system, by hand

I'm likely to do 3, in the short term, just to get things rolling. What do people think?

And who wants access to the status page? should i grant access to all of @tpo/core and @tpo/network-health?

Yup I would go for that for the access since they are the likely people to notice issues the quickest. Thanks!

That option (3) is the git hook basically so by hand you mean git push on my side and then done?

Yup I would go for that for the access since they are the likely people to notice issues the quickest. Thanks!

okay, i'll grant the two teams access to the repo already.

That option (3) is the git hook basically so by hand you mean git push on my side and then done?

nah, (3) is just a hack: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#uploading-site-to-the-static-mirror-system

you basically clone the git repo, build the site locally, rsync to the static source, then run the static mirror voodoo. @hiro is working on throwing this into jenkins or maybe gitlab CI, but i had to get something running quickly and that's what i knew.

And who wants access to the status page? should i grant access to all of @tpo/core and @tpo/network-health? Yup I would go for that for the access since they are the likely people to notice issues the quickest. Thanks! okay, i'll grant the two teams access to the repo already.

that is now done. somehow i had to do this as an admin, see upstream issue 299452

i did option 3 for now. it's clunky and janky and weird, but we got something up and running:

https://status.torproject.org/

outlined next steps in the issue summary, but basically:

• setup CI in jenkins or gitlab CI (+pages?)
• grant access to other teams (will require granting access to CI and/or static site system)
• figure out which categories we want? (maybe update as needed?)

changed the description

i'm done here. i'm throwing it back into the backlog in case people want to finish things up. :) happy to grant access, discuss, answer any questions if there's anything else.

added Backlog label and removed Doing label

unassigned @anarcat

Looks great @anarcat!

We'll just need to be careful regarding placeholder content in case it gets indexed/spotted before everything's ready. Don't want to cause any headaches for the comms team.

I think we should clear the Incident history for now at least? And perhaps the categories too, until they're finalized?

Looks great @anarcat!

Thanks, although you probably deserve a lot more credit than me on that front. ;)

I think we should clear the Incident history for now at least? And perhaps the categories too, until they're finalized?

I can do that, but it seems fairly accurate right now. Is there anything specific you think is problematic in there?

We'll just need to be careful regarding placeholder content in case it gets indexed/spotted before everything's ready. Don't want to cause any headaches for the comms team.

I'm sorry to put it like this, but... we have a comms team? :)

I can do that, but it seems fairly accurate right now. Is there anything specific you think is problematic in there?

The v3 onion services incident in particular. I think comms may want input on the wording there, we've been very specific about how we describe it.

I'm sorry to put it like this, but... we have a comms team? :)

Ha, believe it or not, we do!

The v3 onion services incident in particular. I think comms may want input on the wording there, we've been very specific about how we describe it.

Okay, i'll remove the post.

Ha, believe it or not, we do!

Ouch! Sorry, i thought that everyone was gone back in may... Apologies!

Okay, i'll remove the post.

done.

Thanks!

Ouch! Sorry, i thought that everyone was gone back in may... Apologies!

There's a small group of us part-timing it :)

There's a small group of us part-timing it :)

sorry again, i'll make sure to keep you folks more in the loop next time i go crazy like this. :) comms@, right? do you have a gitlab project or team?

No prob! And yup, it's comms@.

do you have a gitlab project or team?

Not at the moment, afaik.

There is something at https://gitlab.torproject.org/tpo/operations/communications

Ah, thanks @gaba! I haven't been added to that project.

that's a 404 here, presumably i don't have acess... but there's no team per se? should tpo/operations have access here too?

for what it's worth, in #40145 (closed) i setup a new runner which basically cleared the backlog of jobs, and made it possible to start using CI here, either hooked in jenkins or gitlab pages. i haven't investigated gitlab pages any further. in any case, @hiro offered to help with jenkins, so i'll reassign...

assigned to @hiro

added Doing label and removed Backlog label

after a discussion inside TPA, it seems that, at least in the short term, this will need support from gitolite and jenkins to be buildable from Git, and pull requests presented here will need to be merged in gitolite by hand. it certainly beats the current "needs anarcat's workstation" workflow.

we have discussed alternatives to jenkins as well, and i summarized the discussion in https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/static-component/#replacing-jenkins-with-gitlab-ci-as-a-builder

changed the description

marked the checklist item setup a mirrored repo in gitolite (allow access to the same members as here!) as completed

marked the checklist item setup CI in Jenkins @hiro as completed

building on jenkins.

closed

hey @hiro,

thanks for moving this into jenkins! could we get a better idea of the workflow from here on? i assume we need to push to git-rw from here on? what's the URL of that repo?

could you update the service docs accordingly?

https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status

I can do that too, but i'm missing a few pieces...

also - who has access to the git repo?

updated the issue summary with that last step.

reopened

changed the description

marked the checklist item grant access to other teams as incomplete