Hi. Whilst experimenting with the new version of webapp-config recently I noticed the following issue (note that the definition of "clean" here means no webapps installed, no webapp instances in /var/www/localhost/htdocs, no /var/db/webapps directory, no stale conf files pertaining to webapp-config and/or webapps etc) ... 1) Install webapp-config-1.11 on clean system 2) emerge squirrelmail 3) Watch as the ebuild successfully invokes webapp-config: "Running //usr/sbin/webapp-config -I -h localhost -u root -d /squirrelmail squirrelmail 1.4.6" Here's what happens when running through that again with webapp-config-1.50.11: 1) Install webapp-config-1.50.11 on a clean system 2) emerge squirrelmail 3) Watch as the ebuild invokes webapp-config which then fails with the following message (yet the ebuild still concludes "successfully"): * Creating required directories * Linking in required files * This can take several minutes for larger apps * Files and directories installed Traceback (most recent call last): File "//usr/sbin/webapp-config", line 44, in ? main() File "//usr/sbin/webapp-config", line 41, in main config.run() File "/usr/lib/python2.4/site-packages/WebappConfig/config.py", line 1058, in run self.config.get('USER', 'pvr')).install() File "/usr/lib/python2.4/site-packages/WebappConfig/server.py", line 269, in install self.__ebuild.run_hooks('install', self) File "/usr/lib/python2.4/site-packages/WebappConfig/ebuild.py", line 120, in run_hooks if sandbox.start(): File "/usr/lib/python2.4/site-packages/WebappConfig/sandbox.py", line 75, in start if not self.sandbox: AttributeError: Sandbox instance has no attribute 'sandbox' The weird thing is that it does create a /var/db/webapps directory and does appear to populate an entry for squirrelmail as one would expect. As I'm using portage-2.1_pre I also tested this with the stable portage-2.0.54 but it didn't make any difference.
Created attachment 81471 [details] emerge --info output emerge --info output from the affected system
Hi Kerin! Thanks for the report. This problem is not related to the /var/db/webapps issue. The problem here is the way we initialize the sandbox. webapp-config currently does the following: self.__path = ['/usr/lib/libsandbox.so', '/lib/libsandbox.so'] and at a later point: for i in self.__path: if os.access(i, os.R_OK): self.sandbox = i break So it checks the two paths above for presence of the library. I am no amd64 user but if I understand it correctly, your libdir is /usr/lib64 right? While we could probably add this to our list of paths it would be a bad hack. I looked at the webapp-config-1.11 fix you suggested for amd64 and it looks like we would just need to retrieve the value of ABI from portage. We access the portage settings in webapp-config anyhow and so I added the following section to the portage wrapper: if 'ABI' in portage.settings.keys(): config_abi = portage.settings['ABI'] else: config_abi = '/usr/lib' And this to the sandbox wrapper: self.__path = ['/usr/lib/libsandbox.so', '/lib/libsandbox.so', config_abi + '/libsandbox.so'] I added these fixes as webapp-config-1.50.12 to the tree. Can you re-test? In case I based this fix on false assumptions I'd be happy about a correction :)
Hi Gunnar. Thanks for your help on this but unfortunately the changes don't quite make the cut. ABI can be used to determine the variable which must be read but does not, in itself, contain the correct name of the libdir. However, you've given me sufficient insight to knock up something which I think is suitable for inclusion :) The attached patch makes the routine work as follows (pretty much the same way as I suggested in bug 120532): if 'ABI' in portage.settings.keys(): config_abi = portage.settings['ABI'] if 'LIBDIR_' + config_abi in portage.settings.keys(): config_libdir = '/usr/' + portage.settings['LIBDIR_' + config_abi] else: # This shouldn't happen but we want to know if it ever does OUT.die('Failed to determine libdir from portage.settings[\'LIBDIR_' + config_abi + '\']\n') else: config_libdir = '/usr/lib' That's actually enough to fix it but the patch also re-works the sandbox wrapper so that it looks like: self.__path = [config_libdir + '/libsandbox.so', '/usr/lib/libsandbox.so', '/lib/libsandbox.so'] This doesn't make it any more or less reliable. It just shunts the value of config_libdir to the front (because 99.99% of the time we should now avoid iterating through to the 2nd or 3rd items in that list now). For example, in my problematic amd64 case the list will evaluate as [ '/usr/lib64/libsandbox.so', '/usr/lib/libsandbox.so', '/lib/libsandbox.so' ] which is good. And in the case of, say, x86 it will be [ '/usr/lib/libsandbox.so', '/usr/lib/libsandbox.so', '/lib/libsandbox.so' ] which looks a bit odd but it will still hit it on the first pass. Anyhow, after applying this patch it works well here. What do you think?
Created attachment 81555 [details, diff] webapp-config-1.50.12-multilib.patch Here it is - thanks for the help in tracking it down.
*** Bug 125032 has been marked as a duplicate of this bug. ***
Great! Thanks for the patch. I added webapp-config-1.50.13 to the tree. If you confirm that it works on amd64 I'll start a second round of webapp-config stabilization :)
Tested and yes, it works fine. I don't have any further gripes now ;)
