| Summary: | horde webapp master copies set up incorrectly - unusable | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mike Nerone <mike> |
| Component: | [OLD] Core system | Assignee: | SpanKY <vapier> |
| Status: | VERIFIED FIXED | ||
| Severity: | critical | CC: | gmsoft, lannocc, web-apps |
| Priority: | High | ||
| Version: | 2004.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mike Nerone
2004-06-24 12:46:31 UTC
Sounds like a problem with the master copy created by the horde ebuilds, rather than a webapp-config problem. Re-assigning to the maintainer of horde. Best regards, Stu stuart: this is exactly the problem i asked you about and you said you would get back to me about it (you didnt btw) :P Well, the following worked (just moving things right into htdocs instead under subdirectories in the master copy): ====================================================== # cd /usr/share/webapps/horde/2.2.5/htdocs/horde/ # mv * .. # cd .. # rmdir horde # cd /usr/share/webapps/horde-imp/3.2.4/htdocs/horde/imp/ # mv * ../.. # cd ../.. # rm -rf horde # cd /usr/share/webapps/horde-turba/1.2.2/htdocs/horde/turba/ # mv * ../.. # cd ../.. # rm -rf horde # webapp-config -I -h horde.nerone.org -d / horde 2.2.5 # webapp-config -I -h horde.nerone.org -d /imp horde-imp 3.2.4 # webapp-config -I -h horde.nerone.org -d /turba horde-turba 1.2.2 ====================================================== It's a little counter-intuitive (putting things in the htdocs directory in the master copy that end up in subdirectories), but it works. So it should be sufficient if the horde ebuilds are tweaked so as not to use the leading directories within htdocs when making the master copies. Hrm...I hope that was clear. BTW, did Stuart get a copy of that last comment? *** Bug 55064 has been marked as a duplicate of this bug. *** The problem of path begins with horde itself. Before the class change horde install itself under /var/www/localhost/htdocs. Right now is installing under /var/www/localhost/htdocs/horde, thus changing the path to /var/www/localhost/htdocs/horde/horde. As documented on horde docs, the place where horde, and all its extensions (passwd, imp, turba, accounts, etc) must reside is /current path to virual domains/horde. My test (above results) were without the vhost use flag. Also I need to mention that horde user/group must be the user/group apache is running on and not root. IMHO the correct webapp-config instruction for horde should be: webapp-config -I horde 2.2.5 And for its modules, it should be: webapp-config -I -d horde horde-imp 3.2.4 webapp-config -I -d horde horde-vacation 2.2 webapp-config -I -d horde horde-turba 1.2.2 etc. With those, we will bring back horde to /var/www/localhost/htdocs/horde and horde modules to /var/www/localhost/htdocs/horde/module-name That was actually my first thought, as well, since the subdirectory names used by the horde components are not very mutable. However, upon a cursory examination of webapp-config, I realized that it stores webapp installation information in a file call .webapp in the specified installation directory. If webapp-config did not detect this (which is does), then installing another webapp to the same directory would likely overwrite that installation information, and you would no longer be able to UNinstall the first app. It occurred to me that perhaps this behavior should be changed, with either all filenames should have WEB_PN and WEB_PVR in the name, dynamically adding and removing information from the .webapp file. Currently, it *also* creates a file called .webapp-WEB_PN-WEB_PVR, but that seems to contain only the CONTENTS information. The fact that it exists at all may indicate that Stuart does have plans to support multiple app installs to the same directory at some point, but I'm wildly guessing. At any rate, I then decided against my initial instinct that all horde apps should install to "/horde" (with implicit subdirectories) for three reasons: 1. As I said, the subdir names are not *very* mutable; they are mutable with some work, though. If someone wants to run IMP in a subdir named webmail for some reason, (s)he should be able to do so. This would require explicit subdirs. 2. Many webapps that have subcomponents (some of the *nukes come to mind, though oddly we don't seem to have ebuilds for them) allow those components to be installed to a subdir with any name you like far more easily than horde. The installation subdirs would therefore have to be given explicitly in the "-d" option. Having horde's subdir names be implicit would be inconsistent and confusing. 3. Some webapps can run standalone *or* as subcomponents (or plugins/modules/whatever) of other webapps. For example (and this is really just an example - I haven't checked whether the Gentoo ebuilds for these packages currently support this out-of-the-box): Gallery can run standalone or as a plugin under phpBB (or any of the *nukes if we had ebuilds for them ;D). Under the plugin/component-dirnames-should-be-implicit model, when using it as a plugin, Gallery would be installed to the parent webapp's directory (with an implicit subdir of "gallery?" - maybe not...see point 2). However, when using it standalone it would be installed directly to a specified directory (no implicir subdir). Even within a single ebuild, then, this introduces inconsistentcy and confusion, and would require extra logic in webapp-config to determine if it's a plugin or standalone. So my point is, I decided that IMO, explicit full paths, even for horde, are much more consistent, provide maximum flexibility, and just make more sense, so making the architectural changes to webapp-config does not appear to be warranted. It follows that each horde component really should be put directly into "htdocs" (not a subdir of it) in the master copy. I test it, and was able to install horde-imp and horde-passwd under horde with the instructions I gave and was able to uninstall them, of course, by removing first the modules and horde at last. Odd...what version of webapp-config do you have installed? With versions I've tested, including yesterday's net-www/webapp-config-1.10-r4, you can't install a webapp to a dir which already has one installed: here's what happened when I tried (following your instructions): ========================================================================= (first, made sure horde, horde-imp, and horde-passwd were emerged) # webapp-config -I horde 2.2.5 ...success... # webapp-config -I -d horde horde-imp 3.2.4 ...success... # webapp-config -I -d horde horde-passwd 2.2 * Running with these settings: * --force-virtual is OFF * --virtual-dirs is virtual * --virtual-files is virtual * --user is root * --group is root * --hostname is localhost * --server is apache-basic * --directory is horde * package is horde-passwd * version is 2.2 * action is install * link type is file * document root is /usr/share/webapps/horde-passwd/2.2/htdocs * Do we have horde-passwd-2.2 available? * Yes, we do * Is there already a package installed in /var/www/localhost/htdocs/horde? * Package horde-imp-3.2.4 is already installed here * Use webapp-config -C to uninstall it first Fatal error: Install directory already contains a web application Fatal error(s) - aborting ========================================================================= Further, the syntax for removing a webapp (assuming localhost) is "emerge -C -d <directory>". You don't give the webapp name (and if you do, it is ignored), so allowing more than one webapp installed to the same "-d" directory would be ambiguous when it comes time to uninstall. The syntax for removing a package is emerge -C <package> To remove what we call a 'virtual copy' of a package (ie a copy under /var/www), you can use webapp-config -C -h <hostname> -d <directory> Best regards, Stu Doh! Yes, I meant "webapp-config" in that command line, not "emerge." *blush* This may be a case of documentation that needs some brushing up. For example, I faced the exact same problems using commands as given in the man page. But when I tried to remove the packages by virtually cutting and pasting the example uninstall script:
for x in `webapp-config --list-installs phpmyadmin 2.5.7` ; do webapp-config
-C -d $x ; done
(modified for horde) and it failed to uninstall. I just unstalled webapp-config itself and all other webapps to clean up.
*** Bug 58902 has been marked as a duplicate of this bug. *** I suppose there are many different ways this could be accomplished, but here's how I did it. Using webapp-config-1.10-r5 and I'm using the vhost flag: # emerge horde # emerge horde-imp # cd /usr/share/webapps/horde-imp/3.2.4/horde # mv imp .. # cd .. # rmdir horde # webapp-config -I -h my.virtual.host -d / horde 2.2.5 # webapp-config -I -h my.virtual.host -d /horde horde-imp 3.2.4 This is similar to Mike's procedure except that I didn't move any folders in the core horde webapp. By the way, wouldn't it be better if horde files in /usr/share/webapp were directly in htdocs instead of htdocs/horde*? This way horde could be installed as the root for a virtual domain, or under a folder name other than "horde". I think this is was Mike was suggesting. Hope that helps. Yes, that is exactly what I meant. In fact, for my setup, I wanted horde installed at the root, not in /horde. That's why in my procedure, I had to move the core horde files, as well. As for other people, I figured it's just more flexible and consistent that way. fixed the eclass in cvs for USE=-vhost thanks to stuart for the temp fix Well, I saw horde.eclass v1.13, with the fixes, in CVS about twenty minutes ago,. I was going to test when I finished my current task, but 1.13 was gone when I came back. I take it you backed it out due to a problem? I'm not a CVS expert, but shouldn't it show a backed out change like that? 1.13 is the last version in cvs and in rsync ... i really have no idea what you're refering to ... At the time I wrote that, 1.13 had diappeared according to ViewCVS, though I had seen it there earlier. It reappeared overnight. Also note that when I rsync'd last night (about 90 minutes after your CVS change), 1.12 was still in rsync. Something wonky happened with CVS last night, but it looks like it's been resolved now. I wouldn't rely on our viewcvs service. It works on a snapshot - not the live CVS tree - and I believe that each webserver in the www.g.o rotation has its own snapshot to boot. Best regards, Stu |
