Let’s assume you already moved the databases (separate database for Drupal and CiviCRM as a recommended setup) and the files to new location and have set the correct file permissions as well. Here is the part that you need for your CiviCRM to work on new location and domain:

• access your database and empty civicrm.domain:config_backend. You see this anywhere with CiviCRM guide.
• update database details, site path/directory, and domain on civicrm.settings.php
• emtpy sites/default/files/civicrm/template_c (or make this entire dir writable by web user)
• login to you new Drupal site and visit these urls:
  http://sitename/civicrm/menu/rebuild?reset=1
http://sitename/civicrm/admin/setting/updateConfigBackend?reset=1
  Note: This will rebuild the settings for you – if not, repeat/review all the above steps.

Environment: Ubuntu 10.10, Apache, PHP, MySQL, Drupal 6.20

Things to install / setup: Solr, Tomcat6, ApacheSolr module for Drupal, and SolrPHPClient library

1.) Install Tomcat and setup your Tomcat admin user.

aptitude install tomcat6 tomcat6-admin tomcat6-common tomcat6-user
vi /etc/tomcat6/tomcat-users.xml
<role rolename=”admin”/>
<role rolename=”manager”/>
<user username=”tomcat” password=”password” roles=”admin,manager”/>
/etc/init.d/tomcat6 restart

If all is good you will be able to access Tomcat admin at http://hostname:8080. Default page will show with links to admin section, etc.

2.) Install Solr

wget http://apache.rediris.es/lucene/solr/1.4.1/apache-solr-1.4.1.zip (check for updates)
unzip apache-solr-1.4.1.zip
mkdir /usr/share/tomcat6/webapps
cp apache-solr-1.4.1/dist/apache-solr-1.4.1.war /usr/share/tomcat6/webapps/solr.war
cp -r apache-solr-1.4.1/example/solr /usr/share/tomcat6/solr
vi /etc/tomcat6/Catalina/localhost/solr.xml
<Context docBase=”/usr/share/tomcat6/webapps/solr.war” debug=”0″ privileged=”true” allowLinking=”true” crossContext=”true”>
<Environment name=”solr/home” type=”java.lang.String” value=”/usr/share/tomcat6/solr” override=”true” />
</Context>
chown -r tomcat6.tomcat6 /var/lib/tomcat6
/etc/init.d/tomcat6 restart

You should see Solr access on your Tomcat admin/manager page (http://hostname:8080/manager/html).

3.) Connect Drupal Site to Solr (multi-core setup)

I already have a Drupal site with ApacheSolr module installed and SolrPHPclient library.

cp /path/drupal_site/sites/all/modules/apachesolr/schema.xml /usr/share/tomcat6/solr/conf/schema.xml
cp /path/drupal_site/sites/all/modules/apachesolr/solrconfig.xml /usr/share/tomcat6/solr/conf/solrconfig.xml
cp apache-solr-1.4.1/example/multicore/solr.xml /usr/share/tomcat6/solr/
mkdir /usr/share/tomcat6/solr/site_sample1
cp -r /usr/share/tomcat6/solr/conf /usr/share/tomcat6/solr/site_sample1/conf
vi /usr/share/tomcat6/solr/solr.xml
<core name=”site1″ instanceDir=”site_sample1″ />
chown -R tomcat6:root /usr/share/tomcat6/solr/
/etc/init.d/tomcat6 restart

Visit ApacheSolr settings of your Drupal admin and enter the configuration:
Solr Hostname: localhost
Solr Port: 8080
Solr Path: /solr/site1

To add new site to Solr:
mkdir /usr/share/tomcat6/solr/site_sample2
cp -r /usr/share/tomcat6/solr/conf /usr/share/tomcat6/solr/site_sample2/conf
vi /usr/share/tomcat6/solr/solr.xml
<core name=”site2″ instanceDir=”site_sample2″ />

That’s All.

Detailed Setup:

• Drupal 6.19
• ApacheSolr module 6-1.1
• Apache Solr PHP Client Library: Rev.22
• Solr 1.4.1
• Tomcat 6.0.29
• SunJDK 6update21
• RHEL5.5×64

Install Process: Tomcat

• Create solr user
• Download Tomcat6
• Extract to /opt/tomcat  **this will be the $CATALINA_HOME directory, you can use any dir you want
• Edit /opt/tomcat/conf/tomcat-users.xml to enable Tomcat login.  See comments in this file.

<role rolename="manager"/>
<role rolename="admin"/>
<user username="tomcat" password="tomcat" roles="manager,admin"/>

• Test run your Tomcat:  /opt/tomcat/bin/catalina.sh run. Chown all Tomcat files to solr user (chown -R solr.solr /opt/tomcat). Default server setting will use port 8080, to customized edit the file /opt/tomcat/conf/server.xml. If you encounter error on “BASEDIR environment variable is not defined correctly…“, check permissions of .sh files inside /opt/tomcat/bin/ and make them executable (chmod 755 /opt/tomcat/bin/*.sh).
• Add startup (init) script. Copy this Tomcat6 init file from Apache.org to /etc/init.d/tomcat6.  Check and update variables like Java home, Tomcat directory, etc, if needed. Add to startup /sbin/chkconfig --add tomcat6 and /sbin/chkconfig tomcat6 on. Dependencies: redhat-lsb (or lsb-base?)
• Visit your Tomcat Admin page. ex http://localhost:8080

Install Process: Solr

• Download Solr
• Extract to temporary location, ex: /opt/apache-solr-1.4.1
• Copy /opt/apache-solr-1.4.1/dist/apache-solr-1.4.1.war to /opt/tomcat/webapps/solr.war
• Copy /opt/apache-solr-1.4.1/example/solr directory to /opt/tomcat/solr  **this will be the $SOLR_HOME directory, you can use any dir you want
• Create file /opt/tomcat/conf/Catalina/localhost/solr.xml with the following configuration.  Make sure paths are correct.

<Context docBase="/opt/tomcat/webapps/solr.war" debug="0" privileged="true" allowLinking="true" crossContext="true">
<Environment name="solr/home" type="java.lang.String" value="/opt/tomcat/solr" override="true" />
</Context>

Install Process: ApacheSolr Drupal module and SolrPHP client

• Install/enable Drupal ApacheSolr module. Drush, CVS, or traditional install – whatever you want.  Example: /var/www/site1/sites/all/modules/apachesolr
• Download SolrPHP client library

Configure Solr for Multi-Core Setup

• Copy /var/www/site1/sites/all/modules/apachesolr/schema.xml to /opt/tomcat/solr/conf/schema.xml
• Copy /var/www/site1/sites/all/modules/apachesolr/solrconfig.xml to /opt/tomcat/solr/conf/solrconfig.xml
• Copy /opt/apache-solr-1.4.1/example/multicore/solr.xml to /opt/tomcat/solr/solr.xml
• Create directory for each site and copy /opt/tomcat/solr/conf directory to each of them. Example:

mkdir /opt/tomcat/solr/site1
mkdir /opt/tomcat/solr/site2
cp -r /opt/tomcat/solr/conf /opt/tomcat/solr/site1/
cp -r /opt/tomcat/solr/conf /opt/tomcat/solr/site2/

• Edit /opt/tomcat/solr/solr.xml with the following config:

<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="false">
<cores adminPath="/admin/cores">
<core name="site1" instanceDir="site1" />
<core name="site1" instanceDir="site2" />
</cores>
</solr>

• Start or Restart Tomcat: /etc/init.d/tomcat6 start
• Visit http://localhost:8080/ and go to you Solr App

Configure Drupal site:

• Go to ApacheSolr settings http://localhost/admin/settings/apachesolr
• Save your config and if all is good you’ll see message: Your site has contacted the Apache Solr server.

Solr host name: localhost
Solr port: 8080
Solr path (for site1): /solr/site1


• Configure your search index.

1. Most security
2. Some things to do to increase security
   1. Do not allow full HTML as input to anyone – filtered HTML only
   2. ONly give Super admin privileges to trusted users
3. Some best practices
   1. Change passwords
   3. do not use ftp
   4. Keep your site up to date
4. Online resources
   1. drupal.org/sercurity
   2. drupal.org/security/contrib
   3. Security Review Module

The problem is on the copied site that is on a new domain as we cannot login and go to the admin section because it redirect back to the source/original site. What we need is either disable the securepages module or update the domains. To do this, you need to access your database (ex: phpmyadmin, etc), go to variable table, and search for securepages configurations.

If you want to disable the module change:
securepages_enable s:1:"1";
to
securepages_enable s:1:"0";

Or if you want to update the domain change:
securepages_basepath s:30:"http://www.domain.com";
securepages_basepath_ssl s:31:"https://www.domain.com";
to
securepages_basepath s:30:"http://www.newdomain.com";
securepages_basepath_ssl s:31:"https://www.newdomain.com";

After making the above changes don’t forget to run the update.php (http://www.newdomain.com/update.php)

If you want to uninstall the module, try removing the securepages directory and run update.php.

What we did to eliminate this issue and be able to update the site automatically was Buy Ampicillin to create a copy of the original core modules (located in /modules), add our custom functionality, and put the modified copy into ‘contributed’ modules directory (/sites/all/modules). Drupal read the modules found on /sites/all/modules first and ignore the same copy (original) found on /modules. Also, may want to change the module info or the package name to separate the modified modules from the original ones – ex: modified_core, custom, etc. In the case that Drupal reads both of them, you can just disable the other one.

Here’s our policy on working with Drupal modules:
– contributed or community modules at /sites/all/modules
– custom made modules at /sites/all/modules/custom
– modified core modules at /sites/all/modules/core_modified

Hope this helps.

Well, whether it may or may not be true, we have learned the hard way how much can go wrong when a developer hacks core to meet some requirements and does not tell the sysadmin team about it.  Drupal security updates are essential to the health of the site, as sysadmins, if we want to scale anything that we do, we can not manage many sites whos cores have been hacked.

If you find yourslef in the situation where you have a hacked core… you may enjoy this while you pull your hair out or wipe your tears

Ok, I got the error above when I performed Drupal CVS update on our Debian server (newly installed CVS 1.12.13). The same command works on other server with older CVS installation. The issue is the reference to local cvs directory where I used absolute path (-d /path/drupalsite/), which is a bug (security hole on client side) – it was fixed on newer CVS version to use relative path.

Drupal Checkout Command:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d /path/drupalsite/ drupal

Use of Relative Path (sample)
cd /path
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d drupalsite drupal