All,
Please excuse any ignorance in this e-mail as I am not a RH/CentOS/Fedora user and may blunder my way through the correct terminology for my request.
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing.
libc.so.6 reports: GNU C Library stable release version 2.12, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-11). Compiled on a Linux 2.6.32 system on 2015-01-27. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html.
But, when looking through the source code for this version on the CentOS servers I only see: http://vault.centos.org/6.6/updates/Source/SPackages/ [ ] glibc-2.12-1.149.el6_6.4.src.rpm 07-Jan-2015 22:45 15M [ ] glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M
Please point me to the correct source tarball, and all required patches so that I can reconstruct my loaded version of GlibC. A yum command is also acceptable.
Thanks, Andy
On Fri, Feb 27, 2015 at 06:49:23PM +0000, ANDY KENNEDY wrote:
But, when looking through the source code for this version on the CentOS servers I only see: http://vault.centos.org/6.6/updates/Source/SPackages/ [ ] glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M
This is the latest version for a fully patched CentOS 6 system.
% rpm -q glibc glibc-2.12-1.149.el6_6.5.x86_64 glibc-2.12-1.149.el6_6.5.i686
On 27 February 2015 at 13:49, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
All,
Please excuse any ignorance in this e-mail as I am not a RH/CentOS/Fedora user and may blunder my way through the correct terminology for my request.
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing.
libc.so.6 reports: GNU C Library stable release version 2.12, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-11). Compiled on a Linux 2.6.32 system on 2015-01-27. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html.
But, when looking through the source code for this version on the CentOS servers I only see: http://vault.centos.org/6.6/updates/Source/SPackages/ [ ] glibc-2.12-1.149.el6_6.4.src.rpm 07-Jan-2015 22:45 15M [ ] glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M
Please point me to the correct source tarball, and all required patches so that I can reconstruct my loaded version of GlibC. A yum command is also acceptable.
Thanks, Andy _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Andy,
You can use yumdownloader to download the source
$ yumdownloader --source glibc
$ rpm -ivh <package.src.rpm> This will give you all the relevant files required for building the package.
On Fri, 27 Feb 2015 18:49:23 +0000 ANDY KENNEDY wrote:
Compiled on a Linux 2.6.32 system on 2015-01-27.
glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M
The date on that rpm matches the compiled on date that you posted.
On 02/27/2015 12:49 PM, ANDY KENNEDY wrote:
All,
Please excuse any ignorance in this e-mail as I am not a RH/CentOS/Fedora user and may blunder my way through the correct terminology for my request.
No problem.
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
Do you plan on shipping this updated glibc as part of the product, or is this simply for testing? If you plan to distribute/ship an updated glibc, that's probably going to raise a few eyebrows and anger a few sysadmins.
My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing.
libc.so.6 reports: GNU C Library stable release version 2.12, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-11). Compiled on a Linux 2.6.32 system on 2015-01-27. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html.
But, when looking through the source code for this version on the CentOS servers I only see: http://vault.centos.org/6.6/updates/Source/SPackages/ [ ] glibc-2.12-1.149.el6_6.4.src.rpm 07-Jan-2015 22:45 15M [ ] glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M
Please point me to the correct source tarball, and all required patches so that I can reconstruct my loaded version of GlibC. A yum command is also acceptable.
Those src.rpms contain the source and the patches. You may want to read over http://wiki.centos.org/HowTos/RebuildSRPM for info.
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
Do you plan on shipping this updated glibc as part of the product, or is this simply for testing? If you plan to distribute/ship an updated glibc, that's probably going to raise a few eyebrows and anger a few sysadmins.
No release. Only testing.
My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing.
libc.so.6 reports: GNU C Library stable release version 2.12, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-11). Compiled on a Linux 2.6.32 system on 2015-01-27. Available extensions: The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B RT using linux kernel aio libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html.
But, when looking through the source code for this version on the CentOS servers I only see: http://vault.centos.org/6.6/updates/Source/SPackages/ [ ] glibc-2.12-1.149.el6_6.4.src.rpm 07-Jan-2015 22:45 15M [ ] glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M
Please point me to the correct source tarball, and all required patches so that I can reconstruct my loaded version of GlibC. A yum command is also acceptable.
Those src.rpms contain the source and the patches. You may want to read over http://wiki.centos.org/HowTos/RebuildSRPM for info.
Great! Thank you Jim Perrin, Frank Cox, Earl A Ramirez and Stphen Harris for your responses.
Andy
On 03/02/2015 10:38 AM, ANDY KENNEDY wrote:
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
Do you plan on shipping this updated glibc as part of the product, or is this simply for testing? If you plan to distribute/ship an updated glibc, that's probably going to raise a few eyebrows and anger a few sysadmins.
No release. Only testing.
Also, please be advised that rebuilding a package and then trying to compare it to something else built earlier is likely not going to work unless you can duplicate the exact set of packages that are installed in the build root at the time of the build. Even then, with documentation generation, you STILL might not get an exact, bit for bit, match when building later.
It is almost impossible to duplicate a closed and staged build system for a give date unless you are trying very hard to do so.
My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing.
^^ That would likely be impossible to accomplish. See my comments above.
<snip>
Thanks, Johnny Hughes
On 03/02/2015 11:00 AM, Johnny Hughes wrote:
On 03/02/2015 10:38 AM, ANDY KENNEDY wrote:
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
Do you plan on shipping this updated glibc as part of the product, or is this simply for testing? If you plan to distribute/ship an updated glibc, that's probably going to raise a few eyebrows and anger a few sysadmins.
No release. Only testing.
Also, please be advised that rebuilding a package and then trying to compare it to something else built earlier is likely not going to work unless you can duplicate the exact set of packages that are installed in the build root at the time of the build. Even then, with documentation generation, you STILL might not get an exact, bit for bit, match when building later.
It is almost impossible to duplicate a closed and staged build system for a give date unless you are trying very hard to do so.
My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing.
^^ That would likely be impossible to accomplish. See my comments above.
<snip>
The list of packages that were in the "mock build root" for our build of the glibc-2.12-1.149.el6_6.5.x86_64.src.rpm is here:
To get close to an exact match, you need to use mock and use the packages listed above (and only those versions) if you are trying to get a build that matches what we built.
<snip>
The list of packages that were in the "mock build root" for our build of the glibc-2.12-1.149.el6_6.5.x86_64.src.rpm is here:
To get close to an exact match, you need to use mock and use the packages listed above (and only those versions) if you are trying to get a build that matches what we built.
Okay, thanks. I really don't need _EXACT_ match, but close. Again, my aim is to equip GlibC with some logging facilities IF anyone is using the gethostbyname(). Given the help from this list, I was able to rebuild GlibC for CentOS and am testing my stuff now.
I appreciate your help on this matter. Not knowing where the knobs are was the hardest part. I have just about completed my testing.
Again, thanks for the help!
Andy
Okay, thanks. I really don't need _EXACT_ match, but close. Again, my aim is to equip GlibC with some logging facilities IF anyone is using the gethostbyname(). Given the help from this list, I was able to rebuild GlibC for CentOS and am testing my stuff now.
I appreciate your help on this matter. Not knowing where the knobs are was the hardest part. I have just about completed my testing.
Again, thanks for the help!
Andy
Ughh!! I just realized that the app that I'm testing has parts that are linked against 32-Bit libraries. I have to test that as well. Ouch!
This leads to the question:
How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I've done some looking around on the web and I have found something about:
setarch i686 mock -r <something> ... rebuild <my.rpm>
Not being able to find the "mock" package for CentOS, I thought maybe:
setarch i686 rpmbuild -ba glibc.spec
would work. This ended with an error:
enable-bind-now --with-tls --with-__thread --build i686-redhat-linux --host i686-redhat-linux --enable-multi-arch --enable-systemtap --disable-profile --enable-experimental-malloc --enable-nss-crypt checking build system type... i686-redhat-linux-gnu checking host system type... i686-redhat-linux-gnu checking for i686-redhat-linux-gcc... gcc checking for suffix of object files... configure: error: in `/home/akennedy/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-i686-linuxnptl': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.2d2i9G (%build)
I have also looked through the glibc.spec file for something that would make me think that I could change the target variant.
"rpmbuild --target=i686 -ba glibc.spec" gives the same output as the setarch i686 above.
Again, any help on this would be greatly appreciated.
Thanks, Andy
On Tue, Mar 10, 2015 at 5:47 PM, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I've done some looking around on the web and I have found something about:
setarch i686 mock -r <something> ... rebuild <my.rpm>
Not being able to find the "mock" package for CentOS, I thought maybe:
??? Mock is in EPEL.
setarch i686 rpmbuild -ba glibc.spec
If you repackaged the source rpm you should be able to: mock -r epel-6-i386 --rebuild glibc-xxx.srpm
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Tuesday, March 10, 2015 6:02 PM To: CentOS mailing list Subject: Re: [CentOS] Glibc sources?
On Tue, Mar 10, 2015 at 5:47 PM, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I've done some looking around on the web and I have found something about:
setarch i686 mock -r <something> ... rebuild <my.rpm>
Not being able to find the "mock" package for CentOS, I thought maybe:
??? Mock is in EPEL.
De-ignorant me please: How does one discern the package name "EPEL" from mock?
I tried everything I could think of (keeping in mind that I've been a Slackware fan since 1993 or so) from "yum provides */mock" to various other commands that were as equally useless to me. Google wasn't even my friend -- though I did find the Fedora mock developer's page -- but I read something else that says that one cannot use Fedora packages within CentOS without resolving too many dependencies.
Just a little light will do. . . I've felt my way around in the CentOS dark so far without too many cuts.
Thanks, Andy
setarch i686 rpmbuild -ba glibc.spec
If you repackaged the source rpm you should be able to: mock -r epel-6-i386 --rebuild glibc-xxx.srpm
-- Les Mikesell lesmikesell@gmail.com
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of ANDY KENNEDY Sent: Wednesday, March 11, 2015 1:32 PM To: CentOS mailing list Subject: Re: [CentOS] Glibc sources?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Tuesday, March 10, 2015 6:02 PM To: CentOS mailing list Subject: Re: [CentOS] Glibc sources?
On Tue, Mar 10, 2015 at 5:47 PM, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I've done some looking around on the web and I have found something about:
setarch i686 mock -r <something> ... rebuild <my.rpm>
Not being able to find the "mock" package for CentOS, I thought maybe:
??? Mock is in EPEL.
De-ignorant me please: How does one discern the package name "EPEL" from mock?
Oh, never mind. I see this is some "add-on" repo site. Like I said, a little light will do :).
I tried everything I could think of (keeping in mind that I've been a Slackware fan since 1993 or so) from "yum provides */mock" to various other commands that were as equally useless to me. Google wasn't even my friend -- though I did find the Fedora mock developer's page -- but I read something else that says that one cannot use Fedora packages within CentOS without resolving too many dependencies.
Just a little light will do. . . I've felt my way around in the CentOS dark so far without too many cuts.
Thanks, Andy
setarch i686 rpmbuild -ba glibc.spec
If you repackaged the source rpm you should be able to: mock -r epel-6-i386 --rebuild glibc-xxx.srpm
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, Mar 11, 2015 at 1:34 PM, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
De-ignorant me please: How does one discern the package name "EPEL" from mock?
Oh, never mind. I see this is some "add-on" repo site. Like I said, a little light will do :).
It's not just 'some' third party repo - it has stuff pretty much everyone needs and has a policy of not overwriting any core packages so it is generally safe to leave enabled.
yum install http://mirror.cogentco.com/pub/linux/epel/6/i386/epel-release-6-8.noarch.rpm yum install mock
(If you are on Centos 5, you'd have to wget the release rpm and install with rpm).
Hi Andy,
mock is part of EPEL and is almost certainly what you want to use.
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd GitHub: @tartansandal
Suite 1416 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On 11 March 2015 at 09:47, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
Okay, thanks. I really don't need _EXACT_ match, but close. Again, my aim is to equip GlibC with some logging facilities IF anyone is using the gethostbyname(). Given the help from this list, I was able to rebuild GlibC for CentOS and am testing my stuff now.
I appreciate your help on this matter. Not knowing where the knobs are
was
the hardest part. I have just about completed my testing.
Again, thanks for the help!
Andy
Ughh!! I just realized that the app that I'm testing has parts that are linked against 32-Bit libraries. I have to test that as well. Ouch!
This leads to the question:
How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I've done some looking around on the web and I have found something about:
setarch i686 mock -r <something> ... rebuild <my.rpm>
Not being able to find the "mock" package for CentOS, I thought maybe:
setarch i686 rpmbuild -ba glibc.spec
would work. This ended with an error:
enable-bind-now --with-tls --with-__thread --build i686-redhat-linux --host i686-redhat-linux --enable-multi-arch --enable-systemtap --disable-profile --enable-experimental-malloc --enable-nss-crypt checking build system type... i686-redhat-linux-gnu checking host system type... i686-redhat-linux-gnu checking for i686-redhat-linux-gcc... gcc checking for suffix of object files... configure: error: in `/home/akennedy/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-i686-linuxnptl': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.2d2i9G (%build)
I have also looked through the glibc.spec file for something that would make me think that I could change the target variant.
"rpmbuild --target=i686 -ba glibc.spec" gives the same output as the setarch i686 above.
Again, any help on this would be greatly appreciated.
Thanks, Andy _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 28 February 2015 at 05:49, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
I may be way out of line here, haven't had much coffee yet, but I wonder if systemtap could be used to achieve your goals less intrusively?
On 28 February 2015 at 05:49, ANDY KENNEDY ANDY.KENNEDY@adtran.com wrote:
I'm tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.
I may be way out of line here, haven't had much coffee yet, but I wonder if systemtap could be used to achieve your goals less intrusively?
Already knowing how to build GlibC, I think that may take less of my time than attempting to figure out how to use systemtap. But, you better believe that I'll keep that in mind ::throws in toolbox:: for later. This one I need to be as fast as possible on.
Thanks for the info!
Andy
-
ANDY KENNEDY -
Earl A Ramirez -
Frank Cox -
Jim Perrin -
Johnny Hughes -
Kahlil Hodgson -
Les Mikesell -
Stephen Harris