Kotori 0.11.4 für armhf startet nicht

Danke für das neue Kotori 0.11.4 Paket für armhf, leider wirft der Dienst beim Starten den folgenden Fehler:

  File "/opt/kotori/lib/python2.7/site-packages/twisted/internet/_sslverify.py", line 38, in <module>
    TLSVersion.TLSv1_1: SSL.OP_NO_TLSv1_1,
AttributeError: 'module' object has no attribute 'OP_NO_TLSv1_1'

mit kommentierten Zeilen 38+39 startet Kotori dann auch.

Danke @Thias und super, dass Du durchs selber Hand anlegen für Abhilfe sorgen konntest. Wir sehen uns das an! Das nächste Mal testen wir das Paket vor der Ankündigung :-).

Darf ich fragen, welche Betriebssystem Version und welchen Raspberry Pi (2/3) Du verwendest?

A post was split to a new topic: Werte als Strings in der InfluxDB Datenbank

Gerne. Ist ein RasPi 2 Model B und drauf läuft Raspbian Jessie.

Wir haben eigentlich das gleiche System, das als Buildbot für die armhf Pakete dient: Ein Raspbian Jessie, allerdings auf einem Raspberry Pi 3 (was nichts ausmachen sollte). Das sind die Eckdaten:

# uname -a
Linux kotori-one 4.4.9-v7+ #884 SMP Fri May 6 17:28:59 BST 2016 armv7l GNU/Linux

# cat /etc/debian_version
8.0

# python -V
Python 2.7.9

Danke für die Information, wir sehen mal unter die Haube.

$ uname -a
Linux pi 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux

$ cat /etc/debian_version
8.0

$ python -V
Python 2.7.9

nur der Kernel ist neuer bei mir

Gut, dann liegt die Ursache irgendwo zwischendrin. Du startest den Dienst mit dem Python executable aus dem verpackten virtualenv /opt/kotori/bin/python2.7 bzw. benutzt ihn über das ganz normale systemd unit file - so wie gedacht, ja?

Ich gehe davon aus, deswegen: Wir sehen unter die Haube, es liegt bestimmt am Python/Debian packaging oder irgendwo dazwischen in Zusammenhang mit einer OpenSSL Inkompatibilität.

Der Vollständigkeit halber:

apt show openssl | grep Version
Version: 1.0.1t-1+deb8u5

und

$ /opt/kotori/bin/python2.7
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.1k 8 Jan 2015'

^^ Daran sieht man: Hier könnte der Hase im Pfeffer liegen, wir bauen aus Komfort- und Geschwindigkeitsgründen das virtualenv nicht jedesmal neu. Vielleicht passen an dieser Stelle die Versionen 1.0.1k und 1.0.1t nicht gut zusammen. Möglich wärs.

Das Problem hat wohl tatsächlich mit OpenSSL zu tun, aber auf einer anderen Ebene: Falls das Debian Paket python-openssl auf dem System installiert ist (war es bisher bei uns nicht), dann tritt diese Ausnahme scheinbar als unerwünschter Nebeneffekt auf. Mit einem schnellen “apt remove python-openssl” konnten wir das rückgängig machen und Abhilfe schaffen.

Zugegeben: Das ist unschön, weil wir den Dienst eigentlich durch die Paketierungsstrategie über die komplette Isolierung via virtualenv von solchen Dingen unabhängig machen wollten. Bzgl. diesem Aspekt müssen wir wohl noch nachlegen.

Aufgeschnappt haben wir das über:
https://github.com/obfuscurity/synthesize/issues/59#issuecomment-282508950

Wir haben ein aktualisiertes Paket “Kotori 0.11.5” (changelog) veröffentlicht. Nach ersten Tests scheint mit diesem das Problem nicht mehr aufzutreten, egal ob das Debian Paket “python-openssl” auf dem System installiert ist oder nicht.

Wir freuen uns auf Rückmeldungen, ob das nun auch bei Dir klappt.

ich habe zuerst im venv pyOpenSSL auf 16.2.0 angehoben und die 2 Zeilen wieder aktiviert. Kotori startet damit wieder einwandfrei. Yeah

Kotori 0.11.5-1_armhf installierte auch (fast) sauber:

Die folgenden Pakete werden aktualisiert (Upgrade):
  kotori
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.
Es müssen 40,4 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 14,5 MB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] 
Holen: 1 https://packages.elmyra.de/elmyra/foss/debian/ testing/main kotori armhf 0.11.5-1 [40,4 MB]
Es wurden 40,4 MB in 20 s geholt (1.942 kB/s).                                                                                                                                                                                                                                 
(Lese Datenbank ... 153249 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../kotori_0.11.5-1_armhf.deb ...
Removed symlink /etc/systemd/system/kotori.service.
Removed symlink /etc/systemd/system/multi-user.target.wants/kotori.service.
useradd: Benutzer »kotori« existiert bereits
Entpacken von kotori (0.11.5-1) über (0.11.4-1) ...
dpkg: Warnung: Altes Verzeichnis »/opt/kotori/lib/python2.7/site-packages/backports/ssl_match_hostname« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/opt/kotori/lib/python2.7/site-packages/backports« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
kotori (0.11.5-1) wird eingerichtet ...
Created symlink from /etc/systemd/system/kotori.service to /usr/lib/systemd/system/kotori.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/kotori.service to /usr/lib/systemd/system/kotori.service.

Exzellent, vielen Dank!

wird es wieder armhf Pakete für die neuen Kotori-Versionen geben?

Selbstverständlich! Kotori 0.16.0 ist gerade in der Mache, dann bauen wir gerne auch wieder ein armhf Paket. Wenn Du bereits von einer früheren Version ein Paket haben wollen würdest, dann sag gern Bescheid.

Und natürlich auch sonst jederzeit, wenn im Kotori changelog neue Releases zu sehen sind, für die es noch kein armhf Paket gibt.

Hi Matthias,

wir haben neue Pakete für armhf publiziert, siehe

Auf unserem RaspberryPi scheint alles zu laufen, auch das Upgrade von InfluxDB 0.13.0 auf InfluxDB 1.1.1 scheint reibungslos und ohne Datenverlust über die Bühne gegangen zu sein.

Viele Grüße,
Andreas.

Funktioniert auch bei mir. Super