Update from 3.0.4 to 3.0.13 (RHEL and CentOS 7.3 to 7.4): Reference "${group_attribute}" not found
Hi, committing an update from CentOS release 7.3.1611 to 7.4.1708 also a FreeRADIUS update is deployed: * 7.3.1611: freeradius-3.0.4-8.el7_3.x86_64 * 7.4.1708: freeradius-3.0.13-8.el7_4.x86_64 Afterwards it fails to start. I found a bug report on this (which hit Fedora 22 back then in the end of 2015): https://bugzilla.redhat.com/show_bug.cgi?id=1291006 What's the best way to circumvent this? It seems that some reconfiguration is needed, but I don't see exactly *where*. A temporary (surely not elegant) fix is to modify /etc/raddb/mods-config/sql/main/mysql/queries.conf, from authorize_group_check_query = "\ SELECT id, groupname, attribute, \ Value, op \ FROM ${groupcheck_table} \ WHERE groupname = '%{${group_attribute}}' \ ORDER BY id" authorize_group_reply_query = "\ SELECT id, groupname, attribute, \ value, op \ FROM ${groupreply_table} \ WHERE groupname = '%{${group_attribute}}' \ ORDER BY id" in the new 3.0.13 file to authorize_group_check_query = "\ SELECT id, groupname, attribute, \ Value, op \ FROM ${groupcheck_table} \ WHERE groupname = '%{Sql-Group}' \ ORDER BY id" authorize_group_reply_query = "\ SELECT id, groupname, attribute, \ value, op \ FROM ${groupreply_table} \ WHERE groupname = '%{Sql-Group}' \ ORDER BY id" (as it was in 3.0.4). Best, Bernd
On Sep 15, 2017, at 4:26 AM, Bernd <bernd@kroenchenstadt.de> wrote:
committing an update from CentOS release 7.3.1611 to 7.4.1708 also a FreeRADIUS update is deployed:
* 7.3.1611: freeradius-3.0.4-8.el7_3.x86_64
* 7.4.1708: freeradius-3.0.13-8.el7_4.x86_64
Afterwards it fails to start. I found a bug report on this (which hit Fedora 22 back then in the end of 2015):
Which also says it's not a bug. The issue is due to an "rpmnew" file being left around. Find it, and delete it. Alan DeKok.
Am 2017-09-15 13:14, schrieb Alan DeKok:
On Sep 15, 2017, at 4:26 AM, Bernd <bernd@kroenchenstadt.de> wrote:
committing an update from CentOS release 7.3.1611 to 7.4.1708 also a FreeRADIUS update is deployed:
* 7.3.1611: freeradius-3.0.4-8.el7_3.x86_64
* 7.4.1708: freeradius-3.0.13-8.el7_4.x86_64
Afterwards it fails to start. I found a bug report on this (which hit Fedora 22 back then in the end of 2015):
Which also says it's not a bug. The issue is due to an "rpmnew" file being left around. Find it, and delete it.
I didn't say that it's a bug within FreeRADIUS. It's more a glitch in the update mechanism. I removed all *rpmnew files (which should normally not be a problem) but the error remains: # radiusd -X FreeRADIUS Version 3.0.13 Copyright (C) 1999-2017 The FreeRADIUS server project and contributors There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License For more information about these matters, see the file named COPYRIGHT Starting - reading configuration files ... including dictionary file /usr/share/freeradius/dictionary including dictionary file /usr/share/freeradius/dictionary.dhcp including dictionary file /usr/share/freeradius/dictionary.vqp including dictionary file /etc/raddb/dictionary including configuration file /etc/raddb/radiusd.conf including configuration file /etc/raddb/proxy.conf including configuration file /etc/raddb/clients.conf including files in directory /etc/raddb/mods-enabled/ including configuration file /etc/raddb/mods-enabled/always including configuration file /etc/raddb/mods-enabled/attr_filter including configuration file /etc/raddb/mods-enabled/cache_eap including configuration file /etc/raddb/mods-enabled/chap including configuration file /etc/raddb/mods-enabled/detail including configuration file /etc/raddb/mods-enabled/detail.log including configuration file /etc/raddb/mods-enabled/dhcp including configuration file /etc/raddb/mods-enabled/digest including configuration file /etc/raddb/mods-enabled/dynamic_clients including configuration file /etc/raddb/mods-enabled/eap including configuration file /etc/raddb/mods-enabled/echo including configuration file /etc/raddb/mods-enabled/exec including configuration file /etc/raddb/mods-enabled/expiration including configuration file /etc/raddb/mods-enabled/expr including configuration file /etc/raddb/mods-enabled/files including configuration file /etc/raddb/mods-enabled/linelog including configuration file /etc/raddb/mods-enabled/logintime including configuration file /etc/raddb/mods-enabled/mschap including configuration file /etc/raddb/mods-enabled/ntlm_auth including configuration file /etc/raddb/mods-enabled/pap including configuration file /etc/raddb/mods-enabled/passwd including configuration file /etc/raddb/mods-enabled/preprocess including configuration file /etc/raddb/mods-enabled/radutmp including configuration file /etc/raddb/mods-enabled/realm including configuration file /etc/raddb/mods-enabled/replicate including configuration file /etc/raddb/mods-enabled/soh including configuration file /etc/raddb/mods-enabled/sradutmp including configuration file /etc/raddb/mods-enabled/unix including configuration file /etc/raddb/mods-enabled/unpack including configuration file /etc/raddb/mods-enabled/utf8 including configuration file /etc/raddb/mods-enabled/mysql_comp including configuration file /etc/raddb/mods-config/sql/main/mysql/queries.conf /etc/raddb/mods-config/sql/main/mysql/queries.conf[161]: Reference "${group_attribute}" not found /etc/raddb/mods-config/sql/main/mysql/queries.conf[168]: Reference "${group_attribute}" not found including configuration file /etc/raddb/mods-enabled/date including files in directory /etc/raddb/policy.d/ including configuration file /etc/raddb/policy.d/accounting including configuration file /etc/raddb/policy.d/canonicalization including configuration file /etc/raddb/policy.d/control including configuration file /etc/raddb/policy.d/cui including configuration file /etc/raddb/policy.d/debug including configuration file /etc/raddb/policy.d/dhcp including configuration file /etc/raddb/policy.d/eap including configuration file /etc/raddb/policy.d/operator-name including configuration file /etc/raddb/policy.d/filter including configuration file /etc/raddb/policy.d/filter.rpmnew including files in directory /etc/raddb/sites-enabled/ including configuration file /etc/raddb/sites-enabled/default including configuration file /etc/raddb/sites-enabled/inner-tunnel including configuration file /etc/raddb/sites-enabled/control-socket /etc/raddb/mods-config/sql/main/mysql/queries.conf[161]: Reference "${group_attribute}" not found Errors reading or parsing /etc/raddb/radiusd.conf # ll sql* -rw-r-----. 1 root radiusd 6320 Sep 30 2015 sql -rw-r-----. 1 root radiusd 2996 Aug 23 17:18 sqlcounter -rw-r-----. 1 root radiusd 2603 Aug 23 17:18 sqlippool The mentioned lines in /etc/raddb/mods-config/sql/main/mysql/queries.conf: authorize_group_check_query = "\ SELECT id, groupname, attribute, \ Value, op \ FROM ${groupcheck_table} \ WHERE groupname = '%{${group_attribute}}' \ ORDER BY id" authorize_group_reply_query = "\ SELECT id, groupname, attribute, \ value, op \ FROM ${groupreply_table} \ WHERE groupname = '%{${group_attribute}}' \ ORDER BY id" Problem is that in the line ``WHERE groupname = '%{${group_attribute}}' \'' the installation method seems to fail to replace ``${group_attribute}'' by ``Sql-Group''. Thanks, Bernd
Alan DeKok.
On Sep 15, 2017, at 7:54 AM, Bernd <bernd@kroenchenstadt.de> wrote:
I didn't say that it's a bug within FreeRADIUS. It's more a glitch in the update mechanism. I removed all *rpmnew files (which should normally not be a problem) but the error remains:
... Problem is that in the line ``WHERE groupname = '%{${group_attribute}}' \'' the installation method seems to fail to replace ``${group_attribute}'' by ``Sql-Group''.
The upgrade mechanism SHOULD NOT over-write existing configuration files and break your system. On top of that, the upgrade SHOULD NOT create configuration files which are incompatible with each other. The upgrade mechanism shipped with FreeRADIUS isn't broken, and doesn't do that. a) go back to using the old configuration files b) use the new configuration files You're using: c) use some old configuration files, and some new ones. Don't do that. Alan DeKok.
Am 2017-09-15 14:01, schrieb Alan DeKok:
On Sep 15, 2017, at 7:54 AM, Bernd <bernd@kroenchenstadt.de> wrote:
I didn't say that it's a bug within FreeRADIUS. It's more a glitch in the update mechanism. I removed all *rpmnew files (which should normally not be a problem) but the error remains:
... Problem is that in the line ``WHERE groupname = '%{${group_attribute}}' \'' the installation method seems to fail to replace ``${group_attribute}'' by ``Sql-Group''.
The upgrade mechanism SHOULD NOT over-write existing configuration files and break your system.
Sure. It writes rpmnew files for this purpose.
On top of that, the upgrade SHOULD NOT create configuration files which are incompatible with each other.
The upgrade mechanism shipped with FreeRADIUS isn't broken, and doesn't do that.
a) go back to using the old configuration files
b) use the new configuration files
You're using:
c) use some old configuration files, and some new ones.
Unintentionally, and this is the first update to behave this way. So it requires now some manual intervention, which I'm fine with. Thanks, Bernd
Don't do that.
Alan DeKok.
Bernd wrote:
I didn't say that it's a bug within FreeRADIUS. It's more a glitch in the update mechanism. I removed all *rpmnew files (which should normally not be a problem) but the error remains:
IIRC, .rpmnew files contain changes for the new package version that cannot be put in place without overwriting a modified configuration file. You have to merge them into the corresponding configuration file. (Or merge the existing configuration file's changes into the .rpmnew and then replace the configuration file with the .rpmnew.) Richard.
Which also says it's not a bug. The issue is due to an "rpmnew" file being left around. Find it, and delete it.
I didn't say that it's a bug within FreeRADIUS. It's more a glitch in the update mechanism. I removed all *rpmnew files (which should normally not be a problem) but the error remains:
Raise the rpmnew issue with RedHat if you will.
Problem is that in the line ``WHERE groupname = '%{${group_attribute}}' \'' the installation method seems to fail to replace ``${group_attribute}'' by ``Sql-Group''.
Easily fixed by setting 'group_attribute' to 'Sql-Group', i.e. In queries.conf put this line: group_attribute = 'Sql-Group'? It may even be that this is actually *in* one of the .rpmnew files that you just deleted. Have a look at the 3.0.13 tree on Github. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
participants (4)
-
Alan DeKok -
Bernd -
Richard Siddall -
Stefan Paetow