Hi everyone -
Can anyone think of a reason why the NAS-IP and the scr-IP of the
access-req packet should not be the same?
One of NAS is on the other side of a load balancer, source IP is not the
same as NAS-IP.
John
This message is confidential to Prodea Systems, Inc unless otherwise
John Kane wrote:
Is the rlm_sqlippool required when allocating IPs from an SQL DB?
Yes.
I am
trying to set this up on a 1.1.3 install, and don't see that module.
Install 2.1.8.
Alan DeKok.
-
Thanks Alan, unfortunately I am chained to Red Hat RPMs on this project
Is the rlm_sqlippool required when allocating IPs from an SQL DB? I am
trying to set this up on a 1.1.3 install, and don't see that module.
Thanks,
John
This message is confidential to Prodea Systems, Inc unless otherwise indicated
or apparent from its nature. This message is directed to the
Alex Bahoor alexbah...@sbcglobal.net writes:
Arrogant.
http://catb.org/~esr/faqs/smart-questions.html#keepcool
You probably should read the rest of this document as well, but it
seems
that this particular section was written specifically for you.
Bjørn
[JK] Bjorn, thanks for
I have this running on RHEL5 (freeradius 1.1.3-1.4.el5), writing accounting to
a flat file (had it writing to Postgres DB nearly two years ago, but have
forgotten all of that ☺ ).
What issues are you having?
John
From:
Arran Cudbard-Bell
*sigh* the Coffee excuse doesn't work past lunch time does it...
(missed out some curly braces)
instantiate {
sql_old
}
authorize {
# Retrieves credentials
sql_new
# Sets auth-type mschap
mschap
}
authenticate {
Thanks a lot, guys. I am on vacation until Monday, but am very tempted
to login to work and give this a try..nah, it can wait until Monday
:).
Thanks again for you efforts.
John
-Original Message-
From: freeradius-users-
bounces+john.kane=prodeasystems@lists.freeradius.org
Hi,
[JK] Thanks, Arran. Another quick question. Will 2.* do this
'straight out of the box'? If not, will it require much work? We are
evaluating whether attempt this in radius, or make changes in our
system.
your situation is a slightly unique bespoke requirement - as such, it
wont
hmm, all you are doing is setting the values to what they
normally are...you need something like
group {
sql_new {
reject = 1
ok = return
}
sql_old {
I was hoping that would not be your response :)
-Original Message-
From: freeradius-users-
bounces+john.kane=prodeasystems@lists.freeradius.org
[mailto:freeradius-users-
bounces+john.kane=prodeasystems@lists.freeradius.org] On Behalf Of
a.l.m.bu...@lboro.ac.uk
Sent:
so, what you've actually got to do is run the pap method twice.
once for the user-name/password from sql_new and once for the
user-name/password from sql_old. one of those methods would
work for a valid user
thats a funky bit of group/failover requirement that'll have to
be
Is there a 'howto' on upgrade from Freeradius 1.x to 2.x, one that lists
what configs were moved where, etc. that would allow a person to do the
upgrade as smoothly and quickly as possible (I can't seem to find one).
Or better yet, are there any perl or python scripts available that
automate
John Kane wrote:
I've been asked to implement freeradius on a proprietary system that
uses the concept of a password 'grace period', a brief time period
during which both the old and new passwords should be allowed. Is
this
possible with freeradius?
[snip]
Not with any of the 1
I've been asked to implement freeradius on a proprietary system that
uses the concept of a password 'grace period', a brief time period
during which both the old and new passwords should be allowed. Is this
possible with freeradius?
The system uses pptp client access (MS-CHAP) with user/passwords
Forgive me if this is not the correct mailing list for this question
(and if not, point me to the correct one, if possible).
I am running PPTP (poptop w/radiusclient) on the same RHEL Linux box as
the freeradius server. Initially, all works well. But after some time
(30-45 min?), the radius
15 matches
Mail list logo
