mod-wsgi mit Python2.6 aus Apache starten

Django, Flask, Bottle, WSGI, CGI…
Antworten
sunnapper
User
Beiträge: 3
Registriert: Mittwoch 4. Januar 2012, 10:45

Hallo,

ich habe auf meinem QNAP NAS eine svn/trac installation laufen. Anbindung an Apache über mod-wsgi. Nach dem letzten Firmware-Update stellte sich heraus, dass zwei Pakete an unterschiedliche Python-Versionen gebunden sind:

mod-wsgi_3.3-1 benötigt python25
svn-py_1.6-17 benötigt python26

Trac kann ich entweder für python25 oder python26 installieren. Mit python25 klappt dann aber der Zugriff auf svn nicht mehr, da svn-py ja für python26 geschrieben wurde. Installiere ich trac für python26, dann kann mein wsgi-script nicht geladen werden, da mod-wsgi den python25 interpreter aufruft, trac aber in meiner python26 Installation liegt.

Ich finde keine anderen Pakete für ein Down- oder Upgrade. Ich kann auch leider nicht cross-kompilieren, um mir eines der Pakete selbst zu bauen.

Gibt es eine Möglichkeit aus Apache heraus mod-wsgi mit python26 starten zu lassen anstatt mit python25? Setzen von WSGIPythonHome und WSGIPythonPath in der apache.conf brachten keine Abhilfe.
deets

Leider nein. Da solltest du dich mit den maintainern auseinandersetzen. mod_wsgi ist gelinkt gegen eine spezifisch version - das kann man nicht so einfach aendern.

Die Alternative waere, trac als eigenen Daemon zu starten mit py26, und dann mittels mod_rewrite/mod_proxy darauf zuzugreifen.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Du könntest http://wiki.python.de/SSH%20installation propieren und beide Versionen gleichzeitig installieren.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
deets

@jens

Der OP hat ja schon erwaehnt, dass er nicht cross-compilieren kann.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ich rede auch nicht von cross-compilieren (Auf einen PC für die NAS Platform compilieren) sondern von installieren auf dem NAS selbst.

Dazu müßen natürlich ein paar Tools zur Verfügung stehen.


btw. das QNAP NAS läßt sich doch bestimmt auch schön hacken, siehe: http://qnap.nas-central.org/
Was läuft darauf überhaupt für ein System? Das original?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sunnapper
User
Beiträge: 3
Registriert: Mittwoch 4. Januar 2012, 10:45

jens hat geschrieben:Was läuft darauf überhaupt für ein System? Das original?
Yep, das Original. Ist ein NSLU2-Linux, wenn ich es richtig verstanden habe. Von dort bezieht das Tool "ipkg" zumindest seine Pakete.

deets hat geschrieben:Leider nein. Da solltest du dich mit den maintainern auseinandersetzen.
Das probiere ich gerade. Es gibt dieses Forum hier: http://www.nslu2-info.de
Aber ich kann mich da nicht anmelden, da ich nie die Registrierungsemail bekomme! Habe auch schon das Kontaktformular dort verwendet, um darauf hinzuweisen. Aber wahrscheinlich geht deren Mailer Daemon nicht und sie merken nicht, dass man sie nicht kontaktieren kann bzw. dass sich neue Mitglieder nicht registrieren können...

OK. Anscheinend muss ich größeren Aufwand betreiben und doch cross kompilieren. Damit kenne ich mich aber nur bedingt aus. Habe schon versucht auf meinem Mac eine cross-compile Umgebung einzurichten, scheitere aber kläglich, weil ich es nicht verstehe. Nativ für den Mac kann ich mod-wsgi problemlos kompilieren.

Ich dachte evtl. daran mir eine bereits gut konfigurierte Linux-Distri als VMWare-Image zu besorgen. Kennt jemand so eine Distri mit der man für arm-linux cross-kompilieren kann?
Benutzeravatar
sparrow
User
Beiträge: 4505
Registriert: Freitag 17. April 2009, 10:28

ipkg kann, soviel ich weiß, auch Debian-Pakete installieren.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Was auch geht, aber ein wenig mehr Aufwand, dafür mehr Freiheiten: Eine chroot Umgebung bauen.

Hab ich auf dem Medion NAS http://www.mikrocontroller.net/articles/P89626 gemacht. Einmal mit Debian und einmal mit ArchLinuxARM, siehe:
http://www.mikrocontroller.net/articles ... ebootstrap
http://www.mikrocontroller.net/articles ... chLinuxARM

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
sunnapper
User
Beiträge: 3
Registriert: Mittwoch 4. Januar 2012, 10:45

Ich habe versucht ein Debian-Paket zu installieren, das brachte aber auch nichts. Wenn ich es richtig gesehen habe, enthält das Debian Paket nur eine lib, nicht aber die Python-Skripte.

Evtl. kann ich das ja selbst patchen. Dazu muss ich aber den Fehler verstehen. Hier die Ausgabe meines trac-logs, wenn ich versuche mittels trac-admin auf meine svn repositories zuzugreifen ("trac-admin <meinProj> repository sync <meinRepos>")

Code: Alles auswählen

2012-01-06 12:51:30,795 Trac[console] ERROR: Exception in trac-admin command: 
Traceback (most recent call last):
  File "/opt/lib/python2.5/site-packages/trac/admin/console.py", line 107, in onecmd
    rv = cmd.Cmd.onecmd(self, line) or 0
  File "/opt/lib/python2.5/cmd.py", line 218, in onecmd
    return self.default(line)
  File "/opt/lib/python2.5/site-packages/trac/admin/console.py", line 266, in default
    return cmd_mgr.execute_command(*args)
  File "/opt/lib/python2.5/site-packages/trac/admin/api.py", line 123, in execute_command
    return f(*fargs)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/admin.py", line 156, in _do_sync
    self._sync(reponame, rev, clean=False)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/admin.py", line 139, in _sync
    repos.sync(self._sync_feedback, clean=clean)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/cache.py", line 240, in sync
    @self.env.with_transaction()
  File "/opt/lib/python2.5/site-packages/trac/db/api.py", line 77, in transaction_wrapper
    fn(ldb)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/cache.py", line 247, in do_transaction
    cset = self.repos.get_changeset(next_youngest)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 442, in get_changeset
    return SubversionChangeset(self, rev, self.scope, self.pool)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 856, in __init__
    message = self._get_prop(core.SVN_PROP_REVISION_LOG)
  File "/opt/lib/python2.5/site-packages/trac/versioncontrol/svn_fs.py", line 968, in _get_prop
    return fs.revision_prop(self.fs_ptr, self.rev, name, self.pool())
  File "/opt/lib/svn-python/libsvn/fs.py", line 729, in svn_fs_revision_prop
    return apply(_fs.svn_fs_revision_prop, args)
TypeError: argument number 2: 

Ich verstehe es so, dass der Python2.5 Interpreter sich durch die trac-Scripte hangelt, die dann am Ende die Funktion svn_fs_revision_prop aufrufen. Dort kommt es zu dem TypeError. Nach meinem Verständnis liegt das daran, dass die svn-python-Scripte für Python2.6 geschrieben wurden und es hier zu einer Inkompatibilität kommt.

Ich kenne Python aber nicht und kann nicht verstehen, was genau schief läuft und wie ich das patchen könnte.
Antworten