sudo netstat -lnp should help figure out what’s already listening on the DNS or DHCP port.
Actually, I think I found it:
bind 1903 0.0 0.0 1921704 68716 ? Ssl Nov29 0:03 /usr/sbin/named -f -u bind
You have named running on your host (bind9), is that on purpose or just an accident?
If on purpose, it needs to be configured to only bind the interfaces you care about, if it’s an accident, then you should remove the bind9 package.
After that, restarting the LXD daemon will have it spawn its dnsmasq daemon, fixing DHCP for your container.
Greetings
bind was setup as part of a server package (a lamp stack). I am still hoping to run the software that the server was set up for but I would now prefer to run it in a container (lxd).
So I should be removing bind or is there some not too complicated a method that would allow me to ‘use’ this (and/or any other) container?
If I do remove bind is it again cause me issues if I place it in the container for use by the software there?
Bind wouldn’t cause any conflict if run inside a container.
OK - - - removed bind9 and dnsutils.
Network connection still isn’t possible.
memyself@xxxxx:~$ lxc list
±-------±--------±-----±-----±-----------±----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
±-------±--------±-----±-----±-----------±----------+
| debian | RUNNING | | | PERSISTENT | 0 |
±-------±--------±-----±-----±-----------±----------+
memyself@xxxxx:~$ lxc network show lxdbr0
config:
ipv4.address: 10.15.189.1/24
ipv4.nat: “true”
ipv6.address: fd42:a80e:56f1:cd::1/64
ipv6.nat: “true”
description: “”
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/debian
managed: true
Looking at:
stgraber.org/2016/10/27/network-management-with-lxd-2-3/
I don’t understand what I need to do (or change) to effect network connection(s).
(I very much appreciate the clarity and the detail in your blog entries re: lxd. Have seen very few with that level of detail and clarity. For noobs and the less knowing the only thing that could improve what you have are failures and recoveries. By that I mean - - - command x is given, expected result is then listed, also listed would be result xa occurred, followed by something like xa as a result means that setting y is incorrect. Setting y should read like this. For readability this error (and recovery) file would likely be attached to but not directly in the flow of ‘what to do’. I most often find man pages incredibly hard to follow. I know they are written for the expert as a reminder - - - but I’m not an expert and I’m all too often fumbling my way through something that I know precious little about so I count on things like your blog which offer so much greater clarity and assist in the understanding. Thanking you for your assistance!!!)
Did you restart LXD and then restart your container?
Otherwise the dnsmasq daemon still wouldn’t be running.
That did the trick!!!
Thank you very much!
I had restarted the container but had not restarted lxd.
One point that would help, at least IMO, would be if all the lxc commands were modified to lxd commands. It would be then easier to confirm that one is working in lxd.
Something that (IIRC) you are doing but isn’t too common is to date blog entries or other informational blurbs. I have learnt to distrust such without dates as their methodology is far too often severely deprecated most often because the techniques are outdated.
Thank you for your very generous help!!!