Comments on: Easier Plone Hosting: Some Ideas

By: Proworkflow

Proworkflow — Wed, 30 Dec 2009 14:12:07 +0000

I’m not sure if you can run mod_wsgi with a threaded Apache server. So, supporting “Products” as add ons would require testing and verification. But supporting users with this weakness is also a potential source of unwanted support calls.

By: Sophia Katt

Sophia Katt — Sun, 27 Dec 2009 18:34:08 +0000

Also, “Debian VPS” is a good name for a techno band.

By: Killer Bee

Killer Bee — Sat, 26 Dec 2009 02:46:09 +0000

Never been tried Plone in my debian vps. I will try it today, thanks for this wonderful article. Now, I am ready to use it on my 3GB RAM.

By: Robert

Robert — Thu, 30 Jul 2009 06:04:06 +0000

I love this thread...It would be incredible to have Plone appear as a choice on cpanel at hosting companies - or even just a viable choice for hosting companies. It's really too bad that the memory requirement is so steep, though. From a hosting company's point of view, the other red flag is that all it takes is one code problem and the running python instance can just eat all the memory up in a heartbeat. So, supporting "Products" as add ons would require testing and verification. But supporting users with this weakness is also a potential source of unwanted support calls. And you also need ssh access, of course, and that's still often an extra cost (but not much) so it's not a "base package" situation in all cases to have plone as a hosting company option.

As much as I like Plone, modern methods of traffic generation and feeder site infrastructure just do not lend themselves to using Plone, so the target market is not going to be internet marketers who just want to slam up a site for authority generation and be done with it.

So, that just begs the question -- who is zope/plone really targeted at and what kind of applications/solutions is it intended to solve? This would help focus the discussion on commercial plone hosting solutions.

By: BZ

BZ — Sun, 12 Jul 2009 12:45:53 +0000

Slicehost is a great option and they now office slice cloning, so you can take a copy of a slice, clone it and set up another one. This would be great if you could set up the basic slice for Plone (os/tools/installs/buildout) and just clone it to bring up another Plone slice.

I would like to see some great documentation on setting up multiple slices for Apache/Varnish/Plone/ZEO/Zope/etc to handle multiple Plone sites out of one Zope instance.

Apache -> Varnish -> ZEO -> Zope1/2/3 - PloneSite1/PloneSite2/PloneSite3

By: Jon Stahl

Jon Stahl — Fri, 21 Nov 2008 16:57:02 +0000

@mech422: since VPS accounts with 512mb of RAM are now priced around $40/month, I don’t consider the cost of RAM to be much of barrier anymore. It’s all about making it really easy for a novice integrator to get a Plone site up and running fast.

By: Mech422

Mech422 — Thu, 24 Jul 2008 22:18:58 +0000

Hi Jon,

Unfortunately, software doesn't address the biggest issue in plone hosting - RAM. CSquared provides clients with Xen based VM's for plone - and at a minimum you need 512M RAM.

Image creation is easily automated. Updates can be handled by COW (copy on write) file systems, or automated scripts. Administration can be handled by plone_control_panel configlets

But there is no getting around the RAM. And it needs to be physical RAM - swapping just kills Plone.

Even worse, as Zope/Plone is a long running process (as you mentioned...) it eats that RAM even when its not being used. as opposed to (f)cgi based systems that only need the RAM while the script is actually running....

By: Lee Joramo

Lee Joramo — Mon, 04 Feb 2008 15:19:23 +0000

For the last three months, I have been slowly migrating my plone sites to VPS at http://www.slicehost.com . Coming from a high end managed hosting environment, I find it refreshing to be able to create custom servers tailored to their job. (I could not afford this with managed hosting, where I had a server that did everything.)

The Slicehost guys commented in a podcast, that they have built the infrastructure to deploy VPS images pre-built (called stacks) for a purpose. They had intended to provide Rails images, because Rails was difficult to install. They have decided not to offer such images for the time being. As I recall, they feel that in the last year Rails has become both much easier to install, and has many more install options. So the need for a “standard” Rails image has been reduced, at the same time it is less clear what the “standard” would be.

If standard, community backed server configuration could be defined, I think that we could approach that Slicehost and other VPS’s to provide base images.

However, I wonder if we wouldn’t be better off extending the installer script from the Plone Unified installer to cover much of the base server setup. As I have been creating VPS systems, I have been documenting the process with the hopes of building a shell script to automatically build the entire server environment from a fresh Debian vps.

By: Jon Stahl

Jon Stahl — Sun, 03 Feb 2008 19:16:03 +0000

@Erik — great point! I’m really inexperienced with VMs, but I agree, how to maintain and upgrade packages is a key question. Buildout may have some role to play. I’m not sure if it is easy to re-save the VMs as updated images. I would imagine the current VPS providers have some means for doing these kinds of tasks. I’d love hear what others know.

By: Erik Rose

Erik Rose — Sun, 03 Feb 2008 19:03:25 +0000

I’m doing some work toward a departmental hosting service [https://weblion.psu.edu/trac/weblion/wiki/WebLionHosting] at Penn State University. While the image-based approach gets you the initial installation, what will you do about upgrades? That’s where most of the challenge lies, IMO. We plan to run Debian on a bunch of VMWare VMsâ€”one per department, since our departments operate almost autonomouslyâ€”and manage both installation and upgrades using the native package management tools. We’re starting with a base of the excellent Plone 3 packages by Fabio Tranchitella and the rest of the Debian Zope team and adding packages of our own to handle things like Apache config, additional Plone products, and our weird single-sign-on system. With careful planning, I think we can get minor Plone and product upgrades happening unattended.