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

Michael Stapelberg stapelberg at debian.org
Sat Nov 24 15:36:52 GMT 2018 

Dimitri, friendly ping? Would you prefer if I took care of this? If I don’t
hear back from you over the next week, I’ll go ahead :).

(An affected user just asked me in person about the status of this issue.)

On Tue, Nov 6, 2018 at 4:51 PM Michael Stapelberg <stapelberg at debian.org>
wrote:

> Thanks for the reminder. It’s hard to keep track of everything that’s
> going on.
>
> The lintian tag description states:
>
> > The only time a binary or shared library in a Debian package should set
> RPATH or RUNPATH is if it is linked to private shared libraries in the same
> package. In that case, place those private shared libraries in
> /usr/lib/package. Libraries used by binaries in other packages should be
> placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which
> case RPATH/RUNPATH is unnecessary.
>
> It seems like this is exactly what’s happening here?
>
> Can we try removing the rpath from where it can be removed, and overriding
> the lintian tag for the legitimate cases?
>
> I’d prefer to not open libraries to the public unless coordinated with
> upstream, as they need to be aware of the stability guarantees (e.g. when
> to bump the SONAME).
>
> Thanks!
>
> On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov <xnox at ubuntu.com>
> wrote:
>
>> 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.
>>
>
>
> --
> Best regards,
> Michael
> _______________________________________________
> Pkg-freeradius-maintainers mailing list
> Pkg-freeradius-maintainers at alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeradius-maintainers
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeradius-maintainers/attachments/20181124/92ded166/attachment.html>

More information about the Pkg-freeradius-maintainers mailing list