Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 55070 - horde webapp master copies set up incorrectly - unusable
Summary: horde webapp master copies set up incorrectly - unusable
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All All
: High critical (vote)
Assignee: SpanKY
: 55064 (view as bug list)
Depends on:
Reported: 2004-06-24 12:46 UTC by Mike Nerone
Modified: 2004-08-08 22:34 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Nerone 2004-06-24 12:46:31 UTC
I'm using webapp-config-1.10-r1, and want to install horde-2.2.5 and horde-imp-3.2.4 on a vhost called

First try:
# webapp-config -I -h -d / horde 2.2.5
# webapp-config -I -h -d /horde horde-imp 3.2.4
...apparent success...

But it doesn't work because horde-imp gets installed at /horde/horde/imp, instead of /horde/imp, as it needs to. Ok, so I try taking one of the "/horde"s out:

Second try (after cleaning up):
# webapp-config -I -h -d / horde 2.2.5
# webapp-config -I -h -d / horde-imp 3.2.4
Fatal error: Install directory already contains a web application

So basically, it's impossible to install horde and horde-imp.
Comment 1 Stuart Herbert (RETIRED) gentoo-dev 2004-06-24 12:48:50 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,
Comment 2 SpanKY gentoo-dev 2004-06-24 12:54:46 UTC
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
Comment 3 Mike Nerone 2004-06-24 13:38:49 UTC
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 -d / horde 2.2.5
# webapp-config -I -h -d /imp horde-imp 3.2.4
# webapp-config -I -h -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?
Comment 4 Mike Nerone 2004-06-24 13:53:17 UTC
*** Bug 55064 has been marked as a duplicate of this bug. ***
Comment 5 Mario Vazquez 2004-07-06 18:13:17 UTC
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.
Comment 6 Mario Vazquez 2004-07-06 18:15:28 UTC
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.
Comment 7 Mario Vazquez 2004-07-06 18:48:19 UTC
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

With those, we will bring back horde to /var/www/localhost/htdocs/horde
and horde modules to /var/www/localhost/htdocs/horde/module-name
Comment 8 Mike Nerone 2004-07-06 21:40:18 UTC
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.
Comment 9 Mario Vazquez 2004-07-07 11:28:52 UTC
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.
Comment 10 Mike Nerone 2004-07-07 13:44:44 UTC
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
# webapp-config -I -d horde horde-imp 3.2.4
# 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.
Comment 11 Stuart Herbert (RETIRED) gentoo-dev 2004-07-08 00:52:10 UTC
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,
Comment 12 Mike Nerone 2004-07-08 06:22:58 UTC
Doh! Yes, I meant "webapp-config" in that command line, not "emerge." *blush*
Comment 13 James Kyle 2004-07-23 18:56:57 UTC
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.
Comment 14 SpanKY gentoo-dev 2004-07-30 10:26:07 UTC
*** Bug 58902 has been marked as a duplicate of this bug. ***
Comment 15 Shawn Wilson 2004-08-02 09:41:30 UTC
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 -d / horde 2.2.5
# webapp-config -I -h -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.
Comment 16 Mike Nerone 2004-08-02 13:05:09 UTC
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.
Comment 17 SpanKY gentoo-dev 2004-08-07 23:29:42 UTC
fixed the eclass in cvs for USE=-vhost

thanks to stuart for the temp fix
Comment 18 Mike Nerone 2004-08-08 00:54:57 UTC
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?
Comment 19 SpanKY gentoo-dev 2004-08-08 13:51:28 UTC
1.13 is the last version in cvs and in rsync ... i really have no idea what you're refering to ...
Comment 20 Mike Nerone 2004-08-08 15:35:21 UTC
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.
Comment 21 Stuart Herbert (RETIRED) gentoo-dev 2004-08-08 22:34:15 UTC
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,