Mysql – Install wordpress using amazon RDS

amazon-rdsamazon-web-servicesMySQLWordpress

Now this is weird!

I am trying to install a WordPress website on a Amazon EC2 server with Ubuntu 12.04 LTS and [amazon RDS][1] database service.

I have installed apache and wphp and ran the required tests (again and again actually) if something is wrong there.

But when I go to the root of WordPress folder (also the root of the server i .e. folder "www") I get this error

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

Yes this is pretty obvious because I don't want to install MySQL on my system.

The funny thing is I tried searching it online and there are examples of tons of WordPress websites running on RDS and I couldnt find a single page with this issue.

Any solutions/suggestions?

Is is that i'll have to install MySQL on my system even though I don't want to use it . Doesn't it skip the whole point?

Thanks in advance

Edit : I didn't even reach create configuration file page. The index.php file pretty much showed this error and nothing else.

here is the tutorial i was following : http://www.slideshare.net/mrjain/installing-wordpress-on-aws
check out slide 16 it never mentions installing mysql

Best Answer

You don't need to install MySQL server, but you do need the client-side stuff for PHP.

apt-get install php5-mysql should do the trick.

Related Solutions

Ubuntu – EC2 Ubuntu with WordPress can’t connect to RDS

Check that you can connect to the instance with the command line. See instructions here:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html

Maybe you have a problem with the credentials or with the network. Once you find the root cause it is easier to solve it.

Mysql – First attempt to migrate EC2 MySQL to Amazon RDS no going well – SUPER privileges

You do likely need log_bin_trust_function_creators = 1 on RDS but that isn't the issue, here.

You can specify a DEFINER value other than your own account only if you have the SUPER privilege.

^{— http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html}

When a stored program (proc, function, event, or trigger) is running, everything it does has the permissions of the user who defined it, or of the user explicitly stated with a DEFINER declaration. This allows, among other things, for stored programs to permit other users to do things to data they don't directly have permission to manipulate, as long as they have permission to use the stored program itself.

It would be a serious vulnerability, then, if a non-SUPER user could create a procedure with an arbitrary definer, because the user could escalate his or her privileges at will.

This is also true of views, of course, when the definer security context is used, as in the example you posted.

One of the biggest complaints I have with RDS is that you can't have SUPER... and now it can be one of yours, too :) because that fact is the cause of the problem you are having.

Of course, if I were running a managed MySQL service, I wouldn't give anybody SUPER, either, so their security model makes sense, even if it is sometimes unwieldy.

If all of your objects have the same definer, a workaround would be to restore the dump using that account instead of the one you're using now, but that seems unlikely.

Deleting just the line with the DEFINER declaration should make the dumpfile work in cases where it appears on a line by itself, or you could use sed or perl to modify the file... an idea that I already know you're not fond of, but it really is a nice thing about MySQL that such hackery is quite legitimate, and not really all that far afield from the kinds of things I have to do as a DBA even in a non-RDS envirnoment.

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql

...possibly not the answer you hoped for, but you could run that against your dumpfile and should end up with a slightly more usable file.

Related Topic