Daniel Pocock wrote:
> Could you please clarify that - it is possible to build a client library
> from the server source tarball?
Yes. RedHat already packages libfreeradius-radius as a separate RPM,
IIRC.
> In Debian, I see "libfreeradius2" built from the server source tarball
> but that appea
On 20/07/13 14:56, Alan DeKok wrote:
> Daniel Pocock wrote:
>> Should this code be shared with the client project freeradius-client?
> No. The freeradius-client code is pretty bad.
>
>> Or is it preferred to build a new client (or shared library) from the
>> freeradius-server repository eventual
Daniel Pocock wrote:
> Should this code be shared with the client project freeradius-client?
No. The freeradius-client code is pretty bad.
> Or is it preferred to build a new client (or shared library) from the
> freeradius-server repository eventually?
The client code is already LGPL'd. S
On 15/07/13 21:53, Alan DeKok wrote:
> Daniel Pocock wrote:
>> Can anybody comment on which client code should be used for long
>> extended attributes?
>>
>> I see that the freeradius-client project predates RFC 6929.
>
> By a LONG ways.
>
> There's no client code for the extended attribute
Daniel Pocock wrote:
> Can anybody comment on which client code should be used for long
> extended attributes?
>
> I see that the freeradius-client project predates RFC 6929.
By a LONG ways.
There's no client code for the extended attributes. The RFC was just
published. So far as I know, F
Can anybody comment on which client code should be used for long
extended attributes?
I see that the freeradius-client project predates RFC 6929.
Is there any module in the server project that provides a good example
of using these long values from requests?
-
List info/subscribe/unsubscribe
6 matches
Mail list logo
