I'm running FR 2.0.3 and I just found that if there is more than one client with the same IP address in clients.conf, then it will stop processing the remainder of the file and continue startup. The only indication it has done this are 2 error messages that are easily missed when running with debug on. I checked git.freeradius.org and noticed that the client.c committed on 09-March now ignores duplicates if they are exactly the same. In my case, everything was the same except the name. My question is, wouldn't it be better to continue processing the remainder of the file even when there are duplicates that aren't identical or alternatively to preclude the server from starting (I'd vote for the former). Ignoring what could be hundreds of clients that follow the error doesn't seem useful. I propose ignoring all duplicates and having client_add return ok (1). This would log the error for any duplicates (even duplicates that aren't completely identical), but allow processing to continue for the remainder of the file.
Garber, Neal wrote:
I’m running FR 2.0.3 and I just found that if there is more than one client with the same IP address in clients.conf, then it will stop processing the remainder of the file and continue startup.
This is addressed in 2.1.4. It now ignores clients that are *exact* duplicates.
The only indication it has done this are 2 error messages that are easily missed when running with debug on. I checked git.freeradius.org and noticed that the client.c committed on 09-March now ignores duplicates if they are exactly the same. In my case, everything was the same except the name. My question is, wouldn’t it be better to continue processing the remainder of the file even when there are duplicates that aren’t identical or alternatively to preclude the server from starting (I’d vote for the former). Ignoring what could be hundreds of clients that follow the error doesn’t seem useful.
If your server is misconfigured, it's better to know and fix it, than have it silently "work" for some definition of "work".
I propose ignoring all duplicates and having client_add return ok (1). This would log the error for any duplicates (even duplicates that aren’t completely identical), but allow processing to continue for the remainder of the file.
No. Clients that are exact duplicates can be safely ignored. Clients that are "similar" but not the same are conflicts. You may have policies, logging, etc. that depend on the fields that are different. Which one is chosen? One at random? Do you really want the server to work *accidentally*? And one day, when something else changes, the server suddenly picks the *other* client definition, and all of your policies, logs, etc. are different? That's scary. If you want this behavior, fork the git tree, and maintain a separate patch yourself. Git makes this trivial. But putting it into the main tree means that there will be angry email from people when their systems break. And they'll be right to complain. Alan DeKok.
If your server is misconfigured, it's better to know and fix it, than have it silently "work" for some definition of "work".
I agree with you Alan that the server shouldn't just silently "work" with configuration errors. In the past, I've seen configuration errors preclude the server from starting. Is that still the case? If so, then given the seriousness of the error, as described in your response below, perhaps the server should fail to start in this case as well. That would make it more obvious there is a configuration error and allow immediate correction. The current approach causes the server to start in a semi-functional state (because requests from clients before the error are processed and requests from clients after the error are ignored).
No. Clients that are exact duplicates can be safely ignored. Clients that are "similar" but not the same are conflicts. You may have policies, logging, etc. that depend on the fields that are different. Which one is chosen? One at random?
Do you really want the server to work *accidentally*? And one day, when something else changes, the server suddenly picks the *other* client definition, and all of your policies, logs, etc. are different?
I agree with you that conflicts are bad. I wasn't trying to suggest otherwise. However, the current approach (even in 2.1.4) displays 2 error messages buried in the middle of hundreds of other startup messages. They can easily be missed if you don't examine all of the startup messages carefully. Even if you see the messages, it isn't clear that the result of the error is to ignore the remainder of the clients.conf file. I didn't notice there was a problem until hours after a change/restart when some clients reported they weren't able to connect. When I heard of the problem, I noticed messages saying requests were being ignored from unknown clients.
Garber, Neal wrote:
I agree with you Alan that the server shouldn't just silently "work" with configuration errors. In the past, I've seen configuration errors preclude the server from starting. Is that still the case?
Yes.
If so, then given the seriousness of the error, as described in your response below, perhaps the server should fail to start in this case as well.
Huh? It does.
No. Clients that are exact duplicates can be safely ignored. Clients that are "similar" but not the same are conflicts. You may have policies, logging, etc. that depend on the fields that are different. Which one is chosen? One at random?
Do you really want the server to work *accidentally*? And one day, when something else changes, the server suddenly picks the *other* client definition, and all of your policies, logs, etc. are different?
I agree with you that conflicts are bad. I wasn't trying to suggest otherwise. However, the current approach (even in 2.1.4) displays 2 error messages buried in the middle of hundreds of other startup messages.
Please show an example. Duplicates are WARNINGs. Errors cause the server to not start. Alan DeKok.
Hi,
I'm running FR 2.0.3 and I just found that if there is more than one client with the same IP address in clients.conf, then it will stop processing the remainder of the file and continue startup. The only indication it has done this are 2 error messages that are easily missed when running with debug on. I checked git.freeradius.org and noticed that the client.c committed on 09-March now ignores duplicates if they are exactly the same. In my case, everything was the same except the name. My question is, wouldn't it be better to continue processing the remainder of the file even when there are duplicates that aren't identical or alternatively to preclude the server from starting (I'd vote for the former). Ignoring what could be hundreds of clients that follow the error doesn't seem useful.
ouch - random working process that is happy if the wind blows in the right direction. no, the code is simply allowing only exact duplicates to be ignored as errors...which is quirky but stop s afew issues. anyway, another reason to use SQL as the client storage engine - you can put column restraints in which make each field enforced as unique -IP address, name, shortname etc. thus you'll never get the chance of having a duplicate in the first place.... apart from when you first start trying SQL clients and still have real entries in clients.conf ;-) alan
ouch - random working process that is happy if the wind blows in the right direction. no, the code is simply allowing only exact duplicates to be ignored as errors...which is quirky but stop s afew issues. anyway, another reason to use SQL as the client storage engine - you can put column restraints in which make each field enforced as unique -IP address, name, shortname etc. thus you'll never get the chance of having a duplicate in the first place.... apart from when you first start trying SQL clients and still have real entries in clients.conf ;-)
Thanks for taking the time to share your thoughts Alan. I recently started investigating SQL for client and huntgroup definitions and I appreciate your insight. Does using the SQL approach still require a server restart to refresh any changes? Do you know if there are any plans to refresh the clients via radmin? (I realize this isn't a trivial matter..) I'm not sure I follow why what I suggested would cause the server to act in a non-deterministic fashion. Wouldn't it always use the first definition of a client with a specific IP address and ignore any subsequent definitions that cause a conflict (because the conflicting entries wouldn't be loaded in the client tree)? Regardless, I wasn't trying to suggest that the error should be ignored by the admin and that the conflict is not an issue. Rather, if this isn't treated as a fatal error that prevents the server from starting (which is how it is currently treated), then I don't see the value in breaking lots of other clients that have no conflicts. Am I missing something here? I don't think getting the admin's attention via trouble calls and client outages is the best way to inform them there's a problem. My suggestion was to leave the clients with conflicts potentially broken while not breaking the rest of the clients. What are your thoughts about treating the conflict as a more severe error and not allowing the server to start? Does this seem better than the current approach for people that aren't using SQL? It just seems like there must be a better means of notifying the admin of the configuration issue than breaking the valid clients found after the conflicting entry. It's very easy to miss the current error message among all of the other startup messages. If the server failed to start and this error was prominently displayed, I think the configuration problem would be noticed more quickly. Perhaps another option would be to display a warning that configuration errors were detected after the "Ready to process requests" message. This would alert the admin that they should scroll back and look for errors.
Hi,
Thanks for taking the time to share your thoughts Alan. I recently started investigating SQL for client and huntgroup definitions and I appreciate your insight. Does using the SQL approach still require a server restart to refresh any changes? Do you know if there are any plans to refresh the clients via radmin? (I realize this isn't a trivial matter..)
use dynamic-clients - this calls an SQL query which, if the target is now in your DB will update the client list on the fly. no server restarts needed. radmin lists and shows the client etc
What are your thoughts about treating the conflict as a more severe error and not allowing the server to start? Does this seem better than the current approach for people that aren't using SQL? It just seems like there must be a better means of notifying the admin of the configuration issue than breaking the valid clients found after the conflicting entry. It's very easy to miss the current error message among all of the other startup messages. If the server failed to start and this error was prominently displayed, I think the configuration problem would be noticed more quickly.
I seem to recall the error message being one of the last things printed out before the server barfed alan
use dynamic-clients - this calls an SQL query which, if the target is now in your DB will update the client list on the fly. no server restarts needed. radmin lists and shows the client etc
Sounds nice - I'll check it out. Thanks for the tip Alan..
I seem to recall the error message being one of the last things printed out before the server barfed
Well, assuming by "barf" you mean not start, in 2.0.3 and 2.0.5, the server doesn't barf and the error message only appears when debug is on (-Xx). Within the debug, it's closer to the beginning of my output (line 188 of 542 messages). Here's a very abbreviated example: Info: ... . Debug: including... . Debug: main... . Debug: log... . Debug: security... . Debug: client... . Error: Failed to add duplicate client... Error: /usr/local/etc/raddb/clients.conf[115]: Failed to add client... Debug: proxy... . Debug: realm... . Debug: Module: ... . (lots of msgs here) . Debug: listen... Debug: Listening on authentication address * port 1645 Debug: Listening on accounting address * port 1646 Debug: Listening on authentication address * port 1812 Debug: Listening on accounting address * port 1813 Debug: Listening on proxy address * port 1647 Debug: Ready to process requests. It is also logged to radius.log, but I doubt many people check that file every time the server is started to see if there was a configuration error. What I'm suggesting is to handle it the same as errors in certain places of radiusd.conf. For instance, an error in the listen section causes: Debug: radiusd: #### Opening IP addresses and Ports #### Debug: listen { Debug: type = "authxxxxxx" Error: /usr/local/etc/raddb/radiusd.conf[27]: Invalid type "authxxxxxx" in listen section. After which the server exits. If the server exited after the clients.conf error, then it would be consistent and would force the admin to fix it (which I think we agree is the right thing to do - that is, get the admin to fix the conflict..) For now, I will change the clients.conf file so the client I use to monitor the server is at the bottom. This way, if this ever happens again, my monitoring script will detect the failure.
Garber, Neal wrote:
Well, assuming by "barf" you mean not start, in 2.0.3 and 2.0.5, the server doesn't barf and the error message only appears when debug is on (-Xx). Within the debug, it's closer to the beginning of my output (line 188 of 542 messages). Here's a very abbreviated example:
I think that was fixed in later versions of the server. The code now looks fine, and it works in my tests. Alan DeKok.
Well, assuming by "barf" you mean not start, in 2.0.3 and 2.0.5, the server doesn't barf and the error message only appears when debug is on (-Xx). Within the debug, it's closer to the beginning of my output (line 188 of 542 messages). Here's a very abbreviated example:
I think that was fixed in later versions of the server. The code now looks fine, and it works in my tests.
Awesome! Thanks for taking the time to test it Alan.. I'll schedule upgrades of my servers to 2.1.4.
IBM x3550 server install Debian lenny. Download freeradius from ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-2.1.4.tar.gz, compile and install. Question: 1. freeradius -v showing freeradius 2.1.5, was this correct? 2. trying to using mysql as database, ucomment sql in site-available/default, running debug mode got such error /etc/freeradius/sites-enabled/default[152]: Failed to find module "sql". /etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section. 3. On the same server download, compile & install freeradius 2.1.3 with mysql, no problem. What could be the problem on the version 2.1.4/2.1.5? Thank you
Similar problem here... $INCLUDE sql.conf was commented in modules section Removing # was the solution. By default, this was ok in older versions . On Mon, Apr 13, 2009 at 7:42 AM, piston <pistonic@yahoo.com> wrote:
IBM x3550 server install Debian lenny.
Download freeradius from ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-2.1.4.tar.gz, compile and install.
Question:
1. freeradius -v showing freeradius 2.1.5, was this correct?
2. trying to using mysql as database, ucomment sql in site-available/default, running debug mode got such error /etc/freeradius/sites-enabled/default[152]: Failed to find module "sql". /etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section.
3. On the same server download, compile & install freeradius 2.1.3 with mysql, no problem. What could be the problem on the version 2.1.4/2.1.5?
Thank you
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks. Got is resolve. By the way this version of freeradius is 2.1.4 or 2.1.5? A bit confuse here. ________________________________ From: Marinko Tarlac <mangia81@gmail.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Monday, April 13, 2009 3:20:08 PM Subject: Re: Debian lenny with freeradius 2.1.4/2.1.5 sql module fail. Similar problem here... $INCLUDE sql.conf was commented in modules section Removing # was the solution. By default, this was ok in older versions . On Mon, Apr 13, 2009 at 7:42 AM, piston <pistonic@yahoo.com> wrote: IBM x3550 server install Debian lenny. Download freeradius from ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-2.1.4.tar.gz, compile and install. Question: 1. freeradius -v showing freeradius 2.1.5, was this correct? 2. trying to using mysql as database, ucomment sql in site-available/default, running debug mode got such error /etc/freeradius/sites-enabled/default[152]: Failed to find module "sql". /etc/freeradius/sites-enabled/default[62]: Errors parsing authorize section. 3. On the same server download, compile & install freeradius 2.1.3 with mysql, no problem. What could be the problem on the version 2.1.4/2.1.5? Thank you - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Garber, Neal -
Marinko Tarlac -
piston