On Tue, Oct 1, 2013 at 9:23 PM, Jay Ashworth <jra(a)baylink.com> wrote: On Tue, Oct 1, 2013 at 11:25 AM, Paul Selitskas <p.selitskas(a)gmail.com>wrote;wrote: Ideally, my vision of a general-purpose wiki hosting service would provide options that orgs like Wikia generally don't. Wikia for instance covers "fan encyclopedia" type projects very well -- open access, openish license, free ad-supported hosting, casual user ownership with public backups. I'm thinking more along the lines of covering some of those folks who right now are setting up quick ad-hoc installs on their own servers or shared hosting, and then possibly not maintaining the software for years because they have better things to do than figure out how to update and tweak the software. (Right now I have the impression many of those folks have everything work great until it does eventually break or needs an update...) * ability to disable ads for a reasonable cost (or perhaps waived for certain approved projects) * ability to customize your skin! * ability to control or restrict access (limited access, custom auth integration, etc) * ability to host on your own domain * ability to host on SSL * ability to write, install and run custom extensions * custom writing, testing, and maintenance of custom extensions * service tracking down and fixing bugs * etc This might mean customers span a range of actual hosting methods, from "generic wiki on a farm-style cluster" (like Wikimedia and Wikia's primary wiki hosting) to "you pay for a dedicated VPS mini-cluster for your custom code" to "we run dedicated servers for your expensive custom site", perhaps all the way to "we provide consulting and support to help with your own server setup". There are some folks doing contracting/services and hosting on smaller scales, but we don't really have good coordination or a end-user-facing place we can point people for comprehensive support. Perhaps we just need to coordinate the people doing support and hosting already, or perhaps we should consider organizing something either under, or separately from, WMF... I'm not going to make any specific demands at this point, I've just been itching to see something happen on this front for years. :) -- brion

At a minimum we could provide information to hosts regarding what the minimum requirements are to run the latest versions if fully configured. Often they install the software but as old as 1.17. Fred

On 2013-10-01 11:43 AM, Brian Wolff wrote: There's always the generic idea of MediaWiki Foundation[1] we've been discussing or the MediaWiki Development Chapter[2] focused iteration on that idea I never completed the page for. The scope could easily be expanded to also support hosting. And it would be a beautiful place to do it in. Besides just donations, make some profit from hosting MediaWiki installations, and then use that profit to pay more former volunteers to squash bugs and make random features and improvements to MediaWiki full-time. [1] https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation [2] https://www.mediawiki.org/wiki/User:Dantman/MediaWiki_Development_Chapter ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

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. 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. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Tue, Oct 1, 2013 at 12:03 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:

Yes, hosts give very little information up front. You have to try them out to find out what software they have installed. The money is nothing, but spending days trying to make crap work is much more of a loss. I'd like the name of a few hosts where Lua can be make to work without a big struggle. Fred

Le 01/10/13 20:43, Brian Wolff a écrit : You are a step ahead in the discussion. Brion is merely asking if there is any interest. Figuring whom would be the next step. -- Antoine "hashar" Musso

interfaces for deep integration with configuration management and cloud provisioning platforms, and ensuring that these interfaces are intuitive and well-documented. Not well documented yet; but I'll put in a shameless plug that I have a patch [1] that will expose the git treeish information of extensions via the API if anyone wants to review :D [1] https://gerrit.wikimedia.org/r/#/c/65299/ ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Tue, Oct 1, 2013 at 1:34 PM, Ori Livneh <ori(a)wikimedia.org> 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. On 01/10/13 21:34, Ori Livneh wrote:

On Tue, Oct 1, 2013 at 1:34 PM, Ori Livneh <ori(a)wikimedia.org> wrote: Puppet, chef, salt stack, cfengine, CloudFormation, OpenStack, etc? Hmm... THIS. Yes. -- -george william herbert george.herbert(a)gmail.com

On Wed, Oct 2, 2013 at 7:02 AM, Chris McMahon <cmcmahon(a)wikimedia.org>wrote;wrote: No, the AWS Cloudformation ( http://aws.amazon.com/cloudformation/ ). Handles system deployment coordination / customization / cluster management, dynamic scaling interface, etc. It's not the same as the others, but they all play in the space of being management components for large managed system deployments. We appear not to have a WP article on it, which I may remedy, but not today. -- -george william herbert george.herbert(a)gmail.com

On Wed, Oct 2, 2013 at 10:30 AM, Mark A. Hershberger <mah(a)nichework.com> wrote: 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. And then there are the shared hosts that mount the users' directories with 'noexec', or that add proc_open to disable_functions in php.ini, or the like. There's nothing we can do for them. Also note that the "bundled binaries" solution won't help much if you need to shell out to something like nodejs.[1] In that case you'd probably have to go with requiring the end user to download and install nodejs separately. [1]: Lua binaries for Windows (32- and 64-bit), Linux (32- and 64-bit), and OS X Lion total 1.3M. A similar set of nodejs binaries downloaded from nodejs.org totals 42M, which would be a lot to bundle. And yes, that's just the binaries and not all the other files included in the "binary" tar.gz. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

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. --scott ​ ps. as far as a business model goes for a MW hosting company, it would be interesting to pattern it after github -- no charge for "open" wikis (mandatory CC licensing, perhaps with ads, perhaps with size restrictions, perhaps some amount of central auth and vandal protection baked in), but reasonable plans for "private" wikis (with flexible authentication integration and https support so that you can integrate it into your company's infrastructure).

----- Original Message ----- 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. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)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

I have a wiki there, and Orain is actually pretty decent as wiki farms go, though they could probably use more regular staff members. It is non profit for the forseeable future, though ads have been discussed only as in opt in option for those that want them.

Glad to hear you like it! :) On 15 October 2013 04:41, Quim Gil <qgil(a)wikimedia.org> wrote: