Swat2

Rowland Penny repenny at f2s.com
Mon Nov 26 04:32:55 MST 2012


On 25/11/12 20:16, Jelmer Vernooij wrote:
> On Sun, 2012-11-25 at 16:53 +0000, Rowland Penny wrote:
>> On 25/11/12 14:54, Jelmer Vernooij wrote:
>>> 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
>>>
>> Hi Jelmer,
>> I am getting nearer, the error messages in
>> /usr/local/samba/var/log.samba are now:
>>
>> [2012/11/25 16:47:13,  0]
>> ../source4/web_server/wsgi.c:271(DEBUG_Print_PyError)
>>     WSGI: Server exception occurred: error while handling request
>> [2012/11/25 16:47:13,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>>     Traceback (most recent call last):
>> [2012/11/25 16:47:13,  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 16:47:13,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>>         return swat.__call__(environ, start_response)
>> [2012/11/25 16:47:13,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>>     AttributeError: 'module' object has no attribute '__call__'
>> [2012/11/25 16:47:54,  0]
>> ../source4/web_server/wsgi.c:271(DEBUG_Print_PyError)
>>     WSGI: Server exception occurred: error while handling request
>> [2012/11/25 16:47:54,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>>     Traceback (most recent call last):
>> [2012/11/25 16:47:54,  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 16:47:54,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>>         return swat.__call__(environ, start_response)
>> [2012/11/25 16:47:54,  0] ../source4/web_server/wsgi.c:137(py_error_write)
>>     AttributeError: 'module' object has no attribute '__call__'
> Okay, so that at least means the Samba side of things is working now.
> This is all in SWAT itself; I'll dig further.
>
> Cheers,
>
> Jelmer
>
>
>
Hi Jelmer, Thanks for looking into this and I will wait patiently for 
further developments.

Rowland


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the samba-technical mailing list