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?
After analyzing all the possible options, the following works great for me. I hope it works for you too…
find /path/ -type d -print0 | xargs -0 chmod 0775 # For directories
find /path/ -type f -print0 | xargs -0 chmod 0664 # For files
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…
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)…
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
and then comment out the line
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;/' *
Recently, had a look at MySQL slow log to see what’s happening in a particular site. MySQL logged the unix timestamps that is good for many reasons. In order to convert this, here’s a one-liner…
date -d @1382734106
# output - Fri Oct 25 20:48:26 UTC 2013
Some people try to test out an application, a site, a contact form and may use an email like firstname.lastname@example.org 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
# to delete all the deferred emails
postsuper -d ALL deferred
# verify that queue is empty
# for more info, check out the *man* pages of these commands
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 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
In Amazon Linux AMI, one still has to set it up only in