I’m trying to giving ssh access from outside to my containers by setting a NAT port-forwarding rule on the host (Basically I plan to use one port by container and forward the incoming traffic on this port from outside to the container port 22).
I managed to get it working manually but, in order to automatizing the process, I want to create the rule when the container start and removes it when it stops.
The lxc.net[i].script.up and lxc.net[i].script.down seemed to me a good starting point but I noticed that you cannot configure it when editing container config with LXD I mean by using :
lxc config container set rax.lxc lxc.net.0.script.up=path/to/my/script
or
lxc config container edit
I end up with this error message:
Blockquote Config parsing error: Only interface-specific ipv4/ipv6 lxc.net. keys are allowed
So my questions are
Is this the right way to use these hooks ?
And if yes Is there a way to configure these hooks with LXD ?
LXD won’t allow you to set any of the hooks keys on a container, that’s more of a design decision than a technical one. We don’t want containers to depend on shell scripts that may or may not be present, especially when factoring in container migration, restoring an old snapshot, …
There are however ways around this check for those who really really want to go behind LXD’s back
The easiest one of those would be to put those extra bits of config into a text file, then using lxc.include in your raw.lxc to have that file included. This would bypass LXD’s configuration validator and feed that straight to LXC.
For your particular use case, the next LXD release will include the first pass on the proxy device which will let you do such port forwarding directly through the LXD API.
Another thing we have in the pipeline (but no timeline for it yet) is a better set of API events for container lifecycle, with those, you could effectively trigger actions on container start/stop, including checking for LXD configuration keys, those would be non-blocking though.
To learn more about those two, you can take a look at:
I’ve even tested with an empty file to see if the content was lying but it always give me the same result
I’m under lxd 2.1 the stable snap.
If you got any idea i’ll be glad :).
I guess the best thing for now is waiting for the proxy feature to be included in the next stable release.
By the way about the proxy there’s a case I don’t understand; in the case your container get their IPs from dhcp how can you stipulate an IP in the config ?
So the proxy device is funny in that it doesn’t need to know the IP address of the container, in fact, it doesn’t even need the container to be connected to the network.
It’s effectively a tiny process which copies connections across network namespace, so you can have it forward port 22 of some IP on the host, to port 22 of 127.0.0.1 in the container, and that’ll work perfectly fine.
For the include issue, you should use some path under /var/snap/lxd/common/lxd so that it’s visible to LXD running in the snap environment.
snaps don’t see your entire filesystem (for security reasons), so when you tell it to include /usr/local/etc/lxc.raw.conf it attempts to open that path in its own view of the filesystem, where it doesn’t exist.
