Re: Netenv bzw. Scripting/Bash, die 2. :)
Christoph Bohm <christoph.bohm@lsg.nrw.de> schrieb:
> Hallo!
>
> Ich verwende mein Notebook zuhause und im Betrieb - so weit so
> normal. Nun bietet Debian (in meinem Fall: testing) ja die
> Möglichkeit, per netenv beim Booten die Netzwerk-Umgebung
> festzulegen.
Es gibt auch noch andere Programme, die die Netzwerkumgebung automatisch
herauszufinden versuchen.
> Ich habe also an genau dieser Stelle einstmals gesagt,
> welche IP-Adresse, GW und Netmask in der Firma benutzt werden
> soll. Leider juckt ihn das nicht die Bohne, er geht immer auf
> Installation default *seufz*.
Ich vermute, du verwendest netenv aus woody und hast keine PCMCIA-Karte,
sondern eine eingebaute Netzwerkkarte. Damit hat netenv, das auf SuSE
entwickelt wurde, Probleme. Neuerdings gibt es in unstable eine neuere
Version (ich bin ganz zufällig jetzt der Maintainer ;-), die ist besser
angepasst und vor allem entsprechend dokumentiert.
Möglicherweise ist dir damit geholfen. Da es sich nur um ein Skript
handelt (das trpnc-Binary habe ich rausgeschmissen) kannst du es
problemlos auf woody installieren (nimm nicht das aus testing, das hat
noch ein paar kleine Bugs).
> Naja, dachte ich mir, soll er's so haben, schreibe ich mir also ein
> kleines "Skript", das den entsprechenden ifconfig ausführt. Dieses
> rufe ich dann per hand auf (ich weiß, es ist umständlich, und ich
> würde es auch immer schon gerne als init-Skript anlegen, das von einem
> erfolgreichen GW-Ping abhängig die entsprechende Konfiguration
> vornimmt, aber bisher habe ich es noch immer geschoben... :) ).
Wenn du mit Gateway-ping-Versuchen arbeiten willst, dann ist netenv
nicht das richtige. Nimm lieber eines aus
apt-cache search network | egrep 'laptop|notebook|mobile'
> Nun ist es aber so, daß ich in der Firma noch einen Proxy aktivieren
> muß. In meinem "Skript" stehen also auch die nachfolgenden Zeilen:
>
> export http_proxy=http://x.y.z.a:80
> export ftp_proxy=http://x.y.z.a:80
>
> Tja, und diese Variablen sind danach aber leider nicht gesetzt :( Das
> mag wohl damit zusammenhängen, daß ein Skript in einer Sub-Shell
> ausgeführt wird, und die Variablen nur dort gelten.
Wenn du das Skript sourcet statt ausführst, dann geht es.
Gruß, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: