mysql and utf8 handling in FreeRADIUS 3.2.x
Alan DeKok
aland at deployingradius.com
Fri Apr 4 10:42:01 UTC 2025
On Apr 4, 2025, at 6:01 AM, Bjørn Mork via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> I was thinking about detecting the mismatch between table schema and
> mysql client connection.
How?
> But thinking more about this, it's probably not a good idea to add more
> automatic "magic" here. A simple
>
> i_want_multibyte_utf8 = no
>
> defaulting to "yes" would be better and much simpler.
OK.
> I guess there is some use case I don't see, but if I have to decode the
> string to read it then I'd much prefer to have to decode the multi-byte
> utf8 chars too. Dealing with utf8 requires some extra care, as
> demonstrated. And there is no gain unless the one byte utf8 chars are
> allowed. At least in my part of the world.
The issue is that an 'octets' data type is binary data. It's not UTF-8, latin1, or anything else. So the only correct way to handle it is to store it "as is" with no interpretation.
> Or maybe add a sql_charset config item and use it in the rlm_sql_mysql
> sql_socket_init()?
That seems like a source of confusion / errors.
> One stupid problem I faced when trying to work around the problem in a
> hurry, was that I put the "[freeradius]" section into the wrong mysql
> config file. Using /etc/my.cnf.d/freeradius.cnf did not work despite
> /etc/my.cnf containing
>
> !includedir /etc/my.cnf.d
>
> Maybe because that's in a section named "[client-server]" which does not
> match "[freeradius]"?
I'm not sure what affect that has. TBH, I haven't touched those MySQL config files for a while.
Alan DeKok.
More information about the Freeradius-Users
mailing list