Swat2
Jelmer Vernooij
jelmer at samba.org
Sun Nov 25 07:54:25 MST 2012
On Sun, Nov 25, 2012 at 03:47:47PM +0100, Jelmer Vernooij wrote:
> 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.
... and with the actual patch.
Cheers,
Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtld_global.diff
Type: text/x-diff
Size: 556 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20121125/29a21a6a/attachment.diff>
More information about the samba-technical
mailing list