Parse error for entry DEFAULT entry in users file when Auth-Type := SQL
I was trying to upgrade from version 1.1.0 to 1.1.3 but when starting FreeRadius I received the following error: "Error: /usr/local/etc/raddb/users[216]: Parse error (check) for entry DEFAULT: Unknown value SQL for attribute Auth-Type" I use FR with MySQL and the ./raddb/users file contains the default attributes. E.g. DEFAULT Simultaneous-Use := 1, Auth-Type := sql Idle-Timeout = 3600, Acct-Interim-Interval = 180 This worked fine until FR 1.1.1 and stopped working with 1.1.2. I found that one change in the ./src/lib/valuepair.c file caused this problem: At the end of the pairread function: (1265-1271) /* * If we didn't make a pair, return an error. */ if (!vp) { *eol = T_INVALID; return NULL; } It seems that the pairmake function does not return a valid pair when the pair is 'Auth-Type := SQL'. I am not sure if I use the users file in connection with my MySQL setup correctly, or if my users file entry is simply not correct? Is 'Auth-Type := SQL' in the users file still allowed? It doesn't work anymore since 1.1.2. In a posting from Oct 2001 I saw the following:
If you want to do SQL authentication, you should use 'Auth-Type := SQL' in the 'users' file.
If you want to authenticate agains /etc/passwd, THEN you use 'Auth-Type := System'.
Alan DeKok.
Gunther wrote:
I was trying to upgrade from version 1.1.0 to 1.1.3 but when starting FreeRadius I received the following error: "Error: /usr/local/etc/raddb/users[216]: Parse error (check) for entry DEFAULT: Unknown value SQL for attribute Auth-Type"
That's because the SQL module doesn't do authentication.
I use FR with MySQL and the ./raddb/users file contains the default attributes. E.g. DEFAULT Simultaneous-Use := 1, Auth-Type := sql
Why are you forcing Auth-Type to SQL?
Idle-Timeout = 3600, Acct-Interim-Interval = 180
This worked fine until FR 1.1.1 and stopped working with 1.1.2.
No, it did NOT work in 1.1.1. It was IGNORED in 1.1.1, due to a bug in the server.
I found that one change in the ./src/lib/valuepair.c file caused this problem: ... It seems that the pairmake function does not return a valid pair when the pair is 'Auth-Type := SQL'.
Yes, because the SQL module doesn't do authentication.
if my users file entry is simply not correct?
It's not correct.
In a posting from Oct 2001 I saw the following:
If you want to do SQL authentication, you should use 'Auth-Type := SQL' in the 'users' file.
If that was a post from me, it's a typo. It's wrong. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote
I was trying to upgrade from version 1.1.0 to 1.1.3 but when starting FreeRadius I received the following error: "Error: /usr/local/etc/raddb/users[216]: Parse error (check) for entry DEFAULT: Unknown value SQL for attribute Auth-Type"
That's because the SQL module doesn't do authentication.
I use FR with MySQL and the ./raddb/users file contains the default attributes. E.g. DEFAULT Simultaneous-Use := 1, Auth-Type := sql
Why are you forcing Auth-Type to SQL?
Idle-Timeout = 3600, Acct-Interim-Interval = 180
This worked fine until FR 1.1.1 and stopped working with 1.1.2.
No, it did NOT work in 1.1.1. It was IGNORED in 1.1.1, due to a bug in the server.
Yes, that is what I thought. I changed my users file to: DEFAULT Simultaneous-Use := 1 Idle-Timeout = 3600, Acct-Interim-Interval = 180 and things are working fine.
In a posting from Oct 2001 I saw the following:
If you want to do SQL authentication, you should use 'Auth-Type := SQL' in the 'users' file.
If that was a post from me, it's a typo. It's wrong.
Alan DeKok. --
What I found in the 'ancient' times: http://lists.freeradius.org/mailman/htdig/freeradius-users/2001-October/0025 18.html My initial reason for the upgrade from 1.1.0 was a problem with my backup RADIUS server. The idle RADIUS daemon simply died for unknown reasons. It looked to me that RADIUS did a reload of the configuration files and got killed. This happend in in normal and debug mode. With 1.1.3 I did not yet experience that problem. Thanks for your response Alan! Gunther
participants (2)
-
Alan DeKok -
Gunther