21
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Jan 2025
21 points (100.0% liked)
Selfhosted
41924 readers
383 users here now
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: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
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!
founded 2 years ago
MODERATORS
You need different Subdomains as you suggested in your first paragraph. And add a reverse proxy like nginx or caddy to the machine which then proxies the different subdomains to the respective services (e.g. lemmy.your.site to localhost:2222, mbin.your.site to localhost:3333).
Theoretically, you could put a landing page behind some SSO/iam like authentik, and then link to the subdomains from the landing page, but eventually users will need be on the subdomain to use a specific site.
Caveat: this is not my area of expertise. However, I agree SSO is going to be the hardest part of this.
OP, you can use lldap to centralize authentication, so that each user had only one account and one password for all sites. It's trickier to get each of these platforms to work together with SSO. For that, you'll need something like Authentik (OSS SSO solution, like Okta) which you then back by lldap - Authentik handles the SSO and authorization part, and uses lldap for the authentication part. I suggest doing it in stages: install your servers, get them using lldap to log in, and then when it's all working insert Authentik into the mix. Doing something like this and learning all the technology at once is boiling the ocean.
I'm recommending lldap over OpenLDAP because I've used both extensively, and OpenLDAP is a nightmare whereas lldap isn't. lldap is trivial to install, and comes with a nice, simple user/group admin web interface, a sane default schema configuration, and is stupid easy to back up. Just getting OpenLDAP configured with the right schemas can take forever. If you'd said you already had a lot of experience with LDAP in general, then sure: OpenLDAP is capable and powerful. But it's harder.
My one caveat about lldap is that I'm not sure that it's possible to set up master/slave replication - or any sort of replication - which is probably not going to be an issue for your all-in-one set-up, but would limit scaling and failover if you ever get there.
I do rant a little about OpenLDAP because LDAP was in supposed to be lightweight OLAP, and yet is some of the most frustrating software I've ever had to deal with.
Again, I'm not a devops, or any sort of ops, guy, so my perspective is colored by the an attitude that ops is a necessary evil, and not something I love, so easier==better.