Yeah the documentation (if it even exists) of most projects is usually clearly written by people intimately familiar with the project and then never reviewed to make sure it makes sense for people unfamiliar with it. But writing good detailed documentation is also really hard, especially for a specialist because many nontrivial things are trivial to them and they believe what they're writing is thorough and well explained even though it actually isn't.
Honestly, as a newbie to Linux I think the ratio of well documented processes vs. "draw the rest of the fucking owl" is too damn high.
The rule seems to be that CLI familiarity is treated as though its self-evident. The exception is a ground-up documented process with no assumptions of end user knowledge.
If that could be resolved I think it would make the Linux desktop much more appealing to wider demographics.
That said, I'm proud to say that I've migrated my entire home studio over to linux and have not nuked my system yet. Yet... Fortunately I have backups set up.
This reminds me of when I sent someone a program in a zip folder. Windows now opens zip folders by default, and it looks just like any other folder.
So of course they opened the zip and double clicked the exe, but everyone knows you can't open an exe inside a zip folder (at least, if the exe depends on the folders and files around it). If you try to, windows will extract the exe into a temp space, but leave all the dependencies behind. So the exe promptly crashes.
I didn't think I needed to specify "you need to extract the contents of the zip folder first, then run the exe." It feels like saying "you need to take the blender out of the box before you can use it. And not just the _base _ of the blender, you have to take out all the parts."
Some things just feel so much like second nature that we forget.
update: It's all working perfectly!
Here's some more of the owl, the official docs: https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html#registration_shared_secret
So add this to your matrix config:
registration_shared_secret: <PRIVATE STRING>
I'm guessing this string can be whatever you want it to be.
But yeah, I agree in general, some of the docs can be pretty opaque. For example, I wanted to configure NextCloud w/ Collabora in Docker, and I kept getting errors when trying to do what a few sites recommended. I ended up figuring it out, but only through trial and error. I'm going to go through the same pain this weekend when I try out ownCloud Infinite Scale up and running to compare.
Matrix and its implementations like Synapse have a very intimidating architecture (I'd go as far as to call most of the implementations somewhat overengineered) and the documentation ranges from inconsistent to horrific. I ran into this particular situation myself, Fortunately this particular step you're overthinking it. You can use any random string you want. It doesn't even have to be random, just as long as what you put in the config file matches. It's basically just a temporary admin password.
Matrix was by far the worst thing I've ever tried to self-host. It's a hot mess. Good luck, I think you're close to the finish line.
this meme got so much funnier after I realized it was synapse/matrix
Protip: Use Conduit instead of Synapse. It's significantly lighter than Synapse, easier to run, and I guess you can be a cool kid by running something written in Rust. The documentation is even worse though :/ https://conduit.rs/
Being able to find and read software documentation and knowing how to use the tools that automate software deployment are why SRE/devops/cloud guys get paid the big bucks.
I definitely recommend synapse over dendrite or conduit btw. dendrite and conduit have a bunch of missing features, and my first attempt at dendrite server shat the bed with its NATS store and died. I definitely recommend Synapse for all matrix servers going forward.
The .well-known entries I found were the hardest to test, since synapse doesn't provide a web server for them, and Element throws a fit if you don't have CORS set up exactly in the way it wants you to.
I mostly have my matrix server working now, with bridges even. However, Element randomly logs itself out on a daily basis which is really frustrating :/
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
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.
But this is some Docker shit. For myself Docker always feels a little corporate. It's just not very conventional with these multiline commands just to run a command inside a container. Especially the obligatory "-it" to fucking see anything. It's not really straight forward. But if you get used to it and you can make a lot of aliases to use it more easily.
Permanently Deleted
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.
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.https://element-hq.github.io/synapse/latest/setup/installation.html
I have to set literally everything up again on a new microSD for my Pi because the apt-get repositories no longer support the Raspbian version I'm on. I'm not mad; good for security to update, but I don't have half a day free anytime soon for it.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol SMTP Simple Mail Transfer Protocol ZFS Solaris/Linux filesystem focusing on data integrity
5 acronyms in this thread; the most compressed thread commented on today has 3 acronyms.
[Thread #905 for this sub, first seen 3rd Aug 2024, 13:15] [FAQ] [Full list] [Contact] [Source code]
Old I.T. Proverb: Documentation is like sex. Even bad documentation is better than no documentation at all.
Setting up synapse is particularly painful.
I have a 2 page Google Doc that I wrote while installing Matrix (because I wanted to be able to recover from a complete system loss, and knew I'd forget what I did). Half of the doc is my HAProxy notes.
Are you still having issues? I could try cleaning up my notes for a wider audience (note: my professional background includes technical writing and corporate technical training, so I'd be super anal about, and it would take a few hours at least).
Is this meant to be single-user, or a larger host?
So you added the secret to the file and restarted the docker container, right?
Something that I think will help you with self-hosting in the future is to always read through the entire process for setting up whatever you want to set up first, beginning to end, so that you are familiar with what you need to do before attempting it the first time. It's helped me numerous times myself.
