I’ll assume that you have installed apc already, if this is not the case this will probably be something as simple as running
pecl install apc
or downloading the archive from pecl and running:
phpize; ./configure; make; make install

The APC extension needs to be enabled either in php.ini or in one included file with a line like this:
extension=apc.so
there are many other parameters that apc can be fine tuned (see the official doc for more info), but without any other change, just with this line apc will be enabled on all the vhosts on the server.

Disabling some vhosts from using APC
- if we want to disable APC for a particular vhost we just have to add to the vhost config or to .htaccess:
php_flag apc.cache_by_default Off

Enabling APC only on some vhosts
- if we want to have APC disabled by default globally we will have in php.ini:

extension=apc.so
[apc]
apc.cache_by_default=0 # disable by default
... other apc settings...

and we will enable APC for the particular vhost config or using .htaccess using:
php_flag apc.cache_by_default On

Hopefully you found this post useful and this will give you a reason to use APC with more confidence knowing that you have the granularity to disable/enable it as needed in a shared environment.

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.

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].

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.

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

Drupal.org-MakingDrupalFaster.v4

First off, this is great.  It should improve the speed of looking up the DNS info of many sites, and if the service takes off, it should take the load off your NS.

The focus on speed if very clear, the Google public DNS server lists this first as one of the advantages.  It also points to the speed problems caused by DNS latency.

Google Public DNS IP addresses

The Google Public DNS IP addresses are as follows:

• 8.8.8.8
• 8.8.4.4

Enjoy.

Top web site error pages – my favorites.

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

Obama.org site not availalble 404

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.

crowdspring.error error

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

be cool - you tube 404 image

5) Witter error – before the whale

twitter error, before the whale

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

google error

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

Facebook error – not funny at all, especially since it happens a lot

9) the now famous twitter whale – simply brilliant

twitter whale

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

techocrati 404

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.