Setting the Initial Root Password for MySQL on CentOS

I was setting up a new CentOS server tonight and installed MySQL via yum. If you’re familiar with installing MySQL via apt-get on Debian-based systems, you’ll know that during the install it prompts you to set the MySQL root password. Not so on CentOS.

When I’ve installed MySQL on CentOS in the past, I could have sworn the default root password was blank, and that right after the installation is complete you set it like so:

mysqladmin -u root password NEW_PASSWORD

Either my memory is foggy, or something’s changed with how this is done. No matter what I tried I kept getting “access denied” messages from MySQL and of course since I never set a root password, I have no idea what it wants from me.

Luckily there’s a solution, at least one that worked for me, though I still feel like I may be missing something so although this worked, I’m happy to be told there’s a simpler way.

First, make sure no MySQL processes are running:

killall -9 mysqld

Next, start MySQL in safe mode and have it skip grant tables:

/usr/bin/mysqld_safe --skip-grant-tables &

This will let you get in as root without a password. After the process starts, log in and use the mysql database:

mysql -u root mysql

Next, set the root user password:

update user set password=PASSWORD('new_password') where user='root';

It should say 2 or 3 rows affected. Finally, flush the privileges:

flush privileges;

Quit MySQL, and then you’ll want to kill the process you started with mysqld_safe and start the regular MySQL process. You can either bring the process you started earlier by typing ‘fg’, hitting enter, and then hitting ctrl-C to kill it, or you can do a ps -wef | grep mysqld to find the process ID and kill it as per usual.

Finally, restart MySQL and test your new root password:

/etc/init.d/mysqld start
mysql -u root -p

When it prompts you for the password, enter the password you set earlier and you should be logged in successfully.

Note this process also works if you’ve forgotten the MySQL root password.

Hope that save someone else a bit of time, and as I said earlier, I’ll be very happy if someone has a better explanation of why I wasn’t able to log in without a password on a fresh MySQL install on CentOS.

Apache Error “Document Root Doesn’t Exist” on Red Hat Enterprise LinuxWhen the Document Root DOES Exist

I upgraded one of our Red Hat Enterprise Linux VMs to Tomcat 7.0.4 tonight, did a bit of Apache reconfiguration, and when I restarted Apache I got a “document root doesn’t exist” error even though in fact the document root does exist. (Trust me Apache, it’s there.)

I double-checked the owners and permissions of all the directories in question and everything was identical to how things are set on another RHEL VM in this cluster on which I haven’t upgraded Tomcat and done the reconfiguration yet. I was at a bit of a loss, so I googled around a bit and the prevailing sentiment seemed to be this was related to either A) a config file copied from a Windows box and the line breaks were throwing things off (wasn’t applicable in my case), or B) the fact that SELinux was enabled.

If you’ve been around the Red Hat flavors of Linux long enough you’ll remember that SELinux used to be absolutely horrible. For years the very first thing you had to do on Red Hat and Fedora to get anything working at all was turn SELinux off, and for a long time I believe it was even Red Hat’s recommendation under their breath to just shut it off. It’s gotten better over the years, and honestly stays out of the way to the point where I’d almost forgotten about it.

Since I didn’t have anything else to try, however, I went into /etc/sysconfig/selinux and changed SELINUX=enforcing to SELINUX=disabled, restarted the server, and voila the complaining from Apache went away.

What I still don’t get is A) why this isn’t occurring on my other RHEL box with the same setup, and B) why it just started happening now. The only potential weirdness here is that my document root is a symlink, but again, it’s been that way since I setup up these boxes originally and it hasn’t been an issue.

So if you run into this same problem the fix (at least until I have more information about why it’s happening) is to disable SELinux, but if anyone has more ideas about why this might be happening I’d love to hear them.