> 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 "large enough", that's a good patch.
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 radacct size by 10-20%. That's a few more minutes of poorly responsive database. Increasing field sizes to 250 characters when huge majority of people would do fine with only one tenth of that field is not a very good design solution. Perhaps adding a second schema where these fields are maxed up (large_fields_schema.sql)? 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 id causing database filed overflow. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
