I just posted an update to the Linode StackScript for Mercury. Instead of biting off the huge chunk of jumping from 1.0 in Karmic to 1.2 on Lucid, I decided a "baby step" was in order. The StackScript now will install Mercury 1.1 on Ubuntu 10.04. I've tested a few times on my own personal Linode, and it works fine there, but I haven't tested all configurations -- please report back with any successes and/or failures.
In the interest of full disclosure, the link to the script above contains my Linode referral code. If you use that link and purchase a Linode instance with it and stay a customer for 90 days, I'll get a $20 credit to my Linode account. If you want to use the script without sending me the referral, simply remove the 'r=c4f79463ba583ec1f15e3307190bda4bda9d65df&' from the link.
Comments
Thanks I'll try it right now
Thanks I'll try it right now
Great news!
Great news, I'll give it a test in the next couple days. The bozak script hasn't been working for a while now, so i think this was a wise move. As for 1.2 i think there is too much configuration specific to Pantheon, and next to no documentation, for now at least.
Have you tried this on your local host?
Before I commit to Linode or one of the others, I would like to try this on my own machine. Has anyone set that up? Is there a working and comparable stackscript to set Mercury up on my local Ubuntu server?
I went for it
It seems to work, I have a Drupal 6 site working with your script. I was expecting a Drupal 7 site though. Will the next step be to Drupal 7? I actually do not want to build a Drupal 6 site .
FYI justintime, I used your code so I guess you might get something for that.
What is the ETA for Drupal 7 on Mercury?
Referral code & D7
Thanks - I actually meant to include the fact that I had embedded a referral code in the link, but got pulled away in the middle of posting and forgot to add it. I updated the original post with the facts about the referral code.
As for Drupal 7 support, Aaron mentions that it's already supported, but I'm guessing that's only in the 1.2 branch of Mercury, not the 1.1 branch that the stackscript supports now. I'll find out more when I get some time.
You are welcome
I am happy to use your referral code, I would not have given Linode a try without your script. Now I just need to figure out how to get to Drupal 7.
Actually I thought Drupal 7 was indeed supported which is why I was so surprised when I got the Drupal 6 screen. Is the core Drupal (in this case Pressflow) something that we can upgrade or is that just for generic LAMP stacks applicable? I look forward to what you find out. Thanks!
I setup Mercury on a Linode,
I setup Mercury on a Linode, but used their step by step instructions, and did it on Debian 5. FYI - from what I've heard about Mercury, they are packaged this as a hosting service, which makes me wonder if a Drupal 7 version will even exist.
Linode has been freaking awesome for me. Love the company, speed, service, etc.
You can still install D7 on Mercury 1.1
It works like any other 10.4 ubuntu machine you setup with Memcache, Varnish and Drush, you just don't have to build the server by hand. Pantheon already supports D7.
How do we get there?
I feel like this project is a giant bushy shrubbery and I made it inside but on the wrong branch.
So I have a Mercury 1.1 stack and a Drupal 6 setup installed. What steps are necessary to install D7 at this stage?
I know too little about the tuning that is going on behind the scenes in Mercury, will D7 sites run equally well on Mercury 1.1 as do the intended D6 sites (all things being equal, same modules, same theme etc.)?
The main difference that
The main difference that Mercury introduce is that instead of the stock Drupal core, it installs Pressflow Drupal Core variation. As of Mercury 1.2, it still installs Pressflow 6. While there is a Pressflow 7 development, David Strauss, the maintainer of Pressflow, recommends that one installs Drupal 7, instead of Pressflow 7. Pressflow 6 is basically a backport of Drupal 7 or the other way around. Most of the enhancements that came through Pressflow 6 are now in Drupal 7 core. These are the enhancements that make Mercury perform much better than a normal Drupal 6 or 7 installation. For instance, Drupal 7 stock installation does not have Varnish or APC. You need to install them yourself. Same goes for Apache Solr. The Mercury script does all that for you.
Now, having said that, there is nothing to stop you from replacing the Pressflow 6 installation with a Drupal 7 installation. You will need to tweak the settings.php, but other than than, it "should" work out of the box with the rest of the mercury stack - as always YMMV.
Aruna
There's another big difference
There's another big difference too. With D6 + Pressflow, you get the Mercury installation profile, that does things like point your caches to your memcache server, configures the solr module to point at the solr server, etc. You can certainly do all of that yourself, but there's likely a D7 version of the Mercury install profile hanging out somewhere. I'll see if I can track it down if it exists.
Tweaks in settings.php
Absolutely right Justin - though if you run Mercury first most of that would be done for you. In D7, you then need to tweak your settings.php as most of the ancillary settings (Varnish / Memcache / Solr) can be done there.
Having said that, Pantheon is now offering Drupal 7, so there must be a Drupal 7 profile somewhere in Github :)
Aruna
Do you mean
Aruna,
Do you mean, install Mercury 1.1 then delete the Drupal 6 and install Drupal 7 then tweak settings.php?
Justin,
How much of Mercury 1.1 is Pantheon's own custom code? Is there any custom code or is this just tuning apache, Varnish, Memcache and Solr settings?
What Mercury does
From a 40,000 foot view, here's what mercury does:
1) Installs necessary packages
2) Takes inventory of the resources available on the system
3) Configures the various services to use the appropriate amount of resources for the server it's on
4) Downloads Drupal and a few contrib modules, and configures those modules to use the configured services.
If you remove pressflow from /var/www and install D7 there, you still have steps 1-3 done for you. You just need to duplicate step 4 via clicking through the D7 UI.
Just a note that if you do this, I would move the pressflow install to someplace else so you have the original install to reference if need be.
What happens if
Hi Justin,
Thanks for the Everest plus overview, that is helpful.
This is your script isn't it?
http://www.linode.com/stackscripts/view/?StackScriptID=353
I can see where the pressflow is added between lines 198-223. How big of a leap is it to change that to D7 with the necessary modules? Is the rest of the script dependent on pressflow being there?
If anyone tries this, I'd be
If anyone tries this, I'd be interested in the results....but right now I'm leaving my Drupal 6 / Mercury install as is! =)
Notice after install:
I reinstalled the mercury stackscript on another linnode node and at the admin screen I get this notice repeated about 50 times followed with the last line. Is this to be expected?
Notice: Undefined index: in update_xml_parser->end() (line 257 of /var/www/modules/update/update.fetch.inc).
One or more problems were detected with your Pressflow installation. Check the status report for more information.
not working as before
I have tried a fresh install (several times) and I get as far as the email in my account (containing the install url):
Full View
Mercury StackScript is complete
From:
Mercury StackScript no-reply@linode.com
To: myemail@ymail.com
Your Mercury installation is complete and now ready to be configured: http://xxx.xx.xx.xxx/install.php Select "Mercury" as your installation profile, and continue as you normally would.
Enjoy the speed of Mercury!
From that url I get this in firefox.
Oops! Firefox could not connect to xxx.xx.xx.xxx
After several tries I assume something has been changed in the scripts. Can this be true? Can anyone else build this up just to double check?
Logfile
Could you post your /root/stackscript.log file somewhere? A pastebin link would probably be best.
Here is my log
Thanks for looking at my log Justin.
What do you see in here? What do you look for?
http://pastebin.com/JR7HgDyJ
what to look for
It's like what the justice said about porn, I can't define it but I know it when I see it :)
Line 1732 in your pastebin looks to be the culprit. Not for sure why yet. Sit tight and I'll take a look.
Fully qualified domain name
Hah - it's your fully qualified domain name that you're entering in the form. You can't "fake" that. I'm assuming you don't own www.mywebsite.com...
When you fill that in, it uses it all over the place -- in postfix, and specifically, in configuring your bcfg2 client to talk to your bcfg2 server. You can use a FQDN that linode gives you in your control panel (something like li-12345.members.linode.com) or leave it blank, but don't fill in a name that you don't have pointing to that particular server.
clean
I sanitized that post of my url and email. Everywhere is says Mywebsite I replaced that. I used the domain zone in my DNS manager (my url).
step by step without a script
I have been trying to do it all step by step following this: Deploy High Performance Drupal Sites with Mercury on Ubuntu 10.04 (Lucid) http://library.linode.com/application-stacks/project-mercury/ubuntu-10.0... But it is dated. The solr version for example is outdated. It has a few of these kinds of holes. I still do not have it working.
Fix released
Found the bug. Either Ubuntu or Linode (my guess is the latter) changed /etc/hosts so that 127.0.0.1 resolves to localhost.localdomain instead of localhost. The SSL key generation routine had a hardcoded 'localhost' in it, so that was causing the breakage. I put in a fix that should be dynamic to future changes, and tested it. Worked for me, would appreciate your feedback!
Thanks Justintime! I just
Thanks Justintime! I just tried the StackScript last night for the first time and couldn't figure out what I was doing wrong. We are wanting to test this stack against our currently hosting environment in preparation for a large promotional campaign that may push us into the 10,000 pages/hour range for a few hours so trying to get ahead of the curve.
I just got the revised script (an hour ago) and that did the trick. Now I gotta figure out if I install the pressflow or mercury profile. :)
Thanks again! My forehead was getting flat from hitting that brick wall so many times last night.
This time it worked
I still get this notice over 50 times on the admin page when I go there for the first time:
Notice: Undefined index: in update_xml_parser->end() (line 257 of /var/www/modules/update/update.fetch.inc).
Good job finding the bug Justin.
I am still very much interested in getting Drupal 7 in there. Any suggestions on how to do that or what to be aware of trying to get there. Looking at the outdated step by step build of Mercury on linode I see changes in several files which I do not know if this is happening automatically with your script or if something else is being configured. Do tell :)
Thanks Oceanman. To be
Thanks Oceanman. To be specific, I too am seeing these errors in the Drupal (Mercury) installation as a result of the available updates check.
http://my_fqdn/admin/reports/updates/check
It appears that Drupal (PHP) is unable to do a get request out to the internet from the Linode. Just getting back from lunch and will see if there is something that pops to the surface as a solution in case Justintime is tied up.
Error is a notice only
That error is actually only a notice. At least on my Linode, update seems to be working fine. It's likely just a combination of high error_reporting in php.ini coupled with a little bug in either Pressflow or update.module.
Short on time
I'd love to dig in on D7, but I'm up to my eyeballs in work already. My hunch is that doing D7 on Mercury > 1.1 will be much easier than retrofitting, but I'll check with the Pantheon guys about that.
Would with work with ssl?
Justintime:
Would this script work with a site that runs entirely behind ssl?
I'd appreciate your take on this.
Thanks
Varnish doesn't speak SSL
It would work, but out of the box, neither Apache nor Varnish are configured to listen on port 443. Varnish doesn't do SSL, so you'd need to frontend that with something. You could do that with Apache, but in the interest of high performance, I wouldn't do that.
Instead, I'd setup either Nginx or Pound to do SSL on port 443, and have that proxy back to Varnish listening on port 80.
APACHE <-> Varnish <-> Pound
Thanks Justintime.
So you'd get apache serving pages on private port. Varnish acting as a reverse proxy listening on 80 for caching purposes and Pound acting as an ssl proxy on 443. Have I got that right? Any preference between Pound and Nginx? Haven't used them before... and why not make apache listen to 443 and a private port (I've got it listening currently on 80 and 443). It's one less piece in the puzzle....
The thing that I like about this approach is that the ssl complexities are decoupled from the sight which is cool. Ok. I'll get the sight up first and then deal with ssl.
Will pantheon offer ssl, do you know?
btw, installing as we speak on Ubu 10.10 ugraded. Have had to replace the source with a bona fide source and set some of the variables in UDF but so far so good...
You got it
Mercury runs Apache on port 8080. Varnish listens on port 80. You get that much out of the box.
You don't want to use Apache for SSL on an all-SSL site because of the way it allocates one heavyweight process per TCP connection. While it may work for testing, if you're looking at Mercury you're anticipating a large number of simultaneous users. If they're all going SSL to Apache, you've effectively inserted a very tight bottleneck into the stack.
Personally, I've never used pound, but I know it's certainly capable. I'm a little more familiar with NGINX, but I really don't think there's that big of a difference between either.
I can't find any facts to back it up, but I'm pretty sure that the Pantheon hosted service does support SSL and uses pound as the SSL gateway. I would ask in #pantheon in Freenode IRC instead of taking my word for it :)
Sorry I did mean site...
It's been a long day. My bad.
CPU runs at 100% all the time
After installing the mercury stack I left it running for the last 10 hours. There is no traffic to this test site. Despite that my cpu usage is 100% and my mail box is full of notices from Linode:
Your Linode, linodexxxxxx, has exceeded the notification threshold (90) for CPU Usage by averaging 100.6% for the last 2 hours.
What is the remedy for this? Does anyone else have this happening?
Confirmed
It's hudson doing it, but I'm not for sure why yet. Odd, because this is a Linode that I've had installed for a couple weeks, and after rebooting it to test some things yesterday, I'm seeing the same thing. If you just want to kill hudson, just do a
/etc/init.d/hudson stop- that should fix your CPU.I'll report back my findings on what's going on later.
Turning off Hudson worked
My cpu drops to zilch with Hudson off. What is Hudsons job exactly, why do we need it?
I was also wondering if apache solr was working with this stack? I could not find it.
Sorry I've been swamped
Sorry I've been swamped lately. For whatever reason, when I stopped Hudson, CPU usage came back down to 0. However, after restarting it again, the CPU usage stayed at 0, and has stayed there for days. Can you start it back up and see if you get the same?
As for what hudson is doing, it's running drupal cron on a regular basis.
Apache Solr is (or at least should be) in the stack. You can visit admin/settings/apachesolr on your site, and it will tell you if it's working properly or not.
What's wrong with this install?
Hi Justintime,
I've tried to install the script on Ubuntu 10.10 64 bit server running in VirtualBox.
I ran apt-get update, apt-get upgrade first.
As par of the install, I got openssh, postfix, lamp installed.
I think I'm pretty close to getting it up and running but some things are failing:
I got the following warnings:
< update-rc.d: warning: /etc/init.d/mysql missing LSB information
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/apc.so' - /usr/lib/php5/20090626/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/apc.so' - /usr/lib/php5/20090626/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/apc.so' - /usr/lib/php5/20090626/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0
No release history available for varnish 7.x. [warning]
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/apc.so' - /usr/lib/php5/20090626/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0
Before I show you the StackScript.log, I've made a few changes to the StackScript.sh because I wasn't sure that < UDF would be understood on ubuntu. also the source is more traditional?
====== changes to the script
!/bin/bash
<UDF name="fqdn" Label="Fully Qualified Domain Name" default=""
example="Optional fully qualified hostname, ie www.mydomain.com -
if empty, the hostname will default to the one assigned by Linode." />
<UDF name="admin_user" Label="Administrative User" default=""
example="Optional username to setup with password-less sudo access.
You must also add the ssh public key below.
This user is added as the first step, so you can ssh in before
the script is finished." />
<UDF name="admin_pubkey" Label="Administrative User's SSH Public Key"
default="" example="Optional SSH public key (from ~/.ssh/id_dsa.pub)
to be associated with the Administrative User above." />
StackScript written by Justin Ellison justin@techadvise.com
source ./bash_include.sh
DB_NAME=MYDB
DB_USER=TheUser
DB_PASSWORD=ThePassword
FQDN=
hostname --fqdnADMIN_USER=TheUser
ADMIN_PUBKEY=""
NOTIFY_EMAIL="email@destination.net"
Hum... it does not seem I can paste the content of the log here... I'm not seeing it in the post....
Alright, log of install at pastebin
Here's a link to the log at pastebin: http://pastebin.com/5rWXYYSC
Install Failure
Thanks for the script...really helpful.
However, I can't get your latest update to install. When I get the email notification that the script has completed, I get an 'unable to connect to server' error.
Also, looking in the stackscript.log I see the following:
Starting Pressflow Update Script/usr/local/bin/update_pressflow.sh: line 27: cd: /var/www/: No such file or directory
If I ssh into the server, the www directory is gone and there doesn't seem to be pressflow core files anywhere...
Any help would be appreciated.
edit: Just noticed the earlier post with the same problem. However, I did not enter a domain name in the configuration and still have the issue.
...
I've obviously screwed something up - more log entries:
=> 05/30 19:21:23 Installing pressflowmkdir: cannot create directory
/var/www/sites/default/files': No such file or directory cp: cannot stat/var/www/sites/default/default.settings.php': No such file or directorychown: cannot access
/var/www/*': No such file or directory chown: cannot access/var/www/sites/default/settings.php': No such file or directorychmod: cannot access
/var/www/sites/default/settings.php': No such file or directory chmod: cannot access/var/www/sites/default/files': No such file or directorysed: can't read /var/www/sites/default/settings.php: No such file or directory
sed: can't read /var/www/sites/default/settings.php: No such file or directory
=> 05/30 19:21:23 Done installing pressflow
Pressflow never got installed...
Can you place the entire log
Can you place the entire log in a pastebin for me?
...
Thanks for looking at it.
http://pastebin.com/2zi0FCV0
Apache
Something went wrong with the Apache installation, but I can't seem to figure out what.
Have you just tried deleting the Linode and re-running the StackScript again? If not, can you?
...
Yeh. I tried that. I also tried to install it on another linode and got the same failure...
Darn, okay, well, I need to
Darn, okay, well, I need to reproduce it then. Give me some time, but I'll get back to you.
Reason for new problems
Justin,
Are parts of your script being occasionally updated by pantheon? Is this why the script does not continually work? How can we experimenters get a configuration snapshot of our systems? It would be really helpful to know what is being configured in the various components like varnish, hudson, apache, solr and the rest. How can we take a full inventory of our settings and tweets done by the scripts?
Push-button convenience or omnipresence -- pick one :)
@Oceanman - Things aren't supposed to happen to break things, but unfortunately, they happen. 2 problems ago, it was an update released by the BCFG2 authors that broke things. Last time, Linode changed something in their Ubuntu image. Who knows what happened this time.
Issues like these are why many shops standardize on less-bleeding edge distributions like Red Hat and Debian. When you change things less frequently, thinks break less frequently. That's why some never apply any updates to a working production server (although I completely disagree with the practice).
The only way to truly know what's being set on your system, is to look at the source code in the StackScript, and to go over the BCFG2 repos and see what it's doing to your instance. It's all opensource, and you're more than welcome to do so. However, if you know every single setting that's being applied by Mercury, then you really don't need Mercury, except maybe to save time. Nice catch-22, huh?
Now is a great time to point out that the StackScript is a best-effort operation. While I do my best, my time and resources are limited. If it's absolutely essential to your livelyhood that your Mercury site is up, then you probably want to look into the paid Pantheon service -- that's multiple people's full-time job to make sure your server is up and running.
Issue found, working on the fix
Sheesh. A bug in drush make that's exposed by apachesolr is triggering the entire makefile process to not complete. The core issue (in drush make) is reported (ironically by me completely unrelated to this particular instance of the bug) here: http://drupal.org/node/1159548
I logged an issue in the apachesolr queue (http://drupal.org/node/1176636) just so others might save some time tracking it down.
The fix is to use the bleeding edge drush make, but I don't like that as a permanent solution. I need to find a way to say, "if drush make's latest release is less than 6.x-2.3, then use dev". I should have a fix pushed out yet this morning.
Fix pushed
I just pushed the fix up to Linode. Tested by me just once, I'd love to hear reports of either success or failure :)
Worked Great
No problems for me. Installed perfectly as well as the Mercury profile.
Thanks a ton!
Successful deplyoment on Ubuntu 10.04 64 bit in VirutalBox
Justin,
Thank you for all the time and effort you've put into this. Your script ran successfully in a virtual box for ubuntu 10.04.
The following failure-related messages were emitted but I suspect they are harmless. I have included them here as an FYI:
/usr/sbin/service failsafe-x stop
< failsafe-x: unrecognized service
< Configuration file `/etc/init.d/vnstat', does not exist on system.
< Installing new config file as you requested.
< * Starting vnStat daemon vnstatd
< Zero database found, exiting.
< ...fail!
Also, your suggestion to use pound as an ssl front-end was right on. Easy to install and configure.
Thanks for the feedback. As
Thanks for the feedback. As for those errors, you can safely disregard them. It's coming from bcfg2, and I think it's there from earlier Ubuntu releases and was just never purged from the BCFG2 repos. Anyway, they're harmless.
Different result on a compaq box
Hey Justin,
I got a different result running the script on a real box.
I've installed ubuntu 10.04 64 bits fresh.
ran apt-get update /upgrade
ran the script.
It does not complete. Here's the tail of the log....
It ends with "fail to manipulate dmesg.
Also when logging the vnstatd fails with the message "no database..." and hudson throws its usual exception...
=========================
=> 06/03 07:47:32 Done installing pressflow
=> 06/03 07:47:32 Installing Solr Drupal module
=> 06/03 07:47:33 Done installing Solr Drupal module
=> 06/03 07:47:33 Configuring hudson
=> 06/03 07:47:33 Done configuring hudson
root@Banimelek:~# tail -n50 mercury_setup_part2.log
Running probe varnish_vcl_deliver
Probe varnish_vcl_deliver has result:
Running probe php_post_max_size
Probe php_post_max_size has result:
8
Running probe varnish_vcl_recv
Probe varnish_vcl_recv has result:
Running probe mysql_max_connections
Probe mysql_max_connections has result:
40
Running probe apc_num_files_hint
Probe apc_num_files_hint has result:
1000
Running probe innodb_log_file_size
Probe innodb_log_file_size has result:
1073741824
Running probe varnish_vcl_fetch
Probe varnish_vcl_fetch has result:
Running probe groups
Probe groups has result:
group:deb
group:lucid
group:ubuntu
group:amd64
Running probe apparmor_mysql
Probe apparmor_mysql has result:
/mnt/mysql/** rwkl,
Running probe apc_memory
Probe apc_memory has result:
128
Running probe key_buffer_size
Probe key_buffer_size has result:
16
Loaded tool drivers:
APT Action DebInit POSIX Upstart
Phase: initial
Correct entries: 487
Incorrect entries: 4
Total managed entries: 491
Unmanaged entries: 172
Installing ConfigFile /etc/default/hudson
The Following Bundles have been modified:
hudson-package ubuntu-lucid
Failed to manipulate service dmesg
Sorry, but I'm not sure how
Sorry, but I'm not sure how to help you much here - it's cool that it worked in a virtualized environment for you, but the script is designed specifically for use with Linodes and I barely have time to support that. With Linode, I can duplicate your setup exactly and test it myself. When you run it on your own box, I have no idea what hardware and or software might be causing issues.
Stackscript not working
Hi,
I just setup Mercury with stackscript (ID=353) and was having problems getting Drupal to start up. I could serve static pages from the document root, and /update.php but nothing else, just a Varnish 500 error. So I rebuilt the server thinking I'd entered something wrong and now it doesn't finish - no email sent. No /var/www directory created.
Something changed in the last two days since I first tried it. Wondering now, if there are other issues or files that didn't get loaded the first time.
I presume that after successfully running the script one has to add the IP to the /etc/hosts file and enter 127.0.0.1 to /etc/apache2/sites-available/default, correct?
Thanks for all your efforts!
UPDATE: Ha, about 10 seconds after posting I received the script email - not sure why it took more than 30 minutes. No need to modify those files either, already configured for Apache on the localhost. Apache will serve static files from the document root, /var/www, but Drupal won't respond - WSOD. I let the script create the DB but I didn't load any tables from the existing site yet. On the previous install Apache would serve /update.php, but now it won't - I get a Varnish 500 error.
UPDATE2: Operator error - now working, but not all pages load. Even some backend pages like /admin/settings/performance fail with Varnish 500 error. Need to flush the cache I believe but can't get there.
UPDATE3: Replaced all the Drupal files in the site root with my old 6.22 files (with same ownership and perms) except of course the sites directory, and everything is now working. Appears there's something wrong with Pressflow. I was getting a lot of PHP errors like this: PHP Fatal error: Call to undefined function features_include_defaults() in /var/www/sites/all/modules/custom_formatters/custom_formatters.module on line 281. Some incompatibility with my contrib modules? Weird.
Pressflow not drop-in on existing site
I've narrowed it down to /modules and /includes. If I replace those directories and contents with the non-Pressflow versions, the site works ok.
This is not a file permissions/ownership issue, as I've checked that and it's all fine.
I removed the Custom-formatters module as it wasn't being used, but then the same error just moved to the Rules module which I do use extensively.
What am I missing?
Varnish on 32 bit Ubuntu not recommended
Varnish recommends using a 64 bit OS because 32 bits isn't enough to map cache to virtual memory. From Varnish-cache.org:
Also, see this page: http://www.mikeperham.com/2010/01/18/varnish-on-32-bit-systems/
Any reason this script doesn't use 64 bit Ubuntu by default only?
I mistakenly used the 32bit choice but now see that in the Mercury profile you can select the Kernel, so apparently you can switch to 64 bit without having to rebuild the Linode. Tried it and it worked!
Deleted this comment
Deleted this comment
Discussion at Linode
Other people seem to be having the same problem as me.
I opened a thread on Linode: http://forum.linode.com/viewtopic.php?p=43308#43308
Gave up
Couldn't get Mercury to work with the stackscript and importing an existing D6 site.
Just using the standard LAMP stack with APC and it performs well enough for now.
I might give Pantheon a try when it's public at the end of October as promised.
I hope they offer reasonable pricing plans, like starting at $40/mo for a VPS.
Updates
Just a note that I fixed a couple of Solr issues and deployed them to Linode tonight.
My time is extremely limited right now, but if you have issues, please file them in the sandbox project: http://drupal.org/sandbox/justintime/1176768
Tried swapping D6 for D7 after clean install, no luck
Just for the record I tried swapping in Drupal 7 pressflow after running the stack script on a clean box, and I get a Varnish error. I've never used Varnish or memcache before though so there may be something wrong in my setup.
What I did was I copied all the differences between a clean copy of D6 Pressflow and the D6 Pressflow that was installed by this script. That included the mercury profile, the three modules (apache solr,memcache and varnish), some varnish/memcache settings in settings.php.
I'll play around with Varnish settings more and see if I can understand what's needed. Right now one thing I'm really confused about is what is represented by Mercury 1.1 vs 1.2, and why one would support something (D7) that another one would not.
32 vs 64
Justin - I noticed you didn't answer druplicate on the 64 bit issue, who wouldn't want to run the 64?... Is there an issue with doing so?