Mastodon @ OCF

We’ve discussed running a Mastodon server at the OCF as a public service for OCF members. We should do so, because it’s cool, adheres to our principles of using free and open source software, and we can, for example, federate with MIT’s Mastodon server, which makes it extra cool.

It’s available standalone or as a docker container. with the docker container, we can probably put it on marathon and point the database to our future postgres service and point redis to gridlock.

1 Like

This is something I’d really like to do, especially after learning that SIPB (MIT’s OCF equivalent) has done this.

While I don’t expect deploying Mastodon itself to be difficult, we need to figure out a way to handle user login authentication. Here’s a survey of the different methods I’ve seen used at the OCF:

  • Apache’s Kerberos integration (RT does this)
  • nginx’s auth_pam module (Discourse and Marathon admin use this)
  • ocflib’s password_matches command, which calls out to the kinit (Kerberos) command (ocfweb uses this).

The first two use HTTP authentication, which I’d expect to not work well with Mastodon, which wants to show its own username/password forms. The last one probably wouldn’t work either since we can’t use ocflib.

This requires some more investigation into Mastodon’s options for auth (I found this thread). We might need to use their LDAP integration, which means we will have to figure out how to set that up on our end. LDAP auth is notoriously difficult. I only have some low-confidence ideas for how to get it to work. We might need another thread for discussing that.

(EDIT from much later: I finally figured out how to get LDAP integration working, so it should be possible to use Mastodon’s LDAP support)

We could also just generate separate passwords for users’ Mastodon accounts.

Now that Postgres is working, we can look into putting a Mastodon instance on Marathon.

I finally figured out how to get LDAP integration working for other apps, so my past comments on this thread about auth can be disregarded. This should make deploying Mastodon a much easier experience for us. I’m marking this as a newbie project.

This is a great way to learn about how we use Marathon to manage “services” (Docker containers) on our infra.

fydai has a provisional version of this service successfully running on hozer-87:443

@fydai can you let us know the progress on this?

Was on pause for past 3 weeks due winter break. I need about 2-4 more hours of work to get it production-ready, assuming kubernetes is ready for production services.

Near the beginning of the semester, BoD voted on moderation guidelines for Mastodon. Now, we need to actually implement these. To do so, I suggest we choose (elect?) three moderators that plan to regularly use Mastodon. They can serve essentially unlimited terms until they step down or are forced out by BoD or whatever. I would be willing to be one of these three people.

Moderation decisions should require two of the three moderators to agree on an action. We can use a low-volume private slack channel (with notifications on) for this purpose. Actions should all be logged at as specified in the moderation guidelines, including the two (or three) moderators that approved the decision. (Note that Mastodon has an internal audit log that should mirror our public log.)

Finally, we should figure out what to put on the Terms of Use and Privacy Policy page. Currently this is the Mastodon default. We also need a short blurb for the pre-login landing page.