Michael Huhn

@cherif

i-doit prüft bei SSO selbst kein Zertifikat. Die Anmeldung findet vor i-doit statt, in der KB-Anleitung über ADFS und das Apache-Modul mod_auth_mellon. i-doit übernimmt nur den Benutzernamen, den der Webserver danach weitergibt. Die Zertifikatsanmeldung richten Sie deshalb nicht in i-doit ein, sondern dort, wo die Anmeldung stattfindet, bei Ihnen also in ADFS.

Wichtig ist, dass bei der Anmeldung per Zertifikat derselbe Benutzername bei i-doit ankommt wie bei der Passwortanmeldung. Findet i-doit zu diesem Namen keinen Benutzer, zeigt die Anmeldeseite den Text „Single-Sign-On user could not be found in i-doit! Login manually.“

Woran scheitert die Anmeldung bei Ihnen genau: Erscheint dieser Text in i-doit, oder kommt schon vorher eine Fehlermeldung von ADFS?

Anleitung zu ADFS mit i-doit: https://kb.i-doit.com/de/benutzerauthentifizierung-und-verwaltung/sso-vergleich/saml/adfs-saml.html

@bhinterland

wenn Haupt- und Nebenkarten zum selben Vertrag gehören, könnt ihr sie als Einträge in einem gemeinsamen Objekt vom Typ SIM-Karte anlegen:

1. In der Kategorie SIM hinterlegt ihr die Vertragsdaten, z. B. die Telefonnummer.
2. In der Kategorie Karten legt ihr über Neu je Karte einen Eintrag an, z. B. mit dem Titel „Hauptkarte“ und „Nebenkarte 1“, jeweils mit Kartennummer, Pin und PUK.
3. In jedem Eintrag wählt ihr unter verknüpftes Mobiltelefon das Gerät, in dem die Karte steckt.

Das SIM-Objekt zeigt dann alle Karten des Vertrags. Am jeweiligen Mobiltelefon erscheint in der Kategorie Zugewiesene SIM-Karten nur die eigene Karte mit SIM-Objekt und Kartentitel, die übrigen Karten seht ihr am SIM-Objekt. In der Standardkonfiguration lassen sich als Gerät nur Objekte vom Typ Mobiltelefon auswählen.

@joernc

ausschlaggebend ist die Slot-Sortierung des Racks. Steht sie auf absteigend, rechnet die API den Wert von pos wie bei einer Höheneinheit um, auch beim vertikalen Einbau. Bei einem Rack mit 42 HE wird aus Slot 1 so die Position 42, und die gibt es bei den vertikalen Slots nicht. Deshalb kommt die Meldung. Bei aufsteigender Sortierung tritt das nicht auf.

Bei absteigend sortierten Racks kannst du als Workaround die Umrechnung vorwegnehmen: pos = Rackhöhe − Slot + 1, und parent im selben Request mitgeben. Für Slot 1 auf der Rückseite eines 42-HE-Racks also:

"data" : {
   "parent" : <Rack-ID>,
   "insertion" : 0,
   "option" : 4,
   "pos" : 42
}

Damit wird die PDU in Slot 1 auf der Rückseite gespeichert. Gib parent immer im selben Request mit: Ohne parent im selben Request wird die Position beim vertikalen Einbau nicht gespeichert, auch im aufsteigend sortierten Rack und auch wenn das Rack vorher separat als Standort gesetzt wurde. Die API meldet dabei trotzdem Erfolg.

@joernc

jeder Mandant hat seine eigenen Daten, dazu zählen auch Passwörter.
Der neue Mandant kennt also keine andere Benutzer als die, die per Default erstellt sind.

Wenn Sie also in der Loginmaske admin/admin eintippen, wird geprüft in welchem der Mandanten diese Kombination hinterlegt ist. Sie werden direkt eingeloggt wenn es nur einen Mandant gibt, zu dem diese Kombination passt.

@FFlori

dazu muss man den Counter editieren, wie in der KB beschreiben:
https://kb.i-doit.com/de/grundlagen/benutzerdefinierte-zaehler.html#fuhrende-nullen

@thebob1

eine i-doit 8.3 gibt es nicht. Die aktuelle Version ist die 38.

Aktuell gibt es weder eine Anleitung noch eine Funktion, um zwei Datenbanken zusammenzuführen Die Daten müssten also als Import hinzugefügt werden.

@sveno

dazu drei Punkte mit Hintergrund aus dem Code:

1. Stromkreise/Phasen pro PDU

i-doit modelliert das über die Kategorie Branch an der PDU. In der Liebert/Vertiv-MIB, an der sich i-doit orientiert, heisst diese Ebene lgpPduRb (Receptacle Branch), also Stromkreis bzw. Sicherungsabgang. Bei dreiphasigen PDUs entspricht das typischerweise einem Branch
pro Phase (L1, L2, L3), das hängt aber vom PDU-Hersteller-Layout ab. Pro Branch trägst du die Anzahl der Receptacles ein (Default 6).

2. Editieren in der PDU-Übersicht

Die Kategorie PDU-Übersicht (C__CATS__PDU_OVERVIEW) ist intern eine virtuelle Kategorie (source_table = isys_catg_virtual_list). Virtuelle Kategorien aggregieren nur, sie haben keine eigene Speicher-Spaltenstruktur, daher ist der Edit-Button ausgegraut. Das ist gewolltes
Verhalten, kein Bug der Demo.

3. "Stromverbraucher zu Receptacle verbinden"

Receptacles sind in i-doit kein eigenständiges Objekt. Die Tabelle isys_cats_pdu_branch_list hat lediglich eine Integer-Spalte receptables (= Anzahl). Receptacle-Namen, Pwr-Werte und akkumulierte Energie holt i-doit ausschliesslich per SNMP, die Default-OIDs zeigen auf
die Liebert/Vertiv-Enterprise-MIB (1.3.6.1.4.1.476.1.42., Felder lgpPduRcpEntry). Überschreibbar sind die Pfade unter snmp.pdu.path.* in den Tenant-Einstellungen.

Ohne SNMP-fähige PDU bleibt die Receptacle-Spalte auf "Anzahl" sitzen. Die Verknüpfung Server zu PDU läuft dann nicht receptacle-genau, sondern connector-genau über Verkabelung:

• Am Verbraucher: Kategorie Stromverbraucher mit Anschluss
• An der PDU: Kategorie Stromversorger oder einfache Connectors-Einträge
• Verbindung per Verkabelung (Kabelverbindung).

Wenn du es receptacle-genau abbilden willst, hat sich diese Convention bewährt: pro Receptacle einen Output-Connector auf der PDU anlegen, benannt nach Phase und Slot (z. B. L1 / Rec 1 bis L3 / Rec 6), und den Server-Power-Anschluss per Verkabelung mit genau diesem
Connector verbinden. Die Demo macht es ähnlich, dort heissen die Outputs allerdings nur 16A-Anschluss 01 bis 12.

4. Auslastung pro Phase/PDU/Rack

Zwei Wege:

• Live (SNMP): PDU spricht SNMP, OIDs sind in den Tenant-Settings gesetzt, PDU-Übersicht zeigt die Werte automatisch.
• Statisch (Report): Nennlast aus Stromverbraucher (Felder Volt, Watt, Ampere) summieren und per Connector-Titel an der PDU gruppieren. Voraussetzung: der Phasen-Prefix aus Punkt 3.

Skeleton für den Report-Manager (Belegung pro PDU, gefiltert auf Power-Output-Connectors):

  SELECT
      rack.isys_obj__title                              AS Rack,
      pdu.isys_obj__title                               AS PDU,
      SUBSTRING_INDEX(pdu_conn.isys_catg_connector_list__title, '/', 1) AS Phase,
      COUNT(*)                                          AS Receptacles_total,
      SUM(CASE WHEN pdu_conn.isys_catg_connector_list__isys_cable_connection__id IS NOT NULL
               THEN 1 ELSE 0 END)                       AS Receptacles_used
  FROM      isys_catg_connector_list         pdu_conn
  JOIN      isys_obj                         pdu
         ON pdu.isys_obj__id                 = pdu_conn.isys_catg_connector_list__isys_obj__id
        AND pdu.isys_obj__isys_obj_type__id  = 49
        AND pdu.isys_obj__status             = 2
  LEFT JOIN isys_catg_location_list          pdu_loc
         ON pdu_loc.isys_catg_location_list__isys_obj__id = pdu.isys_obj__id
        AND pdu_loc.isys_catg_location_list__status       = 2
  LEFT JOIN isys_obj                         rack
         ON rack.isys_obj__id                = pdu_loc.isys_catg_location_list__parentid
        AND rack.isys_obj__isys_obj_type__id = 4
  WHERE     pdu_conn.isys_catg_connector_list__status            = 2
        AND pdu_conn.isys_catg_connector_list__type              = 2       -- 2 = OUTPUT
        AND pdu_conn.isys_catg_connector_list__isys_connection_type__id IN (4, 5)  -- Schuko + IEC
  GROUP BY  rack.isys_obj__id, pdu.isys_obj__id, Phase
  ORDER BY  Rack, PDU, Phase;

Hintergrund zu den Konstanten: C__CONNECTOR__OUTPUT = 2, Connection-Type IDs 4 und 5 = Schuko und IEC-Power-Connector (aus isys_connection_type). Damit bleiben Netzwerk-Ports und der PDU-Input aussen vor.

Watt-Summen pro Phase folgen demselben Pattern, sobald Stromverbraucher am Server gepflegt ist; dafür joinst du über isys_cable_connection auf die Verbraucher-Seite und ergänzt SUM(consumer.isys_catg_pc_list__watt).

@thebob1

die angezeigten Daten in der Quickinfo sind fest definiert und können nicht angepasst werden.
Einfacher wäre es die Objektliste anzupassen.

@thebob1

Bugs können hier nicht gelöst werden, daher sowas immer an den Support melden.
help.i-doit.com oder via help@i-doit.com

@stefanp74

also es gibt keine direkte Ansicht aber es lassen sich einfach SQL Queries für den Report Manager nutzen.
Da muss dann jedes mal die ID geändert werden, hier 2 Beispiele:

Beispiel 1:

SELECT
      DATE(c.isys_cmdb_status_changes__timestamp)    AS change_date,
      CASE s.isys_cmdb_status__const
          WHEN 'C__CMDB_STATUS__PLANNED'                 THEN 'Geplant'
          WHEN 'C__CMDB_STATUS__ORDERED'                 THEN 'Bestellt'
          WHEN 'C__CMDB_STATUS__DELIVERED'               THEN 'Geliefert'
          WHEN 'C__CMDB_STATUS__ASSEMBLED'               THEN 'In Arbeit'
          WHEN 'C__CMDB_STATUS__TESTED'                  THEN 'Getestet'
          WHEN 'C__CMDB_STATUS__IN_OPERATION'            THEN 'In Betrieb'
          WHEN 'C__CMDB_STATUS__DEFECT'                  THEN 'Defekt'
          WHEN 'C__CMDB_STATUS__UNDER_REPAIR'            THEN 'In Reparatur'
          WHEN 'C__CMDB_STATUS__DELIVERED_FROM_REPAIR'   THEN 'Aus Reparatur zurück'
          WHEN 'C__CMDB_STATUS__INOPERATIVE'             THEN 'Außer Betrieb'
          WHEN 'C__CMDB_STATUS__STORED'                  THEN 'Gelagert'
          WHEN 'C__CMDB_STATUS__SCRAPPED'                THEN 'Verschrottet'
          WHEN 'C__CMDB_STATUS__SWAPPED'                 THEN 'Getauscht'
          ELSE s.isys_cmdb_status__title
      END                                            AS status
  FROM      isys_cmdb_status_changes c
  JOIN      isys_cmdb_status  s ON s.isys_cmdb_status__id = c.isys_cmdb_status_changes__isys_cmdb_status__id
  WHERE     c.isys_cmdb_status_changes__isys_obj__id = 275
  ORDER BY  c.isys_cmdb_status_changes__timestamp ASC;

Beispiel2:

SELECT
      o.isys_obj__id                                 AS object_id,
      o.isys_obj__title                              AS object_title,
      DATE(c.isys_cmdb_status_changes__timestamp)    AS change_date,
      c.isys_cmdb_status_changes__timestamp          AS change_time,
      s.isys_cmdb_status__title                      AS status_constant,
      CASE s.isys_cmdb_status__const
          WHEN 'C__CMDB_STATUS__PLANNED'                 THEN 'Geplant'
          WHEN 'C__CMDB_STATUS__ORDERED'                 THEN 'Bestellt'
          WHEN 'C__CMDB_STATUS__DELIVERED'               THEN 'Geliefert'
          WHEN 'C__CMDB_STATUS__ASSEMBLED'               THEN 'In Arbeit'
          WHEN 'C__CMDB_STATUS__TESTED'                  THEN 'Getestet'
          WHEN 'C__CMDB_STATUS__IN_OPERATION'            THEN 'In Betrieb'
          WHEN 'C__CMDB_STATUS__DEFECT'                  THEN 'Defekt'
          WHEN 'C__CMDB_STATUS__UNDER_REPAIR'            THEN 'In Reparatur'
          WHEN 'C__CMDB_STATUS__DELIVERED_FROM_REPAIR'   THEN 'Aus Reparatur zurück'
          WHEN 'C__CMDB_STATUS__INOPERATIVE'             THEN 'Außer Betrieb'
          WHEN 'C__CMDB_STATUS__STORED'                  THEN 'Gelagert'
          WHEN 'C__CMDB_STATUS__SCRAPPED'                THEN 'Verschrottet'
          WHEN 'C__CMDB_STATUS__SWAPPED'                 THEN 'Getauscht'
          ELSE s.isys_cmdb_status__title
      END                                            AS status_label
  FROM      isys_cmdb_status_changes c
  JOIN      isys_obj          o ON o.isys_obj__id = c.isys_cmdb_status_changes__isys_obj__id
  JOIN      isys_cmdb_status  s ON s.isys_cmdb_status__id = c.isys_cmdb_status_changes__isys_cmdb_status__id
  WHERE     o.isys_obj__id = 12345
  ORDER BY  c.isys_cmdb_status_changes__timestamp ASC;

Hier noch die Vorschau: