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