Alan DeKok <aland@deployingradius.com> writes:
On Jun 28, 2022, at 2:13 PM, Kamil Jońca <kjonca@op.pl> wrote:
Although I only changed freeradius binaries, I have installed multiple different versions of openssl and:
Don't do that.
I am afraid I have to. There exists packages which wants to use libssl1.x and packages which wants to use libssl3.
It's impossible to debug an issue if you change multiple things at the same time. Is the issue OpenSSL? FreeRADIUS? Or a configuration change in FreeRADIUS?
We don't know. And because it could be any one of those things, you'll have to track down exactly which change is the one that broke it.
So probably ssl3 hadles this differently (And probably I have no chance to debug it due to lack of knowledge :( )
You can install *one* OpenSSL package, and try that. You can ensure that FreeRADIUS 3.0.25 and 3.2.0 have the *same* configuration files.
As I wrote above - not on this machine. Moreover, as debian packages impose some kind of dependency (radius 3.0.25 => libssl1 ; radius 3.2 => libssl3, etc ) I suppose the only way to check if my suspicions are right is to compile radius 3.2 from source with libssl1 and check if it will works.
When you make random changes, it's impossible to figure out what went wrong.
I do not know if "aptitude safe-upgrade" is "random change" - in Debian world is the normal way of upgrading packages. And it mostly ( :) ) works.
The only way to fix is is a methodical approach. Change one thing at a time, test it, and repeat.
Of course. But it is good firstly identify thigh which might be changed during upgrade, I think. And then test them one-by-one. For now I am simply trying to narrow search area. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html