PhpMyAdmin Disable Warning: Your PHP MySQL library version differs from your MySQL server version – This may cause unpredictable behavior

Short answer: http://docs.phpmyadmin.net/en/latest/config.html#cfg_ServerLibraryDifference_DisableWarning

For those who still can’t understand…

Open up your PhpMyAdmin’s config.inc.php file and then add the following line in it…

$cfg['ServerLibraryDifference_DisableWarning'] = true;

Now, log out and then log in to PhpMyAdmin. Do you still see the warning?

Advertisements

IPv4 for APT

Ref: http://unix.stackexchange.com/a/13263/20241

At times, apt may try IPv6 to resolve a domain name. In which case, it may not be desirable and sometimes, it just doesn’t work for that particular server. So, to let apt to use only ipv4 for DNS resolution…

Edit /etc/gai.conf

uncomment the following line…

precedence ::ffff:0:0/96 100

If the above line doesn’t exist, just insert it at the bottom or at the top of the file!

Verify the changes with the command (before and after the changes)…

telnet security.ubuntu.com

UFW error in Debian

UFW, Uncomplicated Firewall, was created for Ubuntu, then ported to other distributions as well, primarily to Debian. So, it’s no wonder, there are some incompatibilities when running UFW under Debian, at times. Those incompatibilities or errors are usually fixed in the stable releases. However, due to the difference between how things work and how we expect things to work, there may be some errors with the default configuration.

In Debian 7, UFW was installed lately. And, in the end of deploying it, the following command was run…

sudo ufw --force enable

Immediately, it provided the following error…

ERROR: problem running ufw-init

Upon digging through the issue, I noticed that IPv6 address wasn’t available in that server and UFW meant to complain about it. So, the solution is to disable IPv6 in UFW, by editing

/etc/default/ufw

and then comment out the line

IPV6=yes

.

Happy firewalling!

Correct Nginx try_files syntax with query params

With WordPress sites and Nginx servers, you may have used one of the following try_files directives…

try_files $uri $uri/ /index.php;
try_files $uri $uri/ /index.php?$args;

Both are incomplete. With the first method, arguments are not passed. With the second method, question mark is present, even when there are no query parameters.

A complete solution is to use the following…

try_files $uri $uri/ /index.php$is_args$args;

$is_args checks, if $args is empty. If empty, the value of $is_args becomes empty. Otherwise “?”. Isn’t that genius!

However, if you have large number of vhosts, then it may be time-consuming to go through every vhost to update this change. Here’s a little one-liner to do the same…

sed -i '/try_files/ s/index.php;/index.php$is_args$args;/' *
sed -i '/try_files/ s/index.php?$args;/index.php$is_args$args;/' *

Postfix Flush Deferred Email Queue

Some people try to test out an application, a site, a contact form and may use an email like hello@test.com that would never be delivered by the local email delivery system and would be in the queue forever, or until it is deleted.

Here’s a trick to delete such emails from postfix. Similar commands may be available with other similar tools too.

# to see the mail queue
postqueue -p
# to delete all the deferred emails
postsuper -d ALL deferred

# verify that queue is empty
postqueue -p
# for more info, check out the *man* pages of these commands

Transferring ALL MySQL Data

A few weeks back, I switched the server OS. From Ubuntu 12.04 to Debian 7 for multiple reasons.

  • To get to know Debian OS in general
  • To get rid of frequent updates from Ubuntu flavors
  • To use PHP 5.4, without any modifications.
  • To use PHP 5.5, using DotDeb, sometime in the future.
  • To use MariaDB in a fresh install
  • To see how migrations work from one OS to another OS
  • To see how migrations work from one server to another server
  • To prepare for migrations for clients!
  • To test drive websites using PHP 5.4 or 5.5.
  • To see, if there is any savings in memory in Debian.

Anyway, I setup another server, transferred all the files and the databases. Everything worked after the migrations.

Then, after a few weeks, I noticed that the memory constantly touches its limit. So, I tried to optimize MariaDB. After changing a few things in my.cnf, I typed ‘service mysql restart’. It just failed. Looking at the syslog, I noticed that ‘debian-sys-maint’ can not restart the server. OMG!

The issue happened when I dumped all the databases and the corresponding users from the old server. When I imported everything to the new server, the password for ‘debian-sys-maint’ was also reset.

So, the solution is to reset it back to what’s local password. To do that, get the password from /etc/mysql/debian.cnf file, log into MariaDB server as root, then type the following…

GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'the_local_password';

Fedora 19 – Setup Hostname & FQDN

Fedora 19 seems to have changed the way one can setup the hostname and fully qualified domain name. By making this change, it streamlined the setup similar to how things work in Debian derivatives, including Ubuntu. Here’s how it’s done…

# as 'root'
cat 'hostname' >> /etc/hostname
sed '1i127.0.1.1 hostname.domainname.com hostname' -i /etc/hosts
hostname -F /etc/hostname

# verification
hostname
hostname -f

In Amazon Linux AMI, one still has to set it up only in

/etc/sysconfig/network

.