MySQL Config Backend must not validate formatted options fetched from the DB
There is a dependency between DHCP options and the option definitions. Some options can be parsed without option definitions, but only if the option data is specified in the hex/string format. Many times, administrators specify options with the csv-format
parameter set to true
. Such options require option definitions to be interpreted. There are three places where such interpretation is required. One, when the option is added to the database via cb_cmds hooks library. Second, when the option is fetched from the database and must be used by the DHCP server. Third, when the option is returned via the control channel as a result of the remote-option4-global-get
. However, the option definitions may not be available at the time when options are stored or fetched from the config database.
This ticket is going to address the second case and will remove the dependency of fetched options from the option definitions stored in LibDHCP
. For each option that contains a formatted_value the mysql_cb will return generic option_
member that holds a pointer to an empty option (OptionPtr
) having appropriate option code. The formatted option data will be carried in the OptionDescriptor
object. The returned data won't be validated against definitions in the mysql_cb. We will have another utility function (part of CfgOption
?) that will go over options and validate them against appropriate option definitions. The server will invoke this function upon the config merge.
The other two cases (validating of options in the cb_cmds) are out of scope in this issue. We're going to continue using LibDHCP runtime option definitions to validate the options within cb_cmds. It will be addressed in another ticket(s), likely after 1.6.0.