Due to PCI compliance requirements I had to custom compile the new version of apache (httpd) web server. I figured that I'd try building an RPM for Fedora 9 httpd-2.2.13 during the process so I could apply it across multiple systems.

Links to the RPM's and technical details of how I built the RPM's can be found at the following location.

DISCLAIMER : Use these RPM's at your own risk. They are my first attempt ever at building.

http://www.techdruid.com/index.php/c...m-for-fedora-9

Good Luck.

Since you mention PCI compliance, do they know that F9 is no longer supported? Fedora versions only last 13 mths.
You should think about moving to Centos 5.3 (free version of RHEL), which is updated for 7 yrs.
http://www.redhat.com/security/updates/errata/

That does not instill much confidence. However that could be mitigated by also offering (patches if any and) the .src.rpms for download you get when you run 'rpmbuild -bs httpd.spec'. That way people can inspect and rebuild their own version. (I'll skip the part of GPG-signing packages) Without freely downloadable .src.rpm I strongly suggest people do not install your packages and instead look for packages in official or semi-official but nonetheless trustworthy sources.

CentOS does not release updates that certain scan vendors deem necessary for compliance. At least not in a timely manner. I've had scan vendors tell me I needed a later version of something, but the CentOS distribution would not provide an update as they didn't see the upgrade as critical.

This is the reason I switched to Fedora from CentOS.

But alas. Either way it seems that I have to build custom rpm's to appease the scan vendors.

I didn't expect to instill much confidence. It was as much a learning experience for me, as it was to offer assistance to others.

Also, I'm definitely looking for feedback so that I can improve what I produce in the future. So I appreciate the feedback.

Thanks
Richard

You do know that RHEL (& therefore Centos) don't keep upgrading the main pkg version nums, they just backport the necessary updates and adjust the release num instead eg

pkg-version-release.arch.rpm

where 'release num' indicates what backports have been done, see associated changelogs.
There's a nice breakdown here http://www.linuxtopia.org/online_boo...mpressing.html

Apologies if you already knew this

While I do understand the basic idea behind package an release numbers, I was not aware that they were not releasing new package numbers in conjunction with the software package. Thank you for clarifying this.

Can you tell me where on Red Hat's website I can find the details on what updates are included in their latest release of httpd-2.2.3-22.el5.centos.2 for example? Or perhaps on the CentOS website?

One concern here is that Apache released httpd 2.2.13 on 08-Aug-2009. The most recent release from Red Hat of 2.2.3-22.el5.centos.2 was on 14-Jul-2009. So I'm guessing they don't have the updates made on the 8th of August from Apache. My scan vendor is telling me this update is necessary.

Also. The sad part here is that there is no way for a PCI scan vendor to know if you have properly patched your system.

If I telnet into port 80 on a fully updated Centos 5.3 (Final) system, the version reported is "Server: Apache/2.2.3 (Red Hat)".

Now of course I have the option to go in and tell my vendor that I'm compliant and its a false positive. However, what happens if this disables the scan vendor from alerting when there's another update?

It seems to me that there is a certain amount of rooms for allowing a needed update to slip through the cracks. A system may go unpatched/unnoticed because the scan vendor is not alerting me.

Thanks again

Clearly I acted too quickly in building these RPM's for Fedora.

After digging deeper into the problem with httpd release, I see that the actual problem is with the APR library. So, simply updating the version and banner of httpd did not actually resolve the problem with the APR library.

Red Hat in fact did release a patch to apr & apr-util on August 11th 2009. So I was incorrect to believe that they hadn't addressed this bug.

http://lwn.net/Alerts/346716/

Well, at least I've learned a lot about building RPM's. My latest builds for PHP rpm's resulted in me going back to build glibc rpm's as dependencies. Whew, what fun.

I'm currently building (for learning/experience) glibc rpms. However, I noticed that there are many more binary RPM's and less source RPM's. Can you tell me if this is normal?

When I do an rpmbuild -bb -clean rpmbuild/SPECS/glibc.spec
I get the following RPMs

However, when I do an rmpbuild -bs rpmbuild/SPECS/glibc.spec
I only get the following source RPM

Does the source rpm include the details of all the binaries listed above?

Thanks in Advance
Richard