Nachdem ich den Switch 3560G auf die neue Version 12.2(55)SE12 (IPBASEK9) aktualisiert hatte und einen Reload ausführte, erschien dieses Problem. Die WebGUI wurde nur teilweise angezeigt:
Lösung: Es ist ein Browser Problem mit der Sprache. Es muss die bevorzugte Sprache „English“ eingestellt werden:
Drei Punkte / Einstellungen / Sprachen / Bevorzugte Sprache
Schieben Sie im Browser die bevorzugte Sprache Englisch an die 1. Stelle nach oben und schliessen dann wieder den Browser.
Schaut man sich den Inhalt des tar File’s an, ist auch nur ein Folder „en“ zu finden.
Kaum ist die bevorzugte Sprache „English“ eingestellt, kommt auch wieder wie gewohnt die vollständige WebGUI.
Tja, mich hat es nun auch erwischt. Mit einem selbstsignierten Zertifikat wäre übergangsweise das Problem mit dem Zertifikat gelöst, wenn ich da nicht die falsche DNS Suffix in der CN genommen hätte. Die Folge, kein Zugriff mehr auf die Web-GUI möglich. Der Aufruf über IP Adresse funktionierte nicht. Langes durchstöbern im Internet brachte auch keinen Fortschritt. Vorschläge wir die 30-30-30 Regel, via TFTPD *.bin File hochladen, Ausprobieren verschiedener Benutzernamen und das Reset auf Werkseinstellung, brachten alles keinen Erfolg. Um so mehr war der Frust, CISCO entschuldigt sich für den BUG, der nicht behebbar ist. Entsorge den Router auf eigene Kosten. Doch, einen kleinen Lichtblick gab es von einem englischen Kollegen. Probiere doch aus, welche Ports auf dem Router noch offen sind? Folgende Schritte bin ich dann gegangen:
Schritt 1: RV320/RV325 mit einer Büroklammer den Hardware Button ca. 20 sec gedrückt halten. Die LEDs vom Router fangen and zu blinken und es wird die Werkseinstellung wieder hergestellt.
Schritt 2: Altes Notebook oder Rechner nehmen und die Netzwerkeinstellungen auf DHCP einstellen. Über den Kommandointerpreter: ipconfig /renew eine neue IP Adresse anfordern lassen. Wenn es der einzige Rechner im Netzwerk ist, wird dieser die IP-Adresse 192.168.1.100/255.255.255.0 erhalten. Das sieht gut aus, der Router ist somit mit der Default IP Adresse 192.168.1.1 erreichbar: ping 192.168.1.1.
Schritt 3: Auf diesen alten Rechner installieren wir uns nun das Tool nmap (nicht grafisch, siehe OpenSource) und geben dazu den Befehl: nmap 192.168.1.1 -Pn ein. Wir lauschen auf dem Router, welche Ports noch offen sind und erhalten als Ergebnis diese Liste:
Ein Danke an einen anderen englischen Kollegen im Internet, dieser meinte, nutze den offenen Port 8007, sprich, gebe über die URL vom Browser diese Zeile ein http://192.168.1.1:8007. Ich war erstaunt, yeeeepeah die WEB-GUI erwachte wieder zum Leben. Die Freude währte nicht lange. Nach Eingabe von Benutzername: cisco und Passwort: cisco landete ich immer wieder auf der http://192.168.1.1:8007/welcome/login.cgi Webseite in der Anmeldemaske. Eine Endlosschleife …. Ich bin dann alle hier gefunden Ports durchgegangen. Wie es halt so ist, der letzte Port 8443/tcp – https-alt war dann die Rettung.
Schritt 4: Browser starten, in der URL die Zeile https://192.168.1.1:8443 eingeben und sich freuen, es startet wieder das CISCO Dashboard und der Router lässt sich wieder von neuem Konfigurieren. Aber Achtung, Router auf Werkseinstellung heißt nicht daß alles zurückgesetzt wird. Das Erste was Sie machen müssen, löschen Sie unter Zertifikatsverwaltung > Mein Zertifikat das falsche/defekte Zertifikat oder erstellen sich ein neu selbstsigniertes Zertifikat. Da war ich überrascht und das ist der CISCO Bug. Nach Reset in Werkseinstellung bleiben alle alten Zertifikate im Zertifikatsspeicher/Mein Zertifikat bestehen. Diese werden nicht gelöscht! So etwas ist schon hart, denkt man, es wird auch ein Default Zertifikat mit der Werkseinstellung neu generiert. Aber leider weit gefehlt.
Hinweis: In meinem Fall war die DIAG LED nicht mehr rot. Es gibt Fälle, da bleibt der Router mit blinkender grünen LED und dauerhaft roter DIAG LED in diesem Zustand hängen. Das bedeutet, der Router hat noch nicht seine Default IP 192.168.1.1 gesetzt und kann somit auch nicht angesprochen werden. Diesen Zustand konnte ich noch nicht lösen. Bin aber dabei auch dieses Problem zu lösen.
So, hat es mich nun auch erwischt. Eines Tages fror bei mir der Bildschirm unmittelbar nach der Eingabe des Anmeldenamens und Passworts direkt nach der Bestätigung ein. Ein Willkommens Gruß lief ins unendliche. Was nun?
Wenn bei Ihnen die folgenden Voraussetzungen erfüllt sind, wie bei mir: – Hardware: als Bootlaufwerk eine SSD Festplatte (256 GB, Vendor egal) und eine physische Festlatte als Daten Festplatte. – Version 1607 (Build 14393.693), Wichtiges Update KB3211320, KB3199209, KB3199986 sind Sie ein glücklicher Gewinner wie ich…
Die Lösung:
a.) Eingabeaufforderung in Windows 10 starten: Rechnung starten bis Anmeldung zu sehen ist, SHIFT Taste gedrückt halten und klicken Sie unten rechts den Power Button und wählen „Neu starten“ aus. Dies muss schnell passieren, da sonst der Bildschirm einfriert.
b.) Sie gelangen in das UEFI Fenster, das erkennen Sie an dem hellblauen Hintergrund. Wählen Sie als erstes die „Problembehandlung“.
c.) Wählen Sie hier die Option „Eingabeaufforderung (Administrator)“ und bestätigen Sie die anschließend die Sicherheits-Abfrage.
d.) Deaktivieren Sie nun das „Dynamic Ticking“ Flag: Dynamic Ticks stoppt den Windows System Timer, wenn der Rechner im Leerlauf steht. Es spart bei Notebooks die Akku Power. Für Desktops eine nicht notwendige Funktion. Dieses Problem gab es auch schon in Windows 7 und insbesondere Windows 8. Das Microsoft hier überhaupt nicht reagiert, ist nicht nachvollziehbar. Betrifft es doch viele User.
Wechseln Sie den Laufwerks Buchstaben. Vermutlich wird es (je nach Anzahl der Partitionionen) F: sein. Wählen Sie das Verzeichnis F:\Windows\System32 aus und geben Sie den Befehl: „bcdedit /set disabledynamictick yes“ ein.
Geschafft!! Rechner einfach neu starten.
Meine Empfehlung: Nicht klar ist, ob das Setzen des Flags die Einstellung nach einem Neustart bestehen bleibt. Daher mein Tipp, gleich das neue Update (KB3216755) hinterher herunterladen und installieren (ca. 1 GB). Nach erfolgreicher installation sollten Sie diese Version 1607 (Build 14393.726) installiert sehen.
Erstaunlich wie schnell die Anmeldung funktioniert.
Leider fehlt die Möglichkeit für die Verwendung von SSL also dem Aufruf für https://domain.tld statt http://domain.tld. Ein Aufruf für https://domain.tld ist zwar möglich aber es erfolgt kein Zwangs-Redirect auf eine SSL-Verbindung, also die Umleitung auf https://domain.tld.
Das Neuere ist nicht immer das bessere. Seit Ubuntu 18.04.1 wurde das Konzept /etc/network/interfaces durch /etc/netplan ersetzt. Leider mit Fehlern im Scripting, die bei einer Neuinstallation auftreten. So auch in meinem Falle, wollte ich doch nur schnell einen SAMBA Server installieren und die neuesten Patche herunterladen. Weit gefehlt, denn die Verbindung nach draußen klappte wegen eines DNS Problems nicht.
Im Verzeichnis /etc/netplan/ liegt die 50-cloud-init.yaml Datei. Sie dient dazu die Netzwerkumbgebung zu konfigurieren und kann folgend aussehen:
Note: a.) Bitte keine TABS verwenden, sondern nur Leerzeichen. b.) Nach jeder Änderung die Befehle „netplan generate && netplan apply“ durchführen. c.) Zuletzt den Dienst starten: „systemctl restart systemd-networkd.service„
Nach restart von netplan apply wurde der korrekt angegebene DNS Server in der /etc/resolv.conf 192.168.1.2 immer durch den 127.0.0.53 ersetzt. Eine Internetverbindung konnte somit nicht stattfinden, da die Namensauflösung nicht funktionierte.
Abhilfe konnte nur mit der /etc/systemd/resolved.conf geschaffen werden. Denn dort muss der DNS unter: [Resolve] DNS=192.168.0.2 #FallbackDNS= Domains=domain.local eingetragen werden.
Mit restart des Dienstes „systemctl restart systemd-resolved.service“ klappte dann auch endlich das Herunterladen der Patche/Updates.
Wer noch prüfen möchte ob die Namensauflösung korrekt funktioniert, kann den Status mit dem Befehl „systemd-resolve –status“ abrufen.
Normalerweise werden neue Zertifikate nur dann erstellt, wenn der Hostname geändert oder das Zertifikat versehentlich gelöscht wird. Unter gewissen Umständen müssen Sie den Host zwingen, neue Zertifikate zu erzeugen.
Um die Vorteile der Zertifikatsüberprüfung voll nutzen zu können, insbesondere, wenn Sie vorhaben, verschlüsselte Remoteverbindungen extern zu verwenden, verwenden Sie kein selbstsigniertes Zertifikat. Installieren Sie stattdessen neue Zertifikate, die von einer gültigen internen Zertifizierungsstelle (CA) signiert wurden, oder erwerben Sie ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle.
Melden Sie sich bei der ESXi Shell als Benutzer mit Administratorrechten an.
Sichern Sie im Verzeichnis /etc/vmware/ssl alle vorhandenen Zertifikate, indem Sie sie mit folgenden Befehlen umbenennen. mv rui.crt orig.rui.crt mv rui.key orig.rui.key
Führen Sie den Befehl /sbin/generate-certificates aus, um neue Zertifikate zu generieren.
Starten Sie den Host neu. Durch das Generieren werden die Zertifikate am korrekten Speicherort abgelegt. Alternativ können Sie den Host in den Wartungsmodus versetzen, das neue Zertifikat installieren und anschließend die Verwaltungs-Agenten über die Benutzerschnittstelle der direkten Konsole (Direct Console User Interface, DCUI) neu starten.
Bestätigen Sie, dass der Host neue Zertifikate erfolgreich erstellt hat, indem Sie den folgenden Befehl verwenden und die Zeitstempel der neuen Zertifikatsdateien mit orig.rui.crt und orig.rui.key vergleichen.
Wenn die OneNote-Anwendung dauerhaft abstürzt. Empfehlen wir, den OneNote-Cache-Ordner zu löschen und zu sehen, ob dies das Problem dann nach einem Neustart für Sie behoben ist:
1. Drücken Sie den Befehl + Umschalt + G (während der Finder geöffnet ist)> geben Sie ~/Library/Containers ein 2. Scrollen Sie zu com.microsoft.onenote.mac > Verschieben Sie den Ordner an einen anderen Ort, z. B. auf den Desktop. 3. Starten Sie dann den iMAC neu und versuchen Sie, die OneNote-Anwendung erneut zu starten. 4. Löschen Sie auf dem Desktop den verschobenen Ordner „Microsoft OneNote“.
Wenn die OneNote-Anwendung dauerhaft abstürzt. Empfehlen wir, den OneNote-Cache-Ordner zu löschen und zu sehen, ob dies das Problem dann nach einem Neustart für Sie behoben ist:
1. Drücken Sie den Befehl + Umschalt + G (während der Finder geöffnet ist)> geben Sie ~/Library/Containers ein 2. Scrollen Sie zu com.microsoft.onenote.mac > Verschieben Sie den Ordner an einen anderen Ort, z. B. auf den Desktop. 3. Starten Sie dann den iMAC neu und versuchen Sie, die OneNote-Anwendung erneut zu starten.
4. Löschen Sie auf dem Desktop den verschobenen Ordner „Microsoft OneNote“.
Normalerweise werden neue Zertifikate nur dann erstellt, wenn der Hostname geändert oder das Zertifikat versehentlich gelöscht wird. Unter gewissen Umständen müssen Sie den Host zwingen, neue Zertifikate zu erzeugen.
Um die Vorteile der Zertifikatsüberprüfung voll nutzen zu können, insbesondere, wenn Sie vorhaben, verschlüsselte Remoteverbindungen extern zu verwenden, verwenden Sie kein selbstsigniertes Zertifikat. Installieren Sie stattdessen neue Zertifikate, die von einer gültigen internen Zertifizierungsstelle (CA) signiert wurden, oder erwerben Sie ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle.
Melden Sie sich bei der ESXi Shell als Benutzer mit Administratorrechten an.
Sichern Sie im Verzeichnis /etc/vmware/ssl alle vorhandenen Zertifikate, indem Sie sie mit folgenden Befehlen umbenennen. mv rui.crt orig.rui.crt mv rui.key orig.rui.key
Führen Sie den Befehl /sbin/generate-certificates aus, um neue Zertifikate zu generieren.
Starten Sie den Host neu. Durch das Generieren werden die Zertifikate am korrekten Speicherort abgelegt. Alternativ können Sie den Host in den Wartungsmodus versetzen, das neue Zertifikat installieren und anschließend die Verwaltungs-Agenten über die Benutzerschnittstelle der direkten Konsole (Direct Console User Interface, DCUI) neu starten.
Bestätigen Sie, dass der Host neue Zertifikate erfolgreich erstellt hat, indem Sie den folgenden Befehl verwenden und die Zeitstempel der neuen Zertifikatsdateien mit orig.rui.crt und orig.rui.key vergleichen.
Das Neuere ist nicht immer das bessere. Seit Ubuntu 18.04.1 wurde das Konzept /etc/network/interfaces durch /etc/netplan ersetzt. Leider mit Fehlern im Scripting, die bei einer Neuinstallation auftreten. So auch in meinem Falle, wollte ich doch nur schnell einen SAMBA Server installieren und die neuesten Patche herunterladen. Weit gefehlt, denn die Verbindung nach draußen klappte wegen eines DNS Problems nicht.
Im Verzeichnis /etc/netplan/ liegt die 50-cloud-init.yaml Datei. Sie dient dazu die Netzwerkumbgebung zu konfigurieren und kann folgend aussehen:
Note: a.) Bitte keine TABS verwenden, sondern nur Leerzeichen. b.) Nach jeder Änderung die Befehle „netplan generate && netplan apply“ durchführen. c.) Zuletzt den Dienst starten: „systemctl restart systemd-networkd.service„
Nach restart von netplan apply wurde der korrekt angegebene DNS Server in der /etc/resolv.conf 192.168.1.2 immer durch den 127.0.0.53 ersetzt. Eine Internetverbindung konnte somit nicht stattfinden, da die Namensauflösung nicht funktionierte.
Abhilfe konnte nur mit der /etc/systemd/resolved.conf geschaffen werden. Denn dort muss der DNS unter: [Resolve] DNS=192.168.0.2 #FallbackDNS= Domains=domain.local eingetragen werden.
Mit restart des Dienstes „systemctl restart systemd-resolved.service“ klappte dann auch endlich das Herunterladen der Patche/Updates.
Wer noch prüfen möchte ob die Namensauflösung korrekt funktioniert, kann den Status mit dem Befehl „systemd-resolve –status“ abrufen.
