Description of problem: After reading http://lists.mandriva.com/bugs/2011-03/msg00664.php I used cd /var/lib/named mkdir -p usr/lib/openssl-1.0.0d/engines/ cp /usr/lib/openssl-1.0.0d/engines/* usr/lib/openssl-1.0.0d/engines/ after which "service named start" works. I don't know if this should be considered a bind bug, or an openssl bug, but the engines must now be available in the chroot environment. Copying them is not a great solution though. Reproducible: Steps to Reproduce:
@misc, will you take this one?
Assignee: bugsquad => miscSee Also: (none) => https://qa.mandriva.com/show_bug.cgi?id=62829
Priority: Normal => High
Yup.
Status: NEW => ASSIGNED
The bug is likely due to bond requiring various openssl stuff for dnssec, but for some reason, fedora is not affected and I think the solution of greping openssl include is quite bad ( as it will break on every releases of openssl unless bind have ben rebuilt ).
I submitted a rpm, can you check if it work fine for you ?
In /etc/rc.d/init.d/named, change lines 60 and 61 from $LIBGOST=$(rpm -ql $(rpm -q --what-provides openssl-engines) | grep /libgost.so) [ -d /var/lib/named/$(dirname $LIBGOST ) ] || mkdir -p /var/lib/named/$( dirname $LIBGOST ) to LIBGOST="$(rpm -ql $(rpm -q --whatprovides openssl-engines) | grep /libgost.so)" mkdir -p "${LIBGOST%[/]*}" Removing the $ from the variable name receiving the value is required, asis the hyphen in the rpm whatprovides parameter. Changing the mkdir line, avoids two dirname sub processes, and the mkdir will simply do nothing, if the directory already exists, since the -p option has been provided. I also had problems installing, as urpmi kept trying to put bind and bind-utils in separate transactions. The first was failing due to other package problems (mono/libmono-devel). I think that can be solved by having both bind and bind-utils require each other. Also note that bind now must require openssl, to ensure the appropriate libopenssl? is installed.
Created attachment 242 [details] Changed version of named startup script Sorry for the wordwrap. Attaching changed init.d/named
Summary: service name start fails with "initializing DST: openssl failure". => service named start fails with "initializing DST: openssl failure".
Ok, I commited. However Ahmad noticed that the script would not work if someone has both i586 and x86_64 openssl installed.
Created attachment 248 [details] named init script I've modified the script to copy all /usr/lib*/openssl*/engines/libgost.so files to /var/lib/named. I don't have a 64 bit system to test with, but am guessing depmod will figure out which version should be used.
Attachment 242 is obsolete: 0 => 1
Well, that's not optimum, I think; the lib name is the same in both archs, libgost.so, cp will overwrite one lib with the other. (FWIW, it's easier to provide a patch (in case you're not familiar with it, here's an example): - Copy named to named.orig - Do the changes in named, then: $ diff -u named.orig named > named.patch easier to see what got changed and easier to apply the patch to the package if accepted).
Since the cp includes the --parents option, it will not overwrite one version with another. For testing, I manually extracted the /usr/lib part of the 64 bits openssl rpm on my 32 bit system. Starting named with the latest attachment results in $ tree -if /var/lib/named/usr /var/lib/named/usr /var/lib/named/usr/lib /var/lib/named/usr/lib/openssl-1.0.0d /var/lib/named/usr/lib/openssl-1.0.0d/engines /var/lib/named/usr/lib/openssl-1.0.0d/engines/libgost.so /var/lib/named/usr/lib64 /var/lib/named/usr/lib64/openssl-1.0.0d /var/lib/named/usr/lib64/openssl-1.0.0d/engines /var/lib/named/usr/lib64/openssl-1.0.0d/engines/libgost.so The path, including the correct arch and version must match what's in the real /usr/lib*/, or the results of depmod wouldn't work for finding the appropriate module. I'll attach a diff file of my version compared to the current (9.8.0-3.mga1) version.
Created attachment 256 [details] Copy all versions of libgost.so to chroot environment Patch version of changes made in attachment 248 [details].
I see, the whole $LIBGOST is copied. But we can copy only the correct lib*, I suggested: $ rpm -ql $(rpm -q --whatprovides openssl-engines | grep lib$(rpm --eval %{__isa_bits})) | grep /libgost.so And misc suggested: $ rpm -ql $(rpm -q --whatprovides openssl-engines | grep $(rpm --eval '%mklibname openssl-engines')) | grep /libgost.so
Created attachment 257 [details] Copy all versions of libgost.so to chroot environment Sorry, forgot the -u option on the diff command. Here is the patch with the -u option.
Attachment 256 is obsolete: 0 => 1
Created attachment 258 [details] Copy all versions of libgost.so to chroot environment Trying again, remembering to select the Content type of patch.
Attachment 257 is obsolete: 0 => 1
Created attachment 259 [details] Copy all versions of libgost.so to chroot environment Hopefully last time. My apologies, for so many tries, I haven't used diff to create patches before. This time, files in correct order in the diff command.
Attachment 258 is obsolete: 0 => 1
Regarding Comment 12. The lib version of libgost.so is 94K, while the lib64 version is 104K. Which is worse, wasting a 104K of diskspace, or running three rpm commands every time named is started? Note that the space would only be wasted, if both versions of openssl are installed. Can the 32 bit version of bind be installed in a 64 bit system? If so, will the proposed version still pick the right version of openssl? I'd prefer wasting the space, although as I'm writing this, I just realized that when either version of openssl gets updated, the old version would still be wasting space in the chroot environment. I'll modify my version of the script to remove the existing versions of libgost.so in the chroot environment, before copying in the current version(s), and submit an updated patch shortly.
Created attachment 260 [details] Copy all versions of libgost.so to chroot environment after removing old. Changed to remove old versions of libgost.so from chroot environment.
Attachment 259 is obsolete: 0 => 1
Ouch. The current fix causes named to fail to start in beta 2 prerelease, as it's using an absolute path to /var/lib/named/usr/lib/ as the destintation for the copy of libgost.so. I'll look into what's required to fix this.
In my beta 2 pre-release install log, it has ... installing mageia-gfxboot-theme-4.1.19.30-1.mga1.i586.rpm bind-9.8.0-3.mga1.i586.rpm libgpgme++2-4.6.2-1.mga1.i586.r pm libgudev1.0_0-166-4.mga1.i586.rpm bind-utils-9.8.0-3.mga1.i586.rpm kernel-desktop-latest-2.6.38.3-1.mga1.i586.rpm libdc1394_22-2.1.2-7.mga1.i586.rpm from /tmp/image/media/core starting installing packages created transaction for installing on /mnt (remove=0, install=0, upgrade=7) bind-utils-9.8.0-3.mga1.i586 rndc: connect failed: 127.0.0.1#953: network unreachable cp: cannot create regular file `/var/lib/named//usr/lib/openssl-1.0.0d/engines/libgost.so': No such file or director y bind-9.8.0-3.mga1.i586 Note that it seems to be trying to start bind after installing the bind-utils update, but before it installs the bind update. Checking rpm -q --scripts bind-utils, it doesn't have a install script, so I don't see what is causing the "named start" to run. Any ideas?
is it better if you install libopenssl-engines1.0.0 ?
CC: (none) => dmorganec
This was an upgrade from Mageia alpha1 to beta 2 pre-release (the alpha 1 install was over a Mandriva 2010.2 release including backports). The following openssl updates were installed in a urpmi transaction prior to the one where named failed to start ... libopenssl-engines1.0.0-1.0.0d-1.mga1.i586 libopenssl1.0.0-1.0.0d-1.mga1.i586 libopenssl-devel-1.0.0d-1.mga1.i586 openssl-1.0.0d-1.mga1.i58
(In reply to comment #18) > Ouch. The current fix causes named to fail to start in beta 2 prerelease, > as it's using an absolute path to /var/lib/named/usr/lib/ as the destintation > for the copy of libgost.so. I'll look into what's required to fix this. The "current fix" isn't the named init file in the package, but the one that you patched locally? just to get things straight.
As the bind-utils appears to have triggered the service named (re)start, before the bind update was actually installed, it would have picked up what was in the filesystem before the bind update was installed. In this case, I was updating sdb1, which was originally a copy of Mandriva 2010.2+backports, that had been updated using Mageia alpha2. When I installed beta 1, I mistakenly updated my main Mandriva install on sda14, which is where I had been working on my previous changes to the named init script. With bata 2, I upgraded sdb1, which at that point would have had a copy made from sda14 several days ago. As the bind install, just after the failed start, did not have a failed start after it, and it starts ok on the reboot, should I just ignore this message in the install.log? Having named started during the install seems to me to be a bit premature, so having it fail to start should be ok. The failed start of the service does not cause the urpmi transaction to fail.
CC: (none) => cjw
Bumping to release_critical, should be fixed before release..
Priority: High => release_blocker
Created attachment 303 [details] Patch to fix named startup script After a clean install of beta 2, named is still failing to start. The attached patch fixes that issue.
Patch has been applied in bind-9.8.0-3. Can you please tests and check it's now solved. If so, please close that bug
CC: (none) => ennael1
AFAIK comment #7 still applies. Someone just needs to decide how to solve it. Here's my fix that: a) looks complicated ): b) works in any multiarch situation c) only copies the correct module d) uses a single rpm query It creates a list arch1 file1 file2 ... arch2 file1 file2 ... etc. and then searches for the correct arch + libgost.so [ in specfile, use sed to replace @BUILD_ARCH@ with %{_build_arch} ] [ ideally, we should use a list of compat archs ] # libgost.so needs to be in the chroot, so copy it there # first we need to find the lib for the right architecture BUILD_ARCH=@BUILD_ARCH@ TABLE=$(rpm -ql --qf '%{ARCH}\n' --whatprovides openssl-engines) ARCH_FOUND=0 for i in $TABLE; do if [ $i = $BUILD_ARCH ]; then ARCH_FOUND=1; else if [ $ARCH_FOUND = 1 ]; then if [ ${i%/libgost.so} != $i ]; then LIBGOST=$i; break; fi fi fi done if [ -n "$LIBGOST" ]; then # copy everytime as we need to make sure everything is in sync CHROOT_LIBGOST=/var/lib/named/$LIBGOST mkdir -p "${CHROOT_LIBGOST%[/]*}" cp -p $LIBGOST $CHROOT_LIBGOST fi
The fix for the multiple libopenssl-engines packages problem I described in the previous comment is applied in bind 9.8.0-4 . I tested with 64 bit bind and both i586 and x86_64 versions of the openssl modules. Please test on i586. Problems at install time are likely not critical so i did not try to fix those.
9.8.0-4 fails on i586. + BUILD_ARCH=i386 rpm -ql --qf '%{ARCH}\n' --whatprovides openssl-engines)" rpm -ql --qf '%{ARCH}\n' --whatprovides openssl-engines) rpm -ql --qf '%{ARCH}\n' --whatprovides openssl-engines ++ rpm -ql --qf '%{ARCH}\n' --whatprovides openssl-engines + TABLE='i586 /usr/lib/openssl-1.0.0d/engines <snip> /usr/lib/openssl-1.0.0d/engines/libgost.so The build arch has to be i586, not i386. I'll attach a patch.
Created attachment 326 [details] Fix build arch in /etc/rc.d/init.d/named
The problem was in the specfile, where %_build_arch was apparently the wrong choice. I changed it to %_target_cpu which gives a value that matches the package's RPMTAG_ARCH value for x86_64, i586, and ppc. I cannot easily test with arm and mips since I don't have rpm installed on those systems. Fixed in bind 9.8.0-5.
Closing bug as fixed. Thanks.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
*** Bug 1319 has been marked as a duplicate of this bug. ***