Gentoo Archives: gentoo-project

From: Michael Orlitzky <mjo@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] New Developer: Michael Orlitzky (mjo)
Date: Thu, 05 Dec 2013 21:15:01
Message-Id: 52A0ECBF.3010703@gentoo.org
In Reply to: Re: [gentoo-project] Re: [gentoo-dev-announce] New Developer: Michael Orlitzky (mjo) by "Anthony G. Basile"
1 On 12/05/2013 11:32 AM, Anthony G. Basile wrote:
2 >
3 > My student (gentoo dev twitch153) and I are maintaining webapp-config.
4 > We're both upstream and the ebuild maintainer.
5 >
6
7 Here's a hopefully-short version of our situation. Among other things,
8 we do web hosting for small businesses. These kinds of places have
9 neither the expertise nor interest to manage a website on a shared
10 hosting service, so they pay us a little bit more to do it all for them.
11
12 So we're running Wordpress, Drupal, Joomla, etc. as well as a number of
13 custom sites, and we keep them all up-to-date. Not just the CMSes, but
14 the plugins and whatever else, too.
15
16 For security, I want the sites as isolated as possible. An exploit on
17 one customer's site shouldn't be able to affect another. For that, we
18 use mpm-itk and isolate each site under its own
19 /var/www/${domain}/${host} directory. The temporary directories for PHP
20 are overridden. Other developers besides me need full write access to
21 these directories, but the apps themselves only need read/traverse with
22 write access to an "upload" folder. We use POSIX ACLs to achieve this,
23 and I've written a utility and patches to make that not suck so
24 much[1][2][3]. (Someday I dream of getting the apply-default-acl
25 algorithm upstreamed into libacl so that coreutils et al. could use it.)
26
27 Most sites are kind of standard, but there are differences between them.
28 We do all of the QA after an upgrade, so if I upgrade, say, Wordpress
29 for www.example.com, I have to run through a bunch of checks to make
30 sure it still works. That can take maybe an hour. Since the upgrades do
31 break things occasionally, we have to do them one-at-a-time; otherwise,
32 20 sites would be broken while we QA the first one. The same goes for
33 the plugins/modules.
34
35 So basically, every website needs its own copy of the web app and has
36 its own set of permissions. I don't doubt that webapp-config could be
37 made to do this, but I'm sceptical that the result would be less complex
38 than "everybody gets their own copy" and a makefile to set the
39 permissions. Space isn't an issue, so de-duping the apps isn't a huge
40 gain for us. I would love to be proven wrong though!
41
42 On the other hand, dependency management is critical, and greatly
43 simplifies the job of me not accidentally breaking something. I need to
44 be sure that if a php USE flag gets unset by default, and
45 www.example.com relies on it, that I don't unwittingly update and break
46 the site. Simply copying the webapp ebuilds and deleting SRC_URI is a
47 huge gain for little investment.
48
49
50
51 [1]
52 https://michael.orlitzky.com/articles/problems_with_posix_acls_and_common_utilities.php
53
54 [2]
55 https://michael.orlitzky.com/articles/fixing_posix_acls_in_common_utilities.php
56
57 [3] https://michael.orlitzky.com/code/apply-default-acl.php