Category Archives: Ubuntu Server Configuration

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’

So you ran an upgrade, or got carried away tweaking things on your server, and now MySQL is acting like an island of its own. Your websites can’t connect, your phpmyadmin can’t connect, and you are miserable.

You get errors like

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysqld.sock'

and, you being a n00b like me, are at your wits end.

I may have a quick fix as long as the error is 2002 and it is complaining about a socket.

Go to your MySQL configuration file [which on Ubuntu is /etc/mysql/my.cnf ]

There, copy the socket mysqld is using. It will be something like

[mysqld] 
datadir=/usr/local/mysql/data
socket=/var/lib/mysql/mysql.sock

Copy the line that says socket=/whatever/address/to/the/file.sock

See if there is a block for [client] that mentions socket. If there isn’t, make one below the block for [mysqld] and paste your socket line. If there is, fix the location to match.

Try now. No restart or anything needed. If it will work, it will work right away. If you have done good things in your life and deserve a break, this should put you out of your misery. 😀 It is among the likeliest culprits if new files and upgrades and such have happened.

If this doesn’t happen, then I would investigate to see if that location exists, has right permissions and such things…. or someone mentioned other checking for other configurations that may be messing with this – which I can’t even imagine where to begin.

Good Luck!

Problems upgrading your Ubuntu Server to 12.04 Ubuntu Precise Pangolin?

If you are running a Ubuntu server on a VPS, the latest upgrade may have brought dismay with warnings and errors and finally failure. Some of the sample output can look like:

Processing triggers for man-db …
locale: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15′ not found (required by locale)
locale: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14′ not found (required by locale)

A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade has aborted.
Your original sources.list was saved in
/etc/apt/sources.list.distUpgrade.

SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)
ERROR:root:SystemError from cache.commit(): installArchives() failed

Could not install the upgrades

The upgrade has aborted. Your system could be in an unusable state. A
recovery will run now (dpkg –configure -a).

Please report this bug in a browser at
http://bugs.launchpad.net/ubuntu/+source/update-manager/+filebug and
attach the files in /var/log/dist-upgrade/ to the bug report.
installArchives() failed

Setting up libsnmp-base (5.4.3~dfsg-2.4ubuntu1.1) …
dpkg: dependency problems prevent configuration of libnih-dbus1:
libnih-dbus1 depends on libnih1 (= 1.0.3-4ubuntu9); however:
Version of libnih1 on system is 1.0.3-4ubuntu2.
dpkg: error processing libnih-dbus1 (–configure):
dependency problems – leaving unconfigured
Errors were encountered while processing:
libnih-dbus1

Upgrade complete

The upgrade has completed but there were errors during the upgrade
process.

dpkg: error processing libnih-dbus1 (–configure):

dependency problems – leaving unconfigured
Errors were encountered while processing:
libdbus-1-3
libc6-dev
libdrm2
libc-dev-bin
zlib1g-dev
libnih-dbus1

and so on.

The main reason for this is that your host is running a kernel that is no longer supported, so the upgrade kind of… refuses. To be sure that this is the problem, run:

uname -r

if you get 2.6.18 then this post is likely to help you. The problem apparently occurs because “your host is almost certainly running OpenVZ on a 2.6.18 kernel (all OpenVZ containers share the host kernel)” according to Ishaan Dalal. “The problem is that the libc 2.15 included with Precise requires a minimum 2.6.24 kernel to function.” He is maintaining a repository with a workaround for this.

To use the repository, add it to your sources the easy way like this:

apt-add-repository ppa:izx/ovz-libc

Chances are that this may not work for the same reason the upgrade didn’t – because stuff is broken, in which case, you add the following lines to /etc/apt/sources.list

deb http://ppa.launchpad.net/izx/ovz-libc/ubuntu precise main
deb-src http://ppa.launchpad.net/izx/ovz-libc/ubuntu precise main

And run:

sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys BFAB4BD9

After which if you run

apt-get update

apt-get install -f

apt-get dist-upgrade

you are likely to go smoothly into the upgrade. Follow prompts, etc. Reboot when done, and you should be fine.

…. or at least I was.

WordPress Database Error: You have an error in your SQL syntax

When I used a slideshow plugin on AamJanata, I got this error.

WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'orderorder` INT(11) NOT NULL DEFAULT '0'' at line 1]
ALTER TABLE wp_gallery_slides CHANGE COLUMN order order INT(11) NOT NULL DEFAULT '0'`

Lot of investigation and frustration later led me to realize that if something is working for everyone and not for you, it is useful to look at your unique set up rather than the code.

Snooping in my databases showed me that the Character set used for the table for that plugin was not utf8, – actually different ones for two different plugins both giving me errors. Setting it right fixed the problem.

What to do?
Go to your database in PhpMyAdmin. Run your eyes down the encoding column and see which tables if any have encoding other than what the rest of the database is using. Chances are high that that will be the one giving you trouble. Go to the Operations tab for that table, set the encoding to what the rest of the database is using.

Done.

Rewrite / Disk Cache-enhanced / Minify not working in W3 Total Cache : Idiotproof checklist

W3 Total Cache is hands down the best speed solution I have ever found for WordPress. However, it can be a little intimidating to configure, and sometimes gets you stuck. Being a self-learned admin, I am more often the idiot, so I go back to what works and figure it out. Here’s my bombproof checklist that has never failed

If you get something like this:

It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

or

It appears Minify URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.

Most of the standard advice is not too useful. Then there are those who simply call it a W3TC bug and leave it at that. Maybe it was a bug earlier, but I guarantee you it is working right now and that you can make it work. *

[* = Minify in W3 Total Cache needs php5.5 to work. Most people seem to have php5.3 – then it won’t work and this guide can’t help you – you will have to upgrade php if it is that crucial for it to work.]

Of course you could turn off minify and disk-caching:enhanced in W3 Total Cache and the problem will be gone, but if you want to *make* it work, for the functionality or because you may be like me and something not working drives you nuts… read on.

  • Check installed modules: env, rewrite, mime, headers [if you can fix this, you might as well go ahead and make sure expires is active too for better caching]. On a debian/ubuntuinstall, you’d do
    a2enmod env

    for example.

    No rocket science needed here, but I’ve once scratched my head for an hour and tormented myself with checking htaccess files and permissions and what not on a new debian install only to realize mod_env was not active.

  • Check your .htaccess files. Yes. In the plural. The .htaccess in the root directory should contain W3 Total Cache rules *before* the WordPress rules. Then, there would be more .htaccess files depending on what you have enabled. For example, if you have disk enhanced caching enabled, you’d have an .htaccess to check in the pgcache folder inside w3tc folder inside your wp-content directory. Which brings me to…
  • Check the w3tc folder. I cannot stress this enough. If you want your page caching to work, your wp-content folder will have a folder called w3tc, which will contain a folder called pgcache [if you are using minify, there will be a folder called “min” too]. If it isn’t there, create it. If it is there, chmod its permissions to 777. It should contain an .htaccess file. If the file isn’t there, or you had to create the folder, go to your admin panel for W3 Total cache, click the tab for “Install” scroll down. You will have .htaccess rules applicable for your site listed there. Copy the correct ones – the file paths are written above the content. Can’t go wrong.
  • Go up to your wp-content directory and make sure to chmod your file/folder permissions to 777 – once you get page cache working, you could lower them to find the minimum required. First let’s get it working.
  • Check for crucial files. You can’t miss this. There will be a red alert on your admin panel if files are missing – usually complaining that your wp-content folder is not writeable or the files are missing. See named files, make sure they are there. If they aren’t, you could download a copy of the plugin to grab them easy.
  • I have never failed to get W3TC working with all this right. Yes, I am talking “disk:enhanced” page caching. But as a last shot, worth checking for file ownership, particularly if, like me you are in the habit of ssh-ing in as admin on the server to edit files. If you have entered the WordPress directory, it is worth setting the correct ownership when done to save yourself a lot of misery later.

Note: If you have renamed your .htaccess, you may want to copy back any customized rules that you may have put into it from the old file to the new file. Be ready to take them out if they cause things to crash again 😉

HTML Tidy on Ubuntu

Uh… this could have been a tweet instead of a post.

in your terminal, paste:

apt-get install php5-tidy

Answer “y” when asked. Done.

Just to make this last longer… if this doesn’t do the trick, you aren’t logged in as root. try:

sudo apt-get install php5-tidy

Restart Apache

service apache2 restart

Now, really, I’m done. Seriously.

Pagespeed + Apache2 on Ubuntu Server

I try and get all my installing done before I get into putting files on the server. So, if I wreck something and have to start over, I haven’t wasted a lot of upload and setting up time.

This server I am describing runs Ubuntu Server and I am using it to run a few wordpress sites. WordPress being a resource hog (charming as it is), I want to keep things peak. If it seems excessive, I can always drop the excessive later.

Google’s mod_pagespeed

I have not used this before, but I heard that it compresses images, and that’s good enough for me to give it a shot, rather than fiddle with smush.it plugins that can’t reach many images called the most. I can remember to compress all before uploading, but seriously, who remembers? mod_pagespeed is in beta, but I’m going on trust, seeing as how the project has active development.

So here goes. Pretty straightforward. Get debian package, install. went without a hiccup this one. Easily the least complicated so far.

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb
sudo dpkg -i mod-pagespeed*.deb

service apache2 restart

Now edit /etc/apache2/mods-available/pagespeed.conf and add your cdn (if any) so that pagespeed knows to optimize those files too.

service apache2 restart

Update: I disabled pagespeed after my CPU usage started spiking rapidly and dangerously. I suppose it can be configured better, So I will come back to it at a later date. Too busy to do any extensive tinkering and babying right now.

Update: I have been able to get this to work most excellently – even for my efficeincy obsessed mind – post coming up with my settings and logic soon.

Configuring Varnish Cache for WordPress

Oh, so you installed Varnish, what good will it do, if most of your content is not cached? I went for the “Preparing Varnish/Wordpress? for a Slashdotting in 60 seconds or less… ” code provided on the Varnish site. Its rather ruthless, but I’m not particularly attached to seeing the logged in version of my websites that I want Varnished anyway. Few log in to them. Ruthless works for me. So here’s how to do it. Please note that there is a change of code since that sample was provided, which I have corrected below. Feel free to plug and play.

Edit your /etc/default/varnish file and edit the port and cache size in.

DAEMON_OPTS=”-a :80 
-T localhost:6082 
-f /etc/varnish/default.vcl 
-S /etc/varnish/secret 
-s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1gb”

Port is at 6081, which you change to 80. Set the storage size as per your needs. Don’t obsess over it. You can always edit if needed later.

Then, in /etc/varnish/default.vcl paste the following code.

backend default {    .host = "localhost";    .port = "8080";    .max_connections = 30;    .connect_timeout = 4.0s;    .first_byte_timeout = 600s;    .between_bytes_timeout = 600s;
}

# Drop any cookies sent to WordPress.        sub vcl_recv {                if (!(req.url ~ "homeschoolingindia.in|phpmyadmin|wp-(login|admin)")) {                        unset req.http.cookie;                }        }
# Drop any cookies WordPress tries to send back to the client.        sub vcl_fetch {                if (!(req.url ~ "phpmyadmin|wp-(login|admin)")) {                        unset beresp.http.set-cookie;                }        }

You don’t have to configure everything. What you don’t configure falls back on pretty decent defaults. What is being done here is that all cookies are dropped so that the page becomes cachable, unless you are accessing login or admin, where you need cookies to be able to access. I had some trouble with interaction on the front page. No admin option was available, since this was the production version I was seeing. Making comments was a problem.

The solution was rather simple. I installed the Discus plugin to handle comments. It formats them rather nicely, magages efficiently, integrates reasonably well with wordpress, adds features like likes and shares along with the oh so fabulous lists of mentions. However, the bestest part is that it is delivered through javascript, so it is totally functioning when the page is cached.

Other problems likely may be using any analytics software from the server end. Since most requests will not reach the server at all, there is no way for the server to record hits and so on. Again, javascript to the rescue. What do I say. In my opinion, google analytics works best for my needs anyway.

So, you understand the theme of the matter, basically, you are not going to be pulling any customized pages. Javascript being rendered in the browser, couldn’t care less if it were served from a html page or php. Your adsense will work, so will analytics. Some “link selling” plugins that rely on php may not register as active with your providers, but then you shouldn’t be selling I’ll not comment on the ethics of that…. This site, AamJanata, Wide Aware and Nisarga run like that.

However, this brings us to the site that won’t work. A site that users login and use. You got that right. BuddyPress. Homeschoolingindia.in is not getting the varnish treatment. I guess you could do it so that you use varnish with non logged in users, if you have a lot of non-member visitors. I found it simpler to leave it out.

Two possibilities. The first is to exclude it through varnish. Either by passing requests through for target domain or configuring Varnish per domain, and not for this one. Please to also remember to exclude it in the cookie killing settings. Many possibilities depending on what you want.

The second option is what I did, because it was simple and I had an extra IP from my provider. Configure all sites to be cached to answer on one IP on your backend port 8080 in this example and those not to be cached to answer on port 80 (the regular port) on the second IP. In the default.vcl, in the backend configuration, replace localhost with the IP address serving sites to be cached on port 8080. Done. Your buddypress is now happily guzzling scandalous amounts of resources, while your other wordpresses are playing static html. ;)

There is more, much more, but I find that this is adequate for basic configuration. Later, as you get used to the cache, you will be able to analyze what is happening, and filter in more and more hits to the cache and reduce server load further, but that is another how to in itself, if at all I have the competency to write it.

This should keep your server from crashing under whatever it is that guzzles up memory.

Please note that these are my learnings as I struggle to find out things. I am not a professional. Only a  person who wanted to build a website. I am cutting through the massive finding out missions I had to take and providing the results of that learning. No guarantees, though whatever I say here is working according to my server.

If you would like something more tweakable (and complicated), with load balancing and multiple servers for one site, etc. Try here

Note: This post is old. Soon, there is one more coming up with more nuanced settings, and alternative vcls.

Whys and Why-nots of Varnish-Caching WordPress

After Installing the default server and getting it trouble free and upgraded, its time to set things up as they are meant to be. And unless you have a very dynamic site, you should try Varnish Cache. Its far faster than others, because it sits on the front of the server and serves cache instantly as far as possible. For all intents and purposes, your blog runs like you are serving static html. Static. Get it? Which means there are drawbacks, so please consider the following carefully.

WordPress is a cookie monster. Cookies defy cache. While still useful, you’ll likely end up under utilizing the cache so much that its pointless. After all, the gains must weigh against the extra layer, and thus extra opportunity for something to go wrong, particularly with something with as much potential for disaster as a cache. Essentially, what we will be doing is moving Apache (which serves our wordpress) to a different port, and the Varnish cache takes its place instead.

Good bits. Fast. Regardless of whether you are enduring a “digg” (isn’t that Twitter these days?) or you are trying to reduce the load on the server in general, there is nothing like an instantly loading site to keep visitors happy and returning.

Bad parts. Things that depend on cookies are best removed for performance. Not as simple as you think. Commenting becomes a pain, you may be logged in, but the “edit” link for articles vanishes… etc. There are ways to manage this, but they are more complicated. What I’m using here is efficient, quick and painless, which is how I like things to be.

I prefer using a commenting service which dishes out the comments with javascript. For all intents and purposes, you could add comments to static pages….. which is what we want. As you see, I use Disqus.

Installing Varnish Cache for WordPress on Ubuntu Server

My intention is to whiz up the WordPress. The best of both worlds, so to say. WordPress is very cool, but needs some serious speed boost to lose that leisurely blog feel.

So here’s how you do it. Please remember, this is code I use on Ubuntu. If that is not your server, you are better off following the Varnish Cache website.

Install Varnish.

Begin with getting the key.

curl http://repo.varnish-cache.org/debian/GPG-key.txt | apt-key add -

If you have been following the Server from the beginning, you don’t have curl installed. So you install it and run the command again.

apt-get install curl

If this fails with a missing package, update

apt-get update

and then install curl, and then import key.

Add varnish to your sources.list.

echo "deb http://repo.varnish-cache.org/ubuntu/ lucid varnish-3.0" >> /etc/apt/sources.list

Or, if you have been installing other stuff too, and would like to add them all at once, simply edit the sources.list file and add the repository in.

vi /etc/apt/sources.list

Update and install varnish.

apt-get update
apt-get install varnish

Done. But follow on to configuring. Configuring Varnish for WordPress is another animal altogether.

Fresh Server Install – Ubuntu Server Edition

Your VPS offers you the possibility of a fresh installation, reinstall OS they call it. Do that. Use Ubuntu 10.10

Please note that I am no computer expert, I am telling you what worked for me.

The default installation of Ubuntu doesn’t have locale set. You will get “locale failed” variety errors when you install anything.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_IN"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

More irritating than anything else. So we get rid of that.

apt-get install language-pack-en-base

If you get an error about missing package, etc. Run

apt-get update

and try again.

Then you may have to insert the code for your location.

/usr/sbin/locale-gen en_IN.UTF-8

and

/usr/sbin/update-locale LANG=en_IN.UTF-8

Irritants out of the way, this is the time to do any upgrades you may wish. I brought my server to the latest like so:

sudo apt-get install update-manager-core

Check that /etc/update-manager/release-upgrades has Prompt = normal (default) and run

sudo do-release-upgrade

I generally replace most configuration files with “vendor versions” – I haven’t actually customized anything so far.

This done, I am ready to move to the next step. I have decided on using Varnish as the cache, LAMP, APC opcode cache. I will also be using virtual hosts to host different domains, but that is last.

There is a reason for this sequence. If something messes up, I can click the reinstall button, and there is very little big effort gone into it. So, the tricky stuff comes before the time consuming stuff – as long as there is no dependency.