Hi everyone. I'm the author of the initial stackscript over on Linode.
First, I apologize for not updating everyone sooner, but I've been working two positions at work and have been extraordinarily busy since about December of last year.
I've been aware that the StackScript has been broken (or close to it) for some time now, but the reason has been for the most part due to the huge changes that have been going on within the Mercury project itself. It was pointless to try to put in the effort to fix the script if it was only going to break again within a few weeks.
I bumped into joshk at DrupalCon and quickly asked if he was interested in keeping that maintained. He responded that he was, so the next question was regarding when he hoped things may stabilize to the point where efforts wouldn't be wasted. It's hard to set and keep software deadlines, so treat this a grain of salt, but his goal was by DrupalCon London this year.
Just yesterday I emailed him about some questions, and he pointed out the work that boztek has done. I had been unaware of that up until then, but I'm thrilled he's done it. In the interest of not repeating work, I think I'll make the next version of the StackScript basically get the environment setup to where I can download his repo from GitHub and run the setup program. I should be able to also automate the steps in his readme.
While this certainly makes my job easier, it introduces a dependency. I'm totally fine with this, so long as the software in question works. From what I can gather, it seems to work quite well.
So, as far as timeline, I'm not even offering anything up just yet because I have some logistics to work out before I begin. I just wanted to update everyone with the fact that I am planning on doing it Real Soon Now, and to open up discussion about the new direction the script will take.
Thanks - Justin
Comments
A "production" branch would be nice to have on Github
Instead of pointing the StackScript at the master branch on Github, it would probably be a good thing to have a tested production branch that we can point at so that the script isn't broken when new updates are pulled in.
duplication of effort?
Perhaps it would be best to just wrap bozteks work with a Stackscript include wrapper, so the process can be launched from the Stackscript installer and is included in those lists on Linode, but at the core the processes are identical. Definitely agree we need a stable, tested branch for this...
heh, oh you said that...
doh, anyways I'm willing to help testing as well.
Thanks for your update!
Thanks for your update! Looking forward to testing it!
Per André Rønsen | Front | Twitter: @perandre
very cool
This is something I'm very interested in as well. Looking forward to helping out where I can.
Kyle Mathews
Stackscript problem
I kept getting an error saying that /etc/apache2/conf.d/aegir.conf does not exist when I tried to restart apache2. i know the install.txt says that this would fail, but I wasn't able to hit my server from the domain . . .
I'm not sure whether I made the DNS records incorrectly or the /etc/apache2/conf.d/aegir.conf not existing was the problem.
I was working on the StackScriptID=1027
what you don't know will inspire you
This isn't an Aegir discussion
It looks like you're trying to get Aegir working. This discussion is about getting Mercury working. If you're having trouble with Aegir, the right place to ask questions is over at http://community.aegirproject.org/
Kyle Mathews
I usually don't chime in on
I usually don't chime in on these conversations, but your comment reminded me of Clippy from MS Word :)
--
Cameron Eagans
http://cweagans.net
Haha!
I'll take that as a compliment :)
Kyle Mathews
I'm pleased to see some
I'm pleased to see some progress on fixing the linode script. I use it quite often for clients and my servers
Understanding that @justin has very limited time to work on stuff like this like the rest of us, I would love to see if we CAN help keep this up to date, even if you have to roll out a new version every 3 weeks to keep it working. It is in fact the second most popular script on linode. In my fantasy world, these should be fairly minor changes (version numbers, dependencies, etc) and I would be happy to sponsor a linode dedicated to nothing but rebuilding and testing this stackscript.
Of course I'm not a full time sysadmin or stackscript writer so I could be way off on my assessment on how complicated it is and my real motivation is I use this script a lot and currently can't :-P
Matthew Connerton | matthew@aspiringweb.com
Aspiring Web a design & development agency
Tagging is the answer here too
Ideally, we can configure tagging so that our stackscript will only pull down a tagged (and fully tested) version of Mercury. The code within tags never changes, so you're always guaranteed the same result. This is very similar to module releases in contrib. You may not be guaranteed to have the latest and greatest Mercury configs when you boot up, but you can always update that yourself after installation.
As new tags are tested and proven to work, we can just update a variable in the stackscript to point at the newer tag.
That would be great. My
That would be great.
My question to you is, what do you need to get a working copy of the stackscript going this week? I am more than willing to help within my means for that
I saw the boris script on github and it looks great, but it's missing a little bit of documentation. All that is there is "run apt-get install etc.." but it doesn't tell me what steps I need to take to prepare the server ahead of time. Do I need lamp installed first? a bare server? etc.
Again, my goal here is to get a working script again so I can deploy some servers that I cannot do right now as I don't have the sysadmin chops to install this from scratch.
Matthew Connerton | matthew@aspiringweb.com
Aspiring Web a design & development agency
For what it's worth I've been
For what it's worth I've been working on creating a cleaned up 'public' release of the mercury stack (which can then be made linode-stackscript friendly). More info in my comment here: http://groups.drupal.org/node/134204#comment-442534
However, I've been pretty busy at work so I've been working on this on my own time. Just wanted to post here because it is in the works... but need a bit more free time...