Init: Can’t Open Server Certificate File

Every so often I need to update the SSL certificate on a CentOS box running Apache and when I do, lo and behold, I always run into this error:

[error] (13)Permission denied: Init: Can't open server certificate file /path/to/my/super/secret/ssl/cert.crt

The fix isn’t actually difficult or even hard to find, but I wanted to document it here as it’s one of my frequently forgotten linux commands (and just in case this article ever stops being on the front page of the googles).

If all of the configurations, permissions, and ownership is set up correctly for the certificate, but you’re still running into this issue, it’s likely selinux (Security-Enhanced Linux) that’s causing the problem. Try running ‘getenforce’ and if it returns as ‘enforcing’ you can try the following command:

chcon unconfined_u:object_r:httpd_config_t:s0 /path/to/my/super/secret/ssl/cert.crt

This will let the httpd daemon read the certificate file and allow Apache to start up as expected.

Pandora Can’t Find Music

Have you ever been listening to Pandora on your Android phone or tablet and suddenly it can’t find any music to play? I should have grabbed a screenshot when I first saw it, but the sudden music withdrawal hit and I wasn’t thinking clearly. Anyway, you’ll see an error with a message like “We’re sorry, but we can’t find any more music to play on your station right now. Try switching stations.”

And it’ll show up for every station you try, even when creating a new station.

The internets brought back a few suggestions on how to fix this, but almost all of them said the only fix was to reinstall the app. That’s fine if you don’t mind uninstalling and reinstalling — it doesn’t take that much time, though what I tried did the trick and didn’t required the Google Play Store.

First, go into your device’s settings. This is going to be slightly different for each device flavor of Android, but ultimately you’re going to look for the “Applications Manager” section:

Screen Shot 2015-06-22 at 3.40.40 PM

Next, scroll over to your “Installed” or “Downloaded” apps and open up Pandora:

Screen Shot 2015-06-22 at 3.40.58 PM

Last, click on “Clear Cache” and give it a shot. If this doesn’t do the trick, click on “Clear data” on this page as well. Or you can do both off the bat and be done with it:

Screen Shot 2015-06-22 at 3.41.11 PM

Pretty simple! Like I mentioned previously, you could just uninstall and reinstall Pandora if you’d like, but this is another super-quick way to achieve the same results. I don’t use an iPhone for listening to music, so I’ve never come across this in iOS. I imagine the steps should be pretty similar — leave a comment if you’re an Apple fan and have had to do this on one of your devices. Thanks!

WordPress Stuck in Maintenance Mode

I was working on my blog this evening and decided to update a plugin that was just past due. Being me, I got a little impatient and clicked out of the page while the plugin was still updating and it threw me into a persistent maintenance mode! I wasn’t able to get to the site or the dashboard to try to fix the problem.

If you ever find yourself in the same boat, what happens is that WordPress creates a file called .maintenance in your WordPress directory on your web server. Much like so:

Screen Shot 2015-02-10 at 7.57.42 PM

All you need to do is navigate to the home folder for your wordpress site and remove or rename the file wither using sudo or logged in as a user with permissions to delete the file. On a linux server like I’m currently running, it was in the directory for this site in nginx’s default home folder: /var/share/nginx/www/ and so on and so forth. The command ls -la will show all files (including hidden .whatever files) if you want to confirm what you’re deleting/renaming first, then rm .maintenance or mv .maintenance will get the file out of the way so that your site starts showing up like you’re expecting.

If you’re having a hard time finding the file, you can always su to root and use this command: find / -name .maintenance and the system will find the file then report back its location.

Hope it helps!

Cooler Master Elite 431 Plus — Kind of a Letdown

Upgrading an old computer is always fun for me. Who doesn’t like new gear? So when I was tasked to upgrade the case and hard drive for an older lab machine used for testing, I was eager to jump in. I did some digging around and came up with these two items for the upgrade:

An OCZ Arc 100 240GB SATA3 SSD
Cooler Master Elite 431 Plus

I went back and forth for a bit between the 431 Plus and the Cooler Master HAF 912 for quite a while for a couple reasons. First, my personal machine at home is inside a CM HAF 912 and I love it — tons of space for organizing cables and a large aftermarket CPU cooler, sturdy build, and plenty of fan options are the big winners there. Second, the price between the two are almost the same, with the HAF 912 being just a few dollars more. However, I went with the 431 Plus because I had never built a rig in one and wanted to see how well it would work. Also, since it wasn’t my money going into it, I needed to stay on the cheaper side of things even if it was only to save a couple bucks. Unfortunately, it was a poor choice.

Tell em, Grail Knight guy:

More on the unboxing and install woes after the bump. Click to read more!

Continue reading “Cooler Master Elite 431 Plus — Kind of a Letdown”

mysql-bin.index not found (Errcode: 13)

I ran into an issue last weekend when running my usual upgrade check. Running sudo apt-get update && sudo apt-get upgrade came back saying that mysql-server and mysql-server-5.5 needed to be upgraded and who am I to say no?

My Raspberry Pi started crunching through the upgrade and I went about my usual mid-upgrade routine of checking twitter and the facebooks, but when I came back to it I saw that the upgrade had come to a screeching halt:

Setting up mysql-server-5.5 (5.5.41-0+wheezy1) ...
[ ok ] Stopping MySQL database server: mysqld.
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.5 (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
mysql-server depends on mysql-server-5.5; however:
Package mysql-server-5.5 is not configured yet.

dpkg: error processing mysql-server (--configure):
dependency problems - leaving unconfigured
Setting up mysql-client (5.5.41-0+wheezy1) ...
Errors were encountered while processing:

E: Sub-process /usr/bin/dpkg returned an error code (1)

Ruh roh, right?! Trying to start MySQL back up manually would fail over and over, so I tried just about every variation of installing/reinstalling/purging-then-installing MySQL and each time I’d run into something like:

/usr/sbin/mysqld: File './mysql-bin.000027' not found (Errcode: 13)
150124  9:04:59 [ERROR] Failed to open log (file './mysql-bin.000027', errno 13)
150124  9:04:59 [ERROR] Could not open log file
150124  9:04:59 [ERROR] Can't init tc log
150124  9:04:59 [ERROR] Aborting

150124  9:04:59  InnoDB: Starting shutdown...
150124  9:05:00  InnoDB: Shutdown completed; log sequence number 8235374
150124  9:05:00 [Note] /usr/sbin/mysqld: Shutdown complete

[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!


Setting up mysql-server-5.5 (5.5.41-0+wheezy1) ...
[ ok ] Stopping MySQL database server: mysqld.
/usr/sbin/mysqld: File './mysql-bin.index' not found (Errcode: 13)
150124  9:13:47 [ERROR] Aborting

150124  9:13:47 [Note] /usr/sbin/mysqld: Shutdown complete

[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!

So, the “not found” files piqued my interest. Looking at /var/lib/mysql, I found these files (amongst some others):

-rw-rw----  1 mysql mysql    25993 Jan 24 08:52 mysql-bin.000021
-rw-rw----  1 mysql mysql  1074198 Jan 24 08:52 mysql-bin.000022
-rw-rw----  1 mysql root     25993 Jan 24 08:56 mysql-bin.000023
-rw-rw----  1 mysql root     25993 Jan 24 09:02 mysql-bin.000024
-rw-rw----  1 mysql root   1074198 Jan 24 09:03 mysql-bin.000025
-rw-rw----  1 root  root     25993 Jan 24 09:04 mysql-bin.000026
-rw-rw----  1 root  root   1074198 Jan 24 09:04 mysql-bin.000027
-rw-rw----  1 mysql mysql      475 Jan 24 09:04 mysql-bin.index
-rw-------  1 mysql mysql        6 Jan 13 14:00 mysql_upgrade_info
drwx------  2 root  root      4096 Jan 24 09:04 performance_schema

The first thing that caught my eye was the difference of ownership across the mysql-bin.* files. I concluded that the files weren’t being found because the ownership was causing issues, so I chown’d the files back to mysql:mysql and MySQL started up as expected. However, follow-on attempts to upgrade mysql-server started this whole process over again.

I posted a question on the Raspbery Pi forums to see if anyone had seen anything like this before ( and was directed to look at my my.cnf file regarding the basedir and datadir. While looking there, I noticed that neither parameters existed in my my.cnf file. Now, I had copied my my.cnf file from the my.cnf examples that are provided when you install MySQL, so I was surprised to see that they were missing. I compared it to the vanilla my.cnf file and found that not only were basedir and datadir missing, it was also missing the user parameter. I dropped the vanilla my.cnf back in place and was able to upgrade without an issue. It’s speculation, but I’m guessing that because the mysql user wasn’t specified in the my.cnf file, the system was creating the new .bin files as root which halted the upgrade process.

Anyway, I thought I should document this just in case anyone stumbles on this same situation down the road.