DNS and DHCP LXC reqeuest.

[lukasmrtvy]

Any love for DNS and DHCP LXC turnkey ? My use case is to deploy LXC to Proxmox and handle DNS/DHCP for created VMs with this LXC. Thanks

[Dude4Linux]

@lukasmrtvy - The LXC appliance uses dnsmasq to provide DNS and DHCP services to nat bridged containers. If I understand you correctly, you are wanting to have it also provide services to Proxmox VM's and containers. Current LXC dnsmasq.conf

#/etc/dnsmasq.conf
# Accept DNS queries only from hosts on local subnets
local-service

# Clear DNS cache on reload
clear-on-reload

# Additional hosts added by nginx-proxy
addn-hosts=/etc/hosts.dnsmasq

# Do not provide DHCP or TFTP on the specified interfaces,
# but do provide DNS service
no-dhcp-interface=eth0
no-dhcp-interface=br0

# interface natbr0
domain=local.lxc,192.168.121.0/24
dhcp-range=192.168.121.100,192.168.121.200,infinite
dhcp-option=40,local.lxc

# uncomment following line to debug dnsmasq
#log-dhcp

1. Your Proxmox host and the LXC vm must have static IP addresses defined in /etc/hosts e.g.

   192.168.1.10  proxmox
   192.168.1.11  lxc

2. All other DHCP servers must be disabled
3. Comment out the line above "# no-dhcp-interface=eth0"
4. Create a new config file, /etc/dnsmasq.d/proxmox.conf with the following contents modified with your network address and preferred domain name

   # interface eth0
   domain=local.pmox,192.168.1.0/24
   dhcp-range=192.168.1.100,192.168.1.200,3h
   dhcp-option=40,local.pmox

5. Restart dnsmasq
6. You may need to add the hostname option to each dhcp interface in /etc/network/interfaces in the VM's so that they will register the hostname with dnsmasq.

[JedMeister]

Thanks @Dude4Linux

@lukasmrtvy - Hopefully @Dude4Linux's post might help get you going?!

Although I'm not completely clear why you would be launching our LXC appliance on Proxmox?! FWIW Proxmox already supports LXC OOTB! Our current LXC templates are actually primarily targeted at PVE and are available for download within the Proxmox UI.

Perhaps you are just trying to lock down the security of LXC containers and provide additional separation between them and the host?

Anway... IMO, there is potentially room for a DNS/DHCP "infrastructure" appliance, although I don't see it as a priority. Also even if we did provide one, I doubt that OOTB it would be directly compatible with your use case (although perhaps I misunderstand something?).

[lukasmrtvy]

JedMeister: Well, my use case is to use something like cobbler, matchbox, foreman,etc for PXE. Its really hard to provison VM as IaaS (KVM, not LXC), so PXE would be a great help in this case.

But of course DNS/DHCP server will be usefull as well. For example I am using 2 interfaces on every VM, first for internet, second one for internal communication.. I dont care about static IP addresses on internal interface as long as they get DDNS update to DNS and I can request them with DNS record. Of course that I need to provide them nameserver with DNS server, but this is easily done with DHCP.

[Dude4Linux]

@JedMeister - In my case, I'm running LXC in a Proxmox VM which I use for testing with Ansible. At the time I started developing the Ansible appliance, it had support for LXC containers, but not Proxmox. Someone else has since developed the Ansible modules for Proxmox, but I've never bothered to try them because all my playbooks are written around LXC.

@lukasmrtvy - I'm afraid that you will run into the same problem I've had trying to get TurnKey appliances to auto register with DDNS because they don't currently include the hostname in the dhcp discover request. This has been a thorn in my backside for a long time. I've proposed some changes for v15.1 which I hope will solve the problem, but for now, the /etc/network/interfaces file needs to be modified. AFAIK TurnKey appliances have always used udhcpc to handle DHCP requests. I know of only two ways to get udhcpc to include the hostname in the dhcp discover request.

1. According to the man page, you can include the --fqdn (-F) NAME option on the command line.
2. From experience, I've found that adding the hostname option to each dhcp interface defined in /etc/network/interfaces will work in practice. e.g.

   
   auto lo
   iface lo inet loopback

auto eth0 iface eth0 inet dhcp hostname tkldev

@JedMeister - FWIW I found that either

hostname $HOSTNAME or hostname $(hostname)

seem to work okay, but I couldn't find documentation that confirmed it was okay to use bash variables in the `interfaces` file.  I chose the more conservative approach but that means the file needs to be updated whenever the hostname changes.

[l-arnold]

I am understanding this thread to be documentation on LXC. I read it requires a Static IP and interfaces to be setup as generally described here.

I have just run an Install of 15.0 to Linode. I am getting Linode GLISH contact with the IP that in other installs I can get access to. The LXC install however is not accessible by any of the methods shown in ConfConsole on install completion: http, https, 12320, 12321 or SSH.

I note that the ip address has been assigned by DHCP - correctly (functionally static) Rather than eth0, the Network Adapter is br0

I could request a Static IP for this (likely with a cost) but as I am just testing, I think I need to understand the situation first.

I can fully navigate the backend via GLISH, but only that way. I can shutdown and restart.

Is there more documentation on the LXC appliance?

[l-arnold]

Quick followup. Moving to make IP Static in method above brings inescapable crash in confconsole. Picture attached. I can probably move within shell to set up new settings.
(Referentially, my first go round before this tried to use tklapp as a HostName but that also was not resolving.
Do note, again, that I have gotten Magento, Odoo, Lapp, Wordpress all to install with the same method used here.

[Dude4Linux]

@l-arnold - Like many projects, the TurnKey LXC appliance, suffers from limited documentation. At some point, I hope that TurnKey GNU/Linux will adopt a documentation system based on Sphinx. That would take a lot of effort and is something the principle developers will have to commit too.

In the meantime, there is a Usage document mentioned near the bottom of the appliance description page, https://www.turnkeylinux.org/lxc. Unfortunately the link there points to the 15.0 usage.rst. In January, I released updated documentation for version 15.1, but it is still in the approval queue. You can find the new version at https://github.com/Dude4Linux/lxc/blob/updates-for-15.1-release/docs/usage.rst. I hope it helps. If you have questions that are not covered by the documentation, please let me know here so I can update it before the next release. I just spotted a minor formatting error that I will need to fix.

FWIW, confconsole has never worked properly in LXC containers. In the initial release of the appliance, confconsole was completely disabled. Since then, several contributors have submitted changes to make confconsole compatible with LXC containers, but the results have been mixed.

In a separate PR (pull request) https://github.com/turnkeylinux/confconsole/pull/25 I have proposed changes to confconsole and the appliance build process that address the problem you illustrate in the screenshot above. Unfortunately, it requires a new upstream release of confconsole coordinating with changes to the build process that affects all appliances. I can't give you any estimate of when (or if) the changes will be adopted.

In the meantime, my recommendation is that you study the use of pre-seeding via the inithooks.conf file. For your use case, I'd recommending making a copy of inithooks.conf.example (found in the /root folder) for each of your containers e.g. wp.inithooks.conf. Then modify that file substituting your desired passwords, email address, domain name, etc. Next, add the following lines to each inithooks.conf file substituting your desired static addresses.

export IP_CONFIG=static
export IP_ADDRESS=XX.XX.XX.XX     # your static ip
export IP_NETMASK=255.255.255.0   # your netmask
export IP_GW=YY.YY.YY.YY          # your gateway address
#export IP_DNS1=DD.DD.DD.DD       # optional first dns server address
#export IP_DNS2=EE.EE.EE.EE       # optional second dns server address

Finally create the container while specifying the custom inithooks.conf using the -i option.

lxc-create -n wp1 -f /etc/lxc/bridged.conf -t turnkey -- wordpress -i /root/wp.inithooks.conf

This added bit of functionality was contributed some time ago by another developer, but apparently was never documented. It really should be documented as part of pre-seeding but I can include it in the LXC usage document. Another item for my TODO list.

[l-arnold]

Thank you John! That will give me a good head start. Today when I was pulling the ISO (as I have been unable to build on Linode otherways in TKL 15) I only saw LXC 15.0 on the umd.edu mirror. I will look for a 15.1 version.

Your Inithooks will be helpful guidance in general as I am working on various angles of building right now.

Thank you again! Landis

[Dude4Linux]

@l-arnold - I just updated the usage.rst documentation at the URL I listed above. Hopefully it will be somewhat more clear. I don't believe that a 15.1 version of LXC exists other than my development verson.

I just noticed that you were attempting to run on Linode. Can you tell me a little more about what you are trying to accomplish? I assume you are looking to launch and run TurnKey appliances on Linode just like folks do with AWS? Are you trying to write a Linode StackScript for TurnKey? Or were you just trying to install the LXC appliance over the top of a Linode Debian 9 host. The latter should be doable since I've been able to accomplish it with Ubuntu 16.04. You may want to take a look at my TurnKey Portable Development Environment (PDE) for some ideas about how it could be done. The pde-setup does most of the work. Currently pde-setup only works on Ubuntu, but it could be tweaked for other distributions. Let me know what you think.

[l-arnold]

Hi @Dude4Linux , Realistically I am wanting to do some of both. I could get TKL 14x to install to Linode from XEN builds relatively easily. I can now get TKL 15x ISO builds to install to Linode, but it is quite problematic to make them as compliant as the 14x builds were (reconfiguring GRUB and Image formats are very complicated). I am wanting to be able to control a build stable (ie hore stable) for TKL on Linode. The LXC environment was a query in that direction. I will definitely look at your PDE now. I appreciate the work you are doing in these directions.

[Dude4Linux]

@l-arnold - It appears to me that Linode is based on OpenStack. You might want to try importing the TurnKey OpenStack images as they should be the most compatible images available. ATM, there is a problem with the links on the TurnKey website returning an error

Error: not a legal filename 'turnkey-lxc-15.0-stretch-amd64-openstack.qcow2'

However the files exist on the mirror servers:

turnkey-lxc-14.1-jessie-amd64-openstack.tar.gz                       2016-04-12 04:08  253M  
turnkey-lxc-14.1-jessie-amd64-openstack.tar.gz.sig                   2016-04-12 08:50  1.4K  
turnkey-lxc-14.2-jessie-amd64-openstack.qcow2                        2017-07-28 05:42  738M  
turnkey-lxc-14.2-jessie-amd64-openstack.qcow2.hash                   2017-07-30 13:07  2.2K  
turnkey-lxc-15.0-stretch-amd64-openstack.qcow2                       2018-10-03 11:01  855M  
turnkey-lxc-15.0-stretch-amd64-openstack.qcow2.hash                  2018-10-18 11:10  2.2K  

I don't know why the image formats changed from v14.1 to v15.0. You would have to ask @JedMeister about that. The format change might be one reason you've had difficulty with the newer version. You might start by researching how to import a qcow2 image into Linode.

@JedMeister - You need to check the OpenStack links on the website appliance pages to see why they are returning the error above.