Swat2

[Jelmer Vernooij]

On Sun, Nov 25, 2012 at 02:37:44PM +0000, Rowland Penny wrote:
> On 24/11/12 23:45, Jelmer Vernooij wrote:
> >On Thu, 2012-11-22 at 19:45 +0000, Rowland Penny wrote:
> >>On 22/11/12 14:53, Jelmer Vernooij wrote:
> >>>On Wed, Nov 21, 2012 at 12:04:34PM +0000, Rowland Penny wrote:
> >>>>   we seem to have an interesting problem here, Andrew Bartlett has
> >>>>created a Samba bug report: Bug 9415 - SWAT *.msg files not
> >>>>installed with waf
> >>>>This by itself is not a problem, but it is also listed as a blocker
> >>>>on Bug 8622 - Samba 4.0 can't be released
> >>>>
> >>>>So what is the problem? the problem is that Samba 4 cannot be
> >>>>released until bug 9415 is sorted out, but why bother because Swat
> >>>>itself is so broken and out of date it cannot be installed. It relys
> >>>>on pylons, but pylons seem to have been replaced by pyramids.
> >>>>
> >>>>So Andrew you want a cure for bug 9415, easy, just remove Swat until
> >>>>it is sorted out and works.
> >>>>
> >>>>Before anybody starts shouting, I have tried to follow the
> >>>>instructions at https://wiki.samba.org/index.php/SWAT2
> >>>>None of the instructions there seem to work on Ubuntu 12.04 server
> >>>>and the page was last modified on 7 September 2011. I have also
> >>>>tried searching the web for newer instructions but cannot find any
> >>>>at this time.
> >>>>
> >>>>If anybody knows how to get Swat working, could they please post a
> >>>>howto somewhere.
> >>>I've updated the HOWTO at https://wiki.samba.org/index.php/SWAT2.
> >>>
> >>>You'll also need the patches I recently posted to the mailing list for
> >>>the web service.
> >>>
> >>>Cheers,
> >>>
> >>>Jelmer
> >>>
> >>>
> >>Hi Jelmer,
> >>I have applied your patches and compiled samba 4 again, carried out the
> >>instructions on the swat2 howto page and got swat2 running (I think) ;-)
> >>
> >>netstat -a | grep LISTEN | grep -v unix
> >>tcp        0      0 *:swat                  *:* LISTEN
> >>
> >>lsof -i :901
> >>COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >>samba   31644 root   22u  IPv4 433197      0t0  TCP *:swat (LISTEN)
> >>samba   31644 root   23u  IPv6 433198      0t0  TCP *:swat (LISTEN)
> >>
> >>But when I try to connect to swat (via the servers ipaddress) from
> >>another computer, I get this in /usr/local/samba/var/log.samba
> >>
> >>[2012/11/22 19:34:40,  0]
> >>../source4/web_server/wsgi.c:420(wsgi_process_http_input)
> >>    error while running WSGI code
> >>
> >>I also now have an empty /usr/local/samba/var/log.swat
> >>
> >>Any idea what is wrong?
> >Can you try again with my latest two patches for the web server applied
> >as well? They should make Samba properly return a 500 error to the
> >client and write a Python traceback to the log file.
> >
> >Cheers,
> >
> >Jelmer
> >
> >
> >
> Hi Jelmer, I have applied your latest patches and re-compiled. If I
> goto http://192.168.0.10:901 this changes to
> http://192.168.0.10:901/swat and I get 'An internal server occurred
> while handling this request. Please refer to the server logs for
> more details.'
> 
> Great, a step forward, something happens in the browser! even if it
> doesn't mention the word 'error' ;-)
> 
> I now have this in /usr/local/samba/var/log.samba
> 
> [2012/11/25 14:12:20,  0]
> ../source4/web_server/wsgi.c:271(DEBUG_Print_PyError)
>   WSGI: Server exception occurred: error while handling request
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>   Traceback (most recent call last):
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>     File "/usr/local/samba/lib/python2.7/site-packages/samba/web_server/__init__.py",
> line 67, in __call__
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>       return swat.__call__(environ, start_response)
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>   AttributeError: 'module' object has no attribute '__call__'
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>   Error in sys.excepthook:
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>   Traceback (most recent call last):
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>     File "/usr/lib/python2.7/dist-packages/apport_python_hook.py",
> line 66, in apport_excepthook
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>       from apport.fileutils import likely_packaged, get_recent_crashes
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>     File "/usr/lib/python2.7/dist-packages/apport/__init__.py", line
> 1, in <module>
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>       from apport.report import Report
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>     File "/usr/lib/python2.7/dist-packages/apport/report.py", line
> 16, in <module>
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>       from xml.parsers.expat import ExpatError
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>     File "/usr/lib/python2.7/xml/parsers/expat.py", line 4, in <module>
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>       from pyexpat import *
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>   ImportError: /usr/lib/python2.7/lib-dynload/pyexpat.so: undefined
> symbol: _Py_ZeroStruct
> [2012/11/25 14:12:21,  0] ../source4/web_server/wsgi.c:137(py_error_write)
It looks like some of the python modules rely on the loading process
to provide all Python symbols. Samba doesn't use RTLD_GLOBAL when it
loads the web server service module, which causes the Python symbols
to not be exposed when new Python modules are loaded.

The attached patch fixes this issue. I'm not sure if we actually
want to land this on master though, as it will pollute the symbol
namespace (all symbols from modules and their dependencies will end up
in the global namespace, also making it harder to find dependency
issues).

An alternative would be to have the 'samba' binary explicitly link
against -lpython.

Cheers,

Jelmer