nagios restart != nagios restart

nagios restart != nagios restart (45 Beiträge, 909 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

... oder warum ich mich gerade nicht auskenne...

Gut, ich hab mit Linux (leider?) nicht sehr viel zu tun, darf aber dennoch ein schon bestehendes Nagios betreuen.
An sich nicht wirklich tragisch, da gibt es ein fertiges Paket, das man installiert, ein paar Konfigfiles und Doku im Netz. Dazu noch ein wenig Hausverstand meinerseits und ein paar aufgeschnappte Brocken Linux-Halbwissen und die Sache steht.

Was ich aber nach wie vor nicht behirne: warum kann/darf ich ein Skript nicht direkt von dort aufrufen, wo es liegt, sondern muss immer den kompletten Pfad angeben?

Konkret ging es eben um Nagios, das sich derart verhängt hat, dass man nur mehr über das Skript selbst den Dienst neu starten konnte. Dazu muss man ja /etc/init.d/nagios restart verwenden.
Bin ich jetzt schon im Verzeichnis /etc/init.d/ kann ich noch so oft nagios restart tippen, es wird einfach nicht gefunden:

nagios:/# /etc/init.d/nagios status
nagios (pid 7180) is running...
nagios:/# cd /etc/init.d
nagios:/etc/init.d# nagios status
-bash: nagios: command not found
nagios:/etc/init.d#

Da fragt man sich als Windoof [sic!] Admin, wo da der Unterschied ist - abgesehen davon, dass man ja eigentlich nichtmal sieht, ob das jetzt eine Datei ist, die man ausführen kann oder nicht (ja, ich weiß, Endungen sind was für Weicheier...).

Hat jemand vielleicht eine kurze Erklärung parat bzw. einen Link mit genau solchen Infos zu Linux an sich?

Danke!

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

./nagios restart

Woher sollte man sonst wissen ob jetzt das Prog im Suchpfad oder das im aktuellen Verzeichnis ausgeführt wird?

Woher sollte man sonst wissen ob jetzt das Prog im Suchpfad oder das im aktuellen Verzeichnis ausgeführt wird?

Danke, macht durchaus Sinn. Und zeigt gleichzeitig wieder schön, warum man trotz "Hausverstand" manchmal ansteht (da ist man wohl windows-verwöhnt - sucht dieses doch immer erst im aktuellen Verzeichnis und erst dann im Pfad).

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Man muss immer den genauen absoluten oder relativen Pfad angeben wenn man etwas ausführen möchte, das nicht in PATH liegt.

Als von überall:
/etc/init.d/nagios

Von /etc aus würde auch gehen:
init.d/nagios

Und wenn du in /etc/init.d bist, dann musst du dich auf den aktuellen Ordner beziehen, das geht mit "." (".." wäre dann der übergeordnete Ordner, in dem Fall /etc)
./nagios

das nicht in PATH liegt.

selbiges gilt ja eigentlich unter windows auch

-----------------------------------
x-x-o
o-x-o
o-o-x ... and the winner is x

Außer das er dort auch die Programme aus dem aktuellen Ordner nimmt

ok... stimmt.
-----------------------------------
x-x-o
o-x-o
o-o-x ... and the winner is x

Außer halt dass Windows, aus welchem (sicherheitstechnisch) nicht ganz nachvollziehbaren Grund auch immer, das aktuelle Verzeichnis nicht nur als Teil des PATHs ansieht sondern ihm auch noch höhere Priorität als dem restlichen PATH gibt.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

[...] aus welchem (sicherheitstechnisch) nicht ganz nachvollziehbaren Grund auch immer [...]

Würde ich als "historisch bedingt" einstufen - schließlich war Windows vor NT ja nix anderes als ein GUI für DOS... und unter DOS war's halt damals so.

Es stört mich auch nicht weiter und ist logisch (zumindest für mich) auch nachvollziehbar, aber wissen sollte man es eben

Gibt es eigentlich sowas wie ein Tutorial-Mini-Linux (von mir aus auch in einer VM), das einem solche Dinge näherbringt? Grad mal die absoluten Basics, mit einer kleinen Anleitung, wo was ist und was es macht?

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

afaik, nein. Was soll da bitte auch drin stehen?

Linux hat den Komplexitätsumfang von Windows. Kannst Du Dir ein Mini-Tutorial für Windows für den nichteingeweihten Admin vorstellen? Naja, gibt's schon, nur ist kein Mini-Tut. Heißt MCSA oder so ähnlich...

Und viel darunter bringt auch nix wenn's darum geht das zu administrieren.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Was soll da bitte auch drin stehen?

Na eben so Kleinigkeiten wie "das ist die autoexec.bat/config.sys für Linux, dort sind jene Systemdateien", usw., damit man eben nicht nur die reine Administration sondern auch ein wenig "unter der Haube" Wissen hat.

Vielleicht geht es auch nur mir so, aber ein System zu administrieren heißt auch Dinge zu Wissen, die einen normalen "Benutzer" meist nicht interessieren.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Und da fängt's auch gleich an. "Einfach nur" eine autoexec gibt's nämlich nicht. Es gibt 'n init-job der abläuft (und der theoretisch auch einfach nur irgendein Programm sein kann), der wiederum von seinem Script konfiguriert wird, welches weit, weit mehr ist als 'n simpler Batch-Stapel. Hier wär dann 'ne kleine Abhandlung zum Thema inittab und runlevels. Und dabei werden heutzutage normalerweise (normalerweise. Nicht üblicherweise und schon gar nicht sicher), eine Sammlung von scripts angestossen, die normalerweise (nicht üblicherweise... nicht sicher...) in /etc/irgendwo liegen. Und die (normalerweise, laberrhabarber) gekennzeichnet sind (je nachdem welche Distri so oder auch anders) damit das System weiß in welcher Reihenfolge sie gestartet werden sollen, und in welchem runlevel.

Und außer der Tatsache dass das System initial das Programm unter /sbin/init startet (welches auch immer dort grad rumliegt, muss ja nicht zwingend das übliche init sein) ist davon nix wirklich fix.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Alles schön und gut, ich gestehe ja dem System zu, so flexibel zu sein - aber irgendwas MUSS doch einmal beim Starten "dran sein", um den Rest dann zu starten. Und eben solche Dinge würden mich interessieren. Dass dann da mitunter weiß der Teufel noch was nachkommt soll ruhig sein, eine einheitlche Grundstruktur an Verzeichnissen wird es aber hoffentlich immer geben.
Ich sehe zB. immer dieses /etc/, ein /sbin/, /bin/, /var/, /lib/, usw., die egal wo immer drauf sind - mein WRT54GL mit DD-WRT daheim bringt diese Struktur ebenso mit wie der Nagios Server in der Firma.

Hab ich das also insoweit richtig verstanden, dass diese Struktur zwar immer gleich ist, es aber an der jeweiligen Distri liegt, diese auch wirklich zu nutzen?

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Das hat 'n bischen was von der Schweizer Gesetzgebung. Im Prinzip sind ja alle Kantone gleich, nur im Detail isses halt nicht ganz so und eigentlich könnt jeder was anderes machen, wenn er sich nicht an den Standard halten will und jeder macht's ein kleeeein wenig anders.

Es gibt eine mehr oder weniger "standard" Konfiguration des Ganzen, die auch von den meisten Distris eingehalten wird. Nur ist das eben eine Konvention, nicht eine "so und nicht anders geht's" Vorgabe.

Was ich Dir vorher geschrieben hab ist mehr oder weniger dieser "Standard". Sprich, es gibt 'ne /sbin/init, die eine /etc/inittab liest und entsprechend vorgeht, gettys (oder andere terminals) spawnt, da drin steht auch der Standardrunlevel und was init tun soll um ihn zu erreichen, usw. Bei einigen Distris schaut das so aus, dass es ein /etc/rc.d Verzeichnis gibt in dem da die Scripts drin sind und je nachdem das entsprechende ausgeführt wird. Da gibt's dann für jedes Runleve Unterverzeichnisse, wo scripts drinstehen mit Zahlen im Namen die festlegen, in welcher Reihenfolge die scripts ausgeführt werden sollten. Das war auch der Standard bis so vor... weiß nicht, 4 Jahren oder so. Und bei manchen Distris isses heute noch so.

Daran halten sich aber nicht alle. Gentoo z.B., das ich hier bei der Maschine auf der ich sitz verwende, funktioniert erheblich anders. Wie's genau für Deine Distri ausschaut erfährst Du am ehesten durch googlen. Probier mal sowas wie "linux boot init $distriname" als Suchstring. Ohne die Anführungszeichen natürlich und statt $distriname den Namen Deiner Distribution.

Generell, zum Starten/Stoppen verschiedener Dienste, eignen sich üblicherweise die Start/Stop scripts vom System recht gut. Die findest in /etc/init.d oder /etc/rc.d/init.d (je nach Distri). Die mit Parameter "start" oder "stop" aufgerufen erfüllt meist die Aufgabe recht gut (außer Du versuchst irgendwas relativ dummes, wie z.B. dem System mit einem Aufruf des mount/unmount scripts das Filesystem unter'm *PIEP* wegzuziehen

).

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Danke für die Mühe, einem Linux-DAU das so zu erklärt zu haben, dass er sich was drunter vorstellen kann

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Danke

Ja, der Pfad ist schon ein Hund - besonders dann, wenn NUR dort gesucht wird...

[...] auf den aktuellen Ordner beziehen, das geht mit "."

Das ist eh wie unter DOS/Windows - dort kenn ich mich in der Shell aber ohnehin gut aus - umso mehr wurmt es mich, dass sich Linux zwar vie Shell so herrlich verwalten lässt, mir aber gerade dort das Wissen (noch) fehlt. SS64.com ist zwar gut, aber nur für Dinge, die es unter Windows auch einen echten Befehl gibt...

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

13.07.2010, 15:12 Uhr - Editiert von Glockman, alte Version: hier

./nagios stop
./nagios start

oder halt

./nagios restart

aber nur wenn du im /etc/init.d directory bist

ls -l nagios ( ist etwa wie dir im dos )

nur wenn ein x dabei steht kann man es ausführen rwx = read-write-execute

Danke auch an Dich

ls -l nagios ( ist etwa wie dir im dos )

Ja, den Befehl kannte ich grad noch - aber wie suche ich in allen (Unter)Verzeichnissen nach etwas? Also dir /s nagios*.* für bash.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

find . | grep "nagios"
find / | grep "nagios"

find / -name "nagios*"

Danke nochmal

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

etwa so

find / -name nagios

(fange im root dir an zu suchen nach einem ding namens nagios)

kann bei linux etwas anders sein als bei mir am Solaris

"man find" wäre ein tip . man steht für manual
PS: immer blanks dazwischen, nicht so schlampig wie im dos

13.07.2010, 15:12 Uhr - Editiert von arctic, alte Version: hier

Gleich nochmal danke

man steht für manual

Da kommt die nette Frage "Welche Manual-Seite wollen Sie haben?". Ist recht nett, wenn man den Befehl, den man braucht schon nicht kennt um ihn nachzuschlagen

SS64.com hilft zwar, aber hin und wieder freut man sich auch über die Extra-Auskünfte anderer

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

^ Forum Linux-Support #6085451
	Re(5): nagios restart != nagios restart

Psychopath

13.07.2010, 21:43:23

Der Befehl apropos kann zum Finden eines gesuchten Befehles manchmal hilfreich sein. (Aus der manpage von apropos: apropos - locate commands by keyword lookup)
Viel Erfolg,
j.

Spitze, danke, wird morgen gleich versucht!

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

servise nagios restart

funktioniert bei mir von egal wo ich es starte. Ist CentOS, wenn das (wieder mal) unterschiedlich sein sollte bei deine Distribution...

Save the Earth... it's the only planet with chocolate.
Wir sollten die Fekter aus- oder einweisen...
Amazon Kindle DX: http://www.amazon.com/dp/B0015TG12Q

Ist Debian. Und dass man Services auch "ganz einfach so" mit dem von Dir angesprochenen Befehl neu starten kann wusste ich zB. auch nicht - alle von mir besuchten Nagios-Seiten haben immer vom Skript oder dem Webfrontend gesprochen.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Debian ist das Beste!

Na dann bin ich ja froh, die beste Distri zu haben, und diese genauso gut (oder schlecht) bedienen zu können wie mein DD-WRT via Telnet daheim

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

An apt-get kommt einfach nichts heran

Debian setzt intelligente Benutzer voraus ... *shrug

Edit: *genier*

16.07.2010, 02:24 Uhr - Editiert von lsr, alte Version: hier

... also für uns beide nix?

Den . kannst du übrigens, wenn ich mich richtig erinnere, auch in den PATH schreiben...Problem gelöst

Werd ich mal versuchen, danke!

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Den . kannst du übrigens, wenn ich mich richtig erinnere, auch in den PATH
schreiben...Problem gelöst .

Das wäre in einem Multiuser-Environment schwer fahrlässig.

Stell Dir vor, ich kompilier ein böses programm als non-root user (rootkit, virus, whatever), nenn es "ls" und legs ins /tmp.....

(ja ich weiß, PATH reihenfolge, aber riskieren würd ichs trotzdem nicht)
-
lesen, denken, googlen, nochmals denken, posten
google knows everything

Ich denke jeder Benutzer hat seine eigenen Umgebungsvariablen, inkl. path. Aber vermutlich ist Glockmann root.
j.

Das sollte man natürlich in der .bashrc machen, sodass es nur bei dem einen User so ist...

Nachdem dein Problem ja gelöst ist...

Ich würde dir empfehlen, mal "man bash" durchzuführen und die manpage durchzuackern.
Auf dem Weg sammelst alle Infos - so auch die PATH-Geschichte.

PATH wird übrigens nicht in jeder Shell gleich ausgewertet (in manchen brauchst zB ein "hash -r" oder "rehash" danach, damit eine PATH-Änderung auch greift).

Beim Durchackern stößt Du u.U. auf so manches neues - danach hast aber wirklich alle Grundsatzsachen abgedeckt.

Danke für den Tipp!

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung