Running DW code

[denise]

At OSCON, Mark and I were discussing adoption of the DW code by other sites, and a little bit of how we could work to that point. Mark's interested in cross-site federation and open social-media protocols, but I'm thinking a bit more about making it easier for people to install and run the DW code.

Right now, the code we 'ship', in dw-free, is pretty fully functional. Somebody could grab that code, install it, and have a working and running site without a ton of custom work. It's not easy, though, and there are a lot of "gotcha"s in place during the install process.

Better install documentation is a must, and that's something we can work on, but I'm throwing the option open to the field: what else can we do to improve the DW install process, with the end goal of having someone be able to get the code and get it running with as little hassle as possible? We have a bunch of bugs open to do that, but what (besides documentation and an installer) do you think people would be looking for?

Comments

[sophie]

If possible, I think it would be nice to have a set of scripts that can be run as root (well, run under sudo). Since our supported distro is Ubuntu, I'd suggest having the scripts tailored towards that first, and then we can modify that later, if wanted, for other distros.

They would handle the installing of the pre-requisites based on what the user wanted to install (the pre-requisites would be mostly Perl modules installed using apt-get), setting up a new user, installing various servers, etc.

The reason I say "scripts" instead of "script" is because if you're going to want to do anything production-wise, you're probably going to at least want the web server on a different machine from the database server, so it's probably best to have separate scripts for each of the different parts that can be potentially on different machines.

Of course, the Dreamhack machine already has a fully automated script, but it's not quite what we'd need here because it relies on the pre-reqs already being installed, and assumes a few things about the environment. We might be able to use it as a base, though.

On the other hand, we may want to opt for something based on Puppet, which is what DW.org itself uses to configure machines. I don't know much about that, so someone else would need to speak about that.

[aphenine]

I like the idea of thinking about open social media protocols in developing things for future use. It strikes me as something that would have to be tackled anyway, if DW wants to utilise crossposting and reading pages that span different sites to its fullest potential. It will also evolve naturally out of these segments anyway, so if it's going to happen, it may as well be done properly with an ear open to those who it affects.

On the other hand, in the here and now, making DW easier to adopt is a good idea too. I can't really add anything about it, so I'll stop now.

[allen]

We probably should document the things needed to do to run a full production site a lot better. It's not that bad to get a dev environment going, but once you step past that to configuring all of the other pieces you need (perlbal, mogilefs, memcache, theschwartz workers, gearman, whatever else) the documentation suddenly becomes a lot more sparse.

Some different production targets would also be good. Want to run a local dreamhack? Do these things. Want to use DW as a personal blogging platform? It's overkill, but here's how you'd do it. Private site for running an RPG? Blogging platform just for you and your personal friends? Open site for a small community? Want to replace Facebook? Each of these might require slightly different configuration options. And even if you assume that each site would be unique, it would still be good to have a few different sets of starting points before enabling/disabling features a la carte.

We could do a better job of separating out the user-facing custom configurations. It would be helpful if there were a single place where you could customize the site name, welcome text, etc., instead of having some of it in etc/config.local, some in htdocs/index.bml, etc.

...Hmm, you know, if we separated out the local customizaitons, then there'd really be no reason that we couldn't distribute DW as a pre-configured package rather than getting it from the source repository and configuring it by hand. It'd be a lot of work for somebody, but if DW were packaged as a PPA it would make doing production (as opposed to development) installs a whole lot easier.

[denise]

Yeah, ideally that's my end-route pipe dream. *g* I'd love to have it as installable as, say, Wordpress is.

[matgb]

Moreso please :-)

WP took a step back with 3.x, WP MU did install itself fully if your server had the right spec, but WP still requires the installer create and upload a wp-config file in a text editor.

If MU could install without that and make its own config file, then the basic setup should be able to, but they've merged MU into basic WP now, but require turnign it on in config.

But yeah, wot Allen said. Although it'll be ages until I'll be able tos et up my own server,t he eventual goal must be lots of mini sites working together for dev but separately for hosting.

[jadelennox]

An apt (deb or rpm) package with an auto-config screen. As long as we are pipe dreaming.

And more realistic: An easy-to-maintain way to modify the various config (local, private, etc.) scripts while making sure you aren't losing changes in code updates.