Of the claimed missing componenets, (libfreeradius-server, libfreeradius-radius) we only have lib64freeradius1 which provides libfreeradius-server.so.

 $ urpmq --requires freeradius  | grep radius
config(freeradius)[== 3.0.26-1.mga9]
libfreeradius-dhcp.so()(64bit)
libfreeradius-eap.so()(64bit)
libfreeradius-radius.so()(64bit)         looks OK
libfreeradius-server.so()(64bit)         looks OK

 $ urpmq --whatrequires lib64freeradius1
freeradius                               looks OK
lib64freeradius-devel
lib64freeradius1

Can you please confirm what radius packages you have installed:
 $ rpm -qa | grep radius

CC: (none) => lewyssmith
Source RPM: radius => freeradius-3.0.26-1.mga9.src.rpm

CC'ing DaveH who is knowledgeable about services.

CC: (none) => davidwhodgins

Radiusd searches for the libraries in /usr/lib64/. But all libraries from lib64freeradius1 are installed in /usr/lib64/freeradius/

As temporary workaround, you can copy all *.so libraries from /usr/lib64/freeradius/ to /usr/lib64/
After copying the libraries, the service starts.

Seems like a packaging error in freeradius-3.0.26-1.mga9

(In reply to sturmvogel from comment #3)
> Radiusd searches for the libraries in /usr/lib64/. But all libraries from
> lib64freeradius1 are installed in /usr/lib64/freeradius/
> Seems like a packaging error in freeradius-3.0.26-1.mga9
Thanks for your quick research. I suspected something similar.

Assigning globally, CC'ing the 2 packagers who have dealt with this particular version 3.0.26 .

Assignee: bugsquad => pkg-bugs
CC: davidwhodgins, lewyssmith => geiger.david68210, nicolas.salguero

mid-air collision. :-) My reply was ...
Workaround is to create the following file
# cat /etc/ld.so.conf.d/freeradius.conf 
/usr/lib64/freeradius/

and then run ldconfig.

After doing that ...
[root@x9v ~]# systemctl start radiusd.service 
[root@x9v ~]# systemctl status radiusd.service 
● radiusd.service - FreeRADIUS high performance RADIUS server.
     Loaded: loaded (/usr/lib/systemd/system/radiusd.service; disabled; preset: disabled)
     Active: active (running) since Sun 2024-03-31 15:25:17 EDT; 4s ago
    Process: 33920 ExecStartPre=/usr/sbin/radiusd -C (code=exited, status=0/SUCCESS)
    Process: 33922 ExecStart=/usr/sbin/radiusd -d /etc/raddb (code=exited, status=0/SUCCESS)
   Main PID: 33924 (radiusd)
      Tasks: 6 (limit: 4690)
     Memory: 78.0M
        CPU: 387ms
     CGroup: /system.slice/radiusd.service
             └─33924 /usr/sbin/radiusd -d /etc/raddb

Mar 31 15:25:17 x9v.hodgins.homeip.net systemd[1]: Starting radiusd.service...
Mar 31 15:25:17 x9v.hodgins.homeip.net systemd[1]: Started radiusd.service.

CC: (none) => davidwhodgins

(In reply to Dave Hodgins from comment #5)
> mid-air collision. :-) My reply was ...
> Workaround is to create the following file
> # cat /etc/ld.so.conf.d/freeradius.conf 
> /usr/lib64/freeradius/
> 
> and then run ldconfig.
> 
although there are loads of
OK that worked. I suspected something like that but had no idea how to tell ldconfig how to add /lib64/freeradius to the ld search path. (there used to be an env path LD_LIBRARY_PATH but it seems to have disappeared.
And there is not man page for ldconfig it was hard to figure out how to tell it to look into /lib64/freeradius

I am surpised that although there are loads of .so files in lib64/freeradius  only the first 4 (libfreeradius*.so got put into the ldconfig cache. .
   
Anyway, that /etc/ld.so.conf.d/freeradius.conf file needs to bu included in the radius package. Has noone ever used radius on Mageia in half a year?

I am trying to compile ucserv, a VPN software which I got from Fedora. It wanted radcli. After I got the radius  working, I compiled radcli. It however suddenly wanted to look in /usr/lib/freeradius, rather then /usr/lib64/freeradius, which is where the radius files were located. Now, I  put in a link from /usr/lib/freeradius to /usr/lib64/freeradius, and the compilation worked, but I have no idea why it was suddenly looking in /usr/lib, since it is /usr/lib64/freeradius that is in ldconfig. 

Oh well, now to see if I can get ocserv compiled.

Fixed both mga9 and Cauldron adding a 'ld.so.conf.d' conf file to fix binaries not being correctly linked after RPATH removal.


Assigning to QA,

Packages in 9/Core/Updates_testing:
======================
freeradius-3.0.26-1.1.mga9
freeradius-krb5-3.0.26-1.1.mga9
freeradius-ldap-3.0.26-1.1.mga9
freeradius-mysql-3.0.26-1.1.mga9
freeradius-postgresql-3.0.26-1.1.mga9
freeradius-sqlite-3.0.26-1.1.mga9
freeradius-unixODBC-3.0.26-1.1.mga9
freeradius-yubikey-3.0.26-1.1.mga9
lib64freeradius-devel-3.0.26-1.1.mga9
lib64freeradius1-3.0.26-1.1.mga9
libfreeradius-devel-3.0.26-1.1.mga9
libfreeradius1-3.0.26-1.1.mga9

From SRPMS:
freeradius-3.0.26-1.1.mga9.src.rpm

Assignee: pkg-bugs => qa-bugs

Tested on x86-64, aarch64 (rpi4b) and i586 (vb).

Just tested that radiusd.service starts ok. Not testing that
radiusd actually works as I don't know how to use it and don't have
the energy to dig into learning how.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA9-64-OK MGA9-32-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2024-0118.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

A spammer change the status

Resolution: (none) => FIXED
Status: UNCONFIRMED => RESOLVED