You are here
Morfic - Thu, 2019/02/28 - 01:46
Dear all,
I've been looking to find some documentation (or tutorials) for the domain controller docker image without any luck so far. As you might imagine, I'm trying to figure out what configuration options are available, so what ports to expose, mounts, environmental variables, etc. If anyone has any kind of information/links they can share, docs, videos, whatever, or any other suggestions, I'd be grateful.
Kind regards
Forum:
Tags:
We install Samba4 from the Debian repos
As a general rule, the Samba docs/wiki are pretty good and I consider them the canonical resource. The Arch Linux wiki Samba page is also incredible. Note that TurnKey is based on Debian and Arch is a completely different Linux OS, however, much of the Samba info, especially that regarding config is relevant (obviously not installation/update etc. though).
Regarding the Domain Controller config specifically, you can read about setting up an AD Domain Controller (essentially what the build scripts we use do) in the Samba docs here. Depending on yoru usage scenario, you may also find the page on joining an existing AD domain useful too. The full list of ports is here.
I hope that gives you all the info that you need. If not, please feel free to ask more and I'll do my best to help out (although please note, I'm no Samba expert, nor do I have tons of experience with Docker).
Hi Jeremy,
Hi Jeremy,
Thanks for taking the time to reply, the links you shared do contain valuable information. However, at this point I'm more interested into getting the docker image up and running, like what volumes does it need to persist data, which ports does the image expose (since there are multiple tools bundled), what environmental variables does it support (eg, specifying an admin password), etc. Once I'm able to get a container running on a basic config, I can dive deep in the the docs you suggested so I can get a full domain config.
P.S. the docker hub link from the AD page is incorrect. It points to "https://hub.docker.com/r/turnkeylinux/domain-controller-15.0" whereas it should probably be "https://hub.docker.com/r/turnkeylinux/domain-controller"
BR
Thanks for the note re wrong link
Thanks for the note re the wrong link on the appliance page. We have updated the way that we version our images. Originally each new version was a new docker repo, but as of v15.0, we've moved to the Docker default practice of using version tags instead. So I'll have to fix the way that the links are autocreated.
Regarding the actual container itself, apologies if I misunderstood the context of your question. Our images are monolithic images which don't use the "normal" Docker "application and dependencies only" paradigm. Essentially they are a hack. They are basically just the contents of the ISO delivered via a Docker container. As such, they aren't configured to make use of environmental variables which Docker containers normally support.
The use of our Docker containers is covered in our docs. The info is a little dated (and probably needs an update). Although hopefully it's "near enough" and provides the info you were after?! Regarding the specific ports that we configure, it should be the ones as noted in the appliance Makefile. I.e. the entries that start "WEBMIN_FW_".
I hope that helps a bit more and gives you enough to get going.
Thanks
That certainly helps. Based on your reply and this older thread (that I missed initially), I guess that up to v15 it's not yet possible to externalize configuration and state through the use of volumes/binds, so everything is stored "internally" and lost when the container is removed.
Nonetheless, thanks for your time and help!
Kind regards
No they aren't intended as "stateless" containers
It should still be possible to mount external Docker storage and have your data stored within that volume. So in theory, I'm sure that you could make it work how you want. But it'd be a bit of a hack on a hack...
As noted in that thread you linked to, we do have intentions to provide "proper" "stateless" Docker style containers, but we need to work out how it will all work. Our ISOs and other builds (i.e. "monolithic" builds) continue to be quite popular, so we don't want to upset existing users. And we don't really have the manpower to add a totally new build/build process whilst continuing to maintain what we already do. I'm hoping we can have something worked out by the time it gets to releasing v16.0, but no promises.
Add new comment