| Summary: | Discussion: webapp.eclass | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Stuart Herbert (RETIRED) <stuart> |
| Component: | [OLD] Core system | Assignee: | Gentoo Web Application Packages Maintainers <web-apps> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aalmenar, bakirov, carlo, eckert.thomas, eloi.granado, m.debruijne, matsuu, maxwang_tw, pauldv, rizzo, zul |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 36265 | ||
| Bug Blocks: | 20642 | ||
|
Description
Stuart Herbert (RETIRED)
2003-10-07 15:16:19 UTC
So, yet again: http://bugs.gentoo.org/show_bug.cgi?id=20642 Not everybody is willing or can use the "Vhosts.conf" file for VirtualHosts. Webmin itself had (has?) an error where it didn't write to another file aside the main apache.conf. Also, it doesn't indent the directives inside vhosts. So you end up with a lot of lines starting with DocumenRoot in apache.conf. But that should not pose any problem. So, lets talk about Gentoo. For the comments in the bug I linked above, one would think ALL webapps go to /home/httpd/htdocs, period. It seems now it has been decided that the webapp class must have the autodetection thingie. But, yet again, it doesn't work reliably: emerge dev-db/phpmyadmin Calculating dependencies ...done! >>> emerge (1 of 1) dev-db/phpmyadmin-2.5.3-r1 to / touch: creating `"/home/httpd/htdocs/somedomain.com"': No such file or directory touch: creating `"/home/httpd/htdocs/somedomain.com"/.keep': No such file or directory !!! ERROR: dev-db/phpmyadmin-2.5.3-r1 failed. !!! Function keepdir, Line 230, Exitcode 1 !!! Failed to create .keep in /var/tmp/portage/phpmyadmin-2.5.3-r1/image///home/httpd/htdocs /home/httpd/htdocs/anotherdomain.com /home/httpd/htdocs/anotherdomain.com "/home/httpd/htdocs/anotherone.com" "/home/httpd/htdocs/anotherone.com" Let's look at /usr/portage/eclass/webapp-apache.eclass (my version is v 1.9 2003/08/20 10:19:46) : HTTPD_ROOT="`grep '^DocumentRoot' ${APACHECONF} | cut -d ' ' -f 2`" [ -z "${HTTPD_ROOT}" ] && HTTPD_ROOT="/home/httpd/htdocs/" My proposals are: 1- if the number of lines obtained is different from one, get the default config. Currently, it just checks for whether the result is null. So those lines, changed, would be: HTTPD_ROOT="`grep '^DocumentRoot' ${APACHECONF} | cut -d ' ' -f 2`" [ -z "${HTTPD_ROOT}" -o `echo "${HTTPD_ROOT}"|wc -l` -ne 1 ] && HTTPD_ROOT="/home/httpd/htdocs/" 2- get just the first line: HTTPD_ROOT="`grep '^DocumentRoot' ${APACHECONF} | cut -d ' ' -f 2 | head -n 1`" [ -z "${HTTPD_ROOT}" ] && HTTPD_ROOT="/home/httpd/htdocs/" What do you think about it? By the way, I would want to add that a portage flag for deactivating the autodetection whould be VERY lovely, at least for me (and I want to think that it would apply to others too). On the server I report I'm using /home/httpd/htdocs for both vhosts and webapps (for now), but in others I'm using /home/httpd/domains for them, leaving /home/httpd/htdocs for the webapps (and apache default index.html.*, manual link, and other things created in every upgrade). It would like so much to be able to deactivate the autodetect thingie... Hi! I think there's been some confusion. *None* of the existing ebuilds currently use the webapp.eclass yet. And if you find any that do, please report them to me asap! We are in the process of completing the eclass - and the webapp-config tool that goes with it - and then we'll start converting all of the ebuilds over to the new approach. It isn't ready for live use, and I haven't released into CVS all of the code required for live use yet either. To find out more about our plans, see GLEP #11 on http://glep.gentoo.org. I'm not planning on implementing auto-detection of the HTTPD_ROOT - at least, not at first. There will be a new config file - /etc/conf.d/webapp-config/ - where you will be able to specify the default install location of web-based applications. The default value that Gentoo will ship with will be /var/www/localhost. Installation will be a two-stage process; install a 'master copy' into /usr/share/webapps/, and then run webapp-config to install an instance of the app under your webserver. If you do not have the 'vhosts' flag set, the eclass will kick off the second stage of the process automatically. And if you have the 'vhosts' flag set, you'll be required to install/upgrade installed web-based applications by hand - at least, at first you will. Hooking into 'emerge -u world' is something I'd like to look at once the basic functionality is out there and live. I hope that's helped answer some of your concerns, Stu The webapp eclass has autodetection stuff in it. Do you mean it will be removed
for the first production version?
The packages that use it are:
[root@eloi]s0[/usr/portage] find . -name "*.ebuild" -exec fgrep -l webapp-apache
{} \;
./app-text/info2html/info2html-1.4.ebuild
./app-text/man2html/man2html-1.5l.ebuild
./dev-db/phpmyadmin/phpmyadmin-2.5.3-r1.ebuild
./dev-db/phppgadmin/phppgadmin-3.1.ebuild
./dev-php/jpgraph/jpgraph-1.12.2.ebuild
./net-analyzer/aimsniff/aimsniff-0.8.ebuild
./net-www/mythweb/mythweb-0.11.ebuild
./net-www/phpBB/phpBB-2.0.6-r1.ebuild
./net-www/phpBB/phpBB-2.0.6.ebuild
./net-www/phpmp/phpmp-0.8.2.ebuild
./net-www/phpmp/phpmp-0.8.3.ebuild
./net-www/phpmp/phpmp-0.9.0.ebuild
Maybe a note should be included in the header of the eclass warning everybody
not to use the eclass no matter what. I suppose those package maintainers
wanted some autodetection stuff in their ebuilds (overseeing Donny "woodchip"
Davies recomendations - see bug above), saw the eclass and decided to use
it.
As Stuart mentioned, there are no ebuilds that use the *webapp.eclass* -- you're showing a list of ebuilds that utilize the temporary webapp-apache.eclass. The latter will go away when the former comes closer to fruition. Hi, webapp-apache.eclass != webapp.eclass. They are separate, independent peices of code. Everything that currently uses webapp-apache.eclass will be ported over to use webapp.eclass. Stu Sorry about that. I've reported it in a more convenient bug entry. By the way, it's a great idea to "centralize" this functionality in one place. The webapp.eclass is the one in portage? Is that file actualized? I'm sorry - I'm not sure what you mean by 'actualised'. Thanks, Stu My fault. In my language, "actual" is the translation for "current". So I meant to ask whether the file is being kept current in the portage tree. Just to keep track of the changes, or even being involved in its development. FYI I've just submitted bug 32395 for phpwebsite-0.9.3_p1-r1 using the webapp-apache.eclass. I had based it on phpBB-2.5.4. Can't you just wait for webapp.eclass? Is there any need to duplicate the effort, using a flawed eclass in the way? (Seems to me that when the Apache package maintainter says "No" to DocumentRoot autoguessing, and an eclass implements it by default, it is "flawed"). Well in all reality the "effort" is not that great. It involves a little bit of typing. Also I'm not sure what you mean by the Apache package maintainer saying No to autoguessing. Well, I don't know what is the approach to package maintaining here, but in debian there was a "package maintainter" for every package. May be more open here. I saw woodchip in many of the entries in the apache ebuild Changelog, and thought he was the maintainer. A look at http://www.gentoo.org/main/en/devlist.xml made me more confident on this. Anyway, it's only my guessing, and it's not in my plans to start a flamewar or being a troll :P And here is where he stated he didn't like the autoguessing thingie : http://bugs.gentoo.org/show_bug.cgi?id=20642#c10 *** Bug 36505 has been marked as a duplicate of this bug. *** whats the thing about this /etc/conf.d/webapp-config/ I'm missing this in my system, but would be a nice feature to have. Or is there another way to change the HTTPD_ROOT other than /var/www/localhost? It's annoying to set up Aliases for every webapp. It hasn't been introduced yet. We've got a bit of work to do until all of this is working: * complete the webapp.eclass (done, but not in CVS yet) * introduce the webapp-config package, which also introduces /etc/conf.d/webapp-config (work in progress, not yet in CVS) * convert individual ebuilds over to the webapp approach (not started yet, *lots* of work to do once we're able to get started on this) The updated webapp.eclass, and the current work-in-progress version of webapp-config, will be going into CVS on Thursday night this week. I'll update this bug once this is done. Stu i'm not sure if the webapp.eclass can and should prevent overriding files in the destination DOCROOT but as i recently (see bug #35712) had problems with that i drop a note here. situation: a user installs her webserver of choice. along with the server there comes a bunch of documentation -- often installed in docroot. now the site should be filled with content and as the documentation index.html is no longer needed it is replaced by a new (live) one. the problem: updating the webserver to a newer version will override the personal user content (at least index.html in the example). possible solutions: - modify all ebuild of httpd to install any documentation in a subdirectory - add something like CONFIG_PROTECTION for webapps - ?? there should be a _better_ solution for this Snapshot releases of the webapp-config script can be found at http://dev.gentoo.org/~stuart/webapp-config/ Progress is going well, but I really need more feedback about what this script does - and how it does it. Best regards, Stu Thomas, The problem you've posted about isn't a webapp-config issue; that's an issue for the webserver ebuilds. webapp-config installs apps to work with a webserver; it's not part of the process of installing the webserver itself. But I'm glad you mentioned it here - I might not have noticed this problem myself. Best regards, Stu http://www.gentoo.org/proj/en/glep/glep-0011.html#default-document-root How about using /{var,srv}/www/<fully qualified domain name>/ with stripped off "www." prefix in a default document root for multiple virtual host installations? eg: /{var,srv}/www/example.org/ /{var,srv}/www/example.com/ I think this way is more cleaner, because we already know that we provide a www hosting service for a domain "example.org" and/or "example.com". Commonly, there is a one domain with multiple services (web, mail, ftp, etc) associated with it. So, if, for example, I'd host a virtual mail service, I'd use: /{var,srv}/mail/example.org/<maildir> /{var,srv}/mail/example.com/<maildir> instead of /{var,srv}/mail/mail.example.org/<maildir> /{var,srv}/mail/mail.example.com/<maildir> because I already know, that I host a mailing service for domains "example.org" and/or "example.com" --- Also, I would like to use Red Hat Content Accelerator (TUX) as a frontend and Apache as a backend on our web server. Red Hat Content Accelerator (TUX) uses the next format for host-based virtual hosting (with virtual_server value on TUX set to 1): http://www.some.site.com/a.html => $DOCROOT/some.site.com/a.html That is, Red Hat Content Accelerator strips off the www. prefix variants and transforms the hostname to lowercase. https://www.redhat.com/docs/manuals/tux/TUX-2.2-Manual/virtual-hosting.html That's all ;) Thank you very much! meder: your solution totallys breaks things for those of us that have virtual domains. eg, my http://mail.domain.com points to an instance of Horde so /srv/www/mail.domain.com/ is correctly a webpage, as is: /srv/www/ftp.domain.com/, /srv/www/www.domain.com/ and a few others. I have the actual mail in /srv/mail/domain.com (as the entire domain shares mail). Now that webapp-config is in Portage, and being rolled out across all ebuilds, I'm closing this bug. Thank you to everyone who contributed feedback. Best regards, Stu |
