On Tue, 1 Oct 2013 11:11:16 -0700, Brion Vibber wrote:

Question for the group:

Would an officially supported general-purpose MediaWiki hosting service be useful to people who would like to run wikis, but don't have the time, expertise, or resources to maintain their own installation?

If so, what can we (as interested parties in MediaWiki development and use) do to make this happen?

-- brion

This topic and some of the stuff I've been reading (Google App Engine's PHP docs, various AWS docs, etc...) has brought up a few new additions to my old ideas around wiki hosting, especially my old self-serve idea.

Reading the AWS docs also gave me the thought of a wiki host run on AWS with load balancers, auto-scaled servers (the source of the wiki code in some object store or something not dependent on a server's filesystem), and the job queue in SQS using spot-instances occasionally to chew through the job queue by temporarily spawning a normally expensive server at a cheap price.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

I think Brion should have expressed some distinction between Wiki services (like Wikia), and hosting services that provide everything for MediaWiki to run smoothly, incl. caching software and other fancy stuff.

On Tue, Oct 1, 2013 at 9:23 PM, Jay Ashworth jra@baylink.com wrote:

Something other than Wikia, then?

----- Original Message -----

...

From: "Brion Vibber" bvibber@wikimedia.org To: "Wikimedia-tech list" wikitech-l@lists.wikimedia.org Sent: Tuesday, October 1, 2013 2:11:16 PM Subject: [Wikitech-l] Officially supported MediaWiki hosting service? Question for the group:

Would an officially supported general-purpose MediaWiki hosting service be useful to people who would like to run wikis, but don't have the time, expertise, or resources to maintain their own installation?

If so, what can we (as interested parties in MediaWiki development and use) do to make this happen?

[Please do not consider the existence of this email to imply that only regular posters on wikitech-l are allowed to read, comment on, or give opinions in this matter -- on the contrary, wider input is being requested. Please forward this question to anyone to whom it may be of interest. If you would like to get more input from other people, please feel free to contact them on your own, with or without a forward of this mail, and to make follow-up posts or comments as you need or want to. Please feel free to modify the question, the idea, the proposal, or make comments or additions. Be bold and get involved!]

-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 10/01/2013 02:53 PM, Brion Vibber wrote:

Ideally, my vision of a general-purpose wiki hosting service would provide options that orgs like Wikia generally don't.

If there is an effort to work with hosting providers, I would suggest finding a way to work with a large number of providers rather than working with individual providers.

For example, find a way to work with CPanel and VirtualMin as well as larger providers like Amazon's EC2.

This, along with Fedora and Debian packages, would make the whole "certification" process easier.

Mark.

On Tue, Oct 1, 2013 at 11:43 AM, Brian Wolff bawolff@gmail.com wrote:

I know this is not your question - but officially supported by whom? I would consider this massively out of scope for the wmf unless it was using revenue from this service to subsidize wikipedia. Even then it seems somewhat questionable, politically.

Excellent question: I'd say the key "official"ness markers of a hosting/support organization would be:

* the org has permission to use the MediaWiki name/logo/domains (need agreement with WMF?) * MediaWiki documentation endorses the organization doing the hosting/support (need general consensus with the developers, many but not all of whom are WMF employees)

I'd expect conditions of such would tend to include:

* the org invests its time, money, and people back into MediaWiki development

The actual organization could (maybe should?) be distinct from WMF; whether it could be a wholly-owned subsidiary like Mozilla's "Mozilla Corporation", or a separate mini-company like our MediaWiki release management team, or something else is something I feel needs a lot more input.

-- brion

<quote name="Matthew Walker" date="2013-10-01" time="12:32:08 -0700">

...

the org has permission to use the MediaWiki name/logo/domains

Name and Logo sure -- but why domains? This shouldn't be an exclusive thing; we should not be moving towards having only one shop offering this service. Maybe the WMF could have some sort of 'partners' program that handled licensing.

only if domain includes the trademark, of course.

...

MediaWiki documentation endorses the organization doing the hosting/support (need general consensus with the developers, many but not all of whom are WMF employees)

I don't think I can express how much I loathe organizations that do this. Varnish and Adiscon (rsyslog) are two offenders that come to mind. It seems to create an ecosystem where a new user assumes they must use the hosting provider for an install. And/or that any new features the vendor develops can be locked away and never documented except very sketchily in code. I don't mind having a page on mediawiki.org that would say something along the lines of 'if you dont want to host yourself...' but otherwise I feel the documentation / main site should be kept as neutral as possible.

I wanted to chime in here:

The idea that Brion expressed, I believe, is what we were going for with the public RFP for the MW Release Management work. It showed community support and something to point at (by anyone) if a weird decision was made (or interpreted as such).

So, maybe the default install doc shouldn't say "Step 1: Create account at $Prefered_Vendor" but we can definitely have "known good vendors" listed somewhere...

(just my personal opinion, not that my professional one should be taken as anymore more than that either, really)

Greg

On Tue, Oct 1, 2013 at 12:39 PM, Greg Grossmeier greg@wikimedia.org wrote:

The idea that Brion expressed, I believe, is what we were going for with the public RFP for the MW Release Management work. It showed community support and something to point at (by anyone) if a weird decision was made (or interpreted as such).

Yes -- by no means am I recommending that I or WMF simply crown a preferred vendor by fiat! We would definitely want to go through a similar process; in fact that RFP was one of the things that inspired me to start thinking about hosting & support needs over the summer.

So, maybe the default install doc shouldn't say "Step 1: Create account at $Prefered_Vendor" but we can definitely have "known good vendors" listed somewhere...

Yes; we certainly shouldn't discourage self-hosting or other hosting.

What I mainly want us to accomplish is to make sure that end-users have a safe, up-to-date, "fast path" to setting up their own wiki, with the support they'll need to grow it or move it to self-hosting when they need it. This is more about the "how" (what we can accomplish for our users) than about "who" provides the services.

That could just as easily be a group of recommended hosting services and a confederation of independent consultants rather than a standalone company.

-- brion

On Tue, Oct 1, 2013 at 12:50 PM, Quim Gil qgil@wikimedia.org wrote:

On 10/01/2013 11:11 AM, Brion Vibber wrote:

...

Question for the group:

Would an officially supported general-purpose MediaWiki hosting service be useful to people who would like to run wikis, but don't have the time, expertise, or resources to maintain their own installation?

If so, what can we (as interested parties in MediaWiki development and use) do to make this happen?

I'd say agree the best approach first with folks like https://www.mediawiki.org/**wiki/Hosting_serviceshttps://www.mediawiki.org/wiki/Hosting_services

There are many small companies trying to make a living out of (among other things) MediaWiki hosting and expertise. If we are missing players more involved with the community then we could start knocking those doors rather than triying to build an own house and call it "official".

Can I just say: they're all dinky and antiquated and none of them come close to offering the kind of deployment and configuration experience that I expect a modern platform to have.

I don't like this "every time you have a new idea, God kills a Community member" approach. It'd be more productive to think about the role the Foundation could play in ensuring that MediaWiki exposes the right set of interfaces for deep integration with configuration management and cloud provisioning platforms, and ensuring that these interfaces are intuitive and well-documented. This might actually spur some innovation.

On Tue, Oct 1, 2013 at 1:34 PM, Ori Livneh ori@wikimedia.org wrote:

On Tue, Oct 1, 2013 at 12:50 PM, Quim Gil qgil@wikimedia.org wrote:

...

On 10/01/2013 11:11 AM, Brion Vibber wrote:

...

Question for the group:

Would an officially supported general-purpose MediaWiki hosting service be useful to people who would like to run wikis, but don't have the time, expertise, or resources to maintain their own installation?

If so, what can we (as interested parties in MediaWiki development and use) do to make this happen?

I'd say agree the best approach first with folks like https://www.mediawiki.org/**wiki/Hosting_serviceshttps://www.mediawiki.org/wiki/Hosting_services

There are many small companies trying to make a living out of (among other things) MediaWiki hosting and expertise. If we are missing players more involved with the community then we could start knocking those doors rather than triying to build an own house and call it "official".

Can I just say: they're all dinky and antiquated and none of them come close to offering the kind of deployment and configuration experience that I expect a modern platform to have.

I don't like this "every time you have a new idea, God kills a Community member" approach. It'd be more productive to think about the role the Foundation could play in ensuring that MediaWiki exposes the right set of interfaces for deep integration with configuration management and cloud provisioning platforms, and ensuring that these interfaces are intuitive and well-documented. This might actually spur some innovation.

Other ideas for community engagement:

* Find out what version of MediaWiki each of these hosts is offering and nag the ones that lag behind to upgrade. * Find out which extensions (and which versions) each host is offering and lobby for the inclusion of new extensions. * Find out whether the management interface provided by the host describes MediaWiki in a manner that is compelling and accurate, and which concisely articulates MediaWiki's positioning relative to other wiki and content-management systems.

On Tue, Oct 1, 2013 at 3:22 PM, Isarra Yos zhorishna@gmail.com wrote:

Wikia is dinky? ShoutWiki is antiquated? I don't necessarily disagree with your overall point, but please don't generalise like this; an innacurate statement like that just takes away from it.

Ok, fair point.

On Tue, Oct 1, 2013 at 7:57 PM, George Herbert george.herbert@gmail.comwrote:

On Tue, Oct 1, 2013 at 1:34 PM, Ori Livneh ori@wikimedia.org wrote:

...

Foundation could play in ensuring that MediaWiki exposes the right set of interfaces for deep integration with configuration management and cloud provisioning platforms, and ensuring that these interfaces are intuitive and well-documented. This might actually spur some innovation.

Puppet, chef, salt stack, cfengine, CloudFormation, OpenStack, etc?

do you mean CloudFoundry, the Pivotal thing? http://www.cloudfoundry.com/

On 10/01/2013 04:34 PM, Ori Livneh wrote:

I don't like this "every time you have a new idea, God kills a Community member" approach.

Ori, I like your work on MediaWiki-Vagrant -- surely a new idea! -- but I'd also like you to consider the needs of people who don't have access to the infrastructure or know-how that you do.

For example, many long-time users of MediaWiki would like to use the VisualEditor, but only have the ability to run PHP and, if they're lucky, get some PHP modules installed. So VE is a non-starter.

The approach taken on Scribunto, though -- forking out a bundled lua binary -- works even on shared hosting. I've even managed to get it working on GoDaddy's notorious hosting.

This isn't directed so much at you, but I when it comes to these "new ideas", I'd like to see more thought given to the installed base of MediaWiki sites. More of the Lua approach and ways to adapt the Parsoid-type features to those people with fewer resources.

Thinking about community members may not be the easiest thing to do, but it pays off.

On 10/02/2013 11:16 AM, Brad Jorsch (Anomie) wrote:

On Wed, Oct 2, 2013 at 10:30 AM, Mark A. Hershberger mah@nichework.com wrote:

...

The approach taken on Scribunto, though -- forking out a bundled lua binary -- works even on shared hosting. I've even managed to get it working on GoDaddy's notorious hosting.

Works on *some* shared hosting.

We had problems for a while where many people with shared hosting running CentOS 5 couldn't run the provided binaries because their glibc was too old. Finally I installed CentOS 5 in VirtualBox and recompiled Lua against the older glibc.

Did you try the binaries from these RPMs? http://pkgs.repoforge.org/lua/

Even if you can't install the RPM, maybe you could extract the lua binary and use it.

Mark.

On Wed, Oct 2, 2013 at 12:48 PM, C. Scott Ananian cananian@wikimedia.orgwrote:

One intermediate position might be for WMF to distribute virtual machine images which can easily be installed on any one of a number of different hosting services. OpenStack/Glance appears to be one such system, although ops probably knows better. The current efforts with puppet and vagrant are pretty close to this goal, all that's missing is identifying some appropriate hosting services and closing the documentation gap.

This would also allow our existing community of MediaWiki hosting services to migrate to the new VM-and-image-based model.

I'd rather provide cloud-init scripts with instructions on how to use them. The cloud init script could pull and run a puppet module, or a salt module, or etc. etc.. Providing images kind of sucks.

- Ryan

On Wed, Oct 2, 2013 at 4:50 PM, Jay Ashworth jra@baylink.com wrote:

----- Original Message -----

...

From: "Ryan Lane" rlane32@gmail.com

...

On Wed, Oct 2, 2013 at 12:48 PM, C. Scott Ananian cananian@wikimedia.orgwrote:

...

One intermediate position might be for WMF to distribute virtual machine images

...

I'd rather provide cloud-init scripts with instructions on how to use

them.

...

The cloud init script could pull and run a puppet module, or a salt

module,

...

or etc. etc.. Providing images kind of sucks.

Ok, time for me to throw an oar in the water, as an ops and support guy.

My perception of Brion's use of "officially supported" was, roughly, "whomever is providing support to these hosting customers has a direct, *formal* line of communication to the development staff".

The reason you build images, and version the images, is that it provides a clear solid baseline for people providing such support to know (and, preferably, be able to put their fingers on) exactly the release you're running, so they can give you clear and correct answers -- it's not just going to be the Mediawiki release number that's the issue there.

That's impossible to do reliably if you pull the code down and build it sui generis on each customer's machine... which is what I understand Ryan to be suggesting.

It's a little more work to build images, but you're not throwing it away; you get it back in reduced support costs.

No. I'm suggesting that we provide cloud-init scripts [1] to let people seed their virtual instances. It would pull down a puppet, salt, chef, juju, etc. repository which would then install all the prerequisites, start all the necessary services, install MediaWiki, and maybe install and configure a number of extensions. We could skip cloud-init completely for some of these. I think vagrant has ec2 [2] and openstack [3] providers. salt stack has salt-cloud [4] (or you could use salty vagrant [5]).

Some of these also already have mediawiki modules created and usable. In fact, juju uses MediaWiki for demo purposes relatively often. WMF has a usable puppet module. I wrote a salt module for webplatform.org, which we'll be publishing soon.

The nice part about this is that it's all configuration managed, can be versioned and could also be used to upgrade MediaWiki and all related infrastructure.

Images are a pain in the ass to build and maintain (I build and maintain images), you need to keep them updated because the image will be insecure otherwise, and they are giant. They are also way less flexible.

- Ryan

[1] http://cloudinit.readthedocs.org/en/latest/ [2] https://github.com/mitchellh/vagrant-aws [3] https://github.com/cloudbau/vagrant-openstack-plugin [4] https://github.com/saltstack/salt-cloud [5] https://github.com/saltstack/salty-vagrant

On 10/02/2013 07:17 PM, phoebe ayers wrote:

I have needed such a thing for wikis for small non-profits/library associations that I've been involved with, where I didn't want to host it myself (because I didn't want to take personal responsibility for the site of an organization that I might not stay involved with, and because I don't really have the chops to deal with security and spam issues); but also did not have a good hosting option with a larger organization or library, which I find are often not very familiar with mediawiki (e.g. I've been trying to get our library systems dept. to install some basic extensions for our internal mediawiki for a couple years now).

There's not a lot of money in that particular use case, unfortunately, but I imagine I'm not alone in that need either.

Did you see the Orain wikifarm? https://meta.orain.org/

It seems to be targeted to the non-profit use case.

Mark.

On 10/02/2013 06:33 PM, Mark A. Hershberger wrote:

Did you see the Orain wikifarm? https://meta.orain.org/

No, I hadn't. But I followed your advice, I checked it out, tested the service with a wiki that some friends wanted to create and got to know the main contributors. Thank you! It's a very interesting community project run by wikipedians that love MediaWiki.

In fact I find it has some relation to this discussion and the possibilities suggested by Brion, Ori, Ryan, Mark... You are talking about an affordable Turbo service for power users and they are providing a free Diesel service for anybody.

But no just any diesel, check

https://meta.orain.org/wiki/Special:Version MediaWiki 1.22wmf16, MariaDB, Scribunto and more if you ask for it.

and see also their projects to maintain their farm at https://github.com/Orain https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/tasks/...

These people are clearly aligned with what this community is developing. They also seem to be having a similar vision about maintaining instances pulling from repositories, etc. If some of you think they could improve their approach I'm sure they would be happy to listen and discuss.

Now I imagine the combination of this free-for-all service with the affordable DIY setup you were describing and I see a great service for the community, yes.

Post Disclaimer: today I donated to Orain.org to support the initiative. An hour later they convinced me to move my pet project there. I wasn't amused about having to update core and extensions when MW 1.22 was out. Now my site is running basically the latest you can find out of the Wikimedia servers. And I will concentrate on my users and content. Happy.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384

Hi,

I'm Kudu, the co-founder of Orain (https://orain.org), a new non-profit wiki farm. Although it's pretty new and constantly changing, I think it's pretty similar to what many of you might have had in mind: community-led, free, ad-free and technologically advanced (MW 1.22wmf22, CDN, SSL/TLS, and more to come).

We're also taking an open approach by developing our software openly as free software, including our server configuration (Ansible playbook): https://github.com/Orain Please note that our code is a work in progress.

I think our organization would be a good fit to potentially be officially supported by MediaWiki, since, as a non-profit, we invest all our donations into our servers.

We currently cater to two types of wikis: public wikis (open, CC-licensed) and certain private wikis. The only type of private wikis we're currently accepting are those that in some way benefit society or the advancement of education, e.g. a wiki request we got recently for a philosophy collaboration project between teachers. They could also be non-profits, libraries, etc.

In the future, we will consider expanding to the wikis that don't fit into those categories, such as personal wikis, company wikis, etc. Those may be ad-supported or paid for a small fee. Those could also include custom SSO integration, etc.

Feel free to drop by our IRC channel (#orain on freenode) or reply to this message if you have any questions or feedback. :)

Regards, - -Kudu. On 10/14/13 10:41 PM, Quim Gil wrote:

On 10/02/2013 06:33 PM, Mark A. Hershberger wrote:

...

Did you see the Orain wikifarm? https://meta.orain.org/

No, I hadn't. But I followed your advice, I checked it out, tested the service with a wiki that some friends wanted to create and got to know the main contributors. Thank you! It's a very interesting community project run by wikipedians that love MediaWiki.

In fact I find it has some relation to this discussion and the possibilities suggested by Brion, Ori, Ryan, Mark... You are talking about an affordable Turbo service for power users and they are providing a free Diesel service for anybody.

But no just any diesel, check

https://meta.orain.org/wiki/Special:Version MediaWiki 1.22wmf16, MariaDB, Scribunto and more if you ask for it.

and see also their projects to maintain their farm at https://github.com/Orain https://github.com/Orain/ansible-playbook/blob/master/roles/mediawiki/tasks/...

These people are clearly aligned with what this community is developing. They also seem to be having a similar vision about maintaining instances pulling from repositories, etc. If some of you think they could improve their approach I'm sure they would be happy to listen and discuss.

Now I imagine the combination of this free-for-all service with the affordable DIY setup you were describing and I see a great service for the community, yes.

Post Disclaimer: today I donated to Orain.org to support the initiative. An hour later they convinced me to move my pet project there. I wasn't amused about having to update core and extensions when MW 1.22 was out. Now my site is running basically the latest you can find out of the Wikimedia servers. And I will concentrate on my users and content. Happy.