As mentioned in an earlier post, I have been actively working on melikedrinks.com, as such I am constantly adding new drink inventory which means I have to generate a new sitemap on a fairly regular basis. Today I generated a new sitemap and tried to submit it via Google Webmaster Tools, but upon submission I received a 403 (forbidden error). At first I couldn’t figure out why this was happening, the permission on the sitemap file (and associated dirs) was 664 (775), so apache definitely had access to the file. So I check the apache error log and noticed the; Permission denied: file permissions deny server access: entry. So after a few minutes of rechecking the file permissions, I remembered that I have SELinux enabled and enforcing, so I do a `ls -lZa` and sure enough, the permission type was user_tmp_t when it should have been httpd_sys_rw_content_t. Then I had the aha moment, when the sitemap file is generated it is dropped in the /tmp dir, so I just did a copy from /tmp to the production path, but forgot to change the permission type.
Heres the command I ran to change the permission type:
$ -> sudo chcon -R -v -t httpd_sys_rw_content_t sitemap.xml
Now when I do `ls -lZa`, the permission type is correctly set to httpd_sys_rw_content_t, and when I resubmitted the sitemap to Google Webmaster Tools, everything worked as expected.
Had a weird issue where my demo server was throwing 500 error when a request was made. I spent time digging into my nginx configs to see if there were a issue, once I was able to determine it was not nginx, I started tearing apart my apache vhosts to see what the issue was. It was tough to track down because neither nginx nor apache error logs were logging anything out of the ordinary.
I came across a serverfault.com post where someone suggested using the following command after making a request:
find /var/log/ -mmin -1
This command will return any files whose modtimes are less than a minute old. When I issued the command I noticed that my PHP error log was listed, so I tailed the error log and issued another request. Sure enough, an exception was being thrown because my bootstrap file for my core library could not make a needed database connection.
Now that I was aware that an exception was causing my apache server to issue a 500 response, I still couldn’t figure out why it wasn’t outputting the exception message. I started digging around my php.ini file and found that I had set `display_errors=off`. With display_errors set to off, apache will issue a 500 response rather than output the exception, which is a good thing b/c the exception message had some database connection information.
So if you are setting up an apache/php server and it’s throwing a 500 response, check the php error log too, you may have the same setup.
Also, I read that this type of behavior will occur if the php.ini file could not be read.
Came across an issue where I was getting “SQLSTATE[HY000]  php_network_getaddresses: getaddrinfo failed: Name or service not known” errors when one of my applications was trying to establish a connection to a MySQL db.
In my /etc/resolv.conf file I didn’t have the domain with the host DNS information, so I added it. At this point I was able to ping the host via command line, but was still getting the errors. After some Googling I came across http://albertech.net/2011/05/fix-php_network_getaddresses-getaddrinfo-failed-name-or-service-not-known/ where the author indicated that if you can ping the host via command line but are still getting the errors, try restarting Apache. So I followed his suggestion, restarted Apache, and it worked like a charm.
A buddy at work brought this too my attention and it proved to be an interesting read… Check it out when you get a chance.