Beiträge von Knud

    Moin zusammen,


    da Google ja nun offiziell kein Vertrauen mehr in Symantec hat und sich das ab nächstem Jahr April ja auch auf uns auswirken wird, wollte ich mal fragen wie ihr damit umgeht.


    Hier erstmal noch ein Artikel, für diejenigen, die es noch nicht wussten: https://www.heise.de/security/…as-Vertrauen-3828578.html


    1. Haltet ihr LE für eine echte Alternative für die DV?
    2. Habt ihr Erfahrung mit OV? Habe schon mal bisschen geguckt, bisher war mir alles zu teuer. Gut & günstig wäre wie immer schön.
    3. Gibt es eine Übersicht welcher CA in welchen Browser "anerkannt" wird? Ich habe sowas nicht gefunden.
    4. Könnt ihr gute Alternativen empfehlen zu RapidSSL?


    Schönes Wochenende!

    Das hört sich gut an. :thumbup::) Ist auch angedacht für "kleine" Kunden, die z.B. nur einen vServer mit Domain haben, ein API zur Verfügung zu stellen?

    Als Usecase habe ich einen privaten kleinen DynDNS im Kopf.


    Gibt es schon eine grobe zeitliche Planung, wann das API verfügbar sein könnte?

    Kurze Offtopic-Anmerkung: dafür ist die Variante die Felix im nächsten Post vorschlägt, die deutlich bessere. DynDNS funktioniert nur gut mit einer kurzen TTL und die kannst du bei NetCup nicht setzen, sondern nur der Support und das kostet. So ist zumindest mein aktueller Stand.

    Wenn du eigene DNS-Server betreibst, kannst du auch selber die TTL nach belieben setzen.

    Könnt ihr einen anderen Hoster als Slave empfehlen? (z.B. einen der auch ein Power-DNS-Image fertig hat)

    Fände es aus Redundanz-Gründen sinnvoller, den Slaven woanders stehen zu haben. Vielleicht habt ihr da ja sowas wie eine Kooperation?

    Ich habe auch noch etwas, bin mir aber nicht sicher ob es Fehler sind:


    1. Das Passwort aus dem CCP wird beim Anlegen nicht automatisch für das Verwaltungspanel gesetzt.Sollte das daran liegen, dass es als Hash gespeichert und daher nicht ausgelesen werden kann, dann ist das auf jeden Fall richtig so und kein Fehler. Login über Auto-Login funktioniert problemfrei.


    2. Ein kleiner Fehler bei der Bestellung von Inklusivdomains. Dort steht "Bestellen Sie kostenpflichtig eine Domain oder übertragen Sie eine Domain von einem anderen Anbieter zu netcup. Alle hier bestellten Domains sind kostenpflichtig." Das ist so nicht ganz korrekt, dann hierüber werden auch Inklusivdomains bestellt, die nicht kostenpflichtig sind.


    3. Klicke ich auf PHP-Einstellungen kann ich als kleinste PHP-Version die Version 5.4.45 auswählen. Bei der Bestellung wird allerdings mit folgenden Version geworben: 5.3/5.4/5.5/5.6/7.0/7.1. Oder muss ich irgendwas beachten, wenn ich 5.3 einstellen möchte?

    Die Überprüfung ist hauptsächlich dazu da, um die Inhaberschaft der Domain sicherzustellen. Sonst könnte die jeder eintragen und nutzen, wodurch im schlimmsten Fall sofort Mails angefangen werden könnten, weil sich der gleiche Mailserver dafür zuständig fühlt.

    Verstehe ich nicht. ich muss doch selber festlegen wohin ich meine DNS-Einträge leite...


    Normalerweise sollte eine externe Subdomain problemlos funktionieren. Kannst Du einmal einen Screenshot der geforderten und getätigten DNS-Einstellungen zeigen?

    Okay, man muss es tatsächlich für die Subdomain explizit anlegen. Hatte es mit einer Testdomain probiert. Habe die subdomain hinzugefügt aber die Einträge nur für die TLD angepasst. Das erkennt diese Prüfroutine nicht. Es müssen also tatsächlich explizit für die geforderte Subdomain die passenden Einträge existieren. Damit geht es jetzt. Danke!

    Moin zusammen,


    kleines Problem, dass mir jetzt seit 2h Kopfzerbrechen bereitet.
    Ich habe bei Netcup einige Domains. Für diese Domains gibt es unter unterschiedlichen subdomains unterschiedliche Services (z.B. cloud, webmail, usw.).
    Bisher waren all diese Services auf meinem vServer gehostet. Klappt alles problemfrei.


    Ich möchte jetzt gerne zwei weitere Services anbieten. Diese sollen jeweils mit einem unterschiedlichen Webhosting-Vertrag umgesetzt werden. Nun kann ich die Domain ja aber immer nur einem Webhosting zuordnen. Eine einfach Cname Weiterleitung funktioniert wg. der vhost-Erkennung logischwerweise nicht. Die tolle Alias-Funktion die Plesk bietet, wo man frei seinen Alias eintragen kann, hat Netcup ja vorsichtshalber selbst bei den Expert-Tarifen deaktiviert (warum auch immer...).


    Mein jetziger Ansatz: in der Produktübersicht die Subdomain als externe Domain eintragen. Schluckt er erstmal auch so. Die Überprüfung der DNS-Einträge (warum auch immer die gemacht wird, geht Netcup doch nichts ein wie ich meine DNS-Records einstelle) schlägt allerdings fehl.


    Daher meine Frage an euch:
    Wie muss ich die DNS-Einträge einstellen, wenn ich eine Subdomain als externe Domain in einem Netcuphosting einstellen möchte? Die Hauptdomain soll dauerhaft und unverändert auf den vServer zeigen. Eine weitere Subdomain auf ein anderes Webhostingpaket.


    Ich befürchte irgendwie schon, dass ich hier an die Grenzen des (bei Netcup) Möglichen stoßen werde...


    Aber trotzdem würde ich mich über Lösungsansätze freuen.


    Danke schonmal!

    Schade, aber scheint Netcup nicht zu wollen.


    Ich habe die Failover jetzt einfach weggelassen. Der Server läuft wieder super, keinerlei Ausfälle mehr.
    Habe Testhalber die Failover auf einem Testserver eingerichtet (genauso wie auf dem Hauptserver über den wir hier reden). Hier funktioniert es ohne Probleme. Einziger Unterschied: das Gateway. Aber der Fehler liegt bestimmt bei mir ;)

    Das kann doch nicht euer ernst sein? Dann macht das Forum bitte zu wenn ihr nicht in der Lage seid hier den Support zu gewährleisten...

    Wäre praktisch, ich habe auch ewig gebastelt bis es funktioniert hat wie ich wollte.

    Schade, aber scheint Netcup nicht zu wollen.


    Ich habe die Failover jetzt einfach weggelassen. Der Server läuft wieder super, keinerlei Ausfälle mehr.
    Habe Testhalber die Failover auf einem Testserver eingerichtet (genauso wie auf dem Hauptserver über den wir hier reden). Hier funktioniert es ohne Probleme. Einziger Unterschied: das Gateway. Aber der Fehler liegt bestimmt bei mir ;)

    Nachdem wir noch einen Versuch unternommen haben mittels iptables alles über die Failoverip zu routen, was ebenfalls nur für wenige Stunden zum Erfolg geführt hat, habe ich jetzt einfach mal den Teil mit der Failover weggelassen.


    Oh Wunder!
    Es kommt zu keinerlei Ausfällen mehr.

    Als nächstes werde ich jetzt mal die Failover auf einem anderen Server einrichten und mal sehen ob es da zu den gleichen Problemen kommt.


    netcup: Wie sieht es denn mal mit einer Musterlösung für mein Problem/Anliegen aus? Ich denke ich bin nicht der einzige Kunder der ein Interesse daran hat die Failover als standardmäßige Ausgangs-IP zu nutzen.

    Das Problem kann beseitigt werden, wenn auf dem Server noch zusätzlich ein virtueller Server mit Hilfe z.B. von OpenVZ installiert wird und die zusätzliche IP-Adresse auf Diesem dann konfiguriert wird.

    Halte ich für ziemlich überdimensioniert für so eine Kleinigkeit...


    Wenn ich mich so umgucke im Internet sollte meine Lösung eigentlich funktionieren...


    Von der Theorie her könnte ich mir vorstellen, dass die Konfiguration bis auf die letzte Zeile (up ip route change default ...) richtig ist und auch dauerhaft ohne Probleme funktionieren sollte.


    Begründung:
    In der Letzten Anweisung (up ip route change default ...) wird dem System mitgeteilt, dass es die eigentlich schon vorhandene Gateway IP-Adresse 188.68.48.1 ersetzten soll. Dies könnte von daher auch das eigentliche Problem sein.

    Wie ist denn deiner Meinung nach die korrekte Einstellung um die Failover als ausgehende IP zu nutzen?


    Wie kommt es, dass das über ein halbes Jahr nicht zu Problemen geführt hat?

    Hier mein 'ip route show' des Live-Systems welches die Failover-IP gerade hat.

    Code
    default via 188.68.56.1 dev ens3  src 46.38.230.xxx  
    188.68.56.0/22 dev ens3  proto kernel  scope link  src 188.68.59.xx

    Ist bei mir exakt gleich. Aber in der letzten halben Stunde gab es auch keine Ausfälle. Sehr unregelmäßig das ganze. Ich melde mich wenn es zum nächsten Ausfall gekommen ist, dann kannst du ja vielleicht mal überprüfen ob es diesen Ausfall bei dir auch gab.

    Ich habe das gleiche nun auch nachgestellt (dieser Thread) bislang aber noch absolut keine Erreichbarkeitsprobleme feststellen können (Monitoring mit Icinga und Munin), bin aber ja nicht dirchgehend mit dem Server verbunden.


    Wenn ihr irgendwelche Tests mit meinem Server durchführen wollt -> PM


    Thomas

    Aus welchem Bereich stammt deine Failover? Auch 46.38.230.XXX ?
    Wäre weiterhin interessant ob du das gleiche Gateway nutzt.


    Wir nutzen zum Monitoring mtr. Test führen wir keine durch, da wir leider noch keine Idee haben wodurch sich das Problem provozieren lässt.

    Aber einerseits scheint er damit Probleme zu haben und andereseits möchte ich das auch nicht unbedingt.
    Ich würde ja meine Server gerne weiterhin über ihre eigentliche Adresse entelive.see.de (192.168.123.1) erreichen können - wobei das eventuell trotz der anderen Route geht und die Pakete trotzdem von 192.168.123.1 beantwortet werden, oder?
    Nur neue Verbindungen werden in dem Fall mit der definierten Route über die 192.168.123.3 aufgebaut, oder?

    Die Probleme habe ich, wie im Thread beschrieben, erst seit einigen Tagen. Ich habe nichts umgeändert vorher.
    Das einzige Problem ist, dass Netcup nicht bereit ist mal ernsthaft bei sich nach dem Fehler zu suchen, sondern mich als den Deppen darstellt...
    (Natürlich lässt es sich im Rettungssystem nicht reproduzieren, weil hier die interfaces-Datei abweicht)


    Du kannst mit meiner Lösung den Server über beide IP-Adressen erreichen und er antwortet auch mit der jeweiligen IP-Adresse.
    Standardmäßig nutzt er allerdings die Failover-IP als Ausgang. Das ist auch gut so, da wie du schon sagst, ansonsten die Prüfung der Reverse-DNS zu Problemen führt.
    Natürlich könntest du auch einen DNS-Eintrag auf mailserver1.domain.de setzen mit hoher Priorität auf die HauptIP. Dann halt entsprechend den Reverse-DNS für deine HauptIP anpassen. Genauso könntest du es dann mit den anderen Servern auch machen mit angepasste Priorität. Sollte ein Server aber mal für ein paar Sekunden nicht erreichbar sein, wird die E-Mail sofort an den Ersatzserver zugestellt. Du musst dann dafür sorgen, dass die perfekt synchronisiert werden.


    Ich möchte das daher nur ungern. Weiterhin muss ich die ausgehend IP für Teamspeak anpassen. Teamspeak funktioniert nur wenn man es fest auf eine IP bindet (hat Lizenzgründe). Wenn ich dafür nun die HauptIp nehme dann verliere ich alle Vorteile meiner Failover-IP, da ich nicht mal fix umziehen kann sondern immer auf die Aktualisierung der DNS-Einträge angewiesen bin. Fände ich unglücklich.

    Also!


    Entferne ich aus meiner obigen Config die letzte Zeile:

    Code
    up ip route change default via 188.68.48.1 src 46.38.230.XXX


    Treten keine Probleme mehr auf. Das Problem ist, dass ich nach außen zwingend die Failover-Ip haben muss (Teamspeak läuft sonst nicht,
    und die Mails landen auch bei allen im Spam-Ordner, weil die IP-Adressen nicht übereinstimmen).


    Code
    up ip route change default via 37.120.176.1 src 46.38.230.xxx        down ip route change default via 37.120.176.1


    Führt bei mir zum Totalausfall des Netzwerkes. Habe ich damals beim ersten Einrichten glaube ich auch schonmal versucht...
    Oder ist da einfach nur irgendwo ein kleiner Fehler?
    (Natürlich habe ich die IPs ersetzt ;-))


    "Internetverbindung hängt ca. alle 30 Minuten" ist in diesem Zusammenhang leider nur wenig hilfreich.

    Entschuldigung. Konstruktive Kritik wäre nett und einfach was besseres vorschlagen, dann passe ich das gerne an.

    Als erstes solltest du bei einem Ausfall ein mtr machen: MTR › Wiki › ubuntuusers.de


    Damit kannst du/wir dann sehen an welcher Stelle die Verbindung unterbrochen ist. Denn neben deinem Server und deinem PC kann auch jeder Server dazwischen die Störung verursachen.

    Danke für den Hinweis.
    Mtr laufen lassen auf Google. Als erstes kommt gw02.netcup.net (IP beginnt mit 188). Hier tritt auch der Paketloss auf, wenn es zum Ausfall kommt.
    Bei MTR von außen auf den Server ist der letzte Host vor dem Server gw01.netcup.net (IP beginnt mit 46). Hier kommt es ebenfalls zum Ausfall.
    Bei MTR von Netcup-Server mit anderer IP-Range ist der letzte Host vor dem Server gw01.netcup.net (IP beginnt mit 37). Hier kommt es auch zum Ausfall.
    Bei MTR von Netcup-Server mit gleicher IP-Range ist der letzte Host vor dem Server gw02.netcup.net (IP beignnt mit 188). Hier kommt es nie zu einem Paketloss.


    Wenn ich ein service networking restart durchführe ist der Server umgehend danach wieder verfügbar.
    Ich bekomme irgendwie das Gefühl es liegt an der FailOver...

    Hallo zusammen,


    ich habe ein Problem mit meinem vServer (Generation 6). Da ich den Fehler bisher nicht im Rettungssystem reproduzieren kann, kann der Support mir nicht weiterhelfen. Schade drum.


    Der Server ist ca. alle 30-45 Minuten (unregelmäßig) für einige Sekunden ab und an auch mal für ein paar Minuten aus dem Internet nicht erreichbar. Danach ist alles wie vorher.
    Intern ist er von anderen vServern aber problemfrei erreichbar. Der Server kann in diesem Zeitraum auch über die VNC-Konsole administriert werden, jedoch keine Verbindung nach außen aufbauen.


    Ich habe mir die Datei /var/log/messages schon angesehen. Hier ist nur eine regelmäßige FTP-Aktivität protokolliert, keinerlei Fehler. dmesg gibt ca. 5 Meldungen pro Tag über UDP-Paketen mit falscher Checksumme aus.


    Ich nutze eine Failover und die normale IP. Beide sind extern nicht erreichbar aber intern erreichbar.
    Meine Netzwerkconfig (funktioniert seit einem halben Jahr ohne Probleme):

    Code
    # This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5).source /etc/network/interfaces.d/*# The loopback network interfaceauto loiface lo inet loopback# The primary network interfaceauto eth0iface eth0 inet static	address 188.68.49.2XX	netmask 255.255.252.0	broadcast 188.68.51.255	gateway  188.68.48.1# 2nd network interfaceauto eth0:1iface eth0:1 inet static	address 46.38.230.XXX	netmask 255.255.255.255up ip route change default via 188.68.48.1 src 46.38.230.XXX


    Ich habe in den letzten Wochen updates eingespielt, ansonsten keinerlei Veränderungen vorgenommen. Probleme treten seit ca. 4-5 Tagen auf.
    Ca. 1 Woche vor Auftreten habe ich mich gar nicht eingeloggt, weil ich viel arbeiten war. Deswegen kommt mir das alles sehr komisch vor.


    Hat jemand von euch Ideen woran das liegen könnte?


    Vielen Dank schonmal!