Open aparcar opened 6 years ago
We could possible add some additional information provided by the client into the hook environment.
The hostname would be specially interesting to allow DNS entries
To minimize processing and allow for maximum flexibility at the same time the information from the DHCP packet could be provided as environment variables for each option using hex encoding and a naming scheme like DHCP_CLIENTOPTION## with ## being the hex encoded ID of that option. This avoids issues with zero bytes and other sensitive data potentially needing escaping when passed along to the client. For certain common options a second (mirrored) variable DHCP_CLIENTVALUE## with the decoded value (e.g. IP address form) could additionally be passed. For this value form any unsafe character would be sanitized as something safe like underscore (not valid for host names, but causes least issues when passing around in badly written shell scripts). If the original value is required the raw option bytes could be consulted.
I think we don't need to make too much out of this requests, the information provided by the client to the dhcp server is restricted to a name and a list of options it likes to see. So providing the name or hostname to the hook script is a good idea, going further maybe the requested options list, but for more than this I see no real use case.
Providing the options sent back to the client actually is much easier in the current state of affairs than pulling up the REQUEST from the client and looking up the requested options list. Some initial work can be found at https://github.com/BenBE/ddhcpd/tree/hook-pass-ack-in-env on my branch, which apart from not producing the pretty-printed option values, already does pass all the options to the hook.
Beware: May still randomly kill innocent cute little kittens.
currently the hooks only offer address and mac, would it be possible to add the clients hostname as an arg as well?