Gzip Compression with Nginx

One of the most popular form of compression for file transfer Gzip compression have been used for decades now. Modern browsers are smart enough to recognize if the webpage has Gzip compression header. But what does Gzip actually do ? In short it compresses the texts, scripts, in the page. It can also compress Images but usually web servers are designed to compress the images by default, so, compressing the image again using Gzip would be waste of resources. So, its better to use Gzip to compress the texts, CSS, JavaScripts, etc. Lets look at the Nginx config for compressing page with Gzip and it’d be easier to explain.

gzip on;
gzip_buffers 16 8k;
gzip_comp_level 9;
gzip_http_version 1.1;
gzip_min_length 10;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_vary on;
gzip_static on;
gzip_proxied any;
gzip_disable "MSIE [1-6]\.";

I guess the configuration is crystal clear and it explains everything in pure english, the notable part might be gzip_comp_level which describes the compression level of gzip, it can be between 1 to 9 with 9 being best as of the time of writing. If you want to see the result of different level of compression then phrogz.net has some valuable benchmark result.

Other thing to consider is gzip_types where you can define the mime types that you want gzip to compress.

Gzip static is the most lovely thing here, usually when you are using gzip it only compresses the file in the client site, but gzip static is different beast. Normally with Gzip the server request works like this:

Browser Makes the Request -> Server Receives the Request

Server compresses the file to serve -> Browser receives compressed file

With each request server has to compress the file, which takes some CPU resources and also increases the latency. But with Gzip static, server stores the compressed file in it and when:

Browser Makes the Request – > Server Receives the Requests

Server Sends the Compressed file -> Browser receives the compresses file

This how more latency/bandwidth will be saved with gzip_static on.

To use gzip_static on, you have to compile Nginx –with-gzip-static

Rajib
May 9, 2013
Compression, Nginx, Web Performance
0 comments

Reset Admin Password in Drupal 8 after failed login attempts

Notice: This is for localhost where you don’t have mail server to reset password

A month ago I was testing Drupal 8, and it had been a while I haven’t logged in, I usually keep simple password while development for easy remembrance, but it was not the case this time, so, I forgot the password of my Drupal 8 installation. There are few methods in internet to reset Drupal’s  super administrator’s password and most of them are for Drupal 7. There might not be much difference in Drupal 8 finished version though, but still it took me a small hack around to reset the password.

At first Drupal 8 has nice folder structure, The core files are separated and kept inside core folder, which contains core modules, themes, scripts, etc. Drupal 8 doesn’t include the “password.inc” file by default in /core/includes/ folder, so, I copied the file from Drupal 7 to the includes folder and hit the command line to run the shell script

./core/scripts/password-hash.sh admin # Since its development machine I wanted to use the password as admin

but I got the following error

PHP Fatal error:  Class 'Drupal' not found in /var/www/drupal-8/core/includes/bootstrap.inc on line 2404
PHP Stack trace:
PHP   1. {main}() /var/www/drupal-8/core/scripts/password-hash.sh:0
PHP   2. drupal_container() /var/www/drupal-8/core/scripts/password-hash.sh:86

This might be small namespace error or huge bug, I didn’t care to look at it in details, as my need is to reset the password for now. So, I came up with my own idea:

Drupal 8 stores the failed login attempts in table called “flood”, so, I hit the mysql cli and did

mysql > truncate flood;

Then I went to the database of my Drupal 7 installation and copied the password for uid=1

came back to Drupal 8 database and Updated the password of uid=1 with the copied password.

I felt Drupal 8 security feature and salting techniques might have been different, but it was same sha256 encrypting of Drupal 7 that worked, hence I logged in to Drupal 8 installation without much tussle.

The easiest way to reset your super admin password in Drupal 8 could be to use Inbuilt PHP hash function in PHP Shell and command line mysql with just one command.

In PHP Shell.

phpsh > =hash(‘sha256′,’YourNewPassword’); # The second parameter is for new password

The Output would be something like

“dab6f348e6eefe9e805d9cbaaca90e0aa482b3cdfe7305eff6ea65f4c913b6ae”

In MySQL CLI

mysql > update users set pass=”dab6f348e6eefe9e805d9cbaaca90e0aa482b3cdfe7305eff6ea65f4c913b6ae” where uid=1;

Don’t forget to truncate the flood table. Now you can login with your username and just added password i.e. YourNewPassword

Rajib
May 1, 2013
Drupal, Ubuntu
0 comments

Multi Master Replication error in MySQL

MM-Replication is quiet risky setup, it needs lots of attention and care to work properly. If you happen to see errors like “Could not find first log file name in binary log index file” or “slave SQL thread aborted”, etc then your replication is out of sync. Although the steps here I discuss could be fit to fix any kind of replication, it was well suited for MM replication, due to missing filename from binary log index file.

In Slave you may see this errors when you do > show slave status \G;

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’

This is when your replication goes out of sync for long and you haven’t fixed it. Now:

In Slave: > stop slave; # This will stop the slave

In Master: > flush logs; # This will flush the logs from master at its current position

In Master: > show master status; # This will display the Master status like its current bin file and position. like:


+------------------+----------+--------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000128 | 107 |             |

| +------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

The main important thing here is mysql-bin number and its current position.

Now go to Slave and:

In Slave: > reset slave; # This step is optional though

In Slave: > change master to master_log_file=’mysql-bin.000128′,master_log_pos=107;  # Remember the bin log file and position from master ?

This is not rocket science, Here we are simply saying slave to start reading the packages from this bin file and from this bin position. Now,

In Slave: > start slave;

In Slave: > show slave status \G; # To make output readable use \G

If you don’t see any error you are good. But don’t forget to check the


Master_Log_File: mysql-bin.000128

Read_Master_Log_Position: 107

Usually the Read_Master_Log_Position doesn’t matter much, as when you start the slave, the master would be in different position, but what matters is the bin-file in where you flushed the logs, the slave will start catching master after that.

Warning: This method will not help you recover the unsynced data from master to slave, this will just establish the sync again. To recover unsynced data you have to apply different techniques.

Rajib
April 26, 2013
MySQL
0 comments