RE: (RADIATOR) high availabilty accounting

2001-01-29 Thread Andy De Petter


Hello Hugh,

I'ld suggest a parameter called "PreferPrimary", or something in that
nature, which would cause Radiator to always try the primary SQL server
first.  That way, you might lose a bit of your performance (as it will keep
on trying 2 times, when your primary SQL server is down), but you're pretty
sure that your radius servers will keep on trying to contact your primary
(and in most cases, also the most performant) SQL server.

I was also thinking about something like "NeverGiveUp" parameter, but I'm
having second thoughts about it, as it might heavily decrease radius
performance..

Don't know what you think of the issue?

-a

 -Original Message-
 From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
 Sent: maandag 29 januari 2001 9:11
 To: Andy De Petter; Radiator Mailing
 Cc: [EMAIL PROTECTED]
 Subject: Re: (RADIATOR) high availabilty accounting



 Hello Andy -

 This will work also.

 Mike is doing some work on the SQL subsystem now - perhaps there
 should be a
 parameter that could control this behaviour?

 regards

 Hugh

 On Monday 29 January 2001 18:36, Andy De Petter wrote:
  AFAIK, by restarting radiator processes..
 
  -a
 
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
   Behalf Of Janet N del Mundo
   Sent: maandag 29 januari 2001 7:00
   To: Hugh Irvine
   Cc: [EMAIL PROTECTED]
   Subject: Re: (RADIATOR) high availabilty accounting
  
  
   Hi Hugh,
  
   How do you switch it back to the primary SQL then?
  
   Thanks,
   Janet
  
   Hugh Irvine wrote:
Hello Janet -
   
At 15:25 +1000 01/1/26, Janet N del Mundo wrote:
What if your primary SQL machine comes back up?  Does it
 automatically
switch back to the primary SQL?
   
No it doesn't.
   
regards
   
Hugh
   
--
   
NB: I am travelling this week, so there may be delays in our
  
   correspondence.
  
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
   
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
  
   ===
   Archive at http://www.starport.net/~radiator/
   Announcements on [EMAIL PROTECTED]
   To unsubscribe, email '[EMAIL PROTECTED]' with
   'unsubscribe radiator' in the body of the message.
 
  ===
  Archive at http://www.starport.net/~radiator/
  Announcements on [EMAIL PROTECTED]
  To unsubscribe, email '[EMAIL PROTECTED]' with
  'unsubscribe radiator' in the body of the message.

 --
 Radiator: the most portable, flexible and configurable RADIUS server
 anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
 -
 Nets: internetwork inventory and management - graphical, extensible,
 flexible with hardware, software, platform and database independence.



===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



RE: (RADIATOR) high availabilty accounting

2001-01-29 Thread Ingvar Berg (ERA)

Hello Hugh,

Wouldn't it be nice with some "generic" solution to this generic problem? I.e. handle 
RADIUS primary/secondary and LDAP primary/secondary in a similar way.
Some configurable time before Radiator tries the primary server again will help the 
performance problem Andy is indicating, and if someone really wants to try the primary 
first always, the time parameter could be set to 0.

And how about allowing hostname _or_ hard-coded IP address whenever possible (like 
BindAddress).

/Ingvar

-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: den 29 januari 2001 09:11
To: Andy De Petter; Radiator Mailing
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) high availabilty accounting



Hello Andy -

This will work also.

Mike is doing some work on the SQL subsystem now - perhaps there should be a 
parameter that could control this behaviour?

regards

Hugh

On Monday 29 January 2001 18:36, Andy De Petter wrote:
 AFAIK, by restarting radiator processes..

 -a

  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
  Behalf Of Janet N del Mundo
  Sent: maandag 29 januari 2001 7:00
  To: Hugh Irvine
  Cc: [EMAIL PROTECTED]
  Subject: Re: (RADIATOR) high availabilty accounting
 
 
  Hi Hugh,
 
  How do you switch it back to the primary SQL then?
 
  Thanks,
  Janet
 
  Hugh Irvine wrote:
   Hello Janet -
  
   At 15:25 +1000 01/1/26, Janet N del Mundo wrote:
   What if your primary SQL machine comes back up?  Does it automatically
   switch back to the primary SQL?
  
   No it doesn't.
  
   regards
  
   Hugh
  
   --
  
   NB: I am travelling this week, so there may be delays in our
 
  correspondence.
 
   Radiator: the most portable, flexible and configurable RADIUS server
   anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
   Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
   Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
  
   ===
   Archive at http://www.starport.net/~radiator/
   Announcements on [EMAIL PROTECTED]
   To unsubscribe, email '[EMAIL PROTECTED]' with
   'unsubscribe radiator' in the body of the message.
 
  ===
  Archive at http://www.starport.net/~radiator/
  Announcements on [EMAIL PROTECTED]
  To unsubscribe, email '[EMAIL PROTECTED]' with
  'unsubscribe radiator' in the body of the message.

 ===
 Archive at http://www.starport.net/~radiator/
 Announcements on [EMAIL PROTECTED]
 To unsubscribe, email '[EMAIL PROTECTED]' with
 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) Lost entries in RADONLINE table via SQL

2001-01-29 Thread Sergio Gonzalez

*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi,

I got a little problem. Recently I had to reboot one of my Hiper DSP cards 
(3com chassis), but I couldn't hangup all the users that were online on 
that PRI. I (saddly) had to hard reset the DSP. The problem is that some of 
the entries on the RADONLINE table of my radiator doesn't fit the reality. 
For example, I lost some of the users that were online, and others just 
look to be online, but obviously they're not!. Now i have some users that 
can't log in because the DefaultSimultaneousUse 1 I use in muy radius.cfg 
file, and others (the worst part) can log in more than once!

How can I make radiator to re-check the online users on my NASes, to make 
the RADONLINE table reflects the real online users?



Thanks in advance!!

/Sergio
Sergio Gonzalez
Director Operativo
SkyNet de Colombia S.A.
57 (+1) 6422020
57 (+3) 2277871
57 (+3) 7285094


===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) high availabilty accounting

2001-01-29 Thread Hugh Irvine


Hello Ingvar -

On Monday 29 January 2001 20:02, Ingvar Berg (ERA) wrote:
 Hello Hugh,

 Wouldn't it be nice with some "generic" solution to this generic problem?
 I.e. handle RADIUS primary/secondary and LDAP primary/secondary in a
 similar way. Some configurable time before Radiator tries the primary
 server again will help the performance problem Andy is indicating, and if
 someone really wants to try the primary first always, the time parameter
 could be set to 0.


I have copied Mike on Andy's mail, and I will copy him on this mail too.

I agree that a more generic solution is to be prefered.

 And how about allowing hostname _or_ hard-coded IP address whenever
 possible (like BindAddress).


This is already the case.

regards

Hugh

 /Ingvar

 -Original Message-
 From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
 Sent: den 29 januari 2001 09:11
 To: Andy De Petter; Radiator Mailing
 Cc: [EMAIL PROTECTED]
 Subject: Re: (RADIATOR) high availabilty accounting



 Hello Andy -

 This will work also.

 Mike is doing some work on the SQL subsystem now - perhaps there should be
 a parameter that could control this behaviour?

 regards

 Hugh

 On Monday 29 January 2001 18:36, Andy De Petter wrote:
  AFAIK, by restarting radiator processes..
 
  -a
 
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
   Behalf Of Janet N del Mundo
   Sent: maandag 29 januari 2001 7:00
   To: Hugh Irvine
   Cc: [EMAIL PROTECTED]
   Subject: Re: (RADIATOR) high availabilty accounting
  
  
   Hi Hugh,
  
   How do you switch it back to the primary SQL then?
  
   Thanks,
   Janet
  
   Hugh Irvine wrote:
Hello Janet -
   
At 15:25 +1000 01/1/26, Janet N del Mundo wrote:
What if your primary SQL machine comes back up?  Does it
 automatically switch back to the primary SQL?
   
No it doesn't.
   
regards
   
Hugh
   
--
   
NB: I am travelling this week, so there may be delays in our
  
   correspondence.
  
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
   
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
  
   ===
   Archive at http://www.starport.net/~radiator/
   Announcements on [EMAIL PROTECTED]
   To unsubscribe, email '[EMAIL PROTECTED]' with
   'unsubscribe radiator' in the body of the message.
 
  ===
  Archive at http://www.starport.net/~radiator/
  Announcements on [EMAIL PROTECTED]
  To unsubscribe, email '[EMAIL PROTECTED]' with
  'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



Re: (RADIATOR) Lost entries in RADONLINE table via SQL

2001-01-29 Thread Hugh Irvine


Hello Sergio -

On Tuesday 30 January 2001 05:19, Sergio Gonzalez wrote:
 *This message was transferred with a trial version of CommuniGate(tm) Pro*
 Hi,

 I got a little problem. Recently I had to reboot one of my Hiper DSP cards
 (3com chassis), but I couldn't hangup all the users that were online on
 that PRI. I (saddly) had to hard reset the DSP. The problem is that some of
 the entries on the RADONLINE table of my radiator doesn't fit the reality.
 For example, I lost some of the users that were online, and others just
 look to be online, but obviously they're not!. Now i have some users that
 can't log in because the DefaultSimultaneousUse 1 I use in muy radius.cfg
 file, and others (the worst part) can log in more than once!

 How can I make radiator to re-check the online users on my NASes, to make
 the RADONLINE table reflects the real online users?


Unfortunately, there is no way to do this directly with Radiator.

I think you have two choices, either use "radpwtst" to send dummy queries to 
Radiator to re-sync the session database, or alternatively, write a little 
script that will poll all of your NAS(s) and re-sync the session database as 
above. The script could become a standard part of your operation, running 
once an hour or once a day or whatever.

Has anyone on the list already created such a script? If so, would they like 
to contribute it to the "goodies" section for the next release?

cheers

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



RE: (RADIATOR) Lost entries in RADONLINE table via SQL

2001-01-29 Thread Chris Given

You can use SNMP, or when you get too big for that to work I would suggest
having your NOC delete from the RADONLINE table all entries for that NAS IP
Address when you reboot a card.

-Original Message-
From: Sergio Gonzalez [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 29, 2001 11:20 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Lost entries in RADONLINE table via SQL


*This message was transferred with a trial version of CommuniGate(tm) Pro*
Hi,

I got a little problem. Recently I had to reboot one of my Hiper DSP cards 
(3com chassis), but I couldn't hangup all the users that were online on 
that PRI. I (saddly) had to hard reset the DSP. The problem is that some of 
the entries on the RADONLINE table of my radiator doesn't fit the reality. 
For example, I lost some of the users that were online, and others just 
look to be online, but obviously they're not!. Now i have some users that 
can't log in because the DefaultSimultaneousUse 1 I use in muy radius.cfg 
file, and others (the worst part) can log in more than once!

How can I make radiator to re-check the online users on my NASes, to make 
the RADONLINE table reflects the real online users?



Thanks in advance!!

/Sergio
Sergio Gonzalez
Director Operativo
SkyNet de Colombia S.A.
57 (+1) 6422020
57 (+3) 2277871
57 (+3) 7285094


===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) Using Auth-Type to define additional authentication checks

2001-01-29 Thread Valentin Tumarkin


 Hi,

I need to implement radiator configuration where for a some users
(~5k) after the user authentication (using AuthBy LDAPSDK)
AuthBy PORTLIMITCHECK and/or AuthBy DYNADDRESS is executed.

Is it ok to use Auth-Type attribute in the user LDAP entry (using
AuthAttrdef mapping) to define additional authentication checks
for a user ?


Example:

AuthBy LDAPSDK
Identifier LDAP_GetGroupAttr
.
/AuthBy

AuthBy PORTLIMITCHECK
Identifier MyPORTLIMITCHECK
...
/AuthBy

AuthBy DYNADDRESS
Identifier MyDYNADDRESS
..
/AuthBy

# Called for Additional Auth
AuthBy GROUP
Identifier ExtendedAuth
..
AuthByPolicy ContinueWhileAccept
AuthBy LDAP_GetGroupAttr
AuthBy MyPORTLIMITCHECK
AuthBy MyDYNADDRESS
..
/AuthBy

# Initial auth for all the users
AuthBy LDAPSDK
Identifier BasicAuth
..
# Get additional auth Identifier (if defined)
AuthAttrDef AuthType, Auth-Type, Check
/AuthBy

# Handler for all the users
Handler
...
AuthBy BasicAuth
...
/Handler





Thanks,

Valentin

+
| Valentin Tumarkin
| Xpert Trusted Systems Ltd.
| E-Mail: [EMAIL PROTECTED]
| Office: +972-9-9522380
| Mobile: +972-53-544887
+




===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.