MAAS should let you specify which interfaces you want to bind tftp on.

[Leonardo Borda]

I need MaaS to ONLY bind to the IP address I tell it, preferably from the config. Right now, I get this:

```
tcp UNCONN 0 0 127.0.0.1:69 *:* users:(("twistd",11886,13))
tcp UNCONN 0 0 192.168.122.1:69 *:* users:(("twistd",11886,11))
tcp UNCONN 0 0 192.168.154.132:69 *:* users:(("twistd",11886,10))
tcp UNCONN 0 0 192.168.80.132:69 *:* users:(("twistd",11886,6))
tcp UNCONN 0 0 ::1:69 :::* users:(("twistd",11886,5))
```
But I need it to ONLY bind to 192.168.122.1:69. Looking through `/usr/lib/python2.7/dist-packages/provisioningserver/config.py`, it doesn't look like there's a config option for this. I'm hoping there's some other work around. Environment variable, maybe?

Thanks for the help.

[Leonardo Borda (lborda)]

Use case:
One of the use cases is when you would like to run two TFTP servers on a single machine. We would like both to bind to different IP addresses. The reasoning in doing this is when MAAS isn't able to do all the bare-metal provisioning (re: other provisioning environments in the mix). In this scenario there's is a boot stage that classifies what type of baremetal node is loading and then chainloads to the appropriate service.

[Christian Reis (kiko)]

For the use case Leonardo outlined above, MAAS would actually need to grow the ability to allow specifying (either per-host or more widely) DHCP configuration fragments, which would permit defining a boot filename and next-server.

The approach of using a separate tftp server for the alternative files is a bit of a red herring -- MAAS could certainly track and deliver those files as it does pxelinux.0, the kernel and initrd it delivers for the ephemeral image, for instance -- as the real issue is being able to control what the DHCP response is for a certain range of devices or addresses. Using a separate tftp server for those files just removes one part of the complexity required to address that use case.

Finally, I don't think we want to support multiple provisioning systems being delivered from the same server node without a very strong business rationale; it will make full HA much harder to accomplish, for instance.

[Christian Reis (kiko)]

Limiting the ports tftp listens on for security purposes is definitely something we should look into regardless. It will require some reflection, however.

Restricting tftp to the cluster interfaces we have selected as DHCP Managed would be simple, but unfortunately too simplistic: it would unfortunately break configurations where DHCP is externally managed but where MAAS is still expected to deliver the PXE environment.

We could add an additional management option (PXE only with external DHCP), but we've never considered adding such an option before AFAIK.

[Michael H Wilson (geekinutah)]

@Christian,

I don't think MaaS needs to worry about the case of controlling DHCP configuration fragments for this use case. It just needs to focus on being isolated to where it is used. This code in particular is problematic:

<snip>
def updateServers(self):
        """Run a server on every interface.

        For each configured network interface this will start a TFTP
        server. If called later it will bring up servers on newly
        configured interfaces and bring down servers on deconfigured
        interfaces.
        """
        addrs_established = set(service.name for service in self.getServers())
        addrs_desired = set(get_all_interface_addresses())

        for address in addrs_desired - addrs_established:
            if not IPAddress(address).is_link_local():
                tftp_service = UDPServer(
                    self.port, TFTP(self.backend), interface=address)
                tftp_service.setName(address)
                tftp_service.setServiceParent(self)

        for address in addrs_established - addrs_desired:
            tftp_service = self.getServiceNamed(address)
            tftp_service.disownServiceParent()
</snip>

Instead of assuming everything on the machine is yours, accept a configuration parameter that tells MaaS which interfaces it shold care about. This behavior would be more intuitive and allow use of MaaS in complex environments. It allows the solution to use cases such as the one above to be developed using MaaS as a component or a part of the solution rather than MaaS needing to be an entire vertically integrated solution.

[Aleksey Zvyagintsev (azvyagintsev)]

3y behind... any news ?)

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team