Swat2
Rowland Penny
repenny at f2s.com
Sun Nov 25 09:53:50 MST 2012
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__'
Thanks again.
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