Reject from SQL when user is in users file
Anyway, this is the first of three *actual* questions. I have just set up freeradius 2.1.1. I have an entry in the users file, and when I use radtest, I get the expected correct answers back from the radius server. Then I added "sql" to the default authorize, accounting and post-auth sections in site-enabled/default. The database exists, but not the tables. The server makes connections to the database just fine, but obviously all queries fail :-) Now I get Accept-Reject for the same user. The users file is the same. No changes have been made to the configuration except adding the SQL stuff. If *just* the "sql" lines in the authorize section and the post-auth section are commented out, it goes back to working. My question is: Is this to be expected? Does a failure in SQL somehow override the entry in the users file? Or is this an indication that I've screwed something else up? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: DD23 0DF3 2260 3060 7FEC 5CA8 1AF6 D9E3 CFEE 6B28
My question is: Is this to be expected? Does a failure in SQL somehow override the entry in the users file?
Most likely. Run in debug mode and you will see something like "SQL query error; rejecting user" and sql module will fail. If your sql is not working - don't list it. Ivan Kalik Kalik Informatika ISP
On Mon, 2008-09-29 at 17:17 +0100, tnt@kalik.net wrote:
My question is: Is this to be expected? Does a failure in SQL somehow override the entry in the users file?
Most likely.
Do you know or are you guessing? I do want to get SQL working, but on the principle that I should change a little at a time, I don't really want to start trying to do that if there is something fundamental I've missed. There is another reason that I want to know. I was planning to leave a couple of critical users in the users file as a sort of backup, so they could still log in even if the SQL server dies or is unreachable or whatever. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: DD23 0DF3 2260 3060 7FEC 5CA8 1AF6 D9E3 CFEE 6B28
If you would bother to post the debug (radiusd -X) as suggested in RADME, FAQ, configuration files and almost daily on this list, there would be no need for guessing. Ivan Kalik Kalik Informatika ISP Dana 29/9/2008, "Karl Auer" <kauer@biplane.com.au> piše:
On Mon, 2008-09-29 at 17:17 +0100, tnt@kalik.net wrote:
My question is: Is this to be expected? Does a failure in SQL somehow override the entry in the users file?
Most likely.
Do you know or are you guessing?
I do want to get SQL working, but on the principle that I should change a little at a time, I don't really want to start trying to do that if there is something fundamental I've missed.
There is another reason that I want to know. I was planning to leave a couple of critical users in the users file as a sort of backup, so they could still log in even if the SQL server dies or is unreachable or whatever.
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
GPG fingerprint: DD23 0DF3 2260 3060 7FEC 5CA8 1AF6 D9E3 CFEE 6B28
On Mon, 2008-09-29 at 17:48 +0100, tnt@kalik.net wrote:
If you would bother to post the debug (radiusd -X) as suggested in RADME, FAQ, configuration files and almost daily on this list, there would be no need for guessing.
I won't waste any more of your time. The actual authentication worked fine, but when the server was unable to log it to the database, it failed the whole transaction. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: DD23 0DF3 2260 3060 7FEC 5CA8 1AF6 D9E3 CFEE 6B28
participants (2)
-
Karl Auer -
tnt＠kalik.net