Dandroid

Not having to do a database rollback is a really, really hard problem to solve, and it would almost certainly need to be on the Lemmy developers side, not the server owner's side. And if I'm them, that's a low priority issue, and probably not something I even think about until 1.0.

Basically, they write code that says what to do in the event of a database version change. Usually this only handles upgrade cases, because that's what happening most of the time. One example of something you might do in a db upgrade is let's say you had a column where the data type was only numbers, but now you want to allow any alphanumeric character for some reason. You could have a line of code that converts the number to a string.

Okay, but now you need to go back to the previous version. Okay, your db change code runs, but it's the old version of the db change code, not some new version that you wrote. You unfortunately didn't have a crystal ball when you wrote this code and couldn't predict that you were going to change the data to strings, so you didnt write code to change it from a string to a number.

This is why most software doesn't support downgrades unless you wipe first. For example, if you updated your aging MacBook to the latest Mac OS version, then realized it slows down your laptop too much, you can only go back if you first wipe your laptop in the process. So it's just easier to just take a snapshot before an upgrade and revert to the snapshot if it fails. Some folks will even do "scheduled maintenance" time during the upgrade in which the whole system goes down for a short time so they don't have to risk losing data that happened after the snapshot.

If they know you are free. 😉

I learned about this http response code too late. About 4 years ago I was working at a startup and I was the "lead engineer" (aka only engineer) on a project where I had to design and implement an entire REST API. I really wish I would have put this in somewhere, since we weren't doing code review (because it was literally only me).

Just send this meme.

I just throw bacon on the barbecue at the same time as my burgers. It takes almost the same amount of time to cook, and it's super crispy - just how I like it.

All the bot accounts come from this instance.

The instance admin can choose whether it is full size or not.

I'm gonna have so many USB cables. And I'll still probably not be able to find any.

I mean, I sort of do that. I'm a software engineer. If I finish all my work early, I just stop working. Or I can start working on my task for the next day. My team works in three weeks sprints, so I get all my tasks for the next three weeks. If I finish all of those tasks before the three weeks are over, I really can just slack off. Usually I'll ask for another task, as it makes me look better when it comes time for raises (once a year), but for people who are happy with how much they are being paid, they can just do as little as required and work fewer hours than 8 a day.

The only thing I changed from the nginx_internal.conf that is here is that I added ssl. But with no changes (aside from the required changes described in the instructions) to this file or docker-compose.yml, you should be able to access it using curl http://localhost:8536. I am not using a reverse proxy, as I am not hosting anything other webservers on my server at the moment, so I actually changed the exposed port in docker-compose.yml to map 443 to 8536 so I can serve https on the default port directly from the nginx container. Oh, and I had to add a mounted volume to the nginx container in docker-compose.yml for my ssl certificates for https.

Here's what I added:

docker-compose.yml: (under services -> proxy -> volumes) - /path/to/ssl/certs/on/host/:/path/to/ssl/certs/in/container/ (under service -> proxy -> ports) - "443:8536"

nginx_internal.conf: (under http -> server)

        ssl_certificate /path/to/ssl/certs/in/container/fullchain.pem;
        ssl_certificate_key /path/to/ssl/certs/in/container/privkey.pem;
        ssl_protocols TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5; # Full disclosure, I'm not 100% if this is the best option to put here

        # this is the port inside docker, not the public one yet
        listen 1236;
        listen 8536 ssl; # I had to add "ssl" here to serve https
        # change if needed, this is facing the public web
        server_name yourdomain.tld;

If you wanted to skip https for now and just get it up, replace 443 with 80, and don't make any changes to nginx_internal.conf.

So, from what I have gathered, the lemmy-ui conatiner contains the html/js, and the lemmy container is the backend. Not 100% sure on that, but I believe that's what it is. When trying to set up 0.17.4, I was able to access the UI by adding the lemmy-ui container to the lemmyexternalproxy network and mapping port 0.0.0.0:80 to lemmy-ui:1234.

Ports aren't usually exposed from the container directly. All ports are shared between containers on the lemmyinternal network. Only the nginx container is on the lemmyexternalproxy network, which is the one that can map ports to the host. So basically, your lemmy-ui container is exposing port 1234 to the nginx container through the lemmyinternal network, and nginx container is mapping that port on the lemmyinternal network to the lemmyexternalproxy on port 8536, and then docker is mapping port 8536 from the nginx container to 8536 (or whatever port you set it to. In my case, 443) on 0.0.0.0 (the host and the world).

I hope that I worded that last part in a way that makes sense 😅.

The instructions didn't tell me I needed to. I don't know how someone is supposed to know that. I would have expected the instructions to at very least tell me I needed to make that and what the file name should be. But I did eventually figure it out. I had to search their github page to find the example one, then modify it for https

Oh, that was my bad. I replaced my actual path with because my name is in the path (home directory). Sorry, I definitely should have clarified that.