Bugzilla Bug 125156

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 an attachment (id=81471) [edit]
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 an attachment (id=81555) [edit]
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 ;)