view the rest of the comments
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Unlike most here, I'm not as concerned with opening things up. The two general guidelines I use are 1. Is it built by a big organization with intent to be exposed, and 2. What's the risk if someone gets in.
All my stuff is in docker, so compartmentalized with little risk of breaking out of the container. Each is on it's own docker network to the reverse proxy, so no cross-container communication unless part of the same stack.
So following my rules, I expose things like Nextcloud and Mediawiki, and I would never expose Paperless which has identity documents (access remotely via Tailscale). I have many low-risk services I expose on demand. E.g. when going away for a weekend, I might expose FreshRSS so I can access the feed, but I'd remove it once I got home.
Doesn't Nextcloud running in Docker want the socket exposed?
I googled around for an example https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation.
Ignore me if you've already hardened the containers.
I've never known a reason to expose the docker socket to Nextcloud. It's certainly not required, I've run Nextcloud for years without ever granting it socket access.
Most of the things on that linked page seem to be for Docker rather than Nextcloud, and relate to non-standard configuration. As someone who is not a political target, I'd be pretty happy that following Nextcloud's setup guide and hardening guide is enough.
I also didn't mention it, but I geoblock access from outside my country as a general rule.
I was looking into setting up Nextcloud recently and the default directions suggest exposing the socket. That's crazy. I checked again just now. I see it is still possible to set it up without socket access, but that set of instructions isn't as prominent.
I linked to Docker in specific because if Nextcloud has access to the socket, and hackers find some automated exploit, they could easily escalate out of the Docker container. It sounds like you have it more correctly isolated.
Was it Nextcloud or Nextcloud All in One? I've just realised that the Nextcloud docker image I use is maintained by Docker, not Nextcloud. It's this one: https://hub.docker.com/_/nextcloud/
I use Docker-compose and even the examples there don't have any socket access.
The all in one image apparently uses Traefik, which seems weird to use an auto configuring reverse proxy for an all in one image where you know the lay of the land. Traefik requires access to the docker socket for auto configuration. But you can proxy the requests to limit access to only what it needs if you really want to use it.
What I was looking at was the All in One, yes. I didn't realize there was a separate maintained image, thank you! I'd much rather have a single image without access to the socket at all, I'll give that a shot sometime.
One warning: in my experience, you can not jump two major versions. Not just it won't work, but that if you try it everything will break beyond repair and you'll be restoring from a backup.
Two major versions can sometimes be a matter of a few months apart, so make sure you have a regular update schedule!
(Also, people say never update to a X.0 release, the first version of a major release often has major bugs).
TL;DR don't take too long to update to new releases, and don't update too quickly!
Also, the docker image is often a day or so behind the new release, soNextcloud tells you an update is available but often you then need to wait until the next day to get the updated docker image. I guess this is because (as I've just learnt) the image is built by Docker not Nextcloud.