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
Thatās the kind of arrogant attidude that makes many docs of open-source projects so shitty. If you think that preliminary knowledge about something is required then at least share a link to a source where you can learn it. Docs that require you to puzzle the missing pieces together on your own are shitty docs. A good documentation is a documentation that everyone understands, regardless of their level of knowledge.
No - youāre not installing an app from the App Store. Youāre running services now. There needs to be some minimum assumed knowledge about what that entails. And if you donāt have that knowledge you should expect to seek it out separately.
And if youāre too lazy or think āgee thatās difficultā then guess what? Self-hostingās not for you. No shame - go pay for a service instead.
Running a server is very doable. There are packages to deploy and configure almost everything for you and removing a ton of headache.
Getting your email recognized as not spam by the major providers is pretty much impossible. You need all sorts of stuff to help verify integrity including special DNS records and public identity keys, but even if you do everything right, your mail can very easily get black holed before it even reaches a userās inbox because of stupid shit like someone abused your rented serverās IP years ago, and you canāt seem to get it off everyoneās lists.
Email as a decentralized tool has effectively been ruined by spam and anti-spam measures. Youāre effectively forced to use a provider because itās near impossible to make your outgoing mail work as an individual. I think some of those anti-spam measures are anticompetitive, but I do think some are just desperate attempts to reduce the massive flow of spam.
Itās not impossible, many people I know and myself successfully self host their email. Yes itās not trivial, and yes the ip reputation can be annoying to deal with (but itās possible to cycle to another server to get another ip), but apart from that, if following the best practices (SPF, DKIM, DMARC, proper setup of the mailserver) once itās set up it can run for years without issue.
To set things straight, Iām not saying that it is easy, but itās also not impossible, and only giving up will further contribute to centralized email provider monoculture.
Not for everyone, but for those who can, I feel they should.
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.
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.
A temporary one that youāre expected to remove as soon as youāve created the admin user(s) you need, but yes. It should only be there during initial setup and ideally removed before the server is ever exposed to the internet.
Yes because having a user remember to do something is a great line of defense, better than encrypting it from the get go. It should just be encrypted in the file.
I think thatās the way both Splunk and JFrog work ā you generate or enter a password into the key field in a YAML file somewhere, start the service, and next time you come back the fieldās been encrypted.
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.
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.
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.
Which config file does it go in? Where does it go in that file? Do you literally just put āregistration_shared_secretā or does it need a value? What is the syntax of setting the value? Does it accept spaces, special characters, etc.?
By the way, running synapse - docker or not - is a challenge. It can be very complex especially if you are interested in adding gateways to other services and such. Attempting to use https://github.com/spantaleev/matrix-docker-ansible-deploy might be a better choice as even though it is A LOT, it has a ton of good documentation and you can grow with it as it can help you install various different Matrix servers, gateways and clients as well.
Good luck, hope to hear more about how you get on with it.
I have a 2 page Google Doc that I wrote while installing Mateix (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?
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
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.
Linux on the desktop almost never needs CLI interaction though. Maybe youāll need to copy/paste a command from the internet to fix some sketchy hardware, but almost everything works OOTB these days.
However, self-hosting isnāt a desktop Linux thing, itās a server Linux thing. You can host it on your desktop, but as soon as you do anything remotely server-related, CLI familiarity is pretty much essential.
That depends on your use case for desktop linux of course. For me, yabridge is the tool I needed to run VSTs on Linux. Its CLI only as far as I know.
Donāt get me wrong; Iām not afraid of the CLI. Its just some tools are assuming the end user is a server admin or someone with deeper than the upper crust knowledge of how Linux works.
Donāt forget the situations where you find a good blog post or article that you can actually follow along until halfway through you get an error that the documentation doesnāt address. So you do some research and find out that they updated the commands for one of the dependency apps, so you try to piece together the updated documents with the original post, until something else breaks and you just end up giving up out of frustration.
That sounds an awful lot like modifying an ESP32 script Iāve been trying to follow from a YouTube tutorial published a while back. Research hasnāt uncovered anything for me to troubleshoot the issue so itās a really shit experience.
That shouldnāt be too bad if you understand systemd though, right? Or is there something weird iām missing? Do you have an example guide that illustrates the problem?
CLI familiarity is fine. CD, Nano, mkdir, rm. I am proficient with that. But I am not necessarily proficient with Docker (went with it because it worked nicely for another thing which was well documented and very straight forward). Itās just Iām trying to self host stuff. Some things like Wordpress and Immich are straightforward. Some things arenāt like Matrix and Mastodon. Lemmy is also notoriously bad.
I think if youāre talking wider demographics your model OSs are (obviously) Windows and macOS. People buy into that because CLI familiarity isnāt required. Especially with Apple products everything revolves around simplicity.
I do dream of a day when Linux can (at least somewhat) rival that. I love Linux because I am (or consider myself) intricately familiar with it and I can (theoretically) change every aspect about it. But mutability and limitless possibilities are not what makes an OS lovable to the average user. I think the advent of immutable Linux distros is a step in the right direction for mass adoption. Stuff just needs to work. Googling for StackOverflow or AskUbuntu postings shouldnāt ever be necessary when people just want to do whatever they were doing on Windows with limited technical knowledge.
However on another note, if youāre talking a home studio migration, not sure what that entails, but it sounds rather technical. I donāt want to be the guy to tell you that CLI familiarity is simply par for the course. Maybe your work shouldnāt require terminal interaction. Maybe there is a certain gap between absolutely basic linux tutorials and the more advanced ones like you suggest. Yet what I do want to say is that if you want to do repairwork on your own car itās not exactly like that is supposed to be an accessible skill to acquire. Even if there are videos explaining step by step what you need to do, eventually you still need to get your own practice in. Stuff will break. We make mistakes and we learn from them. That is the point Iām trying to get at. Not all knowledge can be bestowed from without. Some of it just needs to grow organically from within.
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.