Python, Dispy, Sockets tussen unix/windows

[rmbakker]

Als onderdeel van een custom software oplossing die wij voor onszelf ontwikkelen, gebruiken wij o.a. Dispy op respectievelijk een CentOS 7 server en een Windows Server 2012 server.

Wij lopen tegen een zeer specifiek probleem aan waar we idealiter niet een extra dev op zetten - wellicht dat iemand ons hier kan helpen.

Specifiek hebben wij een probleem met het opzetten van een versleutelde verbinding tussen de linux en windows machine. Gebruiken wij geen SSL, dan is er geen probleem en werkt alles naar behoren. Omdat er gevoelige data verstuurd wordt tussen beide machines is dit echter wel absoluut nodig om op te lossen alvorens wij de software live gaan gebruiken.

in ons geval moeten wij alle 3 de modules gebruiken die dispy biedt: scheduler (dispyscheduler), node (dispynode), en cluster (SharedJobCluster)

Wat we hebben geprobeerd:

Gezien het om een interne oplossing gaat, gebruiken we self-signed certs.

Bash:

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout private.key -out private.crt -days 3650

we mergen de 2 files:

Bash:

cat private.crt private.key > private.pem

job submit in dispy:

Python:

# canonical.py
# function 'compute' is distributed and executed with arguments
# supplied with 'cluster.submit' below


def compute(n):
    import time, socket
    time.sleep(n)
    host = socket.gethostname()
    return (host, n)


if __name__ == '__main__':
    # executed on client only; variables created below, including modules imported,
    # are not available in job computations
    import dispy, random
    # distribute 'compute' to nodes; in this case, 'compute' does not have
    # any dependencies to run on nodes
    cluster = dispy.SharedJobCluster(compute,
                                     port=0,
                                  certfile='C:\\project\\private.pem')
    # run 'compute' with 20 random numbers on available CPUs
    jobs = []
    for i in range(5):
        job = cluster.submit(random.randint(5, 5))
        job.id = i # associate an ID to identify jobs (if needed later)
        jobs.append(job)
    # cluster.wait() # waits until all jobs finish
    for job in jobs:
        host, n = job() # waits for job to finish and returns results
        print('%s executed job %s at %s with %s' % (host, job.id, job.start_time, n))
        # other fields of 'job' that may be useful:
        # job.stdout, job.stderr, job.exception, job.ip_addr, job.end_time
    cluster.print_status()  # shows which nodes executed how many jobs etc.

Het probleem komt pas tevoorschijn als we een SSL verbinding toepassen. Gebruiken we die niet, loopt alles vlekkeloos, welk platform of in welke combinatie we dit ook gebruiken.

Een voorbeeld van een test om te kijken of SSL werkt:

Bash:

dispynode.py -d --certfile=/home/user/project/private.pem --clean

Bash:

python "C:\Program Files\Python3\Lib\site-packages\dispy\dispyscheduler.py" -d --ip_addr 127.0.0.1 --ip_addr 192.168.0.103 --node_certfile C:\project\private.pem --cluster_certfile C:\project\private.pem
python canonical.py

deze configuratie werkt niet. we krijgen constant dit soort foutcodes:

1:

Bash:

Reading standard input disabled, as multiprocessing does not seem to workwith re
ading input under Windows
2018-01-03 12:50:08 dispynode - dispynode version: 4.8.3, PID: 3288
2018-01-03 12:50:08 pycos - version 4.6.5 with IOCP I/O notifier
2018-01-03 12:50:08 dispynode - "example" serving 2 cpus
2018-01-03 12:50:08 dispynode - TCP server at 192.168.0.101:51348
2018-01-03 12:50:08 pycos - uncaught exception in !tcp_req/36277304:
Traceback (most recent call last):
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 3730, in _schedule
    retval = task._generator.throw(*exc)
  File "C:\Program Files\Python3\Lib\site-packages\dispy\dispynode.py", line 988, in tcp_req
    msg = yield conn.recv_msg()
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 3732, in _schedule
    retval = task._generator.send(task._value)
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 882,
 in _async_recv_msg
    data = yield self.recvall(n)
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 1438, in _iocp_recvall
    self._read_result = win32file.AllocateReadBuffer(bufsize)
MemoryError

2:

Bash:

Reading standard input disabled, as multiprocessing does not seem to workwith re
ading input under Windows
2018-01-03 12:54:12 dispynode - dispynode version: 4.8.3, PID: 3284
2018-01-03 12:54:12 pycos - version 4.6.5 with IOCP I/O notifier
2018-01-03 12:54:12 dispynode - "example" serving 2 cpus
2018-01-03 12:54:12 dispynode - TCP server at 192.168.0.101:51348
2018-01-03 12:54:13 pycos - uncaught exception in !tcp_req/36342840:
Traceback (most recent call last):
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 3730, in _schedule
    retval = task._generator.throw(*exc)
  File "C:\Program Files\Python3\Lib\site-packages\dispy\dispynode.py", line 988, in tcp_req
    msg = yield conn.recv_msg()
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 3732, in _schedule
    retval = task._generator.send(task._value)
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 882,
 in _async_recv_msg
    data = yield self.recvall(n)
  File "C:\Program Files\Python3\lib\site-packages\pycos\__init__.py", line 1438, in _iocp_recvall
    self._read_result = win32file.AllocateReadBuffer(bufsize)
OverflowError: Python int too large to convert to C long

3:

Bash:

2018-01-03 12:59:54 dispyscheduler - dispyscheduler version 4.8.3
2018-01-03 12:59:54 pycos - version 4.6.5 with epoll I/O notifier
Enter "quit" or "exit" to terminate scheduler, anything else to get status: 2018-01-03 12:59:54 dispyscheduler - Scheduler at 192.168.0.103:51349
2018-01-03 12:59:54 dispyscheduler - TCP server at 127.0.1.1:51347
2018-01-03 12:59:54 dispyscheduler - TCP server at 192.168.0.103:51347
2018-01-03 12:59:54 dispyscheduler - Scheduler at 127.0.1.1:51349
2018-01-03 12:59:54 pycos - uncaught exception in !tcp_req/139968956623560:
Traceback (most recent call last):
  File "/home/user/project/env/lib/python3.5/site-packages/pycos/__init__.py", line 3730, in _schedule
    retval = task._generator.throw(*exc)
  File "/home/user/project/env/bin/dispyscheduler.py", line 368, in tcp_req
    msg = yield conn.recv_msg()
  File "/home/user/project/env/lib/python3.5/site-packages/pycos/__init__.py", line 3730, in _schedule
    retval = task._generator.throw(*exc)
  File "/home/user/project/env/lib/python3.5/site-packages/pycos/__init__.py", line 868, in _async_recv_msg
    data = yield self.recvall(n)
  File "/home/user/project/env/lib/python3.5/site-packages/pycos/__init__.py", line 461, in _recvall
    recvd = self._rsock.recv_into(view, len(view), *args)
  File "/usr/lib/python3.5/ssl.py", line 929, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/lib/python3.5/ssl.py", line 791, in read
    return self._sslobj.read(len, buffer)
  File "/usr/lib/python3.5/ssl.py", line 575, in read
    v = self._sslobj.read(len, buffer)
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1977)

Helaas komen we er beiden niet uit. Ons vermoeden is dat dit te maken heeft met socket programming en het verschil in sockets tussen unix en windows - waar we beiden geen ervaring mee hebben.

Kan iemand ons helpen of heeft iemand een idee waar dit aan zou kunnen liggen?

Helaas is de developer van dispy te druk en reageert langzaam of helemaal niet op onze vragen.

[Dark Blue]

Zonder er erg diep in te kijken, is mijn eerste vraag: let je op het poortnummer waarover je dit verstuurt?
Ik zie in de dispy-documentatie dat je de standaard range mag gebruiken, maar dat je ook specifiek andere poorten mag aangeven.

Ook zie ik dat je specifiek parameters voor certfile en keyfile kunt setten. Ook dat kun je eens forceren.

[MSalters]

Workaround? SSH port forwarding opzetten. In dat geval kunnen je applicaties tegen een unencrypted localhost socket praten, terwijl SSH de encrypted verbinding verzorgt.

[rmbakker]

let je op het poortnummer waarover je dit verstuurt?

We gebruiken de standaard range, zoals je kunt zien in de foutmeldingen. Bovendien gebruiken we commands om dispy te runnen - helaas kunnen we dan geen ports aangeven in die commands.

Ook zie ik dat je specifiek parameters voor certfile en keyfile kunt setten. Ook dat kun je eens forceren.

Er is geen verschil tussen het instellen of niet instellen hiervan. Het is een workaround om alles makkelijker te maken.

Workaround? SSH port forwarding opzetten. In dat geval kunnen je applicaties tegen een unencrypted localhost socket praten, terwijl SSH de encrypted verbinding verzorgt.

Dit zou kunnen. Hebben we als plan B. We weten alleen niet zeker of dit zal werken aangezien de node willekeurig meer poorten opent. Daar hebben we geen controle over.

We geloven nog steeds dat dit geen probleem is met ports, firewalls, settings of SSL is, maar met sockets. We zijn een lange tijd bezig geweest om eventuele configuratie fouten op te lossen en het kan dit bijna niet meer zijn..