So if you do the Docker setup, obeying the instructions and substituting everything that needs to get substituted, but don’t proofread the files in detail and so miss that line 40 of docker-compose.yml doesn’t have the variable {{domain}} like in every other location you need to write your domain, but instead just says LEMMY_UI_LEMMY_EXTERNAL_HOST=lemmy.ml and so you fail to change it away from lemmy.ml… then, everything will work, until you type in your admin password for the first time, at which point your browser will send a request to lemmy.ml which includes your admin username, your email address, and the admin password you’re trying to set. And, also, of course your IP address wherever you are sitting and setting up the server.
I have no reason at all to think the Lemmy devs have set their server up to log this information when it comes in. nginx will throw it away by default, of course, but it would be easy for them to have it save it instead, if they wanted to. And my guess is most people won’t use a different admin password once they figure out why creating their admin user isn’t working and fix it.
@dessalines@lemmy.ml @nutomic@lemmy.ml I think you should fix the docker-compose.yml file not to do this.
Edit: Just to increase the information-to-rudeness ratio of my post. The docs are at:
https://join-lemmy.org/docs/administration/install_docker.html
And they recommend using wget to download:
https://raw.githubusercontent.com/LemmyNet/lemmy-docs/main/assets/docker-compose.yml
Which is pulled from:
https://github.com/LemmyNet/lemmy-docs/tree/main/assets
Which is what has the wrong line 40 in it.
Edit: They fixed it. Good stuff.
I really wish there was a way to enforce transparency of docker env vars.
I get that it’s impossible to make it a part of docker, env vars get parsed by code and turned into variables. There is no way that docker can enforce it, cause a null/undefined check with a default value is all that would be needed to subvert checks by docker, and every language uses a different way to check env vars (eg .env files, environment init scripts, whatever).
And even then, the env var value could be passed through a ridiculous chain of assignments and checks.
And, some of those ‘get env var’ routines could be conditional. Not all projects capture all env vars during some initial routine.
I’ve spent hours (maybe days) trawling through undocumented env vars trying to figure out their purpose, in order to leverage them in docker/k8s stacks.
I wish there was something.
Thankfully, a bit of time spent with a FOSS project and reviewing the code does shed light on hidden env vars.
And a PR or 2 gets comments and documentation updated.
Open source is awesome
Yeah, I honestly just strongly dislike the whole Docker ethos. It was designed for one thing (deployment at scale), at which it excelled, and then everyone uses it for a different thing (reproducible one-off deployment), at which it is fine, basically, but just kind of the minimum set of capabilities to get the job done.
Nix can do what Docker does, in a much superior fashion (lower disk space, much better transparency, rollback ability, lack of towering chains of follow-on effects as you are talking about, and applications outside of mucking around with containerized images), but for some reason everyone uses Docker, and Nix is as far as I can tell unused outside of NixOS.
Whatever. When they make me king, it’ll be different, that’s all I can say.
Nix and Docker / container runtimes are completely different animals. Each is good at what they do, but those are vastly different things, with some overlap. If you want to share a kernel but use fewer resources than a VM, containers can do that. If you want to go further and completely isolate, you can use microvm’s like firecracker.
I don’t follow what is wrong with that. Maybe you mean it’s use where people use it specifically as a package manager. I agree with that, but even then it has its handy place.
Precisely. Containerization is great and Docker does it well. Sending someone a reproducible script that can set up your software package for them is great. Marrying the two concepts unnecessarily and using one specific tool which is designed primarily to do the first, to instead do the second, is the only real issue I’m taking with it.