From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3976 invoked by uid 1002); 5 Aug 2003 00:16:34 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31906 invoked from network); 5 Aug 2003 00:16:34 -0000 From: Stuart Herbert Reply-To: stuart@gentoo.org To: Max Kalika , Troy Dack , gentoo-dev@gentoo.org Date: Tue, 5 Aug 2003 01:14:26 +0100 User-Agent: KMail/1.5.3 References: <86960000.1060038977@valkyrie.lsit.ucsb.edu> In-Reply-To: <86960000.1060038977@valkyrie.lsit.ucsb.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_lbvL/51fkig4spf"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200308050114.29952.stuart@gentoo.org> Subject: Re: [gentoo-dev] [GLEP] Web Application Installation X-Archives-Salt: 56b571b7-ed7c-4eb8-8d94-a6667b75d5a3 X-Archives-Hash: cfb908f7d2665aba604fb6662ab8c5af --Boundary-02=_lbvL/51fkig4spf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline 'lo Max, On Tuesday 05 August 2003 12:16 am, Max Kalika wrote: > > a) A bit of mod_alias magic, and you make the /phpbb/ directories alias= es > > for /usr/share/webapps/phpBB-/files/. If you do this, though, > > how do you get each copy of phpBB to use a separate set of configurati= on > > files? What happens when the app needs write-access to the directorie= s? > > The directories are on /usr, and we're all agreed that /usr should be > > mountable read-only. And does every webserver have something like > > mod_alias in the first place? > > If not mod_alias, then symlink to the DocRoot, but then we're back to not > knowing where the user configured his/her/virtualhosts's DocRoot. mod_alias provides aliases for URLs. Why would you need to know what DocRo= ot=20 is? > > If I've understood your eclass correctly, this is what it tries to do, > > yes? > > Yes. Ah good. > > b) A bit of .htaccess magic, and you have the directory structure of the > > webapp on /var, but directives telling PHP where to find the .php files > > by setting the include_path. The config file problem is solved, becau= se > > you can drop in local config files, and there are real directories that > > can be made writable. Only problem with this approach is that not eve= ry > > type of web server has the equivalent of .htaccess files - and the PHP > > SAPI for each type of web server doesn't necessarily support > > configuration directives in config files either. And that's before we > > think about Perl, Python and other ways that webapps can be implemente= d. > > Local config files? Where would these be stored? How are these handled > for virtual hosts? They would be stored under the virtual DocRoot, for example (using the path= s=20 for my example) in /var/www/www.iammax.com/public_html/phpbb/config.php. Putting the config file into the virtual DocRoot is where Robin's tools wou= ld=20 come in (Robin, are you following this thread at all?). We could put a=20 master copy - a skeleton if you like - in /etc/webapps//. It's t= he=20 skeleton that gets updated by portage. > > Because that's what USE flags are there for. If the user puts '-apache= 2' > > in their USE flags, it's the job of the ebuild to respect that. > > Otherwise, the ebuild is broken - and probably in breach of policy too. > > Ok, this is debatable, but I'm willing to change the eclass to take > -apache2 into effect. [OT, but interesting] How is this debatable? > We can still achieve flexibility along with smaller ebuilds. If we break > down the eclass install function into smaller functions and optionally ca= ll > them from install, we've got ourself a nice tidy system. Good idea - I'll sign up to that. > Here's the problem. First of all, SLOTing won't help that because it > assumes that the versions of the packages *and* the files you are > installing are _different_. I.e. db4 and db3 are SLOTted: they install > libdb-4.so and libdb-3.so respectively and thus can run simultaneously. I must be missing something. Why won't SLOTing help? The behaviour you've= =20 described is *exactly* the behaviour that I want. Why can't phpBB-2.0.4 an= d=20 phpBB-2.0.5 run at the same time on the same box, but under different virtu= al=20 domains? > Now, wrt to the whole virtual server thing. Personally if I was running a > server with, as you say, a non-trivial number of virtual domains who have > different needs, I probably wouldn't use a package management system to > begin with, or truly virtualize everything and use something like > user-mode-linux in which case we're back to single-domain installs. UML is one solution, but the overhead is not insignificant. If the package management system provided a viable solution, don't you thin= k=20 that people would use it? > Going along with your example, how can you do an 'emerge -u phpBB' _for a > particular domain_? =20 Like this. a) emerge -u 'webapp' installs the master copy of 'webapp' in /usr/webapps.= =20 If the webapp is SLOT'ed, none of the domains are upgraded at this point. b) Then, run 'webapp-config --upgrade /path/to/domain/directories'= to=20 upgrade the specific domain. Two stage process. Finally, once all domains are upgraded, you can simply = do=20 an 'emerge -C webapp-old-version' to remove the old SLOT'ed version that is= =20 no longer required. What's wrong with this as a solution? > You're telling portage to maintain a package, and > upgrade parts of it randomly. =20 Nope. I'm telling Portage to maintain the master copy of a package, and to= =20 upgrade that master copy only. > I simply don't think portage will ever have > any way of handling multiple installs of a package in this manner. =20 Why does Portage have to do *everything*? We use portage to get the app += =20 dependencies onto the box, and we use additional tools to manage the virtua= l=20 domain upgrades. > How > about we (Gentoo) just provide single domain/host installs and maybe > SLOTing different versions so they won't be overwritten on upgrades. > Beyhond that, we have to let the sysadmins know to cp -l the installed > files into their vhosts. Because we can do better? > AFAIK, no other distro has support for virtual hosting because of this ve= ry > issue. I have no idea whether other distros support virtual hosting, and if they=20 don't, why they don't. If you have any threads I can read on this, please= =20 send them my way. Otherwise, your statement is an assumption, and=20 assumptions are the mother of all screw-ups. > The most robust solution would be to create a new group (web?) and make a= ll > the webserver users be a part of that group and make these directory > group-owned by said group. (Similar to the "mail" group for many > mail-related services) Why is that robust? > Which takes me back to > wanting to support a single instance install of an app that an admin has = to > copy in place if the default location is unacceptable. It's one solution, sure. I think we can do better, and I'm willing to writ= e=20 the code to do it if necessary. > > * /usr/webapps/ as the main directory. > > * /usr/webapps//public_html/ for files served by the web serv= er > > * /usr/webapps//cgi-bin/ for CGI-BIN files > > * /etc/webapps// to hold the box-default config files > > * is ${PN} for non-slotted packages > > * is ${P} for slotted packages > > I'd say should just be ${PF} for both and not worry about what > is SLOTed and what is not -- it works itself out. =20 (thinks about this) I'd want to test it to be sure, but I think ${PF} woul= d=20 work out okay. Depends whether having the -rX part of the package name is= =20 really important or not. > Otherwise, this seems ok to me and is easy to implement in the eclass. Good-o. So the two of us (ominously quiet in here ;-) are in agreement the= n? =20 Oh, thought it was too good to be true ;-) > The only thing I would > change is the names public_html and cgi-bin. There may be no html and not > binary files in them (respectively). How's about 'public' and 'cgi'? (I > know, I know, nitpicking). Shrugs. I just picked 'public_html' because it's a recognised convention=20 (although not the only one I'm sure). 'public' is too generic for my likin= g. =20 'cgi-bin' *is* a recognised convention, and one we shouldn't break. > Is the approach currently in the eclass unacceptable? (Check for the > existance of the directory/configfile) I think so. See how I determine which version of apache to use in=20 webapp-apache.eclass (as stolen/morphed from Robin's mod_php ebuild!) > > b) you need to honour the 'apache2' USE flag > > Yup, see above...no higher...no, higher than that. Ok there, stop! Lol. For now, just make your eclass rely on mine, seeing as mine's already= in=20 Portage ;-) and re-use what's already coded. No offence, but because of th= e=20 reasons in one of my earlier emails, I don't think your eclass should go in= to=20 Portage until the outcome of this GLEP is determined. Take care, Stu =2D-=20 Stuart Herbert stuart@gentoo.o= rg Gentoo Developer http://www.gentoo.or= g/ Beta packages for download http://dev.gentoo.org/~stuart/package= s/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint =3D 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C =2D- --Boundary-02=_lbvL/51fkig4spf Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/LvblDC+AuvmvxXwRAvVdAKCmhS4v7Ly3pmdQfvG5GiN1e/dSpACeKdRd LyU4Wz7V1A87/7kaM/jvuNM= =p55K -----END PGP SIGNATURE----- --Boundary-02=_lbvL/51fkig4spf--