[Pkg-freeradius-maintainers] Bug#911180: Bug#911180: freeradius: freeradius refuses to start - missing libs

Dimitri John Ledkov xnox at ubuntu.com
Tue Nov 6 15:27:12 GMT 2018


Hey,

On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg <stapelberg at debian.org> wrote:
>
> I still don’t quite understand why you stripped the rpaths to begin with. Can you explain? I think that’d be good to understand before making a decision :)
>

Please recall that when you last tried to upload freeradius it got
autorejected by ftp masters due to rpath.... email from 2nd of June
from you to me....

"""
freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath
usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu',
automatically rejected package.
freeradius-postgresql: If you have a good reason, you may override
this lintian tag.
freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath
usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected
package.
freeradius-iodbc: If you have a good reason, you may override this lintian tag.
freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath
usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config',
automatically rejected package.
freeradius-python2: If you have a good reason, you may override this
lintian tag.
"""

And spot checking this revealed that rpath is redundant for most of
the modules shipped - hence i stripped rpath from them all.
However, clearly that was false for all of them as some of them do use
private lib as now analyzed.

My preference is to not have rpath set on any of these, and simply
expose libfreeradius-dhcp.so and libfreeradius-eap.so as public
libraries.

Also i'm pondering how come freeradius does not set ldpath when trying
to dlopen the plugins from the plugin dir.... cause that would also
work without rpath set on every plugin.

Regards,

Dimitri.



> On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov <xnox at ubuntu.com> wrote:
>>
>> Hello,
>>
>> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg <stapelberg at debian.org> wrote:
>> >
>> > Sorry, didn’t see the merge request. I fixed my notification settings, merged the MR, and gave you permission to the repository.
>> >
>>
>> No worries. I myself only starting to figure out how to correctly use
>> salsa. It is quite new in how everything works.
>>
>> So about the bug, here is the full scope of affected files:
>>
>> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e File:
>> File: libfreeradius-dhcp.so
>> File: libfreeradius-eap.so
>> File: libfreeradius-radius.so
>> File: libfreeradius-server.so
>> File: proto_dhcp.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-dhcp.so]
>> File: proto_vmps.so
>> File: rlm_always.so
>> File: rlm_attr_filter.so
>> File: rlm_cache.so
>> File: rlm_cache_memcached.so
>> File: rlm_cache_rbtree.so
>> File: rlm_chap.so
>> File: rlm_counter.so
>> File: rlm_cram.so
>> File: rlm_date.so
>> File: rlm_detail.so
>> File: rlm_dhcp.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-dhcp.so]
>> File: rlm_digest.so
>> File: rlm_dynamic_clients.so
>> File: rlm_eap.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_fast.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_gtc.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_leap.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_md5.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_mschapv2.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_peap.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_pwd.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_sim.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_tls.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_eap_ttls.so
>>  0x0000000000000001 (NEEDED)             Shared library: [libfreeradius-eap.so]
>> File: rlm_exec.so
>> File: rlm_expiration.so
>> File: rlm_expr.so
>> File: rlm_files.so
>> File: rlm_ippool.so
>> File: rlm_krb5.so
>> File: rlm_ldap.so
>> File: rlm_linelog.so
>> File: rlm_logintime.so
>> File: rlm_mschap.so
>> File: rlm_otp.so
>> File: rlm_pam.so
>> File: rlm_pap.so
>> File: rlm_passwd.so
>> File: rlm_perl.so
>> File: rlm_preprocess.so
>> File: rlm_python.so
>> File: rlm_radutmp.so
>> File: rlm_realm.so
>> File: rlm_redis.so
>> File: rlm_rediswho.so
>> File: rlm_replicate.so
>> File: rlm_rest.so
>> File: rlm_soh.so
>> File: rlm_sometimes.so
>> File: rlm_sql.so
>> File: rlm_sql_freetds.so
>> File: rlm_sql_iodbc.so
>> File: rlm_sql_mysql.so
>> File: rlm_sql_null.so
>> File: rlm_sql_postgresql.so
>> File: rlm_sql_sqlite.so
>> File: rlm_sqlcounter.so
>> File: rlm_sqlippool.so
>> File: rlm_test.so
>> File: rlm_unix.so
>> File: rlm_unpack.so
>> File: rlm_utf8.so
>> File: rlm_wimax.so
>> File: rlm_yubikey.so
>>
>> The majority of files indeed are fine. But a few that use
>> libfreeradius-dhcp.so and libfreeradius-eap.so are not. I have two
>> options to fix this:
>>
>> (1) do not strip rpath from files that use libfreeradius-eap|dhcp.so
>>
>> or
>>
>> (2) make these two libraries public by creating symlinks
>> /usr/lib/libfreeradius-eap|dhcp.so ->
>> freeradius/libfreeradius-eap|dhcp.so
>>
>> because in practice they are public system soname-less libraries
>> shipped in libfreeradius3 and one can compile against them using
>> libfreeradius-dev.
>>
>> In other packages, I went ahead and added sonames to such libraries
>> and made them public - even if soname .0 and strict << versioning.
>>
>> I can implement either of the above two options, what do you prefer?
>>
>> > Thanks for looking into this!
>> >
>> > On Mon, Nov 5, 2018 at 6:53 PM Dimitri John Ledkov <xnox at ubuntu.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Tue, 16 Oct 2018 at 21:48, Michael Stapelberg <stapelberg at debian.org> wrote:
>> >> >
>> >> > Dimitri, this is a result of your change https://salsa.debian.org/freeradius-team/freeradius/commit/1fad1d069a8148c5c640157147f4ad1b111ca919. Could you revert it for the time being, and, if you chose to go forward with a fix, outline the rationale? The commit only describes the what, not the why. Specifically, in which way was the rpath “bogus”?
>> >> >
>> >>
>> >> Digging more into this, to understand how to fix this right.
>> >>
>> >> > Also, while at it, could you please ensure that https://salsa.debian.org/freeradius-team/freeradius is in sync with what’s in the archive? Your NMU is not reflected in the changelog, for example :-/
>> >> >
>> >>
>> >> I can't actually do this. "Ready to be merged automatically. Ask
>> >> someone with write access to this repository to merge this request"
>> >> that's why when I uploaded NMU I opened the merge request on 25th of
>> >> September at https://salsa.debian.org/freeradius-team/freeradius/merge_requests/2
>> >>  please merge that, I think you are the only one who has the rights to
>> >> the repository.
>> >>
>> >>
>> >> --
>> >> Regards,
>> >>
>> >> Dimitri.
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Michael
>>
>>
>>
>> --
>> Regards,
>>
>> Dimitri.
>
>
>
> --
> Best regards,
> Michael



-- 
Regards,

Dimitri.



More information about the Pkg-freeradius-maintainers mailing list