To check if a CVE has been patched on a RHEL based system perform the following.

First, get the real package name:

rpm -qa | grep <package>

Now check the package change log for CVE patches:

rpm -q <package> --changelog | grep <cve number>

Sometimes you will see lines like this in the Apache error log:

[notice] child pid 5 exit signal Segmentation fault (11)

This means for some reason the child thread/fork has segfaulted when trying to process the request.

By default apache won’t give you any more info than this. To get core dumps you will need to do the following.

1. Enable system coredumps for the apache user. In /etc/security/limits.conf ensure the following line is present:

apache soft core 10000

1. Tell apache what directory to put dumps into, do this with the following config line:

CoreDumpDirectory /var/apache/coredumps/

1. Ensure the dump directory is writeable by the apache user (if not then you will get no dumps!).

2. Restart apache and wait for a segfault.

Now if you look in your specified CoreDumpDirectory you should see a number of .dump files.

To debug these you will need to understand system calls and have some general debugging experience when it comes to executables.

An example of how to load up the core dump into a debugger (gdb) is as follows:

gdb /usr/sbin/httpd -c /var/apache/coredumps/somefile.dump

Some genreal tips on how to use a debugger for looking at Apache dumps can be found on their website.

Sometimes you need to know the Apache PID when trying to track down segfaults or CPU usage issues.

There is a very simple way to do this by altering your LogFormat, a command format to have is the CLF (common log format):

%h %l %u %t \"%r\" %>s %b

To enable logging the pid just add the %P var like so:

[%P] %h %l %u %t \"%r\" %>s %b

I had a slightly strange issue this morning with PHP and curl (multi_curl actually but it affects curl too). ClueBot NG was returning API errors all over the place, after a quick look though the main code it appeared that the data from the toolserver API wasn’t getting returned properly. Trying to get the headers from the curl handler went no where, everything was returning back empty or NULL.

After testing the code on a different machine and it working fine I started to look at the URL that was being requested, a quick curl (on the command line) found that it hung. Off I went to look at its DNS entries and realised the tunnel on the server had dropped again (really need to get the server admin to move the tunnel somewhere more stable).

Now you would expect that if you cannot get traffic out on IPv6 that CURL would fall back to IPv4, it appears that it doesn’t! What actually happens is it sits trying IPv6 until the connection timeout is hit then, showing no warning/error returns back NULL data. Yay for CURL!

A quick fix (until the datacenter gets native IPv6) is to force CURL to use ipv4 when resolving domain names. Now anyone that has looked at developing things in C with CURL will know this is really easy, however the PHP bindings don’t even document that you can set the IPRESOLVE option, but you can! Yay for php…

The option is CURLOPT_IPRESOLVE and the value is either CURL_IPRESOLVE_V4, CURL_IPRESOLVE_V6 or CURL_IPRESOLVE_WHATEVER. To force IPv4 just use:

curl_setopt( $ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );

My test script in a broken state is:

<?php
 $ch = curl_init();
 curl_setopt( $ch, CURLOPT_USERAGENT, 'ClueBot/2.0' );
 if( isset( $proxyhost ) and isset( $proxyport ) and $proxyport != null and $proxyhost != null ) {
 curl_setopt( $ch, CURLOPT_PROXYTYPE, isset( $proxytype ) ? $proxytype : CURLPROXY_HTTP );
 curl_setopt( $ch, CURLOPT_PROXY, $proxyhost );
 curl_setopt( $ch, CURLOPT_PROXYPORT, $proxyport );
 }
 curl_setopt( $ch, CURLOPT_URL, "http://toolserver.org/~cobi/cb.php?user=124.124.10.106&ns=0&title=Sayala&timestamp=1313668350" );
 curl_setopt( $ch, CURLOPT_FOLLOWLOCATION, 1 );
 curl_setopt( $ch, CURLOPT_MAXREDIRS, 10 );
 curl_setopt( $ch, CURLOPT_HEADER, 1 );
 curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
 curl_setopt( $ch, CURLOPT_TIMEOUT, 120 );
 curl_setopt( $ch, CURLOPT_CONNECTTIMEOUT, 10 );
 curl_setopt( $ch, CURLOPT_HTTPGET, 1 );
 curl_setopt( $ch, CURLOPT_ENCODING, '' );

var_dump( curl_exec( $ch ) );
?>

And the test script in the fixed status is:

<?php
 $ch = curl_init();
 curl_setopt( $ch, CURLOPT_USERAGENT, 'ClueBot/2.0' );
 if( isset( $proxyhost ) and isset( $proxyport ) and $proxyport != null and $proxyhost != null ) {
 curl_setopt( $ch, CURLOPT_PROXYTYPE, isset( $proxytype ) ? $proxytype : CURLPROXY_HTTP );
 curl_setopt( $ch, CURLOPT_PROXY, $proxyhost );
 curl_setopt( $ch, CURLOPT_PROXYPORT, $proxyport );
 }
 curl_setopt( $ch, CURLOPT_URL, "http://toolserver.org/~cobi/cb.php?user=124.124.10.106&ns=0&title=Sayala&timestamp=1313668350" );
 curl_setopt( $ch, CURLOPT_FOLLOWLOCATION, 1 );
 curl_setopt( $ch, CURLOPT_MAXREDIRS, 10 );
 curl_setopt( $ch, CURLOPT_HEADER, 1 );
 curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
 curl_setopt( $ch, CURLOPT_TIMEOUT, 120 );
 curl_setopt( $ch, CURLOPT_CONNECTTIMEOUT, 10 );
 curl_setopt( $ch, CURLOPT_HTTPGET, 1 );
 curl_setopt( $ch, CURLOPT_ENCODING, '' );
 curl_setopt( $ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );

var_dump( curl_exec( $ch ) );
?>

Simples!

In my kickstart files I “cheat” on disk sizes and let them grow automatically rather than figuring out the size, setting it then having to manually expand it later.

To do this I use the following in my kickstarts:

%include /tmp/partinfo

%pre
# Get disks
set $(list-harddrives)
let numd=$#/2
disk1=$1
disk2=$3

# Build partinfo file
cat > /tmp/partinfo <part /boot --fstype ext4 --size=512 --ondisk=$disk1
part pv.2 --size=0 --grow --ondisk=$disk1

volgroup VolGroup00 --pesize=32768 pv.2
logvol / --fstype ext4 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=512 --grow --maxsize=1024
EOF

Basically in the pre section of the kickstart I write out the disk partition stuff using some bash/list-harddrives into a file. This is then included in the main body of the kickstart (due to the pre code being run before the main stuff this works fine).

Now the issue I had with Centos6 was an error getting throw by Anaconda “Partition requires a size specification”.

It looks like this is caused by a change in the kickstart script which checks if the size is set (pd.size = None was changed to not self.size).

The simplest way to fix this is just to make –size=1 (lets face it, your minimum partition size isn’t going to be smaller 1mb!).

Apart from some other little things like removing the editors, text-internet etc groups out of the kickstart file and downloading the new vmlinuz/initrd.img files everything worked fine first time.

Now to wait for the mirror to finish syncing so I can get some fast installs going (=