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. Re: Is it possible for hooks to hande server shutdown?
(Baptiste Jonglez)
2. Re: Is it possible for hooks to hande server shutdown?
(Dave Cole)
3. Re: Is it possible for hooks to hande server shutdown?
(Baptiste Jonglez)
4. Re: Implementing Radius-based host reservation - discussion
on RADIUS support (Chaigneau, Nicolas)
5. Re: Implementing Radius-based host reservation - discussion
on RADIUS support (Baptiste Jonglez)
----------------------------------------------------------------------
Message: 1
Date: Tue, 3 Oct 2017 07:24:46 +0200
From: Baptiste Jonglez <[email protected]>
To: Dave Cole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Is it possible for hooks to hande server
shutdown?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
On 01-10-17, Dave Cole wrote:
> I have been working on a hook to publish events to a Kafka server. The Kafka
> library creates a thread for communication with the server, which creates a
> problem when the kea server is stopped as there might still be messages that
> have not been delivered to the Kafka server.
>
>
> There is a simple way to monitor the Kafka thread. Is there any way for the
> hook to detect server shutdown and delay process termination until delivery
> to Kafka has completed?
Have a look at the "unload" hook point. I'm not sure what would happen if
you block too long in this function, though: the init system might get
impatient and try to forcibly kill kea.
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20171003/e2fa459a/attachment-0001.bin>
------------------------------
Message: 2
Date: Tue, 3 Oct 2017 06:33:08 +0000
From: Dave Cole <[email protected]>
To: Baptiste Jonglez <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Is it possible for hooks to hande server
shutdown?
Message-ID:
<syxpr01mb1727044a82a423761ca577d7f2...@syxpr01mb1727.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
> From: Baptiste Jonglez <[email protected]>
> On 01-10-17, Dave Cole wrote:
> > I have been working on a hook to publish events to a Kafka server.? The
> > Kafka library creates a thread for communication with the server, which
> > creates a problem when the kea server is stopped as there might still be
> > messages that have not been delivered to the Kafka server.
> >
> > There is a simple way to monitor the Kafka thread.? Is there any way for
> > the hook to detect server shutdown and delay process termination until
> > delivery to Kafka has completed?
>
> Have a look at the "unload" hook point.? I'm not sure what would happen if
> you block too long in this function, though: the init system might get
> impatient and try to forcibly kill kea.
>
> Baptiste
I am not seeing the unload hook point being called on server shutdown. That
was what I was hoping would happen, but I see no evidence of that.
------------------------------
Message: 3
Date: Tue, 3 Oct 2017 08:41:05 +0200
From: Baptiste Jonglez <[email protected]>
To: Dave Cole <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Is it possible for hooks to hande server
shutdown?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On 03-10-17, Dave Cole wrote:
> I am not seeing the unload hook point being called on server shutdown. That
> was what I was hoping would happen, but I see no evidence of that.
Hmm, ok, I never needed this hook point. Are you sure you defined it with
the right type, wrapped in an extern "C", etc, as in the example here?
https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/hooksdgDevelopersGuide.html#hooksdgLoadUnloadFunctions
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20171003/21ebc4e1/attachment-0001.bin>
------------------------------
Message: 4
Date: Tue, 3 Oct 2017 08:56:08 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Baptiste Jonglez <[email protected]>, Marcin Siodelski
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Implementing Radius-based host reservation -
discussion on RADIUS support
Message-ID:
<ab94b0b675bdf14189cd5a861db36c845a733...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
This topic is interesting to me. We're discussing a similar need for RADIUS
support within Kea.
Our need would be the following:
Allow to create and send a RADIUS Accounting message to a remote RADIUS server.
For example, send an Accounting Start when a lease is allocated, with the
leased IP address along with information extracted from the DHCP request
(typically options 82).
On lease expiration or release, send an Accounting Stop.
To have a minimal impact on Kea, we would not wait for the Accounting Response.
So I'm thinking, maybe it would be nice to support some kind of generic RADIUS
engine within Kea, which could be used for multiple purposes. It could be used
for RADIUS based reservation, or called from hooks - to do whatever we need to
do with RADIUS.
This is still early, but I wanted to share with you that this is relevant to
us. :)
Regards,
Nicolas.
> Hi,
>
> We have now made good progress with the code and the tests, although it's far
> from being production-ready yet.
>
> Can we get feedback on the design, so that we can make the needed changes and
> then move to code review? The ticket is here:
>
> http://kea.isc.org/ticket/5349
>
> Thanks,
> Baptiste
>
> On 24-08-17, Marcin Siodelski wrote:
> > Baptiste,
> >
> > Support for Radius based reservations is definitely a useful feature
> > and we have discussed a need for this within the ISC engineering team
> > several times. We will certainly look at your request and will provide
> > some comments in your ticket. However, please allow the time for us to
> > gather together to discuss it. Currently, many of the team members are
> > still on vacation.
> >
> > It is realistic that we'll get back to you by the end of next week.
> >
> > Marcin Siodelski
> > ISC
> >
> > PS. The delay in this response is also caused by the fact that it is a
> > holiday season.
> >
> > On 16.08.2017 11:24, Baptiste Jonglez wrote:
> > > Sorry for the spam, I have just realised that there is a more
> > > appropriate kea-dev mailing list.
> > >
> > > We have just started the initial development of this feature. I have
> > > created a ticket to faciliate feedback from the Kea team:
> > > http://kea.isc.org/ticket/5349
> > >
> > > Thanks,
> > > Baptiste
> > >
> > > On 14-08-17, Baptiste Jonglez wrote:
> > > > I realise I may not have been clear: what we are looking for is
> > > > *host
> > > > reservation* based on lookups towards a Radius server.
> > > >
> > > > So I was basically asking for a new hook point that would allow to
> > > perform
> > > > host reservation within a hook.
> > > >
> > > > A simpler alternative would be to implement radius support
> > > > directly in Kea, alongside the existing Mysql, Postgresql and
> > > > Cassandra support for host reservations.
> > > >
> > > > If we develop this (directly in Kea, not as a hook), would it have
> > > > a chance of being accepted?
> > > >
> > > > Thanks,
> > > > Baptiste
> > > >
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Message: 5
Date: Tue, 3 Oct 2017 13:04:21 +0200
From: Baptiste Jonglez <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Implementing Radius-based host reservation -
discussion on RADIUS support
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
On 03-10-17, Chaigneau, Nicolas wrote:
> This topic is interesting to me. We're discussing a similar need for RADIUS
> support within Kea.
>
> Our need would be the following:
> Allow to create and send a RADIUS Accounting message to a remote RADIUS
> server.
> For example, send an Accounting Start when a lease is allocated, with the
> leased IP address along with information extracted from the DHCP request
> (typically options 82).
> On lease expiration or release, send an Accounting Stop.
>
> To have a minimal impact on Kea, we would not wait for the Accounting
> Response.
This sounds like something that could easily be done as a hook.
In contrast, host reservation (what we are interested in) would be awkward
to do as a hook, so we have an initial implementation directly in Kea.
> So I'm thinking, maybe it would be nice to support some kind of generic
> RADIUS engine within Kea, which could be used for multiple purposes. It could
> be used for RADIUS based reservation, or called from hooks - to do whatever
> we need to do with RADIUS.
You mean a Radius library? For our implementation, we decided to use
libradcli, see the ticket linked below for a rationale.
> This is still early, but I wanted to share with you that this is relevant to
> us. :)
Thanks for sharing :)
> > We have now made good progress with the code and the tests, although it's
> > far from being production-ready yet.
> >
> > Can we get feedback on the design, so that we can make the needed changes
> > and then move to code review? The ticket is here:
> >
> > http://kea.isc.org/ticket/5349
> >
> > Thanks,
> > Baptiste
> >
> > On 24-08-17, Marcin Siodelski wrote:
> > > Baptiste,
> > >
> > > Support for Radius based reservations is definitely a useful feature
> > > and we have discussed a need for this within the ISC engineering team
> > > several times. We will certainly look at your request and will provide
> > > some comments in your ticket. However, please allow the time for us to
> > > gather together to discuss it. Currently, many of the team members are
> > > still on vacation.
> > >
> > > It is realistic that we'll get back to you by the end of next week.
> > >
> > > Marcin Siodelski
> > > ISC
> > >
> > > PS. The delay in this response is also caused by the fact that it is a
> > > holiday season.
> > >
> > > On 16.08.2017 11:24, Baptiste Jonglez wrote:
> > > > Sorry for the spam, I have just realised that there is a more
> > > > appropriate kea-dev mailing list.
> > > >
> > > > We have just started the initial development of this feature. I have
> > > > created a ticket to faciliate feedback from the Kea team:
> > > > http://kea.isc.org/ticket/5349
> > > >
> > > > Thanks,
> > > > Baptiste
> > > >
> > > > On 14-08-17, Baptiste Jonglez wrote:
> > > > > I realise I may not have been clear: what we are looking for is
> > > > > *host
> > > > > reservation* based on lookups towards a Radius server.
> > > > >
> > > > > So I was basically asking for a new hook point that would allow to
> > > > perform
> > > > > host reservation within a hook.
> > > > >
> > > > > A simpler alternative would be to implement radius support
> > > > > directly in Kea, alongside the existing Mysql, Postgresql and
> > > > > Cassandra support for host reservations.
> > > > >
> > > > > If we develop this (directly in Kea, not as a hook), would it have
> > > > > a chance of being accepted?
> > > > >
> > > > > Thanks,
> > > > > Baptiste
> > > > >
>
> This message contains information that may be privileged or confidential and
> is the property of the Capgemini Group. It is intended only for the person to
> whom it is addressed. If you are not the intended recipient, you are not
> authorized to read, print, retain, copy, disseminate, distribute, or use this
> message or any part thereof. If you receive this message in error, please
> notify the sender immediately and delete all copies of this message.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20171003/8c16bdf1/attachment-0001.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 43, Issue 2
**************************************
