Arran Cudbard-Bell wrote:
Techs will also want to test switches in new installs , and they won't
like waiting a day for configuration changes to take effect like
users won't like the service
going down every hour , although we could stagger the server restarts
In reality I expect
Arran Cudbard-Bell wrote:
Coincidently started testing the 2.00 pre code in a proper environment
today instead of just using
radclient. All seems to stand up pretty well, no random crashes or
weirdness... apart from of course the dreaded HUP
which results in a segfault.
That's good to
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Assertion failed in event.c, line 669
...
Happens after all the home servers have been marked as dead, and you
have an incoming request... though could be when it's firing off a ping
check event.
Either way it's repeatable, and
Arran Cudbard-Bell wrote:
Yep works for me too, reaches end of list of possible servers and starts
rejecting all users assigned
to that realm. :)
Thanks.
Also little one with access-reject when home server fails to respond.
Not sent through access reject filter, though that's probably
That will be fixed on another commit.
It turns out the easiest way to fix that was to remove the multiple
places that called Post-Auth-Type Reject, and move it to one central
location. Simpler, less code, does exactly the same thing as before,
and adds the call to Post-Auth-Type Reject
Alan DeKok wrote:
I've just committed massive changes to the server core. The diff is
about 3k lines, and doesn't include deleted or added files.
More code changes today:
Multiple requests are proxied to a home server. If the home server is
marked dead while the NAS is retransmitting
Alan DeKok wrote:
Alan DeKok wrote:
I've just committed massive changes to the server core. The diff is
about 3k lines, and doesn't include deleted or added files.
More code changes today:
Multiple requests are proxied to a home server. If the home server is
marked dead
Arran Cudbard-Bell wrote:
Alan DeKok wrote:
Alan DeKok wrote:
I've just committed massive changes to the server core. The diff is
about 3k lines, and doesn't include deleted or added files.
More code changes today:
Multiple requests are proxied to a home
Arran Cudbard-Bell wrote:
...
FAILURE: Home server 194.83.56.249 port 1812 is dead.
RETRY: Proxying request 13 to different home server 194.82.174.185 port 1812
...
Didn't do that before :S
Yup.
$ cvs update
$ make
:)
Also, if you have SNMP enabled, it now prints out that it's
Alan DeKok wrote:
Got another one for you :P
rlm_detail: /usr/local/freeradius/var/log//%Y%m%d/pre-proxy-detail
expands to /usr/local/freeradius/var/log//20070410/pre-proxy-detail
radius_xlat: 'Tue Apr 10 18:34:28 2007'
modcall[pre-proxy]: module pre_proxy_log returns ok for request 31
On Tuesday 10 April 2007 13:51:29 Arran Cudbard-Bell wrote:
and finally, how do you define a binding for the snmp module it's
on, but I never explicitly bound it to anywhere :|
unlike auth/acct that are bound with listen sections. Seems like there
may be a need for a small extension to
Kevin Bonner wrote:
On Tuesday 10 April 2007 13:51:29 Arran Cudbard-Bell wrote:
and finally, how do you define a binding for the snmp module it's
on, but I never explicitly bound it to anywhere :|
unlike auth/acct that are bound with listen sections. Seems like there
may be a need for
Arran Cudbard-Bell wrote:
Kevin Bonner wrote:
On Tuesday 10 April 2007 13:51:29 Arran Cudbard-Bell wrote:
and finally, how do you define a binding for the snmp module it's
on, but I never explicitly bound it to anywhere :|
unlike auth/acct that are bound with listen
Arran Cudbard-Bell wrote:
...
Assertion failed in event.c, line 669
Hmm... OK.
Happens after all the home servers have been marked as dead, and you
have an incoming request... though could be when it's firing off a ping
check event.
Either way it's repeatable, and *only* happens when
Arran Cudbard-Bell wrote:
Assertion failed in event.c, line 669
...
Happens after all the home servers have been marked as dead, and you
have an incoming request... though could be when it's firing off a ping
check event.
Either way it's repeatable, and *only* happens when all home servers
Arran Cudbard-Bell wrote:
At least in 1.1.5 it doesn't fall through properly if a user belongs to
multiple groups and the check items in the first group partially match..
In which version did it stop working?
Least that my experience.
Anyway, nice work on pre 2.0 , looking forward to it
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
At least in 1.1.5 it doesn't fall through properly if a user belongs to
multiple groups and the check items in the first group partially match..
In which version did it stop working?
I will investigate, as far as I could tell it
Is freeradius development quite closed, or is it open to everyone ?
One of our mantras is As always, patches are welcome.
However, we get the occasional email from people saying I have a
patch... give me CVS commit access. The answer is always No..
Patches get audited for
Arran Cudbard-Bell wrote:
So all potential patches should be created against the CVS head, and
submitted to the developers mailing list ?
That's probably the quickest way. You can also open an issue on the
bug tracker, but that isn't always necessary for simple patches.
Alan DeKok.
--
Arran Cudbard-Bell wrote:
So all potential patches should be created against the CVS head, and
submitted to the developers mailing list ?
That's probably the quickest way. You can also open an issue on the
bug tracker, but that isn't always necessary for simple patches.
Alan DeKok.
--
Alan, thinking about upcoming upgrade from 1.1.5 to 2.0 i tried 2.0 with
my configuration from 1.1.5.
There seem to be some difference which i hope you can explain.
proxy.conf configuration is
realm NULL {
type= radius
authhost= LOCAL
accthost
Alexander Serkin wrote:
Alan, thinking about upcoming upgrade from 1.1.5 to 2.0 i tried 2.0 with
my configuration from 1.1.5.
There seem to be some difference which i hope you can explain.
proxy.conf configuration is
realm NULL {
type= radius
authhost
In 2.0 we lack the group checks:
I thought group checks were slightly broken since 1.1.3 anyway if
not can someone please close the bug report :)
At least in 1.1.5 it doesn't fall through properly if a user belongs to
multiple groups and the check items in the first group partially
Arran Cudbard-Bell wrote:
In 2.0 we lack the group checks:
I thought group checks were slightly broken since 1.1.3 anyway if
not can someone please close the bug report :)
At least in 1.1.5 it doesn't fall through properly if a user belongs to
multiple groups and the check items
I've just committed massive changes to the server core. The diff is
about 3k lines, and doesn't include deleted or added files.
The good news is that it looks to be nearly 100% backwards compatible
with the configurations currently allowed by the CVS head. That is,
I've written it to be
25 matches
Mail list logo
