Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Expressions in option-data (Ola Thoresen)
2. Re: Expressions in option-data (Francis Dupont)
3. Re: Expressions in option-data (Ola Thoresen)
4. Re: Expressions in option-data (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Jan 2016 16:29:14 +0100
From: Ola Thoresen <[email protected]>
To: [email protected]
Subject: [kea-dev] Expressions in option-data
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
We are looking into using kea as the DHCP-server in a client environment
to auto-provision various network equipment.
In the "old" isc-dhcp you could use expressions in the DHCP-replies, like:
option bootfile-name = concat((option agent.circuit-id),".",(option
agent.remote-id),".cfg");
or
option hostname = binary-to-ascii (16, 8, "-", substring (hardware, 1, 6));
Is there any way to replicate this behavior in kea?
I know you can use a test to classify the clients, and match on
different options, but defining a class for each and every host to make
it use a certain bootfile is not really feasible...
Rgds.
Ola Thoresen
------------------------------
Message: 2
Date: Thu, 21 Jan 2016 16:48:26 +0000
From: Francis Dupont <[email protected]>
To: Ola Thoresen <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Expressions in option-data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ola Thoresen writes:
> Hi,
>
> We are looking into using kea as the DHCP-server in a client environment
> to auto-provision various network equipment.
> In the "old" isc-dhcp you could use expressions in the DHCP-replies, like:
>
> option bootfile-name = concat((option agent.circuit-id),".",(option
> agent.remote-id),".cfg");
> or
> option hostname = binary-to-ascii (16, 8, "-", substring (hardware, 1, 6));
>
> Is there any way to replicate this behavior in kea?
>
> I know you can use a test to classify the clients, and match on
> different options, but defining a class for each and every host to make
> it use a certain bootfile is not really feasible...
=> Kea provides another way to do this (and portentially any) kind
of things: the hooks.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 21 Jan 2016 18:46:12 +0100
From: Ola Thoresen <[email protected]>
To: Francis Dupont <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Expressions in option-data
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 21. jan. 2016 17:48, Francis Dupont wrote:
> Ola Thoresen writes:
>> Hi,
>>
>> We are looking into using kea as the DHCP-server in a client environment
>> to auto-provision various network equipment.
>> In the "old" isc-dhcp you could use expressions in the DHCP-replies, like:
>>
>> option bootfile-name = concat((option agent.circuit-id),".",(option
>> agent.remote-id),".cfg");
>> or
>> option hostname = binary-to-ascii (16, 8, "-", substring (hardware, 1, 6));
>>
>> Is there any way to replicate this behavior in kea?
>>
>> I know you can use a test to classify the clients, and match on
>> different options, but defining a class for each and every host to make
>> it use a certain bootfile is not really feasible...
> => Kea provides another way to do this (and portentially any) kind
> of things: the hooks.
>
>
Thanks for the reply.
I see that
http://git.kea.isc.org/~tester/kea/doxygen/d8/db2/libdhcp_user_chk.html
is a start, however it seems a bit much to make a full "plugin" just to
be able to name the bootfile dynamically based on the options provided
from the dhcp-client (or relay)
But I will look into it. It might open up other options that we have
not thought of yet.
Rgds.
Ola (T)
------------------------------
Message: 4
Date: Thu, 21 Jan 2016 23:41:54 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Expressions in option-data
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 21.01.2016 18:46, Ola Thoresen wrote:
> Thanks for the reply.
> I see that
> http://git.kea.isc.org/~tester/kea/doxygen/d8/db2/libdhcp_user_chk.html
> is a start, however it seems a bit much to make a full "plugin" just to
> be able to name the bootfile dynamically based on the options provided
> from the dhcp-client (or relay)
Hear, hear. ISC DHCP didn't have all its fancy capabilities in its 1.0
release either :) The problem here is that ISC DHCP was developed over a
long period of time and the expressions, such as you mentioned, require
a code that is difficult to maintain and extend. One of the reasons to
develop Kea from scratch is that we want to avoid such long term
maintenance pains. You happen to want the hostname to be generated based
on remote-id, but there are people out there, who prefer IP address, MAC
address, circuit-it or any other piece of the packet for that matter.
This is more complicated that it make look like at the first glance.
We strongly believe that the way forward is to develop a number of hooks
libraries that users could mix and match as needed.
Having said all that, I fully understand your point. I think we may have
an opportunity here to develop simple hooks app that would do what you
want it to do. We could use existing client classification code that
essentially takes various options from the packet and evaluates it. It
currently is used to determine if the client belongs to a class or not,
but we could easily extend it to evaluate to a string. That string could
be then used to set an option name. The classification code does not
allow accessing relay options yet, but it's planned for the next
release. I need to think a bit more about this, but it seems very doable.
Do you want to do DNS update with that name or just the option values
sent back to the client?
> But I will look into it. It might open up other options that we have
> not thought of yet.
Please do. I'd love to hear your thoughts about this.
I will talk with the team and we'll see what we can do to make
implementation of such hooks easier.
Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 22, Issue 9
**************************************
