Re: /etc/init.d/* vs. /usr/bin/env
* Andreas Pakulat (2006-01-11):
> On 11.01.06 20:43:27, Andre Berger wrote:
> > * Andreas Pakulat (2006-01-11):
> > > On 11.01.06 18:28:40, Andre Berger wrote:
> > > > bei der Installation von DenyHosts (gegen SSH brute force attacks;
> > > > nicht Teil von Sarge) auf ein Sarge-System bin ich auf folgendes
> > > > Problem gestossen: Sowohl das beiliegende Startscript als auch
> > > > denyhosts.py selbst verwenden "#!/usr/bin/env python". So eingeloggt
> > > > kann ich das Script mit "/etc/init.d/denyhosts start" starten (als
> > > > root; es handelt sich dabei um ein nicht-Debian Python-Startscript,
> > > > das denyhosts mit der Option --daemon startet).
> > >
> > > Hast du den Sinn der Zeile verstanden?
> >
> > Wie meinen? DenyHosts laeuft eben als Daemon und wird alle dreissig
> > Sekunden aktiv. Dass es als root laeuft, ist nicht optimal, aber
> > daran bastele ich spaeter mit Hilfe der DenyHosts-FAQ. Oder meintest
> > du das Shebang?
>
> Genau das Shebang, insbesondere das du dir anguckst was env eigentlich
> bewirkt und warum dann "das richtige" Python aufgerufen wird.
Das ist mir schon klar, ich fand nur keinen Grund dafuer, dass es mit
meinem (einzigen) Python von der Kommandozeile aus ja, aus dem
Init-Script heraus aber nicht ging. Ich tippe auf einen Fehler in
meiner update-alternatives-Syntax.
> > > > Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich
> > > > in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum
> > > > Python-Binary aendern.
> > >
> > > Hmm, wo ist das Python denn installiert? /usr/bin sollte doch auch bei
> > > Skripten in /etc/init.d im Pfad liegen oder irre ich mich da jetzt?
> >
> > Vielen Dank, das hat mich zur Loesung gefuehrt. Ich hatte python-2.3
> > installiert und mit update-alternatives /etc/alternatives/python
> > erzeugt -- genauer gesagt manuell erzeugen muessen, da apt-get
> > install es nicht von sich aus tat.
>
> Das liegt daran, dass die Python-Pakete nicht das Alternatives-System
> nutzen. Die Python-Pakete installieren selbststaendig einen Symlink
> /usr/bin/python der auf die richtige Version zeigt. Bzw. tut das Paket
> python dies.
python2.3 tat das hier jedenfalls nicht.
> > Ich stelle nun allerdings fest, dass kein Link /usr/bin/python
> > erzeugt wurde und "which python" auf meinen manuellen Symlink
> > /usr/local/bin/python zeigte.
>
> Das wird der Grund gewesen sein, IIRC ist PATH initial auf
> "/bin:/sbin:/usr/sbin:/usr/bin" wenn root die UID ist. Somit wird python
> nicht gefunden.
So erklaere ich mir das nachtraeglich auch.
> > Nach dem Erzeugen von Symlinks von
> > /etc/alternatives/py{thon,gettext,doc} nach /usr/bin/ klappt es nun
> > wie gewuenscht.
>
> apt-get install python loest das Problem ohne manuelles Eingreifen.
> Analog gcc installiert dir das immer nen Symlink auf das aktuelle
> Default-Python.
Das war also der Trick. Ich hatte per apt-cache search python mit
einem Auge gesehen, dass es auch 2.2er-Pakete gibt und irgendwie
gleich vermutet, dass die aelteste Version der Debian stable-Default
ist :) Da DenyHosts python2.3 benoetigt, habe ich dies Paket eben
direkt installiert.
> > > > Waehrend /etc/init.d/denyhosts Upgrades ueberdauert, muss ich
> > > > denyhosts.py bei jedem Upgrade von Hand aendern, was mir zu
> > > > fehleranfaellig ist.
> > >
> > > Klaro, aber du koenntest das init.d-Skript so abaendern das die
> > > PATH-Variable mit dem Pfad zum python-Binary erweitert wird. Danach
> > > sollte env in dem denyhosts.py Skript auch den neuen PATH enthalten und
> > > somit python finden.
> >
> > Interessehalber: Wie setz man denn eine globale Variable in Python
> > auf den Wert einer Shell-Variablen?
>
> Das willst du doch gar nicht, was du machen wollen wuerdest waere die
> PATH-Variable zu erweitern und damit das 2. Python-Skript ausfuehren.
Das war es, was ich wollte.
> Wie das genau aussieht weiss ich so aber auch nicht.
Ist nicht tragisch, ich bin sehr zufrieden, dass es jetzt laeuft.
Vielen Dank fuer deine Hilfe, "much appreciated".
-Andre
Reply to: