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: 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!
view the rest of the comments
Can you explain your disclaimer? You suggest not setting your AD domain to a web address you use, like one for self hosted sites? So you buy 2 domains, one for AD and one for sites? Or you use an internal domain for AD?
AD is heavily reliant on the DNS protocol, so heavily in fact that a large component of an AD deployment is a DNS server.
So basically, when the AD DNS server takes over on your network It'll do DNS things as you'd expect, when it gets a DNS call with the AD domain it will answer with the AD server every time
If your AD domain and your web address domain are domain.com then whenever the AD DNS server gets theh call it won't answer with the IP address of the web server, it'll answer with the AD server, even when you are trying to access a web service like domain.com/Plex or something.
You can change the DNS server used on the host, but then you'll be borkin domain functionality in weird ways
Yea, you'd want an entirely different domain or an internal like domain.lan or in my case what I should have done is made it a subdomain like ad.domain.com
And also it's a bitch to change the AD domain once you get it all setup hence I've been procrastinating with hosts file workarounds lmfao
That is the correct answer.
If I remember correctly that is best practise, no? It was something.local or *.intern for years, until TLDs could be whatever you wanted them to be.
Do not use made up domains for anything these days. It will make it a pain if you ever need a certificate for that domain that isn't self-signed.
.local is reserved for mDNS responses, don't use that.
It's more than best practice. Your active directory controllers want to be the resolvers for their members, separate from other zones such as external MX records or the like. Your AD domain should always be a separate zone, aka a subdomain. "ad.example.com".
If your DCs are controlling members at the top level, you'll eventually run into problems with Internet facing services and public NS records.
Also per below. You can't get commercially signed certificates for fake domains. Self hosting certificate authorities is a massive pain in the ass. Don't try unless you have a real need, like work-related learning.
All the descriptions are right and techniques. Microsoft sometimes refers to this is split-brain and their documentation.
Organizations that choose not to do that use an active directory specific subdomain like some of the other comments mentioned. Example: adds. Company.tld.
Computer1.adds.company.tld. Dc1.adds.cimoany.tld.
Others doing split domain are
Adds.company.internal
In shorter terms to what the other comment said, your website won't work in networks that use DNS served by your DC. The website is fine on the Internet, but less so at home or at an office/on a VPN if you're an enterprise.
"I can't go to example.com on the VPN!" was a semi common ticket at my last company 🙃