Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hooks: add hostname #19

Open
aparcar opened this issue Jul 4, 2018 · 5 comments
Open

hooks: add hostname #19

aparcar opened this issue Jul 4, 2018 · 5 comments
Milestone

Comments

@aparcar
Copy link
Contributor

aparcar commented Jul 4, 2018

currently the hooks only offer address and mac, would it be possible to add the clients hostname as an arg as well?

@sargon sargon added this to the r2 milestone Sep 25, 2018
@sargon
Copy link
Owner

sargon commented Sep 25, 2018

We could possible add some additional information provided by the client into the hook environment.

@aparcar
Copy link
Contributor Author

aparcar commented Sep 25, 2018

The hostname would be specially interesting to allow DNS entries

@BenBE
Copy link
Contributor

BenBE commented Oct 3, 2018

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_CLIENT_OPTION_## 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_CLIENT_VALUE_## 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.

@sargon
Copy link
Owner

sargon commented Oct 3, 2018

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.

@BenBE
Copy link
Contributor

BenBE commented Oct 4, 2018

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.

@sargon sargon modified the milestones: r2.1, r3 Jan 7, 2019
@sargon sargon modified the milestones: r3, r4 Mar 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants