Implement the generate() operator.
name: Implement the generate() operator. about: Implement the generate() operator as part of dhcp-eval. generate() is similar to execute() in that it executes an external program. However, unlike execute(), generate() is a data expression: it reads up to 1024 bytes from the standard output of the resulting child process and makes them available as a C string. It can therefore be combined with substring(), concat() and other similar operators for maximum flexibility. Like execute(), generate() can be disabled through ./configure --disable-generate.
Note: this feature request probably rings a bell; it is actually a follow up to https://bugs.isc.org/Public/Bug/Display.html?id=48316 as I am still interested in this feature.
Some initial questions
Are you sure your feature is not already implemented in the latest ISC DHCP version?
=> Sure enough for me to write a patch back in October 2018; according to grep, the situation has not evolved since then.
Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a good time to consider migration?
=> My understanding of the Kea project is that it provides a DHCP server, not a DHCP client. Although my patch extends dhcp-eval, a part common to both iscp-dhcp-server and isc-dhcp-client, it was designed with isc-dhcp-client in mind.
Are you sure what you would like to do is not possible using some other mechanisms?
=> The most common approach to emulate a generate() operator consists in using a separate tool (scripts, Puppet, SaltStack, Ansible, etc.) to re-generate the ISC DHCP client configuration file. This approach is clearly hackish and non-perennial.
Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
=> No, it was only briefly discussed on https://bugs.isc.org/Public/Bug/Display.html?id=48316
Is your feature request related to a problem? Please describe.
This feature is indeed related to a problem: in 2018, we stumbled upon an ISP which expects a particular value for options 90 or 11 (authentication). This value is computed using a proprietary, ISP-specific algorithm (it involves random salts, MD5 hashing and a password... far from rocket science, but definitely ISP-specific) and should be renewed systematically or at least frequently. Moreover, this algorithm is likely to change often enough to discourage its implementation in C within dhclient/dhcpd. generate() enables users to delegate tricky value generations to external programs that can be implemented using higher-level languages and can be updated frequently.
Describe the solution you'd like
I am willing to update the patch I had submitted back in October 2018 and make a pull request out of it. To this end, I need:
- confirmation that this feature could make its way into isc-dhcp
- a 'project allocation'
Describe alternatives you've considered
It would be tempting to look for another DHCP client, or even write a small one dedicated to the ISP mentioned above. That would however be quite frustrating as the dhcp-eval mechanism has been around for years and is so close to offer a solution to the encountered problem.
Funding its development
I consider that I should either give time (i.e. code/patches) or money. In this case, I chose the former.
Participating in development
Are you willing to participate in the feature development?
=> Yes, obviously.
ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions?
=> Yes, totally.
Are you willing to test an unreleased engineering code?
=> Yes, I am.
Email (as provided by registering to ISC's Gitlab instance) is fine.