I haven’t done any programming in over 20 years, but I think I can make a contribution to projects by trying to improve documentation, once I start using some projects
While security has nothing to do with my disgust for docker and people advocating its use, docker adds a layer of complexity, which means it is not necessarily more secure.
What is extremely bad about docker:
it enables extremely shitty configuration control on the side of a developer. There are way too many developers who have a chaotic approach to configurations, and instead of being forced to write a proper installation and configuration guide from scratch, and thereby making themselves(!) aware of active configuration changes they made to make their system work, they just roll out the docker container they develop in, without remembering most of the configurations they made. Which, naturally, means that they are unable to assist in troubleshooting problems or reproduce issues that users might have.
In general, if you can’t write a good user manual, or at least clearly identify needed dependencies and configurations, you should not be developing software for other people.
it combines the disadvantages of a VM (shitty performance) and running directly on the host OS (sandboxing is not nearly as good as on a VM)
it creates insane bloat, by completely bypassing the concept of shared libraries and making people download copies of software they already have on their system
it adds a lot of security risks because the user would have to not only review the source code they are compiling and installing, but also would have to scan all the dependencies and what-not, and would basically have to trust the developer and/or anyone distributing an image that they did not add any malware.
The dankest depths of archlinux wiki. Written by a guy so far gone, so war harden by reading through source code and poorly written technical documentation, ancient forums, leaving no stone unturned. A task so twisted it drives most men crazy.
1% of arch users will ever need this wiki and few have gone through this Herculean task. For them, the first draft is enough, it’s all you can ask of a mind so twisted and broken. Alas it’s as unreadable as the source code and as hard to understand as the forum post from 2009.
Not sayin nothin, but you might want to look at Matrix Conduit. you won't want to keep it open, but it's much easier to set up and it uses a tiny amount of the resources. Synapse kills the server I'm running both conduit and lotide on just fine.
So why didn’t they write that? It’s a bad documentation if someone doesn’t understand it. If you’re not going to explain something, at least share a source to where it’s explained.
Alternatively, you can create new users from the command line.
This can be done as follows:
If synapse was installed via pip, activate the virtualenv as follows (if Synapse was installed via a prebuilt package, register_new_matrix_user should already be on the search path):
cd ~/synapse
source env/bin/activate
synctl start # if not already running
Run the following command:
register_new_matrix_user -c homeserver.yaml
This will prompt you to add details for the new user, and will then connect to the running Synapse to create the new user. For example:
New user localpart: erikj
Password:
Confirm password:
Make admin [no]:
Success!
This process uses a setting registration_shared_secret, which is shared between Synapse itself and the register_new_matrix_user script.
It doesn’t matter what it is (a random value is generated by --generate-config), but it should be kept secret, as anyone with knowledge of it can register users, including admin accounts, on your server even if enable_registration is false.
In this example it is a config value that the software expects to be present, I’m guessing based on the screenshot it is to be added to the homeserver.yaml
It took a little time to get the hang of it, but stick with it and it will get so much easier and it'll make self-hosting anything you want less of a pain in the future.