Swat2
Rowland Penny
repenny at f2s.com
Sun Nov 25 08:06:01 MST 2012
On 25/11/12 14:47, 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.
No patch attached
> 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.
Is this possible? if so how?
>
> Cheers,
>
> Jelmer
>
>
Thanks for the continuing help.
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