

2·
12 days agoBefore I got more into selfhosting, I was running nothing but syncthing in a Raspberry Pi.
The pi was the “Server” and all the other Clients were only connected to the pi (in syncthing).
Worked flawlessly :)


Before I got more into selfhosting, I was running nothing but syncthing in a Raspberry Pi.
The pi was the “Server” and all the other Clients were only connected to the pi (in syncthing).
Worked flawlessly :)


Ha, I wish I could.
I’m not 100% satisfied, so I’m still searching for the “perfect distro for me”, if it even exists.
I have been using Arch Linux on my personal PC and company laptop for 4 years, but I couldn’t get some things to work. Things that, after installing Fedora, worked out of the box.
My current setup is:


Currently using nginx-proxy-manager for exactly this purpose. Nice and easy-to-use UI, including automatic LetsEncrypt ssl certificates :)
It depends on what it is. I do not have a singular documentation-platform or wiki for those things. I’m more of the keep the docs where the code is guy. I also try to keep complexity to a minimum.
All my linux server setups are done with
ansible.ansibleitself is pretty self-documenting, as you more or less declare the desired outcome in YAML form andansibledoes the rest. This way, I do not need to remember it, but it’s easier to understand when looking it up again.Most of my projects have a
gitrepository, so most of what I need to know or do is documentedREADME.md.gitlab-ci.ymlThis way, I was able to reduce complexity and unify my homelab projects.
My current homelab-state is:
docker-basedproductionand astagingserver to testansibleplaybooks or my GitLab CI)On what to include, I always try to think: Will I still be able to understand this without documentation if I forget about the project for 6 months and need to make a change then? If you can’t be sure, put it in writing.
If it’s just a small thing regarding not the project itself or the functionality or setup itself but rather something like I had to use this strange code-block here because of XXX, I’ll just put a comment next to the code-line or code-block in question. These comments mostly also include a link to a bug-report if I found one, so i can later check and see if it’s been fixed already.