Frage Netzwerkkonfiguration mit DHCP POINTOPOINT bei eisfair auf rootserver

[Matthias Prill]

Hallo,

ich habe einen eisfair1 auf einem Server bei Hetzner.
Das war ok, jetzt wurden die aber in die Cloud migriert und bei der
Netzwerkkonfiguration muß ich jetzt meine eigene öffentlich IPV4 Adresse
angeben und der Zugang geht über eine POINTOPOINT Adrresse und ein
Gateway in dem Bereich.


Meine IP gebe ich in der base an:
IP_ETH_1_IPADDR='94.x.y.z'

Manuell mache ich folgendes um den Server erreichbar zu machen:

ifconfig enx5254a2021455 94.x.y.z netmask 255.255.255.255 pointopoint
172.31.1.1 up

route add default gw 172.31.1.1

Wie kann ich das jetzt in der eisfair Konfiguration abbilden?

Gruß
Matthias

[Marcus Röckrath]

Matthias,

Matthias Prill wrote:

> ich habe einen eisfair1 auf einem Server bei Hetzner.
> Das war ok, jetzt wurden die aber in die Cloud migriert und bei der
> Netzwerkkonfiguration muß ich jetzt meine eigene öffentlich IPV4 Adresse
> angeben und der Zugang geht über eine POINTOPOINT Adrresse und ein
> Gateway in dem Bereich.
>
>
> Meine IP gebe ich in der base an:
> IP_ETH_1_IPADDR='94.x.y.z'
>
> Manuell mache ich folgendes um den Server erreichbar zu machen:
>
> ifconfig enx5254a2021455 94.x.y.z netmask 255.255.255.255 pointopoint
> 172.31.1.1 up

eisfair verwendet inzwischen ip zur Einrichtung des Netzwerkes; ifconfig ist
deprecated.

Wie der Befehl dann aussehen muss, kann ich dir nicht sagen,

> route add default gw 172.31.1.1

Auch route zählt zu den veralteten netzwerktools.

Siehe auch:
https://web.nettworks.org/wiki/display/e/Veraltete+Netzwerk-Tools

> Wie kann ich das jetzt in der eisfair Konfiguration abbilden?

Da du obiges nach der normalen (fest vorgegeben) Konfiguration machst,
kannst du doch /etc/init.d/local für eigene Erweiterungen nutzen.

--
Gruß Marcus
[eisfair-Team]

[Matthias Prill]

Am 05.01.2020 um 19:25 schrieb Marcus Röckrath:
> Matthias,

> eisfair verwendet inzwischen ip zur Einrichtung des Netzwerkes; ifconfig ist
> deprecated.

ja, funktioniert aber trotzdem noch :-)

>> Wie kann ich das jetzt in der eisfair Konfiguration abbilden?
>
> Da du obiges nach der normalen (fest vorgegeben) Konfiguration machst,
> kannst du doch /etc/init.d/local für eigene Erweiterungen nutzen.

Ich denke da werde ich das mal einfügen und testen ob es funktioniert...
Danke..
Gruß
Matthias

[Marcus Röckrath]

Hallo Matthias,

Matthias Prill wrote:

>> eisfair verwendet inzwischen ip zur Einrichtung des Netzwerkes; ifconfig
>> ist deprecated.
> ja, funktioniert aber trotzdem noch :-)

Wenn noch nicht geschehen, solltest du die net-tools-deprecated, damit du
vor dem Abräumen der alten Tools sicher bist.

>>> Wie kann ich das jetzt in der eisfair Konfiguration abbilden?
>>
>> Da du obiges nach der normalen (fest vorgegeben) Konfiguration machst,
>> kannst du doch /etc/init.d/local für eigene Erweiterungen nutzen.
> Ich denke da werde ich das mal einfügen und testen ob es funktioniert...

--- und bitte berichten.

> Danke..

Bitte.

--
Gruß Marcus
[eisfair-Team]

[Olaf Jaehrling]

Hallo Mathias,

das hier sollte der neue Syntax sein ....

Matthias Prill schrieb am 05.01.20 um 18:41:

>
> Manuell mache ich folgendes um den Server erreichbar zu machen:
>
> ifconfig enx5254a2021455 94.x.y.z netmask 255.255.255.255 pointopoint
> 172.31.1.1 up

ip addr add 94.x.y.z /32 peer 172.31.1.1/32 dev enx5254a2021455

>
> route add default gw 172.31.1.1

ip route add default via 192.168.0.7
oder
ip route add default via 192.168.0.7 dev enx5254a2021455

>
> Wie kann ich das jetzt in der eisfair Konfiguration abbilden?

Wie Marcus schon schrieb in die /etc/init.d/local
Bitte gaanz wichtig. Ganz am Ende der /etc/init.d/local sollte immer ein
exit 0
stehen


Gruß

Olaf

>
> Gruß
> Matthias
>

[Holger Bruenjes]

ganz wichtig im init Script immer mit Pfad

/usr/sbin/ip

Holger

[Marcus Röckrath]

Hallo Olaf,

Olaf Jaehrling wrote:

> Wie Marcus schon schrieb in die /etc/init.d/local
> Bitte gaanz wichtig. Ganz am Ende der /etc/init.d/local sollte immer ein
> exit 0 stehen

Hat sie bislang auf eisfair nie gehabt; ich meine das bei der Installation
mitgelieferte "Skelett" dieser Datei.

Irgendwie habe ich bislang bewußt keine Fehler wegen des fehlenden exit
wahrgenommen.

--
Gruß Marcus
[eisfair-Team]

[Hilmar Böhm]

..interessant!
Was da noch alles in die /etc/init.d/local rein soll...

Ich benutze dieses initscript u.a., um einen anderen Systemfont zu
laden.
Um eine "boot-mesg" abzusetzen habe ich noch (am Anfang) gesetzt (wie in
/etc/init.d/console):
/etc/config.d/base
/etc/config.d/environment
/etc/config.d/functions

Das ist wahrscheinlich zu viel, evtl. ist nur functions erforderlich?
Damit aber klappts.

Ein Skelet mit einer case start) stop) esac war schon da.
Wo muss genau "exit 0" hin. Gaanz ans Ende?
Absolute Pfade habe ich verwendet.

Dank für eine Info.
Gruß./Hilmar.

[Marcus Röckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Was da noch alles in die /etc/init.d/local rein soll...

Alles was das Herz begehrt und vor der Konfigurationsschicht bewahrt wein
soll.

> Ich benutze dieses initscript u.a., um einen anderen Systemfont zu
> laden.
> Um eine "boot-mesg" abzusetzen habe ich noch (am Anfang) gesetzt (wie in
> /etc/init.d/console):
> /etc/config.d/base
> /etc/config.d/environment

Wenn du Werte aus diesen Konfigurationsdateien auswerten willst, sonst
brauchst du das nicht.

> /etc/config.d/functions

/etc/init.d/functions

> Ein Skelet mit einer case start) stop) esac war schon da.
> Wo muss genau "exit 0" hin. Gaanz ans Ende?

Ja ans Ende.

--
Gruß Marcus
[eisfair-Team]

[Hilmar Böhm]

Hallo Marcus,
danke. Das beruhigt :)
Gruss./Hilmar.
P.S. Ist Matthias weiter gekommen?

[Kay Martinen]

Am 05.01.2020 um 23:19 schrieb Marcus Röckrath:
> Hilmar Böhm wrote:
>
>> Was da noch alles in die /etc/init.d/local rein soll...
>
> Alles was das Herz begehrt und vor der Konfigurationsschicht bewahrt wein
> soll.

Ich setze dort den sleepmode der Platten auf meinem neuen Fileserver
(E-64) und schreibe ein startdatum in ein Flagfile.

>> Ein Skelet mit einer case start) stop) esac war schon da.
>> Wo muss genau "exit 0" hin. Gaanz ans Ende?
>
> Ja ans Ende.

War bei mir auch nicht drin in der rc.local. Ausgeführt wird sie wohl.
Allerdings erinnere ich mich dunkel das es beim Starten recht lange
dauerte bis er am Ende den login prompt zeigt.

Da vermute ich das liegt/lag am fehlenden 'exit 0' das init dort noch so
lange wartet, oder?

Werde beim nächsten reboot mal drauf achten.

Kay

--
Sent via SN (Eisfair-1)

[Hilmar Böhm]

Hallo Kay,

die /etc/init.d/local sieht bei mir jetzt so aus:
#! /bin/sh
#----------------------------------------------------------------------------
# /etc/init.d/local - rc script for gerneral purpose
#
# Creation: 19.07.2003 fm
# Last Update: 20.07.2003 fm
#
# Copyright (c) 2003 Frank Meyer <fr...@eisfair.org>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#----------------------------------------------------------------------------
/etc/init.d/functions
case $1
in
start)
boot_mesg " * Changing system font to ter-g16n..."
/bin/setfont /usr/share/kbd/consolefonts/ter-g16n.psf
;;

stop)
;;
esac
exit 0


Wie gesagt, war bei mir das case..esac schon (leer) vorhanden. stop)
brauch' ich in diesem Fall nicht.

Grüße. / Hilmar.

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

>>> Ein Skelet mit einer case start) stop) esac war schon da.
>>> Wo muss genau "exit 0" hin. Gaanz ans Ende?
>>
>> Ja ans Ende.
>
> War bei mir auch nicht drin in der rc.local. Ausgeführt wird sie wohl.
> Allerdings erinnere ich mich dunkel das es beim Starten recht lange
> dauerte bis er am Ende den login prompt zeigt.
>
> Da vermute ich das liegt/lag am fehlenden 'exit 0' das init dort noch so
> lange wartet, oder?
>
> Werde beim nächsten reboot mal drauf achten.

Ich bin, auch nach einigen Internet-Recherchen, nicht der Meinung, dass exit
0 zwingend ist.

Ich fand, dass es guter Usus sei, mit exit 0 oder einem anderen Wert zu
signalisieren, ob das Skript erfolgreich war oder nicht. Es gäbe
Init-Realisierungen, die selbsttätig anhand des Rückgabewertes ein FAIl
oder OK ausgeben. IMHO bei eisfair nicht und wenn man so was möchte, werden
die gesourcten functions dafür verwendet.

Ein immer vorhandenes "exit 0" würde somit dem Initsystem, falls es das
auswertet, immer ein OK vorgaukeln, unabhängig von dem, was wirklich los
war.

Eine Zeitverzögerung aufgrund fehlendem "exit 0" würde ich eher
ausschliessen.

--
Gruß Marcus
[eisfair-Team]

[Kay Martinen]

Am 06.01.2020 um 13:40 schrieb Marcus Röckrath:
>
> Kay Martinen wrote:
>
>>>> Ein Skelet mit einer case start) stop) esac war schon da.
>>>> Wo muss genau "exit 0" hin. Gaanz ans Ende?
>>>
>>> Ja ans Ende.
>>
>> War bei mir auch nicht drin in der rc.local. Ausgeführt wird sie wohl.
>> Allerdings erinnere ich mich dunkel das es beim Starten recht lange
>> dauerte bis er am Ende den login prompt zeigt.
>>
>> Da vermute ich das liegt/lag am fehlenden 'exit 0' das init dort noch so
>> lange wartet, oder?
>>
>> Werde beim nächsten reboot mal drauf achten.
>
> Ich bin, auch nach einigen Internet-Recherchen, nicht der Meinung, dass exit
> 0 zwingend ist.

Zwingend sicher nicht. Es hängt wohl vom Aufrufer des scripts ab was
dann die Wirkung sein mag. 'exit 0' sagt diesem ja nur 'beendet ohne
Fehler' und was beim schlichten EOF passiert ist m.E. auch nur eine
Frage wer es aufrief, mit welchem environment und shell.

> Ich fand, dass es guter Usus sei, mit exit 0 oder einem anderen Wert zu
> signalisieren, ob das Skript erfolgreich war oder nicht. Es gäbe
> Init-Realisierungen, die selbsttätig anhand des Rückgabewertes ein FAIl
> oder OK ausgeben.

Ich denke es ist ebenso guter usus das ein script das von einem anderen
prozess aufgerufen wurde (hier: init) bei seinem ende automatisch einen
rückkehr-code erzeugt, und dieser an den aufrufer zurück gegeben wird.

> IMHO bei eisfair nicht und wenn man so was möchte, werden
> die gesourcten functions dafür verwendet.
> Ein immer vorhandenes "exit 0" würde somit dem Initsystem, falls es das
> auswertet, immer ein OK vorgaukeln, unabhängig von dem, was wirklich los
> war.

Okay, wenn ein einzelnes exit 0 am ende stünde, ja. Aber man kann
natürlich stattdessen in der case-esac struktur bei start und bei stop
ein 'exit 0' unterbringen und ggf. auch im script fehler abfangen und
dann z.b. mit 'exit 1' zurück melden. Das sollte doch in jedem falle gehen.

> Eine Zeitverzögerung aufgrund fehlendem "exit 0" würde ich eher
> ausschliessen.

K.A. aber ich denke mir das init einfach generell auf die beendigung
eines scripts wartet. Aber wenn es stimmt was du oben sagst das der
eisfair-init weder ok noch fail automatisch erkennt dann bleibt ja nur
die wahl etwas zu warten nachdem das script beendet wurde, oder?
Ich meine auch nur einige wenige Sekunden und ich bin nicht mal sicher
ob es von rc.local kam. Aber das wird doch wohl als letztes aufgerufen.
Dessen ausgaben kommen bei mir zumindest direkt über dem logon (und
motd/issue)

[Kay Martinen]

Am 06.01.2020 um 13:37 schrieb Hilmar Böhm:
> Hallo Kay,
>
> die /etc/init.d/local sieht bei mir jetzt so aus:
> #! /bin/sh

> /etc/init.d/functions
> case $1
> in
> start)
> boot_mesg " * Changing system font to ter-g16n..."
> /bin/setfont /usr/share/kbd/consolefonts/ter-g16n.psf
> ;;
>
> stop)
> ;;
> esac
> exit 0

Sieht bei mir auch so aus, nur boot_mesg kenne ich nicht. Ist das aus
fuctions? Wenn das damit eisfair-like ausgegeben wird werde ich das bei
mir auch mal verwenden.

> Wie gesagt, war bei mir das case..esac schon (leer) vorhanden. stop)
> brauch' ich in diesem Fall nicht.

Du kannst das 'exit 0' auch in den start oder (auch) stop block legen.
Und man sollte auch fehler abfangen können und dann z.b. mit 'exit 1'
zurück melden können.

Ist deine Änderung des Konsolenfonts eigentlich persistent? Ich vermute:
Nein. Denn sonst müsstest du den nicht bei jedem Start setzen.
Wenn du aber änderungen machst die dauerhaft gespeichert blieben dann
denke auch daran sie unter stop) wieder zurück zu nehmen. Je nach art
der Änderung könnte das ja unwillkommene Nebenwirkungen haben. Wenn man
da z.b. einen Drucker aktiviert und er beim runter fahren nicht
deaktiviert wird dann läuft er durch. Nur als Beispiel, aus der Luft
gegriffen.

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

> Ich denke es ist ebenso guter usus das ein script das von einem anderen
> prozess aufgerufen wurde (hier: init) bei seinem ende automatisch einen
> rückkehr-code erzeugt, und dieser an den aufrufer zurück gegeben wird.

Auch ohne "exit 0" gibt ein (Bash-)Skript einen Errorlevel zurück - nämlich
0; was anderes konnte ich auch durch bewußt fehlerhafte Befehle im Skript
nicht provozieren.

<irgendein skript> | echo $?

Ob da im Initprozess etwas anders sein sollte, erschliesst sich mir nicht.

> K.A. aber ich denke mir das init einfach generell auf die beendigung
> eines scripts wartet.

Klar, aber mit einem exit o am Ende hat das nicht zu tun - auch ohne das
wird ein Skript beendet.

> Aber wenn es stimmt was du oben sagst das der
> eisfair-init weder ok noch fail automatisch erkennt dann bleibt ja nur
> die wahl etwas zu warten nachdem das script beendet wurde, oder?

Ein Skript beendet sich selber, wenn es zu Ende ist und liefert genau dann
auch einen Errorlevel zurück.

Den könnte der Init-Prozess auswerten, um Erfolg oder Misserfolg zu melden.

Init wartet nicht z. B. durch Lauschen auf die Prozessliste, ob ein Skript
zu Ende ist.

--
Gruß Marcus
[eisfair-Team]

[Hilmar Böhm]

Hallo Kay,

> Ist deine Änderung des Konsolenfonts eigentlich persistent? Ich
> vermute: Nein.

Richtig. Es ist genauso wenig persistent wie das standardmässige Setzen
des Systemfonts in /etc/init.d/console.
Es hält bis zum nächsten Re/boot. Ein Stoppen ist deshalb
überflüssig.

Deinen und Marcus' Anmerkungen zu "exit 0" stimme ich zu, soweit es sich
um einen Return Code zum aufrufenden Script handelt.
(Ich nehm's wieder raus.)

Die Idee mit dem "boot_mesg" habe ich aus dem Console-Initscript. (es
ist wirklich nur (. /etc/config.d/functions nötig.)

Grüße. / Hilmar.

[Ansgar Püster]

Hallo,

> Den könnte der Init-Prozess auswerten, um Erfolg oder Misserfolg zu melden.
>
> Init wartet nicht z. B. durch Lauschen auf die Prozessliste, ob ein Skript
> zu Ende ist.

/etc/init.d ist nur das "Sammelbecken" für die
Skripts. Entscheidend sind die Kxx bzw. Sxx
Einträge (Links) in /etc/rc?.d.

Zu Init:

Meines Wissens wird zunächst aus der /etc/inittab
ausgewertet, welcher default runlevel auszuführen
ist.

-- schnippt --
id:2:initdefault: # default runlevel is 2
...
l2:2:wait:/etc/init.d/rc 2 # 2: multi-user with network
-- schnipp --

Es wird also /etc/init.d/rc 2 ausgeführt.

In /etc/init.d/rc kann man sich anschauen, was beim
Wechsel zum runlevel 2 passiert, und ob dort ein
Returncode ausgewertet wird.

Linux ist zwar "a magic moment" aber nicht magisch!

Gruß,
Ansgar

[Matthias Prill]

Am 05.01.2020 um 21:14 schrieb Marcus Röckrath:
> Hallo Matthias,
> --- und bitte berichten.
>
Habe diese beiden Zeilen ergänzt:

/usr/sbin/ip addr add 94.x.y.z/32 peer 172.31.1.1/32 dev enx5254a2021455
/usr/sbin/ip route add default via 172.31.1.1

und damit funktioniert es.

Gruß & Danke
Matthias

[Matthias Prill]

Am 05.01.2020 um 22:08 schrieb Olaf Jaehrling:
> Hallo Mathias,
>
> das hier sollte der neue Syntax sein ....
>

> ip addr add 94.x.y.z /32 peer 172.31.1.1/32 dev enx5254a2021455
>
>>
>> route add default gw 172.31.1.1
>
> ip route add default via 192.168.0.7
> oder
> ip route add default via 192.168.0.7 dev enx5254a2021455
>

> Gruß
>
> Olaf

...damit funktioniert es:

/usr/sbin/ip addr add 94.x.y.z/32 peer 172.31.1.1/32 dev enx5254a2021455
/usr/sbin/ip route add default via 172.31.1.1

Gruß & Danke
Matthias

[Marcus Röckrath]

Hallo Matthias,

Matthias Prill wrote:

> Habe diese beiden Zeilen ergänzt:
>
> /usr/sbin/ip addr add 94.x.y.z/32 peer 172.31.1.1/32 dev enx5254a2021455
> /usr/sbin/ip route add default via 172.31.1.1
>
> und damit funktioniert es.

Fein, vielen Dank für die Rückmeldung.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Ansgar,

Ansgar Püster wrote:

>> Init wartet nicht z. B. durch Lauschen auf die Prozessliste, ob ein
>> Skript zu Ende ist.
>
> /etc/init.d ist nur das "Sammelbecken" für die
> Skripts. Entscheidend sind die Kxx bzw. Sxx
> Einträge (Links) in /etc/rc?.d.

Klar, im laufenden Betrieb nutzt man dann allerdings /etc/init.d/<name>
start|stop

Die im Raum szehende Frage ist aber, ob ein "exit 0" notwendig sei.

Ich bin da eher skeptisch.

--
Gruß Marcus
[eisfair-Team]

[Ansgar Püster]

Hallo,

Oh, sorry, ich hatte es so verstanden, dass es um
den Bootvorgang und mögliche Wartevorgänge ging.

Bin dann mal raus.
Gruß,
Ansgar

[Marcus Röckrath]

Hallo Ansgar,

Ansgar Pc3bcster wrote:

>>>> Init wartet nicht z. B. durch Lauschen auf die Prozessliste, ob ein
>>>> Skript zu Ende ist.
>>>
>>> /etc/init.d ist nur das "Sammelbecken" für die
>>> Skripts. Entscheidend sind die Kxx bzw. Sxx
>>> Einträge (Links) in /etc/rc?.d.
>>
>> Klar, im laufenden Betrieb nutzt man dann allerdings /etc/init.d/<name>
>> start|stop
>>
>> Die im Raum szehende Frage ist aber, ob ein "exit 0" notwendig sei.
>>
>> Ich bin da eher skeptisch.
>
> Oh, sorry, ich hatte es so verstanden, dass es um
> den Bootvorgang und mögliche Wartevorgänge ging.

Kay hatte zwischenzeitlich die Vermutung geäußert, ein fehlendes exit 0
könnte für eine Verzögerung sorgen.

--
Gruß Marcus
[eisfair-Team]

[Kay Martinen]

Am 06.01.2020 um 19:23 schrieb Ansgar Püster:
>
> Am 06.01.2020 um 17:39 schrieb Marcus Röckrath:
>> Hallo Ansgar,
>>
>> Ansgar Püster wrote:
>>
>>>> Init wartet nicht z. B. durch Lauschen auf die Prozessliste, ob ein
>>>> Skript zu Ende ist.
>>>
>>> /etc/init.d ist nur das "Sammelbecken" für die
>>> Skripts. Entscheidend sind die Kxx bzw. Sxx
>>> Einträge (Links) in /etc/rc?.d.

Mal abgesehen davon das ich das wohl weiß... deine Nachricht mit diesem
Inhalt ist bei mir ohne inhalt angekommen, als ob nur die kopfzeilen mit
kamen. Ist das nur bei mir so? Dann müsste ich mal meinen SN untersuchen...

>> Klar, im laufenden Betrieb nutzt man dann allerdings /etc/init.d/<name>
>> start|stop

Das ist in jedem Fall einfacher als über rcx.d erst das passende SxxNAME
zu suchen. Außer man hat eh eine runlevel-änderung vor. Aber dafür gibt
es ja mehrere möglichkeiten. Z.b. 'telinit'

>> Die im Raum szehende Frage ist aber, ob ein "exit 0" notwendig sei.
>>
>> Ich bin da eher skeptisch.
>
> Oh, sorry, ich hatte es so verstanden, dass es um
> den Bootvorgang und mögliche Wartevorgänge ging.

Dem ist auch so, meine ich. Denn rc.local wird ja beim booten ausgeführt
- als letztes. Konkreter gehts nur um die Frage ob generell in den
boot-scripten ein 'exit 0' explizit nötig ist weil es evtl. ein "Kein
Fehler" an init melden könnte obwohl im Script selbst doch ein Fehler
auftrat.
Heißt also
Kein exit 0: script beendet sich mit echtem Fehlercode.
Ein exit 0 am Ende: script beendet sich immer mit "Kein Fehler"

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

> Konkreter gehts nur um die Frage ob generell in den
> boot-scripten ein 'exit 0' explizit nötig ist weil es evtl. ein "Kein
> Fehler" an init melden könnte obwohl im Script selbst doch ein Fehler
> auftrat.
> Heißt also
> Kein exit 0: script beendet sich mit echtem Fehlercode.

Wie soll das gehen?

Ein Fehlercode wird immer mit

exit <errorlevel>

gesetzt.

Fehlt also exit am Skriptende wird in aller Regel der Fehlercode 0
rauskommen - anderes habe ich nicht provozieren können, denkbar ist aber
dennoch, dass die ausführende Shell aus bestimmten Gründen auch einen
Fehlercode != 0 zurückliefern könnte.

Zur Auswertung nach Skriptende wäre der eher ungeeignet.

Soll ein Skript mit einem definierten Fehlercode enden, hat der
Skriptprogrammierer dafür zu sorgen.

Das beginnt in der Designphase schon damit, den einzelnen Fehlercodes
bestimmte Zustände zuzuordnen - schau mal in mein fbtr64toolbox.sh rein.

Weiter bedingt das auch, bei Aufrufen externer Programme im Skript deren
Rückgabewerte zu analysieren und darauf geeignet zu reagieren.

> Ein exit 0 am Ende: script beendet sich immer mit "Kein Fehler"

Jedenfalls sieht es dann nach außen so aus, auch wenn im Skript der größte
Blödsinn passiert sein kann.

Ein plumpes "exit 0" ist IMHO genau sinnfrei, wie kein explizites "exit
<errorlevel>".

--
Gruß Marcus
[eisfair-Team]

[Olaf Jaehrling]

Hallo allerseits,


Marcus Röckrath schrieb am 06.01.20 um 13:40:

>
> Ich bin, auch nach einigen Internet-Recherchen, nicht der Meinung, dass exit
> 0 zwingend ist.

Jein .. siehe unten.

>
> Ich fand, dass es guter Usus sei, mit exit 0 oder einem anderen Wert zu
> signalisieren, ob das Skript erfolgreich war oder nicht. Es gäbe
> Init-Realisierungen, die selbsttätig anhand des Rückgabewertes ein FAIl
> oder OK ausgeben. IMHO bei eisfair nicht und wenn man so was möchte, werden
> die gesourcten functions dafür verwendet.
>
> Ein immer vorhandenes "exit 0" würde somit dem Initsystem, falls es das
> auswertet, immer ein OK vorgaukeln, unabhängig von dem, was wirklich los
> war.
>
> Eine Zeitverzögerung aufgrund fehlendem "exit 0" würde ich eher
> ausschliessen.

Die Zeitverzögerung hat damit nichts zu tun. Das "exit 0" ganz am Ende
wird eigentlich nur deshalb angewendet um zu verhindern dass jemand, z.B
durch ein Sicherheitsloch o.ä, am Ender der Datei mitteles echo
ausführbaren code einschleußen kann der dann beim Systemstart immer
mitgestartet wird. Es gab mal ein PHP-Sicherheitsloch mit dem man u.a
echobefehle mit rootrechten ausführen konnte. Damals wurden Binary
nachgeladen und ausgeführt. Deshalb wird immer empfohlen bei der
/etc/rc.d/rc.local bzw. deren äquivalente ganz zum Schluss exit 0
einzugeben. Sollte also jemand was hinten einfügen wird das nicht mehr
ausgeführt weil nach dem exit 0.
Selbst bei Systemen mit systemd wird immer noch die rc.local
ausgewertet, deshalb gilt die Empfehlung weiterhin.

Gru

Olaf

>

[Kay Martinen]

Am 06.01.2020 um 21:54 schrieb Olaf Jaehrling:

> Die Zeitverzögerung hat damit nichts zu tun. Das "exit 0" ganz am Ende
> wird eigentlich nur deshalb angewendet um zu verhindern dass jemand, z.B
> durch ein Sicherheitsloch o.ä, am Ender der Datei mitteles echo

> einzugeben. Sollte also jemand was hinten einfügen wird das nicht mehr
> ausgeführt weil nach dem exit 0.

Das ist ein Wirklich triftiger Grund das ans Ende zu schreiben zumal der
Pfad ja bekannt wäre und ein schlichtes 'echo >>' reichen würde - wenn
es denn erst mal mit root-rechten im Dateisystem schreiben dürfte.

> Gru

Hat da ein fehlendes exit 0 in deinem NUA das 'ß' unterschlagen?

SCNR. :-)

[Olaf Jaehrling]

Hallo Matthias,

Matthias Prill schrieb am 06.01.20 um 17:26:

>
> ...damit funktioniert es:
>
> /usr/sbin/ip addr add 94.x.y.z/32 peer 172.31.1.1/32 dev enx5254a2021455
> /usr/sbin/ip route add default via 172.31.1.1

Schön, freut mich. Danke für die Rückmeldung.

Gruß

Olaf

>
> Gruß & Danke
> Matthias
>

[Olaf Jaehrling]

Hallo Kay,


Kay Martinen schrieb am 06.01.20 um 21:59:

> Am 06.01.2020 um 21:54 schrieb Olaf Jaehrling:
>
>> Die Zeitverzögerung hat damit nichts zu tun. Das "exit 0" ganz am Ende
>> wird eigentlich nur deshalb angewendet um zu verhindern dass jemand, z.B
>> durch ein Sicherheitsloch o.ä, am Ender der Datei mitteles echo
>
>> einzugeben. Sollte also jemand was hinten einfügen wird das nicht mehr
>> ausgeführt weil nach dem exit 0.
>
> Das ist ein Wirklich triftiger Grund das ans Ende zu schreiben zumal der
> Pfad ja bekannt wäre und ein schlichtes 'echo >>' reichen würde - wenn
> es denn erst mal mit root-rechten im Dateisystem schreiben dürfte.

Naja, wie gesagt, durch ein Sicherheitsloch irgendwelcher Programme.
Mich hatte es mal erwischt mit dem proxy mocks. Der wurde mit
rootrechten ausgeführt und hat vermutlich durch bestimmte
Zeichenkombinationen sich irritieren lassen und dann einfache Befehle
ausgeführt. Dadurch wurde mein Server zur Spamschleuder. Böse Erfahrung. :(

Wenn ich mich recht entsinne war doch vor 1-2 Jahre auch mal sowas
ähnliches wieder passiert; und bei irgendeinem php-script, welches ich
mal gesehen hatte, konnte man nach der ?-Abfrage beliebige Kommandos
uebergeben, die dann (hier allerdings mit webserverrechten) auf der
commandline ausgeführt wurden. Es wäre fatal gewesen, wenn der Apache
als root gelaufen wäre.

>
>> Gru
>
> Hat da ein fehlendes exit 0 in deinem NUA das 'ß' unterschlagen?

:) jupp, immer diese "Nullen" TsTsTs :D :D

Gruß

Olaf

[Marcus Röckrath]

Hallo Olaf,

Olaf Jaehrling wrote:

> Das "exit 0" ganz am Ende
> wird eigentlich nur deshalb angewendet um zu verhindern dass jemand, z.B
> durch ein Sicherheitsloch o.ä, am Ender der Datei mitteles echo
> ausführbaren code einschleußen kann der dann beim Systemstart immer
> mitgestartet wird.

Ok, das ist ein Grund. Unsere Diskussion ging halt in eine ganz andere
Richtung.

--
Gruß Marcus
[eisfair-Team]