> On Wed, 2009-07-22 at 10:27 +0100, Ivan Kalik wrote:
>> PS. I must appologize, it was not my intention to imply that if your
>> equipment generates large ids admin is insane by default. My comments
>> were
>> related to that specific case where admin shot himself in the foot by
>> appending text
> Ya, I'm using mysql. I'm not familiar enough with mysql to know if a
> "text" field is slower/faster/no different to varchar() field. Anyone
> here on the list know any better?
There will be no significant impact on performance. There might be
marginal advantage with varchar due to the way tex
On Wed, 2009-07-22 at 10:27 +0100, Ivan Kalik wrote:
> PS. I must appologize, it was not my intention to imply that if your
> equipment generates large ids admin is insane by default. My comments were
> related to that specific case where admin shot himself in the foot by
> appending text to basic
On Wed, 2009-07-22 at 11:20 +0100, Phil Mayers wrote:
> This may be true for other DBs, for it's not for postgres:
>
> http://www.nabble.com/Re%3A-Disadvantages-to-using-"text"-p17109220.html
>
> I'm only suggesting changing the postgres schema. I realise the OP may
> not have been using postgre
Ivan Kalik wrote:
Nothing in freeradius. But on the database side? Radacct is a big chunk as
it is. Most people keep at least 3 months worth of data and than can be
quite a few GB. There is significant impact on database performance at the
time of daily backup. Proposed changes would increase ra
> Phil Mayers wrote:
>> I must admit, I'd assumed someone had a specific reason for the field
>> sizes being what they are, and didn't want to pre-empt them. But if
>> there isn't such a reason, I'll knock one up.
>
> Nothing depends on the fields being specific sizes. If it's possible
> to make
Phil Mayers wrote:
> I must admit, I'd assumed someone had a specific reason for the field
> sizes being what they are, and didn't want to pre-empt them. But if
> there isn't such a reason, I'll knock one up.
Nothing depends on the fields being specific sizes. If it's possible
to make them "lar
On Wed, Jul 22, 2009 at 02:23:30AM +0100, Alan DeKok wrote:
Phil Mayers wrote:
After the 2nd outage this caused (we rely on near realtime accounting) I
looked into it, and found that postgresql suffers no performance benefit
from using "varchar(n)" and I simply altered all the "varchar" fields t
Phil Mayers wrote:
> After the 2nd outage this caused (we rely on near realtime accounting) I
> looked into it, and found that postgresql suffers no performance benefit
> from using "varchar(n)" and I simply altered all the "varchar" fields to
> type "text". We have since experienced no such proble
On Tue, Jul 21, 2009 at 11:30:31PM +0100, Ivan Kalik wrote:
HA! I figured it out: the acctsessionid field was truncating the
Acct-Session-Id attribute being received from the NAS. I bumped the
field up to 100 characters, and viola, the default SQL queries in
dialup.conf started working. Yeah!
On Tue, 2009-07-21 at 23:30 +0100, Ivan Kalik wrote:
> > HA! I figured it out: the acctsessionid field was truncating the
> > Acct-Session-Id attribute being received from the NAS. I bumped the
> > field up to 100 characters, and viola, the default SQL queries in
> > dialup.conf started working.
> HA! I figured it out: the acctsessionid field was truncating the
> Acct-Session-Id attribute being received from the NAS. I bumped the
> field up to 100 characters, and viola, the default SQL queries in
> dialup.conf started working. Yeah!
>
> We actually had the same problem with the callings
On Tue, 2009-07-21 at 15:58 -0400, Kanwar Ranbir Sandhu wrote:
> On Tue, 2009-07-21 at 15:00 -0400, Kanwar Ranbir Sandhu wrote:
> > The DB shows the exact same Acct-Session-Id that is in the packets
> > themselves. Below are the three rows that get entered into radacct when
> > the AAA test is run
On Tue, 2009-07-21 at 15:00 -0400, Kanwar Ranbir Sandhu wrote:
> The DB shows the exact same Acct-Session-Id that is in the packets
> themselves. Below are the three rows that get entered into radacct when
> the AAA test is run from the E120. Is it the "=" in the
> callingstationid field that's th
On Tue, 2009-07-21 at 19:13 +0100, Ivan Kalik wrote:
> > So, why are there multiple records for the same session being created in
> > radacct at all? We obviously have something misconfigured, but I can't
> > put my finger on it.
>
> Hard to say. Are those queries running on the server or has you
> I finally found out why the changes were made. When doing a "AAA" test
> from the E120 with the default dialup.conf and with simultaneous
> checking enabled, radacct would show three entries for that same
> session. Two would show the acctstoptime as NULL, and the third
hy the changes were made. When doing a "AAA" test
from the E120 with the default dialup.conf and with simultaneous
checking enabled, radacct would show three entries for that same
session. Two would show the acctstoptime as NULL, and the third entry
would show the actual acct stop time.
On Tue, 2009-07-21 at 01:17 +0430, Marinko Tarlac wrote:
> you need to search inside radacct table to see is there any session
> with acctstoptime = NULL for fr 2.x or acctstoptime= 0 for 1.x version
> for spec. user
I'm by no means a freeradius expert, but that was what I thought as
well.
T
On Mon, 2009-07-20 at 22:54 +0100, Ivan Kalik wrote:
> I can't see anything good coming from those changes - only bad. I would be
> very surprised if that simultaneous use check works properly. It checks
> local IP pool and not something related to the NAS.
That's what I was thinking. Thanks for
you need to search inside radacct table to see is there any session
with acctstoptime = NULL for fr 2.x or acctstoptime= 0 for 1.x version
for spec. user
Ivan Kalik wrote:
During testing (we're not live yet), a co-worker made some changes to
dialup.conf to get simultaneous checking wo
> During testing (we're not live yet), a co-worker made some changes to
> dialup.conf to get simultaneous checking working with our NAS (Juniper
> E-120, I believe). I haven't been updated on whether or not the
> simultaneous check actually works (just got back from vacati
Hi All,
During testing (we're not live yet), a co-worker made some changes to
dialup.conf to get simultaneous checking working with our NAS (Juniper
E-120, I believe). I haven't been updated on whether or not the
simultaneous check actually works (just got back from vacation), but I
22 matches
Mail list logo
