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 exp
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 t
>>> 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-Au
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 p
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 repe
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 serv
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 whe
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
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
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
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
modc
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 liste
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 reque
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
>
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 retransmittin
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.
--
>> 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
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
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
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 c
>> 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 partia
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
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
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 ba
25 matches
Mail list logo