5 ms·

I'd go a step further: programs aimed to make self-hosting easy should not even need a package manager. They should be self contained (statically linked) binari

by hsn915 5y ago

I'd go a step further: programs aimed to make self-hosting easy should not even need a package manager. They should be self contained (statically linked) binaries. Luckily we have Go which makes this very easy to achieve, and to make things better, Go is designed for web servers. I believe we've had this ability for almost a decade, and still no one is harnessing it to make self-hosting easy and reliable. Further more, they should require absolultely zero configuration to get up and running. We've had SQLite for many years now, so it's easy to make a webserver that does not require a separate sql server to be installed and configured in order to get going. (There are also non-sql embedded data storage engines, many of them written in pure Go, eliminating the CGO problem). Ideally the user will download a program for their own operating system (say, windows). They will run this program, provide it with the ip and root password of their linux server which they rented from some provider, and this program will then upload the actual server program to the host machine and launch it.

Seirdy 5y ago
Echoing this. All the services on my servers (Web, Gemini, Matrix, Fediverse servers and a CSP violations collector) are statically-linked binaries running in sandboxed chroots, with no access to the outside filesystem except a subdir of my data volume mounted into the chroot. Privs are limited to a defined list of acceptable syscalls and other limitations. I'm currently working on enforcing the use of this setup with SELinux policies and transitioning my OCSP fetching and session ticket key rotating scripts to statically linked binaries so I can just stick to one template shared across all services. It would have been much harder to pull this off if these services required large interpreters, adjacent daemons running, and complex orchestration. Given the amount of time I have, I might have just skipped the SELinux step.
- BarbaPeru 5y ago
  I hope you are not saying this is a layperson doable setup. ;-)
- hsn915 5y ago
  The reason I want things to be self contained is not for someone else to use it as a base upon which to build additional layers of complexity. That defeats the whole point.

by hsn915 5y ago

Seirdy 5y ago

Echoing this. All the services on my servers (Web, Gemini, Matrix, Fediverse servers and a CSP violations collector) are statically-linked binaries running in sandboxed chroots, with no access to the outside filesystem except a subdir of my data volume mounted into the chroot. Privs are limited to a defined list of acceptable syscalls and other limitations. I'm currently working on enforcing the use of this setup with SELinux policies and transitioning my OCSP fetching and session ticket key rotating scripts to statically linked binaries so I can just stick to one template shared across all services. It would have been much harder to pull this off if these services required large interpreters, adjacent daemons running, and complex orchestration. Given the amount of time I have, I might have just skipped the SELinux step.

BarbaPeru 5y ago
I hope you are not saying this is a layperson doable setup. ;-)
hsn915 5y ago
The reason I want things to be self contained is not for someone else to use it as a base upon which to build additional layers of complexity. That defeats the whole point.