Wir haben im Laufe des Vormittags einige Optimierungen beim IPv6 Routing vorgenommen. Wir bitten darum das Phänomen in nächster Zeit noch zu untersuchen und bei weiteren Problemen ein Support Ticket zu erstellen (am Besten mit Bezug auf dieses Thema).
Vielen Dank für die ausführliche Beschreibung des Phänomens.
Wie gesagt, die Route war nicht das Problem bei dem Debian, bei mir sind immer die V6 Adressen verschwunden.
Wenn das Problem wieder auftritt, werde ich gerne berichten.
Verschwundene IPv6 Adressen liegen teilweise an konfiguriertem DHCP für die v4 Adressen. Ist die v4 und v6 Konfiguration statisch?
Vielen Dank für den Bugreport!
Der Fehler ist bereits behoben und wird beim nächsten Release korrigiert.
sind die RS 1000 SAS G7SE 15 years auch auf den betroffenen Nodes ?
Den Fehler hab ich dort auch festgestellt (BS ist in dem Fall CentOS 7)
Gruesse,
Dieser war auch betroffen.
Wäre denn postgrey für Netcup einen genaueren Blick wert?
Wir haben mit postgrey die Erfahrung gemacht, dass dies aktuell kaum noch etwas hilft. Es verschlimmert u.a. die Kommunikation mit office365 Accounts, da diese immer über andere Mailserver versenden.
Wir haben inzwischen auf dem WCP und dem Sogo einige Optimierungen an der Spam Erkennung vorgenommen und bitten um Feedback ob sich das Spamaufkommen verringert hat.
Hallo zusammen,
vielen Dank für die letzten Anregungen! Wir konnten schon einiges umsetzen. So gibt es nun unter anderem folgenden neuen Features:
Der Fehler der VNC Console ist in der neusten Version (6.4.4) behoben. Alle die noch auf einer ältern Version online sind müssen sich bitte einem via Logout abmelden und erneut anmelden.
Ich würde die Mountoption überall entfernen, diese kann mehr Schaden anrichten als ursprünglich gedacht. Die fstrim Befehle sollten aber dennoch nicht alle zur gleichen Zeit laufen 
Nutztest du discard als Mountoption oder via einem batched discard mittels fstrim?
Ich habe letztens einen interessanten Artikel gelesen, dass man discard als Mountoption nicht mehr verwenden soll sondern ausschließlich den batched discard. Eine Ausführung einmal pro Tag reicht hier locker aus.
Moin,
mir ist folgender fehler aufgefallen:
wenn man das SCP mit folgender Adresse aufruft: https://servercontrolpanel.de/ oder SCP | Login (https:// servercontrolpanel.de/SCP/Home) (hier extra ein Leerzeichen da es sonst automatisch mit SCP | Login ausgetauscht wird) kommt folgendes:
Das www. kann man normalerweise weglassen, aber hier führt es zu einem Problem.
Danke für den Hinweis. Es ist nun ein funktionierender Redirect eingebaut.
Heute, als ich mir mein "Failover IPv6-Subnet" auf meinem Root-Server "RS 6000 ... SE" routen wollte, stieg das neue Servercontrolpanel aus. Nach erneutem Einloggen in das neue Servercontrolpanel sah ich zwar, dass das "Failover Ipv6-Subnet" nun auf dem Server wie gewünscht zeigte, aber die IP-Pakete wurden nicht bis zum Server geroutet. Erst als ich im alten Servercontrolpanel es wiederholt hatte, wurden die IP-Pakete wie gewünscht zum Server geroutet.
Da ich gestern schon mit dem neuen Servercontrolpanel ein anderes Problem hatte, was aber dann mit Hilfe eines Supportmitarbeiters telefonisch gelöst werden konnte und mir der Supportmitarbeiter so nebenbei auf Nachfrage auch mitteilte, dass man das alte System spätestens eine Woche später abgeschaltet haben möchte und wird, würde ich eher aus Kundensicht vorschlagen, diese beiden Systeme - neu und alt - solange dieses neue System noch nicht wirklich ausgereift ist, noch parallel laufen zu lassen, damit wir Kunden im Extremfall bei Problemen uns noch über das alte System weiterbehelfen können. Denn ich könnte mir auch gut vorstellen, das gerade außerhalb der normalen Supportzeiten es für viele Kunden sehr unangenehm werden kann, wenn sich das neue System nicht wie erwartet verhält und auf das alte System auch nicht mehr zurückgegriffen werden kann.
Vielen Dank für die Meldung. Der Fehler sollte nun behoben sein, wenn nicht bitte eine Email an den Support mit dem betroffenen Server und dem Zeitpunkt inklusive Verweis auf diesen Thread.
Leider reagiert die Konsole / der Monitor nicht wenn ich das neue SCP verwende. Über die "alte" Schnittstelle geht es noch.
Ich werde regelmäßig "disconnected" und die Konsole reagiert nicht auf Eingaben.
Nach einem Logout/Login funktioniert diese wieder. Der Fehler ist ab Version 6.0.4. behoben (steht im Footer).
Es wurde soeben eine neue Version eingespielt. Nach einer erneuten Authentifizierung ist der Session Fehler behoben und auch der Fehler bezüglich den Leerzeichen in den Snapshotnamen wurde korrigiert.
Alles anzeigen
Hallo Christian,
vielen Dank fürs Recherchieren. Wir spielen morgen früh dafür einen Patch ein. Dann gilt eine Session sowohl über eine IPv4- und eine IPv6-Adresse. In der Betaphase war dieser Umstand leider nicht aufgefallen.
Viele Grüße
Felix
Kurzes Update: Der Patch verschiebt sich nochmals.
Aktuell kommt es bei FreeBSD Installationen vereinzelt zu zu kleinen Festplatten. Wir sind dabei den Fehler zu untersuchen. Sollte die Festplatte nur 8GB anzeigen bitte ein Ticket beim Support eröffnen.
Laut der Ausgabe der Kernelnummern handelt es sich hier um ein Produkt welches auf Linux VServer basiert. Die Stabilität der Produkte auf Basis LInux VServer sind leider nicht so stabil wie wir unsere Produkte verkaufen wollen. Aus diesem Grund haben wir auch vor Jahren angefangen nur noch Root-Server auf KVM Basis zu verkaufen. Ich kann Ihnen aktuell nur empfehlen auf ein aktuelleres Produkt zu wechseln, hier ist die Stabilität deutlich besser.
Das kommt im Endeffekt immer auf den genauen Einsatzzweck an.
Bei der vorgeschlagenen Konfiguration steht ja auch nur "sollte". Bei einer Domain die rein auf dem Server liegt trifft das auch zu, aber bei einer geteilten Domain (verschiedene Subdomains zeigen auf unterschiedliche Server) empfiehlt es sich mydomain hier auf den gleichen Wert wie myhostname zu setzen. Außerdem wird postfix inzwischen hauptsächlich mit vielen Domains betrieben und die eigentlichen Emaildomains werden als virtual domain gepflegt.
Im Debian Jessie Image setzen wir bereits auf dovecot. Im Debian Jessie Image selbst ist auch der chmod für die dovecot.conf Workaround bereits integriert.
Ändert sich daran etwas, wenn die IPv4 Konfiguration ebenfalls statisch und nicht per DHCP aufgebaut ist?
Wir haben vereinzelt Meldungen, dass wir in dem angegeben Zeitraum Erreichbarkeitsprobleme aus Teilen des Netzes der Liberty Global / Unity Media hatten. Wurde zufällig ein Traceroute / MTR zum angegeben Zeitpunkt durchgeführt?
Guten Tag,
vielen Dank für die Anregung. Wir sind hier allerdings auf den Hersteller der Software angewiesen. Aktuell haben wir noch keine Rückmeldung, wann hier eine neue Version zur Verfügung steht.
