APC (Alternative PHP Cache) is a free, open, and robust framework for caching and optimizing PHP intermediate code. APC is a great tool to speed up a php driven site and I can’t even think of a big site running on a php framework without an opcode cache (other good choices are eaccelerator or xcache). Why would not everyone want to use this? The reason why this is not enabled by default everywhere is because in certain situations it can break things. Most peoples will not see any problems, but still, if you run a server with many clients sharing the same apache service this might be a problem (as the apc module loading it is a server-wide config). This post will show how we can use APC globally and disable it for some vhosts (that might have a problem with using APC) or the reverse to just use it one a special vhost that might need this.
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.
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: securepages_enable s:1:"1";
to securepages_enable s:1:"0";
Or if you want to update the domain change: [Read more →]
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
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: 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.
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.
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:
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.
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
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.
Facebook error – not funny at all, especially since it happens a lot
