'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 aliases > > 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 configuration > > files? What happens when the app needs write-access to the directories? > > 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 DocRoot 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, because > > 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 every > > 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 implemented. > > 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 paths 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 would come in (Robin, are you following this thread at all?). We could put a master copy - a skeleton if you like - in /etc/webapps//. It's the skeleton that gets updated by portage. > > Because that's what USE flags are there for. If the user puts '-apache2' > > 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 call > 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 described is *exactly* the behaviour that I want. Why can't phpBB-2.0.4 and phpBB-2.0.5 run at the same time on the same box, but under different virtual 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 think that people would use it? > Going along with your example, how can you do an 'emerge -u phpBB' _for a > particular domain_? Like this. a) emerge -u 'webapp' installs the master copy of 'webapp' in /usr/webapps. 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 upgrade the specific domain. Two stage process. Finally, once all domains are upgraded, you can simply do an 'emerge -C webapp-old-version' to remove the old SLOT'ed version that is 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. Nope. I'm telling Portage to maintain the master copy of a package, and to 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. Why does Portage have to do *everything*? We use portage to get the app + dependencies onto the box, and we use additional tools to manage the virtual 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 very > issue. I have no idea whether other distros support virtual hosting, and if they don't, why they don't. If you have any threads I can read on this, please send them my way. Otherwise, your statement is an assumption, and assumptions are the mother of all screw-ups. > The most robust solution would be to create a new group (web?) and make all > 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 write the code to do it if necessary. > > * /usr/webapps/ as the main directory. > > * /usr/webapps//public_html/ for files served by the web server > > * /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. (thinks about this) I'd want to test it to be sure, but I think ${PF} would work out okay. Depends whether having the -rX part of the package name is 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 then? 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 (although not the only one I'm sure). 'public' is too generic for my liking. '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 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 Portage ;-) and re-use what's already coded. No offence, but because of the reasons in one of my earlier emails, I don't think your eclass should go into Portage until the outcome of this GLEP is determined. Take care, Stu -- Stuart Herbert stuart@gentoo.org Gentoo Developer http://www.gentoo.org/ Beta packages for download http://dev.gentoo.org/~stuart/packages/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C --