Habe dieses Thema noch weiter verfolgt.
Angelegte Ports in der Kategorie "Netzwerk" werden offenbar einwandfrei erzeugt. Das Obengesagte betrifft aus meiner Sicht bislang "nur" die Kategorie "Verkabelung", und damit Anschlüsse wie sie z.B. Steckdosen haben.
Ich würde mich freuen, wenn einer der Entwickler vielleicht kurz etwas dazu sagen könnte, insbesondere, ob dieser Fehler behoben wird, und ob er in der Subskriptionsversion ebenfalls besteht.
viele Grüße,
Frank
Lokale IP-Adreßräume sollten in Zeiten von VRF, VPN und Virtualisierten Instanzen nicht global einzigartig sein.
Zumindest Netzbereiche müssen mehrfach anlegbar sein, nicht nur als aufeinander aufbauende Supernets, sondern mit gleicher Maskierung.
Aktuell kommt bei der Anlage eines Layer-3-Netzes beim Check eine Overlapping Warning, dass das Netz andere Netzbereiche überschneidet (das ist mit einem Supernet "Global v4" keine Kunst).
Der Trick sollte hier aber normalerweise sein, das Layer3-Netz einem distinguierten (von anderen Netzen abgeschlossenen) Layer2 Netz zuzuordnen, dann müßte die Kollision / Overlapping verschwinden bzw. nicht mehr angezeigt werden. Oder ist das so zu verstehen, daß man nur die doppelt angelegten / sich theoretisch überschneidenden Netze angezeigt bekommen soll? Das wird mit der Zeit aber sehr unübersichtlich….
Zumindest die nicht-öffentlichen Netze sollten von einer Overlapping Warning ausgenommen werden, weil diese dazu tendieren, in größeren
IT-Installationen (oder Dokumentationen, siehe mein Vorredner / TE) doppelt aufzutauchen.
Dazu zählen auch die neuen CGN-Netzbereiche, die von RIPE nur für Carriergrade-NAT Zwecke reserviert wurden.
Zusammenfassend geht es hier um folgende Standards:
RFC1918:
(Private address)
RFC6598:
(Shared address /CGNAT)
RFC 5735:
(Link local)
Evtl. eine Idee für die nächsten Updates?
Gruß,
Frank
Hallo,
vielen Dank für das Update. Das freut mich sehr, daß es die Darkfiber Dokumentation in i-doit geschafft hat. Welche kommerzielle Version (1.5?) ist hier genau gemeint? Bezieht sich das auf das kommende Update 1.5.3?
An der Beantwortung habe ich auch Interesse und verweise noch zusätzlich auf diesen Thread:
http://forum.i-doit.org/index.php/topic,3358.msg10994.html#msg10994
Hallo Maurice,
nein, das war offenbar noch nie vorgesehen. Offenbar scheint es in der IT-Landschaft -außer bei dir und bei uns- nicht vorzukommen, daß Patchfelder fest back-to-back miteinander verbunden werden. Oder man kann sich nicht vorstellen, daß das manuelle Verbinden der Anschlüsse fast genauso lange dauert wie das physische Auflegen der Kabel. Wir haben das vor mittlerweile fünf Jahren angesprochen gehabt, es hat mehrere Threads gegeben in denen das besprochen wurde, aber bei synetics offenbar niemanden erreicht.
Du hast das ja im letzten Jahr auch schon einmal angefragt gehabt, so daß eigentlich der Bedarf der Kunden langsam offensichtlich sein sollte. Hat trotzdem niemanden wirklich interessiert. Nicht mal eine Rückmeldung, "ja machen wir, nein machen wir nicht" war dazu zu lesen. Hier mal die Threads dazu:
Deiner von Oktober 2014: http://forum.i-doit.org/index.php/topic,3507.msg11471.html
Der alte von April 2010: http://forum.i-doit.org/index.php/topic,1492.msg6604.html
Noch ein alter, April 2010: http://forum.i-doit.org/index.php/topic,1475.msg8268.html
Ich habe es mittlerweile aufgegeben danach zu fragen.
Gruß,
Frank
Hallo Maurice,
diese Frage haben wir uns vor 4 Jahren auch alle schon gestellt. Es gibt schon einen Thread hierzu, den könnte man evtl. mal reaktivieren.
http://forum.i-doit.org/index.php/topic,1475.msg8268.html
Ich bin gerade nicht ganz sicher, was die aktuelle Version angeht, ob es da schon Fortschritte in der Angelegenheit gibt.
Stimme zu! Ist ein nerviges Problem, was mit wenig Aufwand gelöst werden könnte.
Einen Linux-Server, egal ob nun virtuell oder dediziert, kann man durchaus sehr sicher machen. Ich würde keinen vServer nehmen, da die CMDB durchaus sehr ressourcenintensiv werden kann (vor allem bei mehreren Mandanten in nicht quantifizierter Größe). Du willst genug Ressourcen übrig haben.
Wenn Sicherheit das zentrale Thema ist (davon gehe ich nach Deinen bisherigen Angaben aus), würde ich das um eine Firewall/VPN-Lösung erweitern und ansonsten von "außen" gar keine Zugriffe oder eben nur per bereits angesprochener HTTP-BASIC-AUTH erlauben. Die läßt sich einfach einrichten und ist, da sie direkt im Apache stattfindet, nahezu unknackbar - zumindest wenn das Passwort vernünftig gewählt ist. Übrigens kann man über den Weg auch statische Kundennetze (oder eben VPN-IP-Ranges) freischalten und andere außen vor lassen. Dann findet für die "richtigen" Nutzer natürlich auch keine 2. Passwortabfrage statt, sondern nur für Leute, die von unbekannten IP-Ranges darauf zugreifen. Die sicherste Lösung ist aber die "reine" VPN-Variante, d.h. andere externe Zugriffe sind nicht möglich. Nur, wer im VPN sitzt, kann auf die CMDB zugreifen. Ist im Prinzip wie ein Firmennetz, und kann auch mit solchen kombiniert werden.
Zufällig sind wir übrigens ISP, und haben solche VPN-Installationen schon mehrfach (auch für prominente Kunden) im Einsatz. Ich mag hier auf dem Board keine öffentliche Werbung machen, aber wenn Du Interesse hast und Unterstützung brauchst, kannst Du dich per PN an mich wenden.
Gruß,
Frank
Ich finde schon, daß dies noch ein relevanter Bereich ist, der Teil der Dokumentation mit i-doit sein sollte und nicht den Rahmen sprengt. Weshalb sollte eine IT-Dokumentation bei Glasfasern an der Layer2-Grenze aufhören? Wenn ich schon Kupferkabel, deren Länge und Farbe sowie sonstige Beschaffenheit, dokumentieren kann, sollte das doch wohl auch mit anderen Übertragerstandards gehen. Allerdings ist eben die Glasfasertechnik nicht eben unkomplex und die vielen Ebenen, die hier ja angesprochen wurden, sollten durchaus von vorneherein berücksichtigt werden, z.b. mit Containerobjekten. Ich habe mich noch nicht entschieden, ob wir da eine eigene Kategorie zusammenzimmern oder auf eine etwaige Umsetzung innerhalb von i-doit warten sollten. Es wäre natürlich hilfreich, wenn es so etwas wie eine Aussage dazu von Seiten der Entwickler geben würde.
Ich hoffe, synetics nimmt hiervon Notiz und nimmt das vielleicht in eine (interne?) Roadmap auf. Ich bin, wie gesagt, gerne mit Vorschlägen oder "Anschauungsunterricht" behilflich. Wenn jemand bei s. das liest, darf er sich gern bei mir melden (E-Mail Adresse im Profil).
Idee: Einfach eine HTTP BASIC AUTH davor schalten? (.htaccess)
Das ist nach aktuellem Technologiestand relativ sicher.
Das Passwort ließe sich zudem unabhängig von i-doit-Credentials verwalten und auch für mehrere User einrichten. Und für die sichere Datenübertragung könnte man SSL zuschalten.
Nachtrag: Die Objekte werden natürlich auch nicht angelegt, d.h. nicht nur ein Anzeigefehler, sondern die ganze Funktion ist tot.