Marcin Jessa <[EMAIL PROTECTED]> wrote: > > You can send a HUP signal to th eserver. > That would require apache to have access to the radius deamon when > using a web-based interface.
Uh, no. > Even worse, it'd be pretty much impossible to write an secure GUI > application to remotely access freeradius and make it reread the > data stored in SQL since activating the changes made in the nas > table will require sending HUP signal to the server. You're having a web page update RADIUS clients in SQL, and you're worried about a "secure" GUI? That makes no sense. If the application can update the SQL data, you've already lost most of the security of your system. It means that someone breaking in through that application can update SQL, and then use a malicious RADIUS client to further attack the server. > Maybe a wrapper for that could fix it but IMHO it's not a very > "elegant" solution. A web GUI updating the configuration for a security-critical application isn't a very "elegant" solution, either. Pick your battles. If you're going to drive around with your card windows rolled down, it doesn't make much sense to lock the doors for extra "security". > I mean, if a user is loged in and the user's accouting information cannot be > stored in the database becouse the radius daemon was not accessible by a NAS. > Will the accounting information from the time when the radius wasn't running > get appended to the old information (before radius got HUP'ed) ? The NAS will keep sending the accounting information until it gets a response. And to answer a question you didn't ask, you're making the assumption that a HUP will kill the server. It won't. It will cause the server to re-read it's configuration files. Nothing more. > > Source code modifications. > Can this be added to the todo list? Whose? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
