radwho: No configuration information in radutmp section of radiusd.conf
Hello, I have a problem with radwho since I upgraded from 2.1.10 to 2.2.0. The same configuration (I'm trying now the default configuration installed from ubuntu packages) works with version 2.1.10 and not with 2.2.0. The error I get is; radwho: No configuration information in radutmp section of radiusd.conf My config (for default virtual server) is: authorize { preprocess chap mschap suffix eap { ok = return } unix files expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix eap } preacct { preprocess suffix files } accounting { detail unix #radutmp attr_filter.accounting_response } # Session database, used for checking Simultaneous-Use. Either the radutmp # or rlm_sql module can handle this. # The rlm_sql module is *much* faster session { radutmp # # See "Simultaneous Use Checking Queries" in sql.conf # sql } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } # # When the server receives a reply to a request it proxied # to a home server, the request may be massaged here, in the # post-proxy stage. # post-proxy { eap } I have tried it enabling and disabling radutmp in accounting section. As I have already said, this same configuration works with 2.1.8 (default ubuntu package) but not with 2.2.0. Any idea? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337
Angel L. Mateo wrote:
Hello,
I have a problem with radwho since I upgraded from 2.1.10 to 2.2.0. The same configuration (I'm trying now the default configuration installed from ubuntu packages) works with version 2.1.10 and not with 2.2.0. The error I get is;
radwho: No configuration information in radutmp section of radiusd.conf
You need to have a "modules" section, with "radutmp" listed in it.
My config (for default virtual server) is:
Which doesn't really help. What's in the "modules" directory?
accounting { detail unix #radutmp
Well, that won't help. You're trying to use "radwho", but aren't logging accounting information. That means "radwho" will NEVER show you anything.
session { radutmp
Which again does nothing, because the radutmp file will be empty. Alan DeKok.
El 16/11/12 17:03, Alan DeKok escribió:
Angel L. Mateo wrote:
Hello,
I have a problem with radwho since I upgraded from 2.1.10 to 2.2.0. The same configuration (I'm trying now the default configuration installed from ubuntu packages) works with version 2.1.10 and not with 2.2.0. The error I get is;
radwho: No configuration information in radutmp section of radiusd.conf
You need to have a "modules" section, with "radutmp" listed in it.
In my modules section I have modules { ... $INCLUDE ${confdir}/modules/ .. } and I have a file ${confdir}/modules/radutmp with content: radutmp { filename = ${logdir}/radutmp username = %{User-Name} case_sensitive = yes check_with_nas = yes perm = 0600 callerid = "yes" }
My config (for default virtual server) is:
Which doesn't really help.
What's in the "modules" directory?
accounting { detail unix #radutmp
Well, that won't help.
You're trying to use "radwho", but aren't logging accounting information. That means "radwho" will NEVER show you anything.
I'm not sure about this. I have tried configuration with radutmp line commented and uncommented. But the fact is that radwho is loggin information, because radutmp is updated and if I use radwho -F <file> then I can see is not empty. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337
On Mon, Nov 19, 2012 at 2:28 PM, Angel L. Mateo <amateo@um.es> wrote:
accounting { detail unix #radutmp
Well, that won't help.
You're trying to use "radwho", but aren't logging accounting information. That means "radwho" will NEVER show you anything.
I'm not sure about this. I have tried configuration with radutmp line commented and uncommented. But the fact is that radwho is loggin information, because radutmp is updated and if I use radwho -F <file> then I can see is not empty.
That's odd. The only thing writing the utmp file should be accounting section. Did you perhaps forgot to restart the server after making the change? Anyway, from a quick glance at radwho, the relevant change is probably https://github.com/FreeRADIUS/freeradius-server/commit/41960ed2 . If you know how to reverese a patch and build from source, you can try reverting the patch (direct patch link: https://github.com/FreeRADIUS/freeradius-server/commit/41960ed2.diff) and see if it helps. I'm assuming you have a non-empty utmp file already? If it works, then you found a bug and pinpoint the source. If it doesn't, then it's something else. -- Fajar
El 19/11/12 09:15, Fajar A. Nugraha escribió:
On Mon, Nov 19, 2012 at 2:28 PM, Angel L. Mateo <amateo@um.es> wrote:
accounting { detail unix #radutmp
Well, that won't help.
You're trying to use "radwho", but aren't logging accounting information. That means "radwho" will NEVER show you anything.
I'm not sure about this. I have tried configuration with radutmp line commented and uncommented. But the fact is that radwho is loggin information, because radutmp is updated and if I use radwho -F <file> then I can see is not empty.
That's odd. The only thing writing the utmp file should be accounting section. Did you perhaps forgot to restart the server after making the change?
Anyway, from a quick glance at radwho, the relevant change is probably https://github.com/FreeRADIUS/freeradius-server/commit/41960ed2 . If you know how to reverese a patch and build from source, you can try reverting the patch (direct patch link: https://github.com/FreeRADIUS/freeradius-server/commit/41960ed2.diff) and see if it helps. I'm assuming you have a non-empty utmp file already? If it works, then you found a bug and pinpoint the source. If it doesn't, then it's something else.
Same configuration, with freeradius 2.2.0 but using radwho from 2.1.8 works. Instead of revert patching the file, I have copied radwho command from previous folders, and it works without any problem. So it seems that the problem is that now -F options is mandatory instead of optional. If this was the only problem, it wouldn't be any problem, but I'm having the same problem with radzap: /usr/bin/radzap -P 131833856 -u <user> -N <ip> localhost <secret> radwho: No configuration information in radutmp section of radiusd.conf! This same configuration with previous versions of radius works without any problem. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337
On Mon, Nov 19, 2012 at 4:25 PM, Angel L. Mateo <amateo@um.es> wrote:
Same configuration, with freeradius 2.2.0 but using radwho from 2.1.8 works. Instead of revert patching the file, I have copied radwho command from previous folders, and it works without any problem.
So it seems that the problem is that now -F options is mandatory instead of optional.
At least you determined that it was a regression. The next step depends on whether a developer cares enough to fix this problem quickly. Of course it would be quicker if you could determine which changeset caused the regresession, or (even better) provide a patch to fix this :)
If this was the only problem, it wouldn't be any problem, but I'm having the same problem with radzap:
/usr/bin/radzap -P 131833856 -u <user> -N <ip> localhost <secret> radwho: No configuration information in radutmp section of radiusd.conf!
This same configuration with previous versions of radius works without any problem.
radzap is now a wrapper around radwho and radclient. If you say previos version's radwho can be used as-is as a simple drop-in, then the workaround should be to just rename or move 2.2.0-version somewhere else and put the working 2.1.x's version in your path. Personally, I don't use either radwho or radzap. I just use sql, plus some modified queries to "automatically" invalidate old sessions (e.g. since we use 1-hour interim-update interval, any accounting records that is not in "stopped" state that is over 2 hour old can be considered invalid). Hope you find the best solution. -- Fajar
participants (3)
-
Alan DeKok -
Angel L. Mateo -
Fajar A. Nugraha