Re: 093 Crashes with unknown tokens
Greg G wrote: How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. We use some custom items now and then. If despite what you said you're still using FreeRADIUS, you could use the script check-radiusd-config each time you update your config files and then avoid stopping an already running server. I think the script check-radiusd-config is installed in the same time with radiusd, or you can find it in the source tarball in the directory freeradius-0.9.3/scripts -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Matt Sapp wrote: Greg, While you may have misunderstood Alan's terseness as him being nasty to you, please look at the situation. You're saying that if there was a configuration file error, then by all means, stop the server, but if it's just a users file error, then it shouldn't be halted and the server should keep going on with some half-correct information. Well, I'm perfectly happy if the user that contains the wonky data (most often, it's not really a typo, but a new token we're experimenting with) gets ignored. I'm content with having *one* customer call me because they can't get authenticated than have the whole system come down because there's something different in a single user. Personally, I don't see how the users file being in proper shape is any less critical than any other configuration file being correct. You'd be much better off implementing some solution to make sure the users file is correct (perhaps some type checking in whatever system you use to manage your users -- surely you don't have a bunch of type-prone data entry people editing the users file by hand, do you?). The users file has a very specific format, and it's not hard to follow. If you have proper checks in your management system, this is a moot point, and this has been pointed out in reference to the dialup_admin package. Interestingly, the old Livingston radius format didn't need the commas at the end of the lines. I was really surprised when none of the other radius servers I looked (Free, Open, Gnu) could read that file. I can live with having to generate the file differently to work in the updated format. (Was that an RFC change, or was Livingston just broken?) As another example, GnuRadius doesn't like an ampersand in a username, but FreeRadius does. Should my system come down becuase I've got what seems to be *valid* data, but the radius server doesn't understand it? [RFC 2138 has provisions for non-alphanumerics in the User-Name field.] -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
093 Crashes with unknown tokens
Here's what I get from FR 0.93 /usr/local/etc/raddb/users[9]: Parse error (reply) for entry 007gold: Unknown attribute My-Key Errors reading /usr/local/etc/raddb/users radiusd.conf[921]: files: Module instantiation failed. And then back to a prompt. That's bad since I won't always be able to watch the radiusd start up. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: Here's what I get from FR 0.93 /usr/local/etc/raddb/users[9]: Parse error (reply) for entry 007gold: Unknown attribute My-Key Errors reading /usr/local/etc/raddb/users radiusd.conf[921]: files: Module instantiation failed. And then back to a prompt. That's bad since I won't always be able to watch the radiusd start up. So... it doesn't crash. It gives an error, which tells you what went wrong, and why. What, exactly is unclear about the error message? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: Here's what I get from FR 0.93 /usr/local/etc/raddb/users[9]: Parse error (reply) for entry 007gold: Unknown attribute My-Key Errors reading /usr/local/etc/raddb/users radiusd.conf[921]: files: Module instantiation failed. And then back to a prompt. That's bad since I won't always be able to watch the radiusd start up. So... it doesn't crash. It gives an error, which tells you what went wrong, and why. What, exactly is unclear about the error message? Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. Otherwise, it becomes a fairly trivial task to crash out the daemon. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. -Greg G
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. To doing what? Are you really asking that the server send RADIUS responses with the WRONG information in them? Otherwise, it becomes a fairly trivial task to crash out the daemon. It's not a crash. Stop calling it that. It's an error. And if you have write access to the configuration files for the server, it's ALWAYS a trivial task to stop the server. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. Then double check the files before you let the server use them. It's not the servers fault you made a mistake. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
At 12:42 PM 11/21/2003, Greg G wrote: Alan DeKok wrote: Greg G mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: Here's what I get from FR 0.93 /usr/local/etc/raddb/users[9]: Parse error (reply) for entry 007gold: Unknown attribute My-Key Errors reading /usr/local/etc/raddb/users radiusd.conf[921]: files: Module instantiation failed. And then back to a prompt. That's bad since I won't always be able to watch the radiusd start up. So... it doesn't crash. It gives an error, which tells you what went wrong, and why. What, exactly is unclear about the error message? Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. Otherwise, it becomes a fairly trivial task to crash out the daemon. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. Sorry, I prefer my failures to be deterministic. I don't want the server carrying on and running with a partial config and doing something un- expected. Garbage in/Garbage out. If you are concerned with making typos, you may want to look at the 'dialup-admin' package, which allows you to easily manage an SQL database rather than a flat users file. Your chances of making a typo would then be greatly reduced imho, and if you did typo on one entry for a user, it would not affect any other users. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. To doing what? Are you really asking that the server send RADIUS responses with the WRONG information in them? Well, if I have one bad entry in a users file with 10,000 users in it, I'd rather it just ignore that user with the bad entry. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. Then double check the files before you let the server use them. It's not the servers fault you made a mistake. How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. We use some custom items now and then. -Greg G
Re: 093 Crashes with unknown tokens
Chris Parker wrote: Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. Otherwise, it becomes a fairly trivial task to crash out the daemon. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. Sorry, I prefer my failures to be deterministic. I don't want the server carrying on and running with a partial config and doing something un- expected. For config issues, I agree, but if there's an unknown key in the *users* file, I don't think the system should stop. Especially if it's a key that's only in one or two users (which is usually the case here). If you are concerned with making typos, you may want to look at the 'dialup-admin' package, which allows you to easily manage an SQL database rather than a flat users file. Your chances of making a typo would then be greatly reduced imho, and if you did typo on one entry for a user, it would not affect any other users. I will look into it, but I also don't want the authentication server to stop if we take the database down for maintenance. We're a bit tied to the file method at the moment, although I suspect that feeding directly from our database will be better and might be in the plan. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. We use some custom items now and then. Then those items should go into a custom dictionary. -- --Mike --- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: Well, if I have one bad entry in a users file with 10,000 users in it, I'd rather it just ignore that user with the bad entry. Then use SQL. Then double check the files before you let the server use them. It's not the servers fault you made a mistake. How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. If it's not really a mistake, why are you complaining? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: Well, if I have one bad entry in a users file with 10,000 users in it, I'd rather it just ignore that user with the bad entry. Then use SQL. I may have to, but I can't do that short-term. I really need a radius server that I can force to re-read the users file on-demand. FreeRadius seems to be able to do that, but isn't quite as stable as I'd like. I've found that the SIGHUP will bring down the server if it's still in the start-up phase. It probably should ignore the HUP signal until it's ready. How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. If it's not really a mistake, why are you complaining? Because FR is exiting when it runs into a key that it doesn't know, thereby bringing down the whole authentication system. I regard that as worthy of complaining about. -Greg G
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: I may have to, but I can't do that short-term. I really need a radius server that I can force to re-read the users file on-demand. FreeRadius seems to be able to do that, but isn't quite as stable as I'd like. I've found that the SIGHUP will bring down the server if it's still in the start-up phase. It probably should ignore the HUP signal until it's ready. Yup. Because FR is exiting when it runs into a key that it doesn't know, thereby bringing down the whole authentication system. I regard that as worthy of complaining about. Then fix it. You have the source. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Well exuse the hell out of me for not having worked with open source stuff before. You've got a great bedside manner, ya know. -Greg G Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: I may have to, but I can't do that short-term. I really need a radius server that I can force to re-read the users file on-demand. FreeRadius seems to be able to do that, but isn't quite as stable as I'd like. I've found that the SIGHUP will bring down the server if it's still in the start-up phase. It probably should ignore the HUP signal until it's ready. Yup. Because FR is exiting when it runs into a key that it doesn't know, thereby bringing down the whole authentication system. I regard that as worthy of complaining about. Then fix it. You have the source. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: Well exuse the hell out of me for not having worked with open source stuff before. You've got a great bedside manner, ya know. Ah, yes. The you've got to do what I want NOW for FREE! response. Perhaps you didn't understand my explanations as to why I disagreed with your position. Perhaps you didn't care. Either way, it's not my problem. Grow up. Go read the README again. It's directed at you. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: Well exuse the hell out of me for not having worked with open source stuff before. You've got a great bedside manner, ya know. Ah, yes. The "you've got to do what I want NOW for FREE!" response. No, it's the "Hey, asshole, maybe you know the code better than I do" reponse. Perhaps you didn't understand my explanations as to why I disagreed with your position. Perhaps you didn't care. Either way, it's not my problem. You didn't give me any explanation other than "because I said so" and "go sift through my code, loser". -Greg G
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: Ah, yes. The you've got to do what I want NOW for FREE! response. No, it's the Hey, asshole, maybe you know the code better than I do reponse. I *do* know the code better than you, and I disagree with your position. All else aside, that should tell you something. You didn't give me any explanation other than because I said so and go sift through my code, loser. Then you didn't read my messages. The insults are instructive. The main README file is ever so applicable to this situation. Go read it, and stop wasting your time posting baseless complaints on the list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: Ah, yes. The "you've got to do what I want NOW for FREE!" response. No, it's the "Hey, asshole, maybe you know the code better than I do" reponse. I *do* know the code better than you, and I disagree with your position. All else aside, that should tell you something. It does, but not what you'd hoped. It looks like I'm going to wind up using GNU Radius, because it *doesn't* exit when it encounters something it doesn't understand in the user file. It discards the entry for the invalid user. It doesn't seg fault if I make an acct request. And I don't have to fight with someone whose idea of gathering up new coders is "Fix it" without any help or guidance whatsoever. The main README file is ever so applicable to this situation. Go read it, and stop wasting your time posting baseless complaints on the list. So my asking for a feature is a baseless complaint? Rght. -Greg G
Re: 093 Crashes with unknown tokens
Greg G [EMAIL PROTECTED] wrote: It does, but not what you'd hoped. It looks like I'm going to wind up using GNU Radius, because it *doesn't* exit when it encounters something it doesn't understand in the user file. It discards the entry for the invalid user. Meaning that the server doesn't behave as intended, and it's probably difficult for the administrator to figure that out. So you're left with a server which isn't doing what you want... It doesn't seg fault if I make an acct request. shrug You're probably running Solaris. That will get fixed in a future release. And I don't have to fight with someone whose idea of gathering up new coders is Fix it without any help or guidance whatsoever. No... I told you what my opinion was, and why. You didn't understand me, or didn't care enough to listen to me. Your response was a blind repetition of YOU fix it! My response was then simply an echoing of your complaint: No, YOU fix it. I find it instructive that your own words directed at you cause huge amounts of anger and hostility. So my asking for a feature is a baseless complaint? Rght. Not listening to the response makes it baseless. But why am I wasting my time? You've already made it clear that you can't read the documentation, the README, or my replies on this list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Greg G wrote: Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. Otherwise, it becomes a fairly trivial task to crash out the daemon. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. cp users users.old vi users check-radiusd-config if $?; then cp users.old users mail -t ggersh -s Typo in users file startup.log else service radiusd restart fi Or something like that. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G [EMAIL PROTECTED] wrote: It does, but not what you'd hoped. It looks like I'm going to wind up using GNU Radius, because it *doesn't* exit when it encounters something it doesn't understand in the user file. It discards the entry for the invalid user. Meaning that the server doesn't behave as intended, and it's probably difficult for the administrator to figure that out. So you're left with a server which isn't doing what you want... No, it's doing just what I want. It's logging the problem with the user entry and getting on with processing. There's no reason that an single authentication item in the users file should halt the server. If it's a problem in the configuration file or something critical like that, absolutely there should be no further action. I understand that you have a different opinion, but that doesn't negate mine, or the fact that this is how I'd like it to work. Pointing me at the readme file isn't much help either, since that boils down to "fix it, or don't. Whatever." -Greg G
Re: 093 Crashes with unknown tokens
Greg, While you may have misunderstood Alan's terseness as him being nasty to you, please look at the situation. You're saying that if there was a configuration file error, then by all means, stop the server, but if it's just a users file error, then it shouldn't be halted and the server should keep going on with some half-correct information. Personally, I don't see how the users file being in proper shape is any less critical than any other configuration file being correct. You'd be much better off implementing some solution to make sure the users file is correct (perhaps some type checking in whatever system you use to manage your users -- surely you don't have a bunch of type-prone data entry people editing the users file by hand, do you?). The users file has a very specific format, and it's not hard to follow. If you have proper checks in your management system, this is a moot point, and this has been pointed out in reference to the dialup_admin package. However, as has been stated, if you really think it should keep going and skip any users entries that are broken, you do have the source, and you can do whatever you wish with it. This doesn't mean Alan is going to accept it back into the main FR tree, but if you're dead-set on expecting the server to handle your typos rather than dealing with them where they should be corrected elsewhere, it's probably a 5 line change to do so. -Matt MNU Network Administrator --- Original Message Below --- From: Greg G [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 093 Crashes with unknown tokens Date: Fri, 21 Nov 2003 16:51:54 -0500 No, it's doing just what I want. It's logging the problem with the user entry and getting on with processing. There's no reason that an single authentication item in the users file should halt the server. If it's a problem in the configuration file or something critical like that, absolutely there should be no further action. I understand that you have a different opinion, but that doesn't negate mine, or the fact that this is how I'd like it to work. Pointing me at the readme file isn't much help either, since that boils down to fix it, or don't. Whatever. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
On Fri, 21 Nov 2003, Matt Sapp wrote: Personally, I don't see how the users file being in proper shape is any less critical than any other configuration file being correct. You'd be much better off implementing some solution to make sure the users file is correct (perhaps some type checking in whatever system you use to manage your users -- surely you don't have a bunch of type-prone data entry people editing the users file by hand, do you?). For what it's worth, it may be better to make this a matter of procedure. For my part, whenever I make any change to Radius configuration files, I follow the following steps: 1) Edit the file and make changes. 2) Run radiusd -X. This will show any fatal errors in the config without you having to stop your good radius. It will quit with a message about radius already running, but up until then, will show you whether or not radius *will* start with the new config. 3) Restart radiusd with the new config if radiusd -X worked out okay. It's probably possible to write a script (and eventually I probably will but am too lazy now) to run this sort of check and only restart radiusd if things are okay, but I think just making sure that people check is a quicker fix than code hacking. Not a better fix, but a quicker fix. :-) I do agree that I don't really want Radius running with a semi-woogly config, although it can be a pain the times where I forget to check it with -X, since those are always the times I've made a mistake. Heh. Kristina - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
