On 16 March 2017 at 12:20, Jonathan Wakely <jwak...@fedoraproject.org>
wrote:
[..]
> I can only repeat that such people should consider linking own binaries
>> against uClibc as this implementation is not affected by issue with hidden
>> loading NSS DSOs which probably make such binaries useless on moving
>> around
>> against latest fedora/RH7 and RH5.
>>
>
> If you don't move the binaries around you don't have a problem.
>
> You're still assuming you know everybody's use cases.
As an argument against what I'm suggesting already in this thread was used
case statically linked binaries in chrooted envs with some old legacy
binaries.
Risk coming from such scenarios is not as a "potentially may happen in
future" but something which is already happening probably +1 time a day
globally.
If statically linked with glibc binaries will be linked on top latest
Fedora and will be used inside suh envs crash by NSS issue is almost
unavoidable because such binary it will be trying to load NSS DSO modules
from old glibc.
Again: such problems will never happen if using in such extreme/unusual
conditions static libc will be allowed but only against uClibc which is not
affected by NSS ABI issues.
And last argument/nail to this NSS issue coffin.
This issue is so well known to glibc developers that they made glibc static
code producing static NSS modules as statically linked modules. Such
support is provided only for two types of NSS methods: files and dns. This
is kind of very minimal NSS support which potentially in all cases of using
statically linked binaries will be possible to use.
*Problem is* that Fedora glibc is not ready to embed such code statically
because current build procedure does not builds static NSS binaries for
files and dns methods. So *none of the Fedora packages provides
libnns_{files,dns}.a* !!!
Other consequence of above: if someone will be even tying to build
statically linked binaries using other methods of mapping like sss or other
it will be not possible to build such binaries because static glibc code is
not prepared to be linked with more than those handful/stub files and dns
NSS methods support.
BTW: during checking that current Fedora glibc static binaries are not
ready even solve those well known scenarios I found that already glibc spec
file is generating glibs-nss-devel subpackage.
S rpm -qpl glibc-nss-devel-2.25.90-1.fc27.x86_64.rpm
/usr/lib64/libnss_compat.so
/usr/lib64/libnss_db.so
/usr/lib64/libnss_dns.so
/usr/lib64/libnss_files.so
/usr/lib64/libnss_hesiod.so
/usr/lib64/libnss_nis.so
/usr/lib64/libnss_nisplus.so
Looks like someone didn't know that those symlinks are not a devel symlinks
and they are installed by am/ac/lt glibc build suit only because it was
easier to use library build/install method.
Will try to create bugzilla ticket to delete those symlinks in %install,
remove glibc-nss-devel and add it to Obsoletes list.
Another subject related to the NSS libc issue is provide fully working
solutions to any future solutions when NSS ABI issue will be hit again ale
on glibc upgrade will be on the system on some with "in the middle state"
when glibc will be due upgrade and part of the upgrade procedure will be
necessary to execute some script finishing such upgrade. There are two
possible solutions:
1) classic like it is already implemented in Solaris where is provided
/sbin/sh which is static binary not affected by NSS ABI issues
2) use rpm embedded lua interpreter to execute bits of such procedures.
BTW point 2). To avoid /bin/sh dependencies IMO it would be good to invest
some time to review existing %post{,un}, %pre{,un} %trigger scripts to
rewrite as much as possible to use lua rpm internal interpreter instead SH.
However I think that provide in Fedora something like /bin/sash (which is
still available on http://members.tip.net.au/~dbell/programs/) may be very
attractive for some docker/minimalistic scenarios. So provide in Fedora
sahs may be kind of OOTB and fully supported better solution than probably
currently used :)
Definitely this minimalistic shell (his static binary on x84_64 has only
~950KB) is very useful in some systems rescue scenarios. It saved my ass
many times in the past. It is perfect as well as main shell interpreter
inside initrd.
So .. one more time: my proposition *is not about cutting off all people
from using statically libc* linked binaries.
One more time: *it is misunderstanding* and this is not what I'm proposing.
Part of my proposition with stop provide glibc-static is to propose
alternative and 100% working solutions but without glibc-static packages.
You can take it as *provide Right(tm) Solutions* of NSS ABI glibc issues to
all average joe-developers which are 99.99% not aware that potentially
they are shooting in own foot (really number of people around the world
aware of those issues is very low/handful).
*In all those rare cases* instead glibc-static *should be used* *uClibc*
(or alternative).
uClibc is actively developed and widely used on many CPU platforms as it is
essential on many embedded platforms so risk that are some issues with this
library is already probably the same as with using glibc.
uClibc is already part of the Fedora distribution and it is* functional
replacement of glibc-static *in scenarios like using embedded/minimalistic
system images, rescue and early system boo system and other similar
scenarios.
So nothing more needs to be done now except provide in Fedora documentation
that because glibc-static has (by its natural internal complexity) some
well known ABI issues Fredora to prevents happen those issues stops
distributing glibc-static and provides as replacement using uClibc static
libc binaries.
One more time: *provide package and allow to end developers use
glibc-static is nothing more than asking for troubles.*
All test suits using full static linking testing be can abandon as static
linking with libc is a bit pointless (as there is nothing special in glibc
static binaries which may expose some linker issues during such tests).
And/or such test suits should be tweaked to use uClibc as well as *only
officially supported method* of using 100% statically linked binaries so
testing such solution on distribution build layer will be provided as well.
In such scenarios uClibc will be additionally tested on Distro layer during
regular builds of some distribution packages.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
