I spun up my own Mastodon today and quickly realized there was a 500 character limit to posts. I googled around, found some good guides and decided to make a quick bash script for it. Replace the below values inside the carrots with your settings.
The 500 character limit is why I rarely use my fosstodon account. Maybe I’ll spin up my own instance. Although I said that about akkoma and I haven’t tried to spin that up.
I don’t mean to discourage you - this is a good hack. But as a seasoned code monkey, I see a few things that can be possibly improved so they will have less chances of biting you in the future. Please feel free to disregard this, of course.
s/500/…/g
This is a bit overbroad, as it replaces any “500” in those files. It works now, as this is probably only occurrence is the limit you want to tweak, but it’s a crude approach that may inadvertently break at any moment.
docker exec
Those changes are ephemeral and won’t survive if container is re-created for any reason (unless /opt/mastodon is a volume - I guess this is how it survives docker container restart?). I would rather recommend building your own custom image. Start by making a patch file:
docker run -it --rm -user root <mastodon image> bash
cp -r /opt/mastodon /opt/mastodon.vanilla
sed <your-updates-here> # or you can run vi or nano or any other editor
diff -urN /opt/mastodon.vanilla /opt/mastodon
exit
Take diff’s output, save it to fix-limits.patch in a new empty directory, then write a brief Dockerfile next to it, that goes like this:
FROM <base-mastodon-image>
COPY fix-limits.patch ./
RUN patch -p2 fix-limits.patch
And finally run docker build -t my-mastodon . and use my-mastodon as a replacement image. This will ensure your changes will persist, plus you’ll have a proper patch file that you can use with any version (point is, it will warn you if something would change in a way that the patch would no longer apply cleanly).
I’m writing this on a phone, from scratch, without any testing, so you may need to tweak things a little bit. E.g. I’m not sure what’s the WORKDIR in the base image - just assuming its /opt/mastodon (which it probably is), but you may need to edit the COPY command’s second argument and/or -p parameter to patch.> docker container restart
Yes - same as with the original script, upgrades would require more manual steps than just updating the version in the Compose file. This is how it’s typically done.
There are ways to automate this. Docker Hub used to have a feature for automatic rebuilds when base images had changed, but AFAIK this feature was removed some years ago. Now it’s a matter of setting up a CI with periodically (nightly or weekly) scheduled pipelines, but it’s not a trivial matter.
Semi-automation can be achieved by using build-time arguments. I’m at my computer now, so here’s a revised process:
First, a bunch of manual commands that would allow us to write a patch. I’ll use those crude sed statements - just because they work today, but YMMV.
docker run -it --rm --user root tootsuite/mastodon bash
cp -r /opt/mastodon /opt/mastodon.vanilla
sed -i 's/500/1000/g' /opt/mastodon/app/javascript/mastodon/features/compose/components/compose_form.js
sed -i 's/500/1000/g' /opt/mastodon/app/validators/status_length_validator.rb
diff -urN /opt/mastodon.vanilla /opt/mastodon
This will produce a nice patch like this that you can copy. Create an empty directory and save as change-limits.patch in there:
ARG MASTODON_VERSION=latest
FROM tootsuite/mastodon:${MASTODON_VERSION}
USER root
RUN apt-get update && apt-get install -y --no-install-recommends patch
COPY change-limits.patch ./
RUN patch -up3 < change-limits.patch
USER mastodon
RUN OTP_SECRET=precompile_placeholder SECRET_KEY_BASE=precompile_placeholder rails assets:precompile
And a shell script to semi-automate the upgrades. Note it requires curl and jq to be available to parse JSON.
And finally, create a file called .dockerignore that contains only one line that would say build.sh. That’s just minor cosmetic touch saying that our build.sh is not meant to be a part of the build context. If everything is correct, there should be now 4 files in the directory: .dockerignore, build.sh, change-limits.patch and Dockerfile.
Now when you run build.sh it will automatically find the latest version and build you a custom image tagged as e.g. my-mastodon:v4.1.3, which you can use in your Compose file. For a distributed system like Docker Swarm, Nomad or Kubernetes you’ll want to tweak this script a little to use some registry (your-registry.example.org/your/mastodon:v4.1.3) and possibly even apply changes further (e.g. docker service update --image ...).
Mutable tags like latest can become confusing or even problematic (e.g. if you’ll want to downgrade it’s best to have previous version image readily available for some time - even if the build process is reproducible), so I would really recommend to use explicit version number tags.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
The 500 character limit is why I rarely use my fosstodon account. Maybe I’ll spin up my own instance. Although I said that about akkoma and I haven’t tried to spin that up.
Would a post with over 500 characters show up on an instance that has the 500 character limit?
I don’t mean to discourage you - this is a good hack. But as a seasoned code monkey, I see a few things that can be possibly improved so they will have less chances of biting you in the future. Please feel free to disregard this, of course.
This is a bit overbroad, as it replaces any “500” in those files. It works now, as this is probably only occurrence is the limit you want to tweak, but it’s a crude approach that may inadvertently break at any moment.
Those changes are ephemeral and won’t survive if container is re-created for any reason (unless
/opt/mastodonis a volume - I guess this is how it survivesdocker container restart?). I would rather recommend building your own custom image. Start by making a patch file:Take diff’s output, save it to
fix-limits.patchin a new empty directory, then write a brief Dockerfile next to it, that goes like this:And finally run
docker build -t my-mastodon .and usemy-mastodonas a replacement image. This will ensure your changes will persist, plus you’ll have a proper patch file that you can use with any version (point is, it will warn you if something would change in a way that the patch would no longer apply cleanly).I’m writing this on a phone, from scratch, without any testing, so you may need to tweak things a little bit. E.g. I’m not sure what’s the WORKDIR in the base image - just assuming its /opt/mastodon (which it probably is), but you may need to edit the COPY command’s second argument and/or
-pparameter to patch.> docker container restartWouldn’t you need to rebuild your image any time the upstream image changes?
Yes - same as with the original script, upgrades would require more manual steps than just updating the version in the Compose file. This is how it’s typically done.
There are ways to automate this. Docker Hub used to have a feature for automatic rebuilds when base images had changed, but AFAIK this feature was removed some years ago. Now it’s a matter of setting up a CI with periodically (nightly or weekly) scheduled pipelines, but it’s not a trivial matter.
Semi-automation can be achieved by using build-time arguments. I’m at my computer now, so here’s a revised process:
First, a bunch of manual commands that would allow us to write a patch. I’ll use those crude
sedstatements - just because they work today, but YMMV.This will produce a nice patch like this that you can copy. Create an empty directory and save as
change-limits.patchin there:Now, put the Dockerfile next to the patch:
And a shell script to semi-automate the upgrades. Note it requires
curlandjqto be available to parse JSON.And finally, create a file called
.dockerignorethat contains only one line that would saybuild.sh. That’s just minor cosmetic touch saying that ourbuild.shis not meant to be a part of the build context. If everything is correct, there should be now 4 files in the directory:.dockerignore,build.sh,change-limits.patchandDockerfile.Now when you run
build.shit will automatically find the latest version and build you a custom image tagged as e.g.my-mastodon:v4.1.3, which you can use in your Compose file. For a distributed system like Docker Swarm, Nomad or Kubernetes you’ll want to tweak this script a little to use some registry (your-registry.example.org/your/mastodon:v4.1.3) and possibly even apply changes further (e.g.docker service update --image ...).Mutable tags like
latestcan become confusing or even problematic (e.g. if you’ll want to downgrade it’s best to have previous version image readily available for some time - even if the build process is reproducible), so I would really recommend to use explicit version number tags.Hope this helps.
Oh I know my workaround is probably the worst possible correct answer for how to do this. Thanks for that, I’ll give it a shot!
It’s OK. I do hacks like this all the time - no shame in this. However, when sharing a recipe with others it’s best to promote better practices :)