You are here
I am unable to connect my containers to the network, please note that this are my first steps with LXC and I may have ommited something, so please feel free to point it out if you find it (in fact, please do it).
I have downloaded the turnkey-lxc-15.1-stretch-amd64.ova (several times actually, in several computers) and imported it to Virtualbox (for Windows, Versión 6.0.18 r136238 (Qt5.6.2), for freebsd 12.1 virtualbox version 5.2.34) and ESXI 5.5 and 6.7, in all cases using bridged network, the results are the same, as follows...
After initial configuracion (password, email, install updates (which proves conection to the network), reboot, get to the configuration console (LXC appliance services, shows ip address and various ports for ssh, web, webmin, etc) at this point I ssh in to the system, always using putty (recent enough or last version available) and run the commands in the web "Example (Bridge):
cat <<EOF > /root/wp1.conf export ROOT_PASS=secretrootpass export DB_PASS=secretmysqlpass export APP_PASS=secretadminwppass export APP_EMAIL=admin@example.com export APP_DOMAIN=www.example.com export HUB_APIKEY=SKIP export SEC_ALERTS=SKIP export SEC_UPDATES=FORCE EOF
I've tried changing the aproppiate fields fot passwords, mail and www and as is, with the values unchanged, then I run the next command:
lxc-create -n wp1 -f /etc/lxc/bridge.conf -t turnkey -- wordpress -i /root/wp1.conf
I've tried with wordpress, openvpn, nextcloud and others I don't remember now, in all cases I follow with:
lxc-start -n wp1 -d (or whatever name I used instead of wp1)
tand I get:
Container ncloud not connected:
then:
lxc-attach -n wp1 (or whatever name I used instead of wp1)
and:
ip address
to which I get:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 2a:5b:8e:8a:38:73 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::285b:8eff:fe8a:3873/64 scope link
valid_lft forever preferred_lft forever
So I went and followed this instructions https://www.turnkeylinux.org/forum/support/sun-20200202-2107/turnkey-lxc-containers-not-connected-solved to no avail.
So I turned to the source, deleted the VM, imported it clean and started again (several times actually) password, email, install updates, reboot and followed the networking section of https://wiki.debian.org/LXC#Installation including the "Minimal changes networking in “stretch”" section.
After that (and a reboot just in case) results are just the same, so I MUST be doing something stupidly wrong, cause at this point I can not get to connect any container for the life of me.
So I place myself in the wiser hands and expertise of the internet people who have guided me in my journey here for the past 20 years.
Thank you all for your time.
Other experiments
Please note that after I downloaded and installed minimal debian stretch, and after following installation and network instructions in https://wiki.debian.org/LXC#Installation, containers DO get an ip address:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:8e:b9:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.9.76/24 brd 192.168.9.255 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe8e:b962/64 scope link
valid_lft forever preferred_lft forever
Altough, this is not ideal for me, since I was trying to take advantage of the preconfigured turnkey appliances, and not having to make all from scratch... So if you can find what I should do differently, I'll test it inmediately.
Substitute "br0" with "enp0s3" maybe?
Hey Sergio, try my solution again but Substitute "br0" with "enp0s3"?
I looked at some diffrences and noticed you dont have a:
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether 00:0c:29:c4:18:6b brd ff:ff:ff:ff:ff:ff
Dont know if thats a problem. Just curios Is the host on the network with a static IP? I assigned my TK LXC host a static IP.
When I execute the "ip a" command, in addition to the eth0: lines, part of the results contain these lines in there:
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:c4:18:6b brd ff:ff:ff:ff:ff:ff
inet 192.168.2.240/24 brd 192.168.2.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fec4:186b/64 scope link
valid_lft forever preferred_lft forever
I am wondering if a variable needs to change.
In my case it was "br0:" and in your case perhaps its "enp0s3:" that may need to change.
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:8e:b9:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.9.76/24 brd 192.168.9.255 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe8e:b962/64 scope link
valid_lft forever preferred_lft forever
Ben
Hey Sergio, is networking ok on the host?
I assume that all the network info you've posted is from guests? I suggest that your should be 100% sure that networking is working fine on the host first. Considering the different things that you've tried, I'm guessing that it probably is, but just in case something else is going on here, please double check the network connectivity of the host system. If you haven't already, I suggest setting a static IP.
Assuming that the network info from both posts are guest container info, then are you sure that the "vanilla" Debian is working how you think it is? Obviously, it's working, but looking at that the info you've posted, assuming that is an LXC guest, that IP address (192.168.9.76) looks to me like a NAT IP address, rather than a Bridged one. Unless of course your LAN uses 192.168.9.x IP addresses (possible but seems unlikely)?!
If I'm right, then you're comparing apples to oranges, as NAT networking will provide a separate internal interface, but you won't be able to connect directly to that IP from elsewhere on your LAN. Instead you'll need to configure port forwarding and use the host's IP address. That's a totally valid way of doing things, but it isn't what you were doing before on TurnKey. FYI, the config that you've been trying to use on TurnKey is also described on the Debian wiki.
FWIW you can use NAT (instead of Bridged) networking on the TurnKey LXC appliance too. If you are happy with that, perhaps that will "just work"?
Regarding what we do to our appliance, as I noted before, all our build code is on GitHub. You can see the LXC specific packages we install in the plan. The additional (and/or tweaked) config files are within the overlay. Note the contents of the overlay is relative to '/'. So 'overlay/etc/some/config/file' should be found at '/etc/some/config/file' on your server. The other tweaks done are contained within the conf script. From a glance, it looks like it mostly tweaks kernel config/parameters relating to the host firewall.
I haven't worked extensively on it. In the last few years it has been further developed and maintained by a community member. Unfortunately, he hasn't been around for a while, but I'm sure that he would have some good ideas. As he isn't about, I suspect that I'll ge a much more intimate knowledge of it when I do the v16.0 update that will need to be done at some point.
Regardless, I don't understand why it's causing so much pain?! The example code from the docs was definitely working fine when it was released (as I tested it myself). I wonder if there's been a security upgrade that has broken something? That's the only thing that occurs to me... Although it still wouldn't explain how Ben managed to get it going but it won't work for you?!
The end
Thank you both for the help, but after 3 more days of banging my head against the wall, I found the answer 23 pages deep in an old discussion in another forum, and after searching the web so much and seeing how often this happens, I want to suggest a footnote perhaps for the LXC page here, something like:
Because otherwise you won´t get the bridge to work correctly (or at all) like it was my case, maybe this is obvious for some with some knowledge of networks, but sure it wasn´t for me and as I've learned, so many others that like me test everything first on a VM before touching hardware.
So that was it! everything was working as expected, and I have it up and running with 5 containers while I do my testing and set things the way I need it.
Jeremy, yes, my network is 192.168.9.x because I use a lot of openvpn and I need a segment that nobody uses.
With that solved everything I've tried has worked so far, so the learning curve has flattened a lot for me, since now I can test things as I'm reading them and everything works the first time (that I don´t make a typo, which happens a lot).
Thank you all and Jeremy, soon I'll post a problem I'm having with the openvpn appliance, which I fixed but it is a terrible fix and I'd like to fix it properly. Thanks again!
Wow, I've never come across that!?!
I've never come across that!?! It definitely sounds like we should add that to the LXC appliance docs somewhere!
Whilst I've never come across it, in fairness, I've never run the LXC host appliance in VMware or VirtualBox either - I use KVM/QEMU. I can only assume that KVM set it like that by default or is somehow smart enough to know when it's needed?
Regardless, great detective work and fantastic to hear that you've worked it out!
BTW, I'm not 100% sure where to put it, but to ensure that it doesn't get forgotten, I've opened an issue so it at least gets documented somewhere.
Re your OpenVPN workaround that you aren't happy with, I'm more than happy to add my 2c, but I'm no expert when it comes to OpenVPN. So no promises there, but sure please tell me about it when you get a chance.
Awesome!
Ill look for and use this solution!
I bet this was it in my case as well!
Really great!!
Add new comment