Moin moin,
gestern ist etwas furchtbares passiert. Während des Betriebes sind mehrere Rechner einfach neu gestartet. Interessant war an dieser Stelle, das es alle Rechner waren, die durch den OPSI Server verwaltet werden. Der Server selbst ist inzwischen über ein Jahr dort in Betrieb und hat solch ein Verhalten noch nie gezeigt. Nun wurde aber letzte Woche der Kreis der OPSI Admins erweitert und ich nehme mal an, das hier der Faktor Mensch für das Problem verantwortlich war.
Meine Recherchen in den Logfiles waren nicht sehr erfolgreich, bzw. geben keinen Aufschluß ob es wirklich so passsierte. Ich nehme aber an, das entweder im opsi config interface oder im opsi-admin der Befehl hostControl_reboot ohne Rechnerangabe durchgeführt wurde. Das hat in meiner Testumgebung jeweils das geschilderte Problem verursacht. Ich muß es hier ein Problem nennen, da dieser Befehl in einer kurzen Unachtsamkeit schnell ausgelöst ist und furchtbare Folgen haben kann. Zum Glück sind keine Server an den OPSI gebunden. Ich mag mir gar nicht vorstellen, was dann los gewesen wäre.
Jetzt habe ich zwei Fragen:
1. Kann ich doch noch irgendwo nachvollziehen, ob das so passiert ist, wie ich vermute? Hier geht es nicht darum einen Schuldigen zu finden, aber um die weitere Existenz des OPSI Server.
2. Sollte es wirklich so sein, das dieser Befehl ohne Rechnerangabe dann für alle Systeme gilt, wie kann man das abstellen?
Wenn ich alle Systeme neu starten möchte, dann doch bitte mit einem entsprechenden Parameter. In dieser Form ist das ein furchtbares Event, wenn die Systeme ohne Nachfrage einfach neu starten.
hostControl
Re: hostControl
Hallo,
allgemein gesprochen, ja das ist durchaus plausibel
. Man kann vielleicht etwas in der bash_history sehen oder in der opsi-admin history.
Aber vielleicht etwas zum Hintergrund. Bei opsi4 Methoden ist der gängige Standard, dass wenn keine Parameter angegeben werden, generell alle Objekte angesprochen werden. In dem angesprochenen Bereich ist es auch so. Diese Methode generell auf zu weichen wäre aus Abwärtskompatibilitätsgründen (komisches Wort) fatal.
Wir hatten vor einiger Zeit schon mal diese Diskussion im Entwicklermeeting und waren damals der Meinung, dass man hier keinesfalls, dass Standardverhalten von opsi beeinflussen darf. Denn es gibt viele Partner, die für opsi Erweiterungen betreiben und auch sehr viele Anwender, die auf Basis Ihrer Geschäftsprozesse viel in opsi Skripten. Wenn sich nun das Verhalten Grundsätzlich ändern würde, würde das viel Arbeit bei sehr vielen Leuten bedeuten (und arbeit bedeutet immer Kosten).
Wir haben uns aufgrund deines Reports noch mal zusammengesetzt und haben nun beschlossen, dass wir nur bei den zwei Methoden: hostControl_reboot und hostControl_shutdown eine Änderung vornehmen, die verhindert das man ausversehen alle Rechner runterfährt oder neu startet. Da diese zwei Methoden sehr betriebskritische Features sind und wir davon ausgehen, dass diese zwei Methoden nicht auf diese Weise geskriptet werden, kann man diese Entscheidung durchaus vertreten.
Allgemein gilt: opsi ist SEHR mächtig. Auf der Konsole kann man bei opsi, wie auch bei anderen Tools, sehr viel falsch machen und sehr schnell, sehr viel kaputt hauen. Dies im Hinterkopf, sollte man bei der Rechtevergabe für ein produktives opsi-System sehr vorsichtig sein. Eine Möglichkeit, die auch wahrscheinlich sauberer ist, einigen Leuten per acl komplett den Zugang zu diesen zwei hostControl Methoden zu entziehen oder generell das hostControl für eine ausgewählte wahl an Users frei zu geben. Oder noch viel Besser ein Inhouse-Workshop buchen oder die Admins in die opsi-Schulung schicken, es sind immer wieder Plätze für die Schulungen frei. Dort wird der richtige Umgang mit dem Webservice vermittelt.
Die oben angesprochene Änderung wird soweit sie die interne Qualitätskontrolle besteht mit dem nächsten Release veröffentlicht.
allgemein gesprochen, ja das ist durchaus plausibel
. Man kann vielleicht etwas in der bash_history sehen oder in der opsi-admin history.Aber vielleicht etwas zum Hintergrund. Bei opsi4 Methoden ist der gängige Standard, dass wenn keine Parameter angegeben werden, generell alle Objekte angesprochen werden. In dem angesprochenen Bereich ist es auch so. Diese Methode generell auf zu weichen wäre aus Abwärtskompatibilitätsgründen (komisches Wort) fatal.
Wir hatten vor einiger Zeit schon mal diese Diskussion im Entwicklermeeting und waren damals der Meinung, dass man hier keinesfalls, dass Standardverhalten von opsi beeinflussen darf. Denn es gibt viele Partner, die für opsi Erweiterungen betreiben und auch sehr viele Anwender, die auf Basis Ihrer Geschäftsprozesse viel in opsi Skripten. Wenn sich nun das Verhalten Grundsätzlich ändern würde, würde das viel Arbeit bei sehr vielen Leuten bedeuten (und arbeit bedeutet immer Kosten).
Wir haben uns aufgrund deines Reports noch mal zusammengesetzt und haben nun beschlossen, dass wir nur bei den zwei Methoden: hostControl_reboot und hostControl_shutdown eine Änderung vornehmen, die verhindert das man ausversehen alle Rechner runterfährt oder neu startet. Da diese zwei Methoden sehr betriebskritische Features sind und wir davon ausgehen, dass diese zwei Methoden nicht auf diese Weise geskriptet werden, kann man diese Entscheidung durchaus vertreten.
Allgemein gilt: opsi ist SEHR mächtig. Auf der Konsole kann man bei opsi, wie auch bei anderen Tools, sehr viel falsch machen und sehr schnell, sehr viel kaputt hauen. Dies im Hinterkopf, sollte man bei der Rechtevergabe für ein produktives opsi-System sehr vorsichtig sein. Eine Möglichkeit, die auch wahrscheinlich sauberer ist, einigen Leuten per acl komplett den Zugang zu diesen zwei hostControl Methoden zu entziehen oder generell das hostControl für eine ausgewählte wahl an Users frei zu geben. Oder noch viel Besser ein Inhouse-Workshop buchen oder die Admins in die opsi-Schulung schicken, es sind immer wieder Plätze für die Schulungen frei. Dort wird der richtige Umgang mit dem Webservice vermittelt.
Die oben angesprochene Änderung wird soweit sie die interne Qualitätskontrolle besteht mit dem nächsten Release veröffentlicht.
Vielen Dank für die Nutzung von opsi. Im Forum ist unser Support begrenzt.
Für den professionellen Einsatz und individuelle Beratung empfehlen wir einen Support-Vertrag und eine Schulung.
Gerne informieren wir Sie zu unserem Angebot.
uib GmbH
Telefon: +49 6131 27561 0
E-Mail: sales@uib.de
Re: hostControl
Moin,
danke für die ausführliche Antwort. Die hat es ja ganz schön in sich, verhärtet aber meinen Verdacht, das dort tatsächlich ein entsprechender Befehl abgesetzt wurde. Ist es möglich, das Befehle aus dem Config Interface nicht geloggt werden? In der opsi-admin history habe ich geschaut, finde aber keinen entsprechenden Eintrag.
Das hier eine Änderung vorgenommen werden soll, finde ich ausgesprochen super. Ich kämpfe gerade um die Reputation des Servers in unserem Unternehmen. Da sind solche Dinge natürlich erstmal Gift.
Wie gesagt, bedanke ich mich herzlich für deine ausführliche Antwort und hoffe, das wir künftig sowas vermeiden können. Ein paar gute Tipps hast du ja gegeben, die ich auch dann demnächst umsetzen werde.
Viele Grüße und ein schönes Wochenende
Torsten
danke für die ausführliche Antwort. Die hat es ja ganz schön in sich, verhärtet aber meinen Verdacht, das dort tatsächlich ein entsprechender Befehl abgesetzt wurde. Ist es möglich, das Befehle aus dem Config Interface nicht geloggt werden? In der opsi-admin history habe ich geschaut, finde aber keinen entsprechenden Eintrag.
Das hier eine Änderung vorgenommen werden soll, finde ich ausgesprochen super. Ich kämpfe gerade um die Reputation des Servers in unserem Unternehmen. Da sind solche Dinge natürlich erstmal Gift.
Wie gesagt, bedanke ich mich herzlich für deine ausführliche Antwort und hoffe, das wir künftig sowas vermeiden können. Ein paar gute Tipps hast du ja gegeben, die ich auch dann demnächst umsetzen werde.
Viele Grüße und ein schönes Wochenende
Torsten
Re: hostControl
Ich muß hier leider nochmals ein wenig nachhaken, da ich auf folgenden Eintrag gestoßen bin: viewtopic.php?f=6&t=2941
Da hier in den nächsten Tagen eine Entscheidung fallen wird, ist es natürlich nicht so schön, wenn man ein ähnliches Problem findet und 2011 eine Lösung gesucht wird. Aber seit dem scheint da ja nichts passiert zu sein. Ich verlange jetzt nicht sofort eine Lösung, aber es sollte zeitnah eine Info dazu kommen, das hier Änderungen vorgenommen werden.
Derzeit sind über vier Depot Server insgesamt 96 Clients angebunden und es war angedacht, das noch auszuweiten. Ich muß jetzt erstmal davon ausgehen, das alle 96 Clients neu gestartet wurden und da sehe ich dann schon ein erhebliches Risiko. Der Kunde hat ziemlich viel Vertrauen in das System verloren.
Die Änderungen der ACL hilft natürlich weiter und es ist jetzt umgesetzt worden, bzw. alle Admins haben nun erstmal keinen Zugriff mehr auf den OPSI. Aber die Lösung ist das ja nicht und ohne Zugriff können wir auch das System auch abschalten.
Da hier in den nächsten Tagen eine Entscheidung fallen wird, ist es natürlich nicht so schön, wenn man ein ähnliches Problem findet und 2011 eine Lösung gesucht wird. Aber seit dem scheint da ja nichts passiert zu sein. Ich verlange jetzt nicht sofort eine Lösung, aber es sollte zeitnah eine Info dazu kommen, das hier Änderungen vorgenommen werden.
Derzeit sind über vier Depot Server insgesamt 96 Clients angebunden und es war angedacht, das noch auszuweiten. Ich muß jetzt erstmal davon ausgehen, das alle 96 Clients neu gestartet wurden und da sehe ich dann schon ein erhebliches Risiko. Der Kunde hat ziemlich viel Vertrauen in das System verloren.
Die Änderungen der ACL hilft natürlich weiter und es ist jetzt umgesetzt worden, bzw. alle Admins haben nun erstmal keinen Zugriff mehr auf den OPSI. Aber die Lösung ist das ja nicht und ohne Zugriff können wir auch das System auch abschalten.
Re: hostControl
Hi,
das Posting, welches du gefunden hast war der Anstoß der Diskussion, die ich schon erwähnt habe. Allerdings ist der ältere Post ein anderes Problem, als das was du beschrieben hast. Im Posting ging es dadrum, dass bei Eingabe eines falschen Parameters (Tipp-Fehler, oder alter Client oder wie in dem Fall statt die ID des Clients die IP-Adresse) alle Clients bedient wurden. Das war definitiv ein Bug und wurde damals schon behoben. Das was du beschreibst ist der Aufruf ohne Parameter. Dieses Verhalten ist wie ich vorher schon schrieb Standardverhalten der opsi4 Methoden.
Die Änderungen sind implementiert und im internen Tests, wenn diese die QA überstehen werden Sie veröffentlicht. Eine offizielle Ankündigung wird es wie üblich bei Veröffentlichung über die Standard-Kanäle von opsi-Releases geben.
Wenn ich das hier richtig sehe, geht es hier um einen Bedienungsfehler. Mit verbieten über ACL meinte ich, dass man die hostControl-Methoden einschränkt, nicht das ganze opsi-System. Wenn man diese Methoden über den configed bedient, tritt dieser Fall auch nie auf, denn der opsi-configed übergibt immer einen Parameter bei diesen Methoden. Nur wenn man diese Methoden in der Konsole verwendet, besteht dieser Schutz natürlich nicht.
Nach wie vor gilt, wenn es sich um eine produktive Installation handelt, danach hört sich dein Post sehr stark an, empfehlen wir dringend einen Supportvertrag.
das Posting, welches du gefunden hast war der Anstoß der Diskussion, die ich schon erwähnt habe. Allerdings ist der ältere Post ein anderes Problem, als das was du beschrieben hast. Im Posting ging es dadrum, dass bei Eingabe eines falschen Parameters (Tipp-Fehler, oder alter Client oder wie in dem Fall statt die ID des Clients die IP-Adresse) alle Clients bedient wurden. Das war definitiv ein Bug und wurde damals schon behoben. Das was du beschreibst ist der Aufruf ohne Parameter. Dieses Verhalten ist wie ich vorher schon schrieb Standardverhalten der opsi4 Methoden.
Die Änderungen sind implementiert und im internen Tests, wenn diese die QA überstehen werden Sie veröffentlicht. Eine offizielle Ankündigung wird es wie üblich bei Veröffentlichung über die Standard-Kanäle von opsi-Releases geben.
Wenn ich das hier richtig sehe, geht es hier um einen Bedienungsfehler. Mit verbieten über ACL meinte ich, dass man die hostControl-Methoden einschränkt, nicht das ganze opsi-System. Wenn man diese Methoden über den configed bedient, tritt dieser Fall auch nie auf, denn der opsi-configed übergibt immer einen Parameter bei diesen Methoden. Nur wenn man diese Methoden in der Konsole verwendet, besteht dieser Schutz natürlich nicht.
Nach wie vor gilt, wenn es sich um eine produktive Installation handelt, danach hört sich dein Post sehr stark an, empfehlen wir dringend einen Supportvertrag.
Vielen Dank für die Nutzung von opsi. Im Forum ist unser Support begrenzt.
Für den professionellen Einsatz und individuelle Beratung empfehlen wir einen Support-Vertrag und eine Schulung.
Gerne informieren wir Sie zu unserem Angebot.
uib GmbH
Telefon: +49 6131 27561 0
E-Mail: sales@uib.de
Re: hostControl
Ich danke Dir für die Antwort.
Ein Supportvertrag kommt jetzt natürlich erstmal nicht in Frage. Im Moment muß man ja erstmal sehen, wo die Reise hingeht. Einerseits bei euch und andererseits bei uns. Mich muß man ja auch nicht von dem System überzeugen, da ich nun seit 2010 fleißig damit arbeite. Erst als Test, anschließend als internen Installationsserver und nun schließlich beim Kunden. Dummerweise tauchte das Thema ja beim Kunden auf und nun gilt es ihn zu überzeugen, das der Server nur das macht, was man ihm sagt. Da baer keiner für den Fehler verantwortlich sein will, geht der Kunde von einem Produktfehler aus.
Es ist nicht leicht und ich habe schon sehr viel Energie investiert. Es wäre schade, wenn es jetzt ein so doofes Ende nimmt.
Edit: Kann man im opsi-admin die acl für die hostControl Methoden ändern? Ich habe jetzt in einer Testumgebung den Zugriff auf opsi-admin selbst gesperrt.
Ein Supportvertrag kommt jetzt natürlich erstmal nicht in Frage. Im Moment muß man ja erstmal sehen, wo die Reise hingeht. Einerseits bei euch und andererseits bei uns. Mich muß man ja auch nicht von dem System überzeugen, da ich nun seit 2010 fleißig damit arbeite. Erst als Test, anschließend als internen Installationsserver und nun schließlich beim Kunden. Dummerweise tauchte das Thema ja beim Kunden auf und nun gilt es ihn zu überzeugen, das der Server nur das macht, was man ihm sagt. Da baer keiner für den Fehler verantwortlich sein will, geht der Kunde von einem Produktfehler aus.
Es ist nicht leicht und ich habe schon sehr viel Energie investiert. Es wäre schade, wenn es jetzt ein so doofes Ende nimmt.
Edit: Kann man im opsi-admin die acl für die hostControl Methoden ändern? Ich habe jetzt in einer Testumgebung den Zugriff auf opsi-admin selbst gesperrt.