Ubuntu 13.10 internet very slow “nothing helps” fix

I installed Ubuntu 13.10 on my laptop and went nuts with the laggy laptop. I have 2gb memory on it, which shouldn’t be causing such a comatose experience. I installed drivers, tweaked memory, did a hundred things, nothing helped.

Digging around in the innards, I found that /etc/resolv.conf was very strange and was showing localhost as the name server. This couldn’t be right. Digging around, I found that any attempt to put working DNS servers was getting rewritten.

In the end, I found a strange fix. Network Manager configuration (sudo gedit /etc/NetworkManager/NetworkManager.conf)was using dns from dnsmasq. Guessing (rightly as it turns out) that I didn’t need dns served from my computer (and i have no idea how it would sync it), I commented out that line and restarted network manager. It looks like this.


Commented it out like so


Now /etc/resolv.conf is showing the DNS servers it gets from the internet provider.

I have no idea if this is the “right answer”, but if your computer is slow and freezing on using internet, and your /etc/resolv.conf is showing or or something as your dns server instead of proper dns server IPs, it is worth a shot. You can always uncomment it if it doesn’t help.

My computer is running faster, freezing less and hasn’t yet exploded.

Ioncube with Nginx+php-fpm giving 502 gateway error SOLVED

Ubuntu 13.10 seems to be having trouble with ioncube and php-fpm. My earlier guide on loading ioncube may not work for you anymore.

This is really strange and I have no idea why no one seems to mention it, but if you are getting frustrated trying to install the ioncube loader on php-fpm, just ignore the instructions to create the 20-ioncube.ini file, and plug the line directly into the end of your php ini.

Steps to install ioncube loader with php5-fpm

cd /usr/local
sudo wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
sudo tar xzf ioncube_loaders_lin_x86-64.tar.gz
mv /usr/local/ioncube/* /usr/lib/php5/20121212/

This is the same.

Now, instead of creating a file called 20-ioncube.ini or ioncube.ini directly add it to your php.ini file (On Ubuntu with a repository installed php5-fpm package, php.ini will be found at /etc/php5/fpm/php.ini)

At the very end add:

zend_extension = /usr/lib/php5/20121212/ioncube_loader_lin_5.5.so

Then restart php-fpm

service php5-fpm restart

If it still doesn’t work, try doing the same thing as root.

If you can’t find your php.ini, create a php file on your website with some random name. Open it in an editor and add the line:

Access the file on your site with a browser. It will have all kinds of info about php, including the configuration files (php.ini and others) locations.

Ubuntu network slow RTL8101E/RTL8102E PCI Realtek

I recently reinstalled Ubuntu, and found that my network was agonizingly slow. Installing the driver from the Realtek website fixed this. My card is RTL8101E/RTL8102E PCI Express Fast Ethernet controller, but I imagine this will work for other versions too.

The problem is that the default driver does not support this card well. Blacklist it.

sudo gedit /etc/modprobe.d/blacklist-network

and add


to it

Download driver from the Realtek website.

Extract it. Compile it by going to the folder where you have extracted it (Downloads, for example) as root (your prompt will be something like this: root@vidyut-Compaq-435-Notebook-PC:~/Downloads/r8101-1.025.00#)and:



make install

The make install didn’t work for me, so I had to manually copy it into the folder.

cp src/r8101.ko /lib/modules/3.11.0-12-generic/kernel/drivers/net/ethernet/realtek/

Then run:

depmod -a
modprobe r8101
service network-manager restart

That should do it or try

ifconfig eth0 down
ifconfig eth0 up
service network-manager restart

Your network should be working normally now.

WordPress with MariaDB instead of MySQL

So I heard good things about MariaDB and decided to switch from MySQL to MariaDB. MariaDB is a fork of MySQL developed by the original developers of MySQL and it is intended to be a drop in replacement – meaning all your commands and databases from MySQL should continue to work seamlessly after the switch.

Tall claim, but with years of relationships with webservers, it isn’t too tough to know that even an upgrade can break things. Here, however seamlessly, the DATABASE management software was being replaced. Only a complete novice would believe “as advertized” to the point of not being worried.

My biggest fear was breaking my blogs. Backups are there, but…. it is unpleasant to see your precious sites not working, and I was apprehensive.

So anyway, I did it.

Added the repository (these are my instructions, but they helpfully provide a configurator for customized MariaDB repositories for your Operating System – version – MariaDB version, which you should totally use).

sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
sudo add-apt-repository 'deb http://mirrors.hustunique.com/mariadb/repo/5.5/ubuntu saucy main'

I’d done paranoid backups to the nth degree before, as you should too, but I won’t bore you with the details. Suffice it to say that I had 3 of each database AND a snapshot of my VPS to restore with “one click” if I got itchy AND I copied the mysql directory anyway (I really love my blogs. Really). I think this was mostly of therapeutic value after the first backup, but hey, it was good for my blood pressure.

Updated and installed MariaDB.

sudo apt-get update
sudo apt-get install mariadb-server

The only pain here was that the repository I used was agonizingly slow to download from, which really did not help my anxiety levels, since I’m used to the more blazing fast ubuntu repositories. Or perhaps it was a temporary patch of bad network I hit.

Regardless, if you are superstitious, you may want to avoid this one.

After a wait that almost had me too old to care, the installation was done.

That is it. There was no noticeable difference to my site except seeming slightly faster. I noticed the configuration file got replaced, but the defaults are good enough that the blogs are completely normal. I expect once I get around to tweaking it, the performance may get even better, but this is good already.

The backups did not get used. A textbook “drop in”. Zero hassle.

Do it already. The only cure for your wondering is finding out.

Meteor::Socket bind: Address already in use at Meteor/Socket.pm line 115.

If, after installing meteor server, you get an error like

Meteor::Socket bind: Address already in use at Meteor/Socket.pm line 115.

when trying to start it up with ./meteord -d or /etc/init.d/meteord start, it means that you likely have another instance of meteor running.

Unless you have changed ports around, you can kill the exising instance of meteor with pkill meteor or simply use it without starting a new one 😉

Installing Meteor Server on Ubuntu

Meteor is a javascript server that does interesting things like live updating your live blog with far less load on your server than without it. However, setting it up is iffy, and the instructions are not idiot proof. So here are the steps distilled from my hits and misses, so that you may not have to go through that yourself.

Meteor Server Installation instructions

These instructions are as per instructions provided on the Meteor Server website along with my comments.

Make a directory for the Meteor Server and cd into it.
mkdir usr/local/meteor
cd usr/local/meteor

We begin with getting and unpacking Meteor Server:
wget http://meteorserver.org/download/latest.tgz
tar zxvf latest.tgz
rm latest.tgz

Alas, this doesn’t work. There is no file at the provided url, and I had to use the url provided for download. So this should work.

wget https://github.com/visitsb/meteorserver/blob/master/build/meteor-latest.tgz?raw=true
At this point, check the name of the file you got.
if it is “meteor-latest.tgz?raw=true”, then
mv meteor-latest.tgz?raw=true meteor-latest.tgz
before proceeding, or the next step won’t work. Now
should give you “meteor-latest.tgz”. Ready to move on.
tar zxvf meteor-latest.tgz
rm meteor-latest.tgz

Now to set it up.

Copy the init script to /etc/init.d/meteord:

cp daemoncontroller.dist /etc/init.d/meteord

You will need to edit the file to change the path if you did not install meteor in /usr/local/meteor. If you wish to use this to start/stop Meteor, you will need to edit line 14 to specify which user account will be used to run it. The default is meteor, so if you want to create that user account now, type:

useradd meteor

Now copy the configuration file to /etc/meteord.conf:

cp meteord.conf.dist /etc/meteord.conf

To start meteor at boot, they recommend

chkconfig meteord on

This part didn't work for me, as I don't have chkconfig installed - the instructions seem "Fedora-ish" - I have no idea how Fedora works. Never used it. Instead, I did

update-rc.d meteord defaults
update-rc.d meteord enable

At this stage, you should be able to start meteor in debug mode (according to them).

./meteor -d

For me, it didn't. I needed to

chmod +x meteord

as they have suggested. I also did

chmod /etc/init.d/meteord

I could start meteor in debug mode successfully, but

/etc/init.d/meteord start

wouldn't work.

I was getting "/bin/sh^M: bad interpreter: No such file or directory"

Found two problems. The first was that /etc/init.d/meteord script refers to /etc/init.d/functions which didn't exist. I edited the file to change the line

. /etc/init.d/functions


. /lib/lsb/init-functions

By checking what file was being referred by scripts that were working.

About the "^M" in the error, I discovered that it was caused by the file having dos line endings. It should have been unix line endings.

I opened it in vi

vi /etc/init.d/meteord

and in the command mode itself (hit ESC if you've switched to INSERT) entered:

:set fileformat=unix

Then saved and exited




starts Meteor.


I will do a separate post on using Meteor to power Live Blogging Plus (when I finish doing it).


Setting up live blogging that works with the latest version of WordPress

True to form, I want big things for my blog, but they aren’t easy. This time the idea came from a reader who wanted my commentary tweet series on current events to be done instead as a live blog, so that they could read all the ideas at once in one place and they would also remain easily accessible.

Great idea, except all the plugins I came across for live blogging were outdated and not working correctly with the latest WordPress, with the exception of 24liveblog, which I was not so keen on, as the content does not reside on my server, but theirs (though it is free and they promise never to take it down).

If you are fine with the content being hosted on another service, look no further, 24liveblog is good, and free and the resulting liveblog can be embedded on your site with a code provided.

I wanted to make the plugins work as I wanted the content to reside on my server AND I wanted it to make tweets linking to the post with each update.

So I have updated the live blogging plugin to fix several issues with tweets not getting posted to Twitter. You can download Live Blogging Plus it here.

The plugin is capable of delivering the live blog more efficiently using meteor, so I am planning to set up a meteor server for it to use. Stay tuned.

Enhanced by Zemanta

Upload Error: client intended to send too large body

If you are using Nginx and are unable to upload files exceeding 1MB or so (most common) and get your error log shows “client intended to send too large body”, then here is the fix.

Edit your Nginx configuration file (which on Debian/Ubuntu will be found at /etc/nginx/nginx.conf) and edit the setting for client_max_body_size to something you can live with. If there is no line for it, add this line:

client_max_body_size 5M;

Obviously, replace 5M (for MB) with a number that makes you happy if your upload is larger.

Enhanced by Zemanta
Nginx logo

Nginx-1.5.6 with ngx_pagespeed (Google Pagespeed module) and ngx_cache_purge

So I got tired of fiddling around with repositories offering builds that compiled ngx_pagespeed with Nginx. I was getting a lot of errors, was using older versions of Nginx and was not able to make the dotdeb repository work.

I was wary of compiling, because I’m a creature of habit, and I like my Nginx installed as a service and other minor pleasures of life (I still haven’t learned to make init scripts :p)

What I have basically done is compiled the latest Nginx (1.5.6 – as of writing this post) along with these two modules I wanted in the place of the Nginx package.

So far, all seems to be working well, and I’m hitting pagespeed scores of 98+ without any noticeable strain on the server. So, for what it is worth, here is what I did.

Step 0: Install dependencies for compiling

Time to become root (better than typing “sudo” for each line.

sudo bash

Enter your password to become root@whatever:~#

Install dependencies for compiling.

apt-get install build-essential zlib1g-dev libpcre3 libpcre3-dev

Step 1: Get the latest ngx_pagespeed

The ngx_pagespeed page gives you the code to install the beta package. I just grabbed the current master download from the button on the right (right-click and copy link 😉 )

You could choose either. I’m not certain the server won’t explode because of whatever I’m doing. So play safe if you want. I just wanted all the fixes already.

This is if you use the recommended beta:

$ cd ~
$ wget https://github.com/pagespeed/ngx_pagespeed/archive/release-
$ unzip release- # or unzip release-
$ cd ngx_pagespeed-release-
$ wget https://dl.google.com/dl/page-speed/psol/
$ tar -xzvf # expands to psol/

What I did was:

$ cd ~
$ wget https://github.com/pagespeed/ngx_pagespeed/archive/master.zip
$ unzip master.zip
$ cd ngx_pagespeed-master/
$ wget https://dl.google.com/dl/page-speed/psol/
$ tar -xzvf # expands to psol/

Step 2: Get the latest ngx_cache_purge

You know the drill by now. Just giving the steps I did:

$ cd ~
$ wget http://labs.frickle.com/files/ngx_cache_purge-2.1.tar.gz
$ tar -xvf ngx_cache_purge-2.1.tar.gz

I could have used the master here as well, but I wasn’t having too many errors with it, so it seemed an unnecessary risk (yeah, I know kinda late in the day to be cautious).

Now for the tricky part.

Step 3: Configuring Nginx for compiling

What we are going to do in this step is configure the source to build right on top of the existing Nginx package.

$ # check http://nginx.org/en/download.html for the latest version
$ wget http://nginx.org/download/nginx-1.5.6.tar.gz
$ tar -xvzf nginx-1.5.6.tar.gz
$ cd nginx-1.5.6/

This assumes you have a Nginx server running (you don’t need to stop it yet. I’ll tell you when) that you want to replace and a preference for organizing the files “as usual” in the Ubuntu/Debian way. I had the added greed of not wanting to invent anything I could recycle – like the lazy habit of “service nginx restart” for example. If not, you could probably install it anywhere. There may be easier ways of doing this.

Remember I am NOT an expert, I am simply a determined person trying to get what I want and making do with my limited knowledge.

Ok. Let’s proceed. Get the configuration of your existing nginx package (for the paths). You could also skip to next step without going through this reasoning and method and only return here if there is a problem.

nginx -V

You want to copy this to a text file somewhere for easy reference.

Now, you have to create the command for configuring using the paths here.

./configure --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log

If you run this command, you will find some alerts going “Not found” in the checking. This is normal, since you don’t need all the things it checks for (indeed some are found on other Operating Systems altogether), but it is a good idea to keep an eye on what’s missing, in case there is a problem…. and there is.

This command will give you all the “Not founds” from that lengthy output. It is the same command, using grep to catch the lines:

./configure --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log | grep 'not found'

The rest seems ok to my inexperienced eye, but “checking for nobody group … not found” is a problem. So we set the user and group to www-data by adding this to our configure line.

--user=www-data --group=www-data

Then we add our modules from steps 1 and 2.

 --add-module=$HOME/ngx_pagespeed-master  --add-module=$HOME/ngx_cache_purge-2.1

And we have our complete line.

Step 4: Configure the build

$ ./configure --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --user=www-data --group=www-data --with-http_ssl_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_spdy_module --add-module=$HOME/ngx_pagespeed-master  --add-module=$HOME/ngx_cache_purge-2.1

I have no idea what you will do if you get errors. Comment here, and I’ll see if I have ideas. This should build smoothly on a standard Ubuntu server (I tried on three, all three worked).

Hopefully all went well, and we make the build.

$ make

Now for the other tricky part.

Step 5: Stop your existing Nginx server

Find out where the Nginx files and folders are

$ whereis nginx
nginx: /usr/sbin/nginx /etc/nginx /usr/share/nginx

Check and doublecheck that these are the same folders we are configuring. Not the end of the world if you get it wrong, but you’ll probably get errors with the init script and will have to either make a new one or hack it. Sure they are the right folders?

Now stop the server.

$ service nginx stop

Move your configuration folder somewhere safe.

$ mv /etc/nginx ~

Delete the existing install (we have simply stopped the server, not removed the package). Remember the locations we got in the whereis? add them all to a delete command. (yes, I know we moved the configuration folder somewhere safe, just doing a lazy copy-paste)

$ rm -rf /usr/sbin/nginx /etc/nginx /usr/share/nginx

Step 6: Install the compiled Nginx in the place of the files we removed

Time to install the make we did earlier.

$ make install

Step 7: Add a line to fastcgi_params

Edit the new fastcgi_params file /etc/nginx/fastcgi_params and add

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

This line gets added when you install from a package. The source doesn’t have it. No idea why.

If you don’t do this, you’ll get blank pages and a lot of frustration trying to figure out why your server isn’t working. Then you’ll get superstitious over masquerading builds as packages and so on. (Don’t ask how I know) So don’t forget.

Step 8: Return the configuration files to their respective places in /etc/nginx

Move or copy or create the files in sites-available, symlink them to sites-enabled, and so on. The usual stuff.

If you don’t return your original nginx.conf here and choose to use the new one, please remember to add in the http block:

        # Virtual Host Configs
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

Your earlier package installed by Ubuntu/Debian would have configured the folders automatically, but the source does not have this structure, so you will have to include the files (or paste their contents here – messy) or returning the server blocks into position will *still* not load them and leave you puzzled.

Tweak to taste. The old files worked as they were, for me. I was able to start my new server with a downtime of less than 2 minutes after I had these steps lined up and ready to copy-paste.

Start/restart server.

If there are problems with emerg not being able to bind to port, just do

pkill nginx

and start it

service nginx start


My pageload time went from 20+seconds for first page load (I wish I had a screenshot) to under 1s for first pageload right off the bat – this is before configuring pagespeed, and frankly, with this performance, I’ll leave pagespeed unconfigured if it so much as whimpers.

So maybe it was all for nothing, unless you count installing Nginx-1.5.6 with the conveniences of a package before it hit the repositories 😉

Note: When it is time for an update, there may be issues. I have no idea what will happen, but worst comes worst, I can

apt-get remove nginx


apt-get install nginx



unless a better option has hit the repositories by then.

I will also post urgent updates here if anything goes wrong. So far as I can see, this is working as a dream.

Also note: There may be changes in performance over the next couple of days as I fiddle around trying to configure stuff. Not a reflection of end result if you suddenly find the blog slow. Work in progress.

Enhanced by Zemanta