You are here
Hello, I'm brand new to TKL and could use some direction to reduce my fumbling and confusion. Please help if you can :)
I'm looking to setup a home network for about 8 machines -- mostly Windows 7 and 10 with a linux mint laptop -- and a linux server to bind them all and in light reveal them. (this would be the role I hope TKL fills.)
I've installed the TKL Linux Containers app. There was network issue which I'll get into somwhere else, but it's working now. My most pressing question is: Now what? How do I add other TKL apps to the container? (namely Domain Controller and File Server) And then get them working together?
Or, am I going about this in a non-optimal way. Should I install linux, then Xen, and then put the Domain Controller and File Sharing TKL vm machines into that?
Thanks!
Hey Matt, if you can wait a few days, I'd urge you to...
I am in the final stages of wrapping up the v15.0 release and newer versions of LXC, fileserver and domain controller are all in the build bucket awaiting publishing by my colleague Alon.
Having said that, you don't need to wait and the current v14.2 builds are definitely serviceable.
Which ever way you go, you'll likely find the LXC appliance usage docs quite handy. Note that there have been significant changes (I'd argue improvements) in v15.0 so if you persevere with v14.2, then use this link to the v14.2 docs instead.
Having said that, I suspect that you'll need to make some tweaks to get ACLs in the domain controller working properly within an LXC. Personally, I'd probably consider running that as a full VM (although it should totally be possible to get it fully working in a container).
Whilst I love LXC (and obviously TurnKey too), I must admit that personally I use Proxmox as a hyperviser. That allows the option to use LXC containers (you'll find the TurnKey LXC templates downloadable within the webUI) or KVM VMs (so you can even install Windows if you really wanted...).
With regards to the domain controller, beyond the most basics (i.e. the initial development and basic testing since), TBH, I don't actually have a ton of experience with it. The firstboot inithooks should allow you to get the basics in place, and the Samba docs should hopefully assist with any remaining questions. If you find any bugs in our appliance, or see gaps that would be good to have filled, or any other feedback then please post back. If you're sure it's a bug, please post straight onto the GitHub tracker.
The fileserver is pre-configered as a stand-alone server, but I'd really like to make it easy to join to an existing domain-controller. Unfortuantely, I didn't get there for v15.0. But it is possible - this page should help head you in the right direction. Again if you have feedback, please share.
Hope that heads you in the right direction... Good luck with it all.
New appliances have just been published.
The new appliances have just been published. If you get a chance, please take them for a spin and share your feedback with us. :)
upgrade in place?
thanks! is it possible to upgrade from 14.2 LXC in place or do I need to download install from scratch? (We're bandwidth constrained, so conserve wherever possible)
Ideally download and do a clean install
Ideally download the fresh image and do a clean install. That is because we haven't packaged all the tweaks and changes that we've made.
However, as TurnKey is based on Debian (v14.x = Debian 8/Jessie; v15.x = Debian 9/Stretch), it is possible to do a Debian "in place" upgrade. If you do a google for "how to upgrade debian jessie to stretch" you should find plenty of into, although it's essentially just a case of changing the sources.list entries (from jessie to stretch) and running "apt-get update && apt-get dist-upgrade". If you have any data that's important, please make sure that you do a backup first (just in case). If doing a Debian upgrade of a bare metal server, an image (e.g. using something like Clonezilla) is a good option (as Debian upgrades can't really be rolled back).
Good luck and either way, please feel free to post back with any feedback or questions.
lxc 15 installed... now what?
I feel like this is where I've landded: https://abstrusegoose.com/474
:-]
I've installed a clean TKL LXC on bare metal. The automatic network config didn't work, but I've worked around that. I can connect to lxc server via webmin and ssh and do stuff. Question is, now what? How are sub-containers installed?
https://www.turnkeylinux.org/lxc references 'Turnkey LX Template' which by description does what I'm after, "Download and create a container of any TurnKey appliance", but that script doesn't exist on my new system:
root@lxc ~# lxc-{tab}{tab} lxc-attach lxc-test-clonetest lxc-autostart lxc-test-concurrent lxc-cgroup lxc-test-console lxc-checkconfig lxc-test-containertests lxc-clone lxc-test-createtest lxc-config lxc-test-destroytest lxc-console lxc-test-device-add-remove lxc-create lxc-test-get_item lxc-destroy lxc-test-getkeys lxc-device lxc-test-list lxc-execute lxc-test-locktests lxc-freeze lxc-test-lxcpath lxc-info lxc-test-may-control lxc-ls lxc-test-reboot lxc-monitor lxc-test-saveconfig lxc-snapshot lxc-test-shutdowntest lxc-start lxc-test-snapshot lxc-start-ephemeral lxc-test-startone lxc-stop lxc-test-symlink lxc-test-apparmor lxc-unfreeze lxc-test-attach lxc-unshare lxc-test-autostart lxc-usernsexec lxc-test-cgpath lxc-wait root@lxc ~# lxc-{tab}{tab}ahh, in Github the path
ahh, in Github the path starts `/overlay/usr` but when installed it's just `/usr`, so the template is in `/usr/share/lxc/templates/lxc-turnkey`.
On running it it tells me path is a required argument. It's not clear if this is a source or destination path. The screen message indicates there's some kind of interaction with `lxc-create`. The help from that tool tells me the required path argument is a destination. Ok, we're getting somewhere.
Looking around the file system I don't see an obvious intended target for containers. `/opt` is empty, as is `/srv`, but maybe they are better placed in they're own disk partitions. Well, there's `lxc-destroy` so I can always move it later (sure hope downloads are cached...).
[more reading and experimenting] There's an inithooks example in `/root`. It contains several "password" parameters. It's unclear if these are passwords that already exist or if these are ones which will be created. Throw caution aside and just use the sample unchanged; this is an internal network so using predefined ones is (somewhat) less risky.
Hmm, empty error. Well we've hit a wall and can't go any farther tonight.
The reference to 14.2-jessie
The reference to 14.2-jessie is curious. I'm pretty sure the ISO i downloaded was v15. How do I verify what was written to the boot usb device is v15? And even if I used v14.2 by mistake, it should have worked anyway, just fetched an older version, right?
This what was installed:
and the isolinux folder files in the boot-usb:
2nd run at installing v15 ISO
2nd run at installing v15 ISO on baremetal worked (xref). I had to edit `/etc/network/interfaces` to get the network working (xref), after that Turnkey template worked too with minimum of fuss.
So now I'm at the next "now what?" The sub-lxc is installed, how do we get to it and make it do stuff?
LXC usage mentions lxc-start
LXC usage mentions lxc-start and lxc-list. Not working here:
... 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. INFO [lxc-turnkey]: successfully completed creating container domain-controller. root@lxc ~# root@lxc ~# lxc-start -n domain-controller lxc-start: log.c: log_open: 300 failed to open log file "/var/lib/lxc/domain-controller/domain-controller.log" : No such file or directory lxc-start: tools/lxc_start.c: main: 317 Executing '/sbin/init' with no configuration file may crash the host root@lxc ~# lxc-ls f {empty response} root@lxc ~#Well, that's enough for tonight. Maybe sunrise will illuminate. Or moonlight if I get insomnia ;-)
Hey Matt, apologies on my lack of input
I've been trying to tidy up the remaining v15.0 release lose ends (and I'm nearly done). But I see you've been busy but spinning your wheels a bit. Figured I better at least poke my head in and point you in the right direction...
Apologies if our instructions are not as clear as they should be. Unfortunately, we all suffer from the curse of knowledge. So your insight here would be totally invaluable in assisting us to make the docs more user friendly, especially to the uninitiated!
I think the flaw in your process is that you are using the lxc-turnkey template directly, rather than leveraging the default LXC commands as intended. Perhaps us providing a link to the template file so early in the info creates a bit of a red herring?
The way it's intended to work is via the default lxc commands (which we provider silent wrappers for). That allows existing LXC users to use LXC as they are already accustomed, but allows us to extend the functionality to make it easier for TurnKey users (at least that's the underlaying thought process). FWIW, you can see the wrapper scripts which we provide (on GitHub) here, as you appear to have worked out, they should be on your local server under /usr/local/bin.
All this is noted in the TurnKey LXC docs, however, I note that the page has been moved for v15.0 (it was docs/README.rst before, now it's docs/usage.rst). FWIW you should be using lxc-create (as noted in the docs) to create your initial LXC container. I suspect that your usage of the template file directly is causing the container to not be set up as it should for the other commands.
So to run through it all:
Create your default inithooks conf. Adjust values after the '=' as desired (i.e. set your own passwords, email, domains, etc).
Create the server via
lxc-createlike this:E.g. to create a TurnKey
WordPressappliance which is calledwp1(using the default inithooks.conf created earlier; and bridged networking) run this:Then starting it should be as simple as this:
FWIW I did test that as part of the testing process prior to release, so it should "just work" as I've posted above (I tested the current ISO prior to release). However, my testing wasn't exhaustive, so if anything doesn't work as you think it should, please don't hesitate to ask more. Perhaps there is a bug we've missed. Also hope my pointers help and you aren't still experiencing gaps...
If you have suggestions on how we can improve the documentation, please edit the files on GitHub. The appliance page is generated from the appliance Readme (I don't think that I'd updated it to the latest version yet, on my todo list...). And the usage docs are here (and I don't think that they are cross posted anywhere else, but perhaps I'm mistaken...?)
Apologies again that I haven't posted sooner. Hope that helps.
Thanks for the redirection. I
Thanks for the redirection. I started with the template script because that's the one who's description resembled "downloads, installs and configures {thing}", which sounds a lot like a 'turnkey' process, which is the promised land dream that brought me here ;-) (A refugee after a month of failing to get a Samba 4 domain controller installed and configured on Ubuntu; couldn't resolve dns issues).
In contrast lxc-create and lxc-start are not mentioned at all on the LXC app home page, while something in the template script usage help messages make it sounds like lxc-create is called by template. Looking inside the lxc-create script I don't see anything about where the image it's to use comes from (downloading). i.e. After creation how is it populated? In contrast there's many lines in template about that.
Pretty sure it's the "-t turnkey" bit in lxc-create
I'm pretty sure that the "
-t turnkey" bit of the lxc-create command is what calls the template script.I haven't actually been closely involved in the development, nor maintenance of the TurnKey LXC appliance. My colleague Alon (who mostly works behind the scenes) created the original appliance and community member John Carver (aka Dude4Linux) has been the primary maintainer/developer since then. Also I don't actually use it myself (I use Proxmox VE on my home server - because it has support for both full VMs as well as containers; and a pretty web UI). So my contact with the TurnKey LXC host (and vanilla LXC itself) is limited to code review and testing (of TurnKey LXC appliance). FWIW Proxmox has it's own container management scripts.
Having said that, the lxc-create man page says:
-t, --template template 'template' is the short name of an existing 'lxc-template' script that is called by lxc-create, eg. busybox, debian, fedora, ubuntu or sshd. Refer to the examples in /usr/local/share/lxc/templates for details of the expected script structure. Alternatively, the full path to an executable template script can also be passed as a parameter. "none" can be used to force lxc-create to skip rootfs creation.So that pretty much confirms my suspicions...
I have some suggestions for improving the documentation for new TurnKey LXC users and would love your input:
The current appliance page somewhat assumes users are already familiar with LXC. That seems to be a clear mistake on our behalf. Do any/all of the above suggestions sound like good ideas to you?
(PS - I hope you don't mind, I just adjusted the title of this thread and added some additional tags.)
Ok, so I used your
Ok, so I used your commandlines, substituting domain-controller for wordpress. Create reported no errors but start isn't happy.
Ahh, so create also dowloads, and, downloads are cached, great!
But:
Tried starting again:
Ok, so something is doing something. `ps ax| grep lxc` shows a single process:
The DC doc explains there are some additional steps, but at this point I don't know how to get to the DC lxc machine in order to do them. Where does the container go? With the template command target folder was a required parameter.
Well, off to do more exploration and testing.
Just guessing...
Perhaps you need to ensure that you have cleaned up from previous attempts using the template file directly? TBH, I'm not 100% sure, but the error(s) that you're getting suggests to me that may be the case?!
I'd start by listing the containers and seeing what's there. Then I'd probably consider removing everything and creating your domain controller from scratch.
can't destroy the container
To answer Q from earlier, it looks like the lxc-create containers go to `/var/lib/lxc`.
Lxc-ls only shows 1 container. I tried to remove it with lxc-destroy but am told it's still running. Lxc-stop ran successfully, at least it reported no error. Lxc-destroy again but again a "domain-controller is running" message. Running lxc-stop a 2nd time did the trick, but then once again lxc-destroy says container is still operating. `lxc-ls --full` confirms container is running.
The quest to summon Shiva
Thinking a background script is automatically spawning the controller I periodically checked the running status with `lxc-ls -f` and `lxc-info` while I did other things. The goal being to determine the schedule and time the destroy command accordingly. Didn't work, the state is always stopped until I run lxc-destroy. I even tried chaining together in a single command with `&&`.
I then tried to login to the container and shut it down from inside, using `lxc-console`, but got stuck in a loop. It wouldn't recognize my password. I tried the ones from inithook, the master lxc password, and some others just for fun. All of them were unrecognized. There was no way to break out of the login cycle, to say "I give up! let me out!". I had to open another ssh session. Sometimes when I hit [enter] at the end of my password an 's' would show on screen, so my guess is the right keys weren't being sent through.
I tracked down the lxc-destroy script and stepped through, manually running the lines I can understand. Ahhh! This is what's booting up the container again:
And now we are successful:
we have lift off!
Success! Well, at least as far the stage 1 rocket. The domain-controller container is installed, runs, and reports an IP. Now to figure out Samba AD config.
----
Ok, to my mind all that's needed to make this TURNKEY is a number of simple scripts following the form of LXC-install-{appname}. The scripts are included in turnkey-lxc-appliance image, and can be updated periodically with something similar to `apt-get update`.
It asks 2 questions:
The same password can be used for all 3 invocations - host os, sql db, and app. People who want to use it in the wild with more security levels can still edit inithook.conf.
We don't need the app name (lxc-create --name=..), we already have that, it's in the script name.
Bridged vs NAT? well that could be asked too I 'spose without complicating things. It's a simple boolean. Other options? Well they're all still available in the existing commands.
A newbie's 2$
Yay! Really glad to hear you got it running!
Great work. Really glad to hear that you got it running! Re the previous suggestions I had, I've opened an issue on our issue tracker so it doesn't get forgotten. I'll aim to have it updated at least by our next release (although ideally sooner).
So let me see if I get you straight, you're suggesting an (interactive) script which the user could run which could:
WRT naming this script, we have a precedent of prefixing TurnKey specific scripts with
turnkey-(e.g.turnkey-version). I'd be inclined to stick with that precedent. Although we could provide an alternate name starting withlxc-(probably includingturnkeyortklin the name too to make it clear where it comes from).If we were to develop this script, my inclination would be to allow it to accept arguments (e.g.
--password) (so it could run non-interactively). But any arguments not supplied would be asked. Perhaps to add value, it would also start the freshly created/configured container?TBH, I'm not sure if/when we'll get to that, but in essence I think it's quite a cool idea. If you want to hone your bash skills, then perhaps it's something you might want to have a crack at?! :)
Something else re inithooks and set up.
It may not be immediately obvious, but there are additional (optional) inithooks that apply to some of our servers. It's a little out of date (and needs update for v15), but the inithooks readme documents most of them.
You can also re-run them (all) interactively by running
turnkey-init. Or you can re-run the applaince specific ones by launching them directly. E.g. for the Domain Controller appliance; run/usr/lib/inithooks/bin/domain-controller.py.Again, it needs updating for v15, but there is some documentation that should still be (mostly) relevant in the docs regarding the domain controller here. The info is (sort of/somewhat) replicated on the website in the appliance specific docs.
As you are no doubt aware by now, documentation is an area of TurnKey where we are sadly lacking and need some significant improvement...
Thank you Jeremy
I neglected to say Thank you Jeremy for your frequent checking in and nudges in the right direction. It really helped. I likely would have given up if I didn't see you paying attention, and being receptive to feedback.
You're most welcome Matt! :)
I really enjoy helping people out (I'm actually a social worker by profession). And I want TurnKey to be the best that it can be. I want it to be the best, most user friendly server distro around. As Alon and Liraz (the TurnKey founders) are wont to say; "easy things should be simple and hard things should be possible"! We've still got a long way to go, but I'd like to think that we'e making progress.
FWIW I learned most of what I know about Linux while helping people here on the TurnKey forums! I was a complete Linux newb when I first came across TurnKey. But it really piqued my interest, so I spent heaps of time trying to help people (talk about the blind leading the blind...) and I learned so much along the way. Then one day, Liraz offered me a job with TurnKey and they'll never get rid of me now! :p
Summary
Work in progress. I'll continue to update this post for awhile.
Goal: A home Active Directory based environment from one physical machine.
With Samba 4, this means one server as Domain Controller and a second as File Server, with both of these hosted in an LXC container. Everything is behind a router and not directly exposed to internet.
[1] Download and create bootable USB or CD from Turnkey Linux Containers image.
Install it. Possibly need to fix network settings.
It lives at: http://lxc.home.lan/
[2] Install LXC Domain Controller:
Create default inithooks conf. Adjust values after the '=' as desired (i.e. set your own passwords, email, domains, etc).
Download and install Domain-Controller:
-n dc: what to name the machine, e.g. \\dc from a Windows workstation.
-f .../bridged.conf: use bridged network config, the DC will show up as a unique machine on the network, distinct from the LXC controller.
-t turnkey: tell LXC scripts to use the turnkey template
-- domain-controller: the name of the Turnkey app to download and install. Important: there is intentional whitespace between `--` and `domain-controller`
Start the domain controller:
It lives at: http://dc.home.lan/ and \\dc
[3] Install LXC Fileserver:
largely same as #2.
It lives at: http://files.home.lan/ and \\files
[4] Join Fileserver to domain.
Configure.
(I don't have this part working. Fileserver is joined to domain but user syncing etc. is not happening).
[5] Join windows workstation(s) to domain.
Install RSAT tools for easier domain administration, including user and group management. Some of the tools error out, but the important ones work.
[6] Live long and prosper.
Great work Matt!
Thanks for this Matt. I'm sure that this will be useful for others.
As noted elsewhere, I've removed your duplicate posts and mildly edited the one I left.
Re the user mappings on your Fileserver, FWIW our Fileserver uses a Samab3 style config which maps Samba users to Linux users. Historically, the automation of the synchronisation of that was handled by a samba module that plugged into the Linux user management system. However it was since discovered that there was a security issue with that module and Samba are no longer maintaining it, so it is gone...
My understanding is that Samba4 style config (as default on the domain controller appliance) uses a single Linux user account to contain all Samba users. However for that to work. it requires filesystem ACLs (they allow additional info beyond the basic Linux file permissions system).
So I may be incorrect, but AFAIK, on your fileserver, you have 2 options.
1. Manually create all your users on the fileserver (both Samba and Linux). Obviously that will only work in a home type environment where you will rarely need to add additional users. In an SMB environment it's probably sub-optimal. Also note, that if any of the Linux users are used (e.g. SFTP), that passwords will not be auto synced. So if a user changes their Windows/Samba password, that will not automatically update the password of the Linux user. This may not be an issue, but I wanted to raise it. TBH, I forget what implications that may have for the fileserver files webUI.
The other option would be to enable ACLs. TBH, I'm not 100% sure how to do that on an LXC guest, but I do know that it will depend on support from the host (I.e. the LXC host appliance will need to have them enabled). You may also need to manually add something to the LXC guest config file to pass them through to the guest. Hopefully google will assist there...
Please share if you find anything interesting and/or useful. Alerting other users is really helpful and may also give us ideas of stuff which might be useful to pre-configure in a future release.
Welcome Matt
Welcome to the world of TurnKey GNU/Linux. Sorry to hear that you had some problems getting started. Despite the name TurnKey, there is still a bit of learning curve for new users, especially for more complicated appliances like LXC. I remember being exactly where you are when I started working with the LXC appliance several years ago. Reading the thread above, I would say that you're getting up to speed faster than I did. :)
Thanks for being an involuntary guinea pig re: testing of the v15.0 LXC appliance. Your experience should help us improve the documentation for v15.1.
I've issued a new git pull request that addresses the network issues you mentioned.
Update confconsole for v15.1 #25 They are now waiting for Jeremy's approval and releasing an updated Debian package for confconsole.
In the meantime, if you would like to test the changes in your environment, you can download new copies of:
/usr/lib/confconsole/ifutil.py
/usr/lib/confconsole/plugins.d/System_Settings/hostname.py
To run the test, first backup the original files above and your current /etc/network/interfaces file. Next replace the files from the links above and restore the default /etc/network/interfaces which should look something like this
Then you should be able to use confconsole to switch between DHCP and static modes as well as change the hostname.
Information is free, knowledge is acquired, but wisdom is earned.
Add new comment