ServerSide Attributes

[Alexey Dotsenko]

In clause 3) I indicated the only reason (forced, and not standard) to 
use a local attribute in the replay context — if there are a lot of 
them. And probably in vain did it...
It’s easier to place the attribute in the right context. This will avoid 
problems in future versions of the server.
Usually, reports about the misuse of a feature suggest that the behavior 
of the program in this aspect is not guaranteed and may change in the 
future.


On 28.05.2019 14:25, Nicolas Breuer wrote:
> Hi,
> 
> Indeed i have this message : This attribute MUST go on the first line 
> with
>  So the best is to attribute an index of 3000 and ignore the message
> at Startup. The attribute is only needed for assigning the user in the
> correct group.
> Indeed the attribute is not intended to be sent to the NAS.
> 
> I found an other way put an index of 999 but after reading your mail,
> I think I will ignore the startup error and set a number of "3000"
> As it's intended 😊
> 
> 
> 
> -----Message d'origine-----
> De : Freeradius-Users
> <freeradius-users-bounces+nicolas.breuer=belcenter.biz at lists.freeradius.org>
> De la part de Alexey Dotsenko
> Envoyé : mardi 28 mai 2019 13:11
> À : freeradius-users at lists.freeradius.org
> Objet : Re: ServerSide Attributes
> 
> Hello,
> 
> I suppose you see a message like the following:
> Warning: [/etc/raddb/users]:1 Check item "My-Attr" found in reply item
> list for user "DEFAULT". This attribute MUST go on the first line with
> the other check items
> 
> This means (according to the comment in the dictionary file):
> 1) local attribute is supposed to be used as check (control) attribute.
> These attributes are specified in the first line of the user-item in 
> the
> users file:
> DEFAULT Hint == "SLIP"
>          Framed-Protocol = SLIP
> 
> In this example, Hints - is a check item (attribute), and
> Framed-Protocol - is a reply item (attribute). If you see a warning at
> startup, it means that you used the local attribute in the replay
> context (where the Framed-Protocol in example), whereas its use is
> assumed in the check context (where the Hint in example).
> 
> 2) In your case, this only works until a certain point: local 
> attributes
> in the replay context will be processed by the server like any other,
> but will not be transferred to the client. A warning on the startup 
> says
> about this - "why use local attributes in a replay context if you are
> not going to send them to the client? Use check context for this - it 
> is
> for this purpose intended."
> 
> 3) In general, this is not a error. If you have a very large array of
> local attributes, it is very inconvenient to use them in the context of
> a check - a very long string is obtained. In this case it is easier to
> use them in the context of a replay - it allows multi-line definition.
> But it is better to use other modules, such as ldap or sql - they do 
> not
> have a similar problem.
> 
> On 28.05.2019 11:11, Nicolas Breuer wrote:
>> Hello,
>> 
>> https://networkradius.com/doc/3.0.10/concepts/dictionary/creating_server_attributes.html
>> 
>> Following the documentation, we can create server-side attributes with
>> number range 3000-4000.
>> If I create a new attribute , I have a warning on the startup that I
>> can't use that on a reply attribute in the user file but it's working.
>> 
>> Can you advise what we can do ?
>> 
>> Thanks
>> 
>> 
>> 
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html
> 
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html