Bug 481420 – app-admin/webapp-config - hardlinks cause running multiple instances of www-apps/wordpress to fail

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Romain Riviere 2013-08-17 08:55:46 UTC]

When using webapp-config to install a webapp instance, it will create hardlinks for a vast majority of files (pretty much everything except config files).

In the case of wordpress, this becomes a problem as soon as a second instance is created. Since Wordpress relies on PHP's __FILE__ to include some of its files, two or more instances will end up working as just one, usually the first one used.

Reproducible: Always

Steps to Reproduce:
1. emerge wordpress
2. install two instances using webapp-config and standard settings, in separate hosts dirs
Actual Results:  
Both separate instances will act as just one

Expected Results:  
Separate instance should behave independently

The problem can be worked around by making an actual copy of files that use __FILE__, and perhaps by using config-owned permissions on all files.

[Comment 1 Anthony Basile 2013-08-17 15:26:40 UTC]

(In reply to Romain Riviere from comment #0)
> 
> The problem can be worked around by making an actual copy of files that use
> __FILE__, and perhaps by using config-owned permissions on all files.

I'm surprised this hasn't come up before.  I also don't think that sym linking vs hard linking (which has been floating around) would make any difference here.

However, looking in php files for uses of __FILE__ is ugly.  A more generalizable (and elegant) solution would inlcude an array which list which files are to be copied and which are to be linked.  The list could be supplied by the ebuild maintainer on a per webapp basis.

Any other design ideas here?

[Comment 2 Romain Riviere 2013-08-17 15:33:08 UTC]

(In reply to Anthony Basile from comment #1)

I was not suggesting that webapp-config should look for uses of __FILE__ itself, I suppose the ebuild maintainer could do this, as you suggest.

[Comment 3 Devan Franchini (RETIRED) 2014-01-24 21:51:02 UTC]

I'm aware the issue still persists, but does this bug need to be open? Maybe it'd be best if the Wordpress ebuild maintainer added a suggestion the Wordpress' post_install() message to install the webapp with the --copy flag enabled. And if they don't have the vhost USE flag enabled to have portage install the webapp with the --copy flag enabled. I'm going to close this as FIXED but I'll contact the maintainer to see if we can't do something about this.

[Comment 4 Jouni Rinne 2014-02-02 12:48:05 UTC]

Now that WordPress is auto-updating itself since the 3.8 version, how does it affect the usage of hard-linking by webapp-config?

[Comment 5 Leho Kraav (:macmaN @lkraav) 2014-02-02 14:27:59 UTC]

I would think one of the disable constants need to be used on webapp-config installations http://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/

[Comment 6 Romain Riviere 2014-04-30 14:29:04 UTC]

In short, hard-linking pretty much prevents auto-updates, since webapps source files are owned by root.

Also, the bug is still present. Maybe it could be reopened and re-assigned to wordpress instead?