redundant {} slight bug and feature request
Hiya
I have setup redundant {} so that should the MySQL process on the system fail,
it fails back to a secondary server.
During testing I have noticed a slight log bug (possibly :) ). If 2 servers
are used sql1 and sql2, if during operation sql1 goes away and stops responding, the
daemon correctly tries to use it and fails over to sql2, and authorizes the login,
however it logs the connection error in the log file and also that it has rejected the
user (when it hasn't due to the second server working). Just a small thing
Another thing I have noticed is that if one of the servers is down when the
daemon starts, it never seems to try talking to that one again, even if the server
that was up should fail. So EG sql1 and sql2 again. sql1 is down at startup, daemon
uses sql2. sql1 then comes back up and shortly after sql2 dies, daemon now fails all
connections claiming the sql server is down, even tho sql1 is accepting connections.
What I did notice watching the logs was that SQL connections were established
to both SQL servers if they were availible. Does this mean that is sql1 becomes busy,
additional connections will be farmed off to sql2? If it does, then can this
behaviour be stopped until sql1 does fail?
Thanks again for your time.
--
-
Graeme Hinchliffe (BSc)
Core Internet Systems Designer
Zen Internet (http://www.zen.co.uk)
ICQ 3842605 (link)
Sales : 0870 6000 971
Fax : 0870 6000 972
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Stop packet confirmation when in proxy mode - Feature Request
Drew Flickema [EMAIL PROTECTED] wrote: For the most part, I run my FR install in proxy mode. It has been seen that session stop packets are received by my FR, but on occasion, these stop packets are not received by the FR authentication endpoint due to network issues or possibly the FR endpoint experienced a hiccup. The server is configured by default to re-transmit proxied packets, until the middle server sees a reply. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Stop packet confirmation when in proxy mode - Feature Request
For the most part, I run my FR install in proxy mode. It has been seen that session stop packets are received by my FR, but on occasion, these stop packets are not received by the FR authentication endpoint due to network issues or possibly the FR endpoint experienced a hiccup. Would a feature request for this be in order? Has anyone else seen anything like this and if so, what did you do about it, ignore it? Thanks, Drew Flickema - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Feature request: new check attributes
I need to be able to sort users by the NAS that they connect to. I'm experimenting with using Called-Station-ID to sort by, but not all of my NASes will be using a dialup number (PPPoE through DSL, VDSL, etc.). Ideally, I'd like to sort by NAS-IP-Address. I'm envisioning two different scenerios: 1) New check attributes that can be assigned to any user or group -- maybe Allow-NAS-IP and Deny-NAS-IP? These attributes could be stacked (in a logical, common-sense way), meaning more than one could be assigned to a user or group to create a sort of per user/group access list. 2) In reference to the rlm_sql module, there are currently two levels that attributes can be assigned to (not counting realms which aren't working yet) -- the user level and the group level. Could we add a third nas level. I.e. nascheck and nasreply tables? I would find this EXTREMELY useful. Thanks for the great software! --Aaron - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Feature request: new check attributes
Aaron Paetznick [EMAIL PROTECTED] wrote: I need to be able to sort users by the NAS that they connect to. See the 'huntgroups' file. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Feature request
Michael S. McCollough [EMAIL PROTECTED] wrote: When I use the network inclusive clients config to allow NAS on a given network radius access, under /var/radacct the nas is named via the IP address. If I were to use single entries for all these clients I would see the client shorname. I propose (when network inclusive used) creating a directory ./radacct/shorname/ip.ad.dr.es.sx be used for logging. So why not configure that? Read 'radiusd.conf' and 'doc/variables.txt' I am quite sure my C is not up to par (I haven't written a C program in almost 8 years) but would be curious as to where it is located and if anyone could do or is interested in doing this? Or am I just configuring something wrong? No, just not configuring it correctly. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Feature request
Title: Message
When I use the
network inclusive clients config to allow NAS on a given network radius access,
under /var/radacct the nas is named via the IP address. If I were to use single
entries for all these clients I would see the client shorname. I propose (when
network inclusive used) creating a directory ./radacct/shorname/ip.ad.dr.es.sx
be used for logging. I am quite sure my C is not up to par (I haven't written a
C program in almost 8 years) but would be curious as to where it is located and
if anyone could do or is interested in doing this? Or am I just configuring
something wrong?
clientx.x.x.0/24
{
secret = password
shortname = NorthAm-Wcom}
This would make the
the above logged as:
/var/log/radacct/North-Am-Wcom/x.x.x.1
/var/log/radacct/North-Am-Wcom/x.x.x.2
for each client.
This just makes it easy to drill down when you have alot of radius
clients.
