I made a copy of Drupal6 site with SecurePages module installed and configured. This module is configured to redirect all or certain pages to https - depending on your configurations. For our setup we usually include the login and admin sections to redirect to https.

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:

1

securepages_enable  s:1:"**1**";

to

1

securepages_enable  s:1:"**0**";

Or if you want to update the domain change:

1
2

securepages_basepath s:30:"http://**www.domain.com**";
securepages_basepath_ssl s:31:"https://**www.domain.com**";

to

1
2

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.

I noticed lots of email being relayed on one of our shared hosting server, CentOS5 with Cpanel and running Exim, and the strange thing is that the email server (MX) for these accounts are pointing to Google (GoogleApps), and we have correct entries for localdomains and remotedomains for these account. The relayers (‘From’ server/address) looks like spam anyway. From the mail logs I noticed that the relayed messages have ’fixed_login’ and key (’rsa-sha1’) for their authentications.

Since the mail server for these accounts are pointing to other servers, I deleted all the email accounts, forwarders, mailinglists, etc. After this I’ve seen sending error/failure messages from mail logs of the said accounts It shows ’fixed_login authenticator failed for hostxx’ [535 Incorrect authentication data].

Although we made it a standard not to make any changes to Drupal core and core modules, there are times that our developers really need to make changes to core modules in order to add the required functionality. Cases like additional feature for ‘user’ or ‘comment’ modules and so on. At this state we can’t perform automatic update on our sites as we might overwrite the changes - so we need to do the update manually. Well, this is ok if you maintain one or two sites, but if you have more than 100 sites then it will take you some time.

What we did to eliminate this issue and be able to update the site automatically was 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. :)

You may know that Drupal’s developers have a saying about hacking core, its whenever you hack core, god kills a kitten.

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 :)

Absolute Path Error:

1

cvs [checkout aborted]: absolute pathnames invalid for server (specified `/path/drupalsite/')

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:

1

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)

1
2

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

Last December I gave a talk at the Chicago Drupal Meet Up on increasing your Drupal site’s performance.  I thought I would share the slides from that presentation with everyone - so here it is.  I tried to cover a fairly wide array of topics at a high level.  We started with page load performance definition, identifying the differences between the high availability and scalability concepts and then we jumped into page load performance.  The talk was very drupal specific in terms of load page improvement recommendations, and we covered a few MySQL drupal performance tweaks, some apache modules and tools, such as YSLOW, Google page speed and JMeter.

Drupal.org-MakingDrupalFaster.v4

My small collection of my favorite 404 and error messages on the web, from mostly big sites.  Some are humorous, some are quirky, and I think they are all great.  No one is perfect.

Enjoy.

Top web site error pages - my favorites.

1) barrackobama.com - simple, to the point, diffusing.

2) Plaxo.com - (oops! There seems to be a problem.  I’ll tell you what… let us fix it and this can be our little secret.)  humorous

3) crowdspring.com - (our servers are currently fighting among themselves and we’re putting them into a timeout.) - if you have kids you will appreciate this.

4) youtube.com - (“The functionality is not available… Be cool - we’ll be back 100% in a bit.”) - I like the slang

5) Witter error - before the whale

6) Google apps error - not funny, not cool… common google, you can be fun too!

7) suumbleupon.com error - (“we’ll be right back, in the mean time why dont you go outside and play for a while”) - LOVE this one

8) Facebook error - not funny at all, especially since it happens a lot

9) the now famous twitter whale - simply brilliant

10) technorati.com error (“Doh! The Technorati Monster escaped again.”) - good one

With the release of Apache 2.2.12, we can now configure multiple SSL sites in one IP address. It is available of you have Server Name Indication (SNI) extension for OpenSSL. Visit TechRepublic’s post on ”Configure Apache to support multiple SSL sites on a single IP address” for details and vhost sample configuration. And for complete reference please refer to this page ”SSL with Virtual Hosts Using SNI” and Apache mod_ssl documentation.

We’ll try this on our server and hopefully offer this to our shared hosting clients who wants SSL but not interested in paying extra for a dedicated ip address. :)

Adding additional block devices to XEN guests is accomplished using xm block-attach command. In this example I am exporting an external USB hard drive that was recognized as /dev/sda1 by the hosts kernel. Important thing to keep in mind is that you must use xvdX as the guest block device name.

1

xm block-attach 6 phy:/dev/sda1 /dev/xvda1 w

This command will export /dev/sda1 on host machine to guest domain 6 as /dev/xvda1 with write permissions.