1. Home
  2. Deutsch

Subcategories

  • Fragen und Infos rund um i-doit, das Team, Ziele und Pläne

    1k Topics
    4k Posts
    M
    Hallo Community, ist es möglich, die auf ein Objekt wirkenden Risiken kaskadiert nach unten zu vererben (bzw. die ganze Kaskade darzustellen)? Beispiel: (Auf jeder Ebene liegen eigene Risiken) Gebäude * 2) Raum * 3) Objektgruppe physische Server * 4) VM_Host01 * 5) Fileserver_Buchhaltung Darstellung der Risiko-Kaskade, die auf den Fileserver Auswirkung hat (z.B. Ebene 1: Gebäudebrand; Ebene 2: Zutritt nicht Berechtigter Personen; Ebene 3: Manipulation am Gerät; Ebene 4: leitet sich aus Objektgruppe ab; Ebene 5: Nicht Verfügbarkeit von Buchhaltungsdaten) Ich habe bislang nur die Ableitung von Risiken auf ein Objekt aus den zugeordneten Objektgruppen gefunden.

  • Fragen zu Installation, Konfiguration oder Nutzung

    2k Topics
    8k Posts
    A
    Hallo, ich wundere mich, warum normale Templates und Templates für Massenänderung unterschiedlich sind. Es gibt bei uns einige Fälle, z.B. Schränke, Patchpanels usw. für die ich die spezifischen Eigenschaften nach dem CSV-Import per Massenänderung setze (Hersteller, Anschlüsse usw.). Für diese Objekttypen habe ich aber auch schon normale Templates, wenn man einzelne Objekte per Hand anlegt. Beide Template-Sorten machen doch eigentlich das gleiche, würde nicht ein Template für beide Zwecke genügen?

  • Einen Fehler melden, Änderungen anregen oder selber entwickeln.

    1k Topics
    4k Posts
    G
    @Michael-Huhn Danke für die Rückmeldung. Ich habe zwei Drafts eingestellt. Ich muss nochmal in Ruhe schauen, ob ich was übersehen habe. https://github.com/i-doit/knowledge-base/pull/1093 https://github.com/i-doit/scripts/pull/50 Was mir generell am meisten aufstößt, ist dass die DocumentRoot komplett mit Schreibrechten für den Apache ausgestattet wird. Auf der Seite vom Hardening wird dann mit Permissions und immutable Attribute das wieder gesichert. Das macht IMHO wenig Sinn, dass man sichere Voreinstellungen des Systems (z.B. Owner root:root mit Context httpd_sys_content_t) aufweicht, um sie dann später umständlich wieder zu härten. Ich bin ja ein Fan davon, gleich alles richtig und sicher zu installieren (dann kann man es auch gut als RPM verpacken) und nur auf die Verzeichnisse dem Webserver Schreibrechte zu geben, wo diese tatsächlich notwendig sind. Aber dann kann man natürlich erstmal nicht den Web-Updater benutzen. Aber die sind aus Sicherheitsgesichtspunkten sowieso immer kritisch, wenn der Web-Update seinen eigenen Code aktualisieren will, sofern man keinen Umweg über ein Script geht, welches als root läuft (der Web-Update startet z.B. per sudo ein Script als root, welches den Code aktualisiert...) Soll man das hier diskutieren oder ist es besser, ich mache ein Issue im GitHub zu diesem Thema?
Log in to post
Load new posts
  • M

    Raumpläne verschwunden

    7
    2
    0 Votes
    7 Posts
    299 Views
    D
    Hi @mikelae , du musst die eingefügten Raumpläne makieren und dann übernehmen und speichern. so siehts aus wenn es nicht makiert ist [image: 1620643193929-test1.png] so ist makiert [image: 1620643246005-test2.png] VG DIM
  • H

    idoitcmk :SSL certificate problem: unable to get issuer certificate

    2
    1
    0 Votes
    2 Posts
    357 Views
    Michael HuhnM
    Hallo @hallo456, zuerst mal werden in Zertifikaten immer Hostnamen verwendet und keine IP-Adressen. Somit sollte der Hostname in der Konfiguration des Check_MK 2 Add-ons stehen. Weitere Informationen zur Verwendung von HTTPS findest du z.B. unter https://kb.i-doit.com/display/de/Sicherheit+und+Schutz#SicherheitundSchutz-Transportverschlüsselung mfg Micha
  • H

    idoitcmk Status FAIL

    5
    1
    0 Votes
    5 Posts
    441 Views
    M
    Zum Problem mit "Undifined index: mandator" gibt es laut i-doit support schon ein Bug Ticket. Da wird noch daran gearbeitet. Ich bin in das selbe Problem gelaufen. idoitcmk push sollte aber trotzdem funktionieren (tuts bei mir aber nicht). siehe: Topic 3766 lg, Marco @oliver-w said in idoitcmk Status FAIL: Hallo zusammen, dann "missbrauche" ich mal diesen Thread für mein Problem. [image: 1588765079743-d9ef584d-4304-4408-98f4-a9d704063155-grafik.png] Sowohl die Anbindung des Addons an die JSON-RPC API als auch die Verbindung zum Livestatus funktioniert nicht. idoit und checkmk laufen auf unterschiedlichen Hosts - rein lokaler Testaufbau. Hier die entsprechenden Stellen der config.json: "i-doit": { "url": "http://localhost/src/jsonrpc.php", "key": "277lbx7723pcwwk8", "username": "admin", "password": "admin", "language": "en", "limitBatchRequests": 500 }, "check_mk": { "webAPI": { "url": "http://192.168.100.10/TESTSITE/check_mk/webapi.py", "username": "automation", "secret": "MOINKUGACUIJUGHVCAYG", "effectiveAttributes": true }, "livestatus": { "title": "Check_MK", "type": "tcp", "host": "192.168.100.10", "port": 6557 } }, Weitere Konfig: [image: 1588765834150-524dceea-0d4a-4b1c-a4a0-e320f6c58bbc-grafik.png] [image: 1588765864643-e915a3dd-38a7-45b2-87e4-a55f593fdf90-grafik.png] Wäre für jegliche Hilfe dankbar. Schöne Grüße!