Posts by H6G

    MTU Probleme im Netcup-internen Netz? Halte ich für sehr unwahrscheinlich.

    Im ICMPv6 sind einige Message-Types freigeschaltet. Vorher gab es in die Richtung ja eher keine Probleme.

    Nanü? Beide Endpunkte zeigen auch von meinem Internetanschluss einzelne Pakete mit hoher Antwortzeit.

    Ein Neustart der Beiden hat es jetzt gerichtet - obwohl beide erst seit 30 Tagen laufen.

    (die zwei anderen waren wohl statistische Ausreißer dazu...)


    Kernel 4.14.20

    Ist ja nicht nur auf IPv6 beschränkt.

    Nur ICMPv6 ist gerade am Auffälligstem. Aktuell pegelt er sich im LAN bei 200 ~ 30 ms ein.

    Meine Firewall ist für ICMP-Traceroutes zu den ldap Kisten zu restriktiv.


    Sporadisch gehen ja Pakete verloren.

    Mach uns ein paar Traceroute6, bitte. UDP oder ICMP oder TCP, egal...

    Code
    1. traceroute to ldap.h6g-server.net (2a03:4000:2:62b::1), 30 hops max, 80 byte packets
    2. 1 gw01.netcup.net (2a03:4000:6:d000::2) 0.937 ms 0.863 ms 0.881 ms
    3. 2 ldap.h6g-server.net (2a03:4000:2:62b::1) 3.321 ms 3.420 ms *
    4. traceroute to ldap2.h6g-server.net (2a03:4000:9:391::1), 30 hops max, 80 byte packets
    5. 1 gw01.netcup.net (2a03:4000:6:d000::2) 0.617 ms 0.685 ms 0.656 ms
    6. 2 * ldap2.h6g-server.net (2a03:4000:9:391::1) 0.498 ms 0.596 ms

    mein Monitoring spielt gerade Verrückt. Ports 636 und 587/25. Oder ein Problem mit TLS.

    Apt-Log von Mittwoch

    Code
    1. Start-Date: 2018-04-03 10:49:37
    2. Commandline: apt-get upgrade
    3. Requested-By: pzillmann (1000)
    4. Upgrade: openssl:amd64 (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2), libsystemd0:amd64 (232-25+deb9u2, 232-25+deb9u3), libicu57:amd64 (57.1-6+deb9u1, 57.1-6+deb9u2), udev:amd64 (232-25+deb9u2, 232-25+deb9u3), libudev1:amd64 (232-25+deb9u2, 232-25+deb9u3), systemd-sysv:amd64 (232-25+deb9u2, 232-25+deb9u3), libpam-systemd:amd64 (232-25+deb9u2, 232-25+deb9u3), systemd:amd64 (232-25+deb9u2, 232-25+deb9u3), libssl1.1:amd64 (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2), libssl1.0.2:amd64 (1.0.2l-2+deb9u2, 1.0.2l-2+deb9u3), tzdata:amd64 (2018c-0+deb9u1, 2018d-0+deb9u1)
    5. End-Date: 2018-04-03 10:50:30

    Am Abend darauf fingen die Probleme an. Aktuell wieder ICMPv6 Probleme zu zwei Hosts.

    Hat jemand gerade ähnliche Probleme? Ist kein Root-Server

    Code
    1. ts3 A 185.230.162.247
    2. _ts3._udp SRV 0 5 9987 ts3.flamespeak.de

    ---oder---

    Code
    1. @ A 185.230.162.247
    2. _ts3._udp SRV 0 5 9987 flamespeak.de

    wenn du _ts3._udp.ts3 SRV 0 5 9987 flamespeak.de nimmst, dann ist ein Teamspeak unter ts3.flamespeak.de erreichbar.

    Dementsprechend musst du das letzte .ts3 weglassen.


    Dennoch brauchst du mindestens einen A Record in der Kette. D.h. du musst für flamespeak.de oder eine Subdumain (z.B. ts.flamespeak.de) einen solchen A Record erstellen. Prinzipell reicht das auch schon do. Das i-Tüpfelchen sind dann noch die SRV Records.


    In deinem Fall für flamespeak.de dann _ts3._udp SRV 0 5 HIER-TS-PORT-EINTRAGEN flamespeak.de

    https://www.netcup-wiki.de/wiki/Domains_CCP#DNS


    Ansonsten auch von mir die Bitte: ganze und verständliche Sätze zu schreiben.

    Da die Domain bei Netcup registriert ist, müsstest du in die Netcup DNS-Einstellungen gehen.

    Dort erstellst du einen A Record, dieser zeigt auf die IPv4 Serveradresse (Name: @, Ziel: Serveradresse)

    Wenn dein Server auch IPv6 unterstützt, kannst du zusätzlich einen AAAA Record erstellen


    ---oder---


    Du erstellst dir einen SRV Record, der wiederum auf eine Subdomain zeigt. (siehe Anhang)

    Das ist z.B. gut, wenn du einen schlecht zu merkenden Port hast. Standard ist 9987


    Screenshot at 2018-03-26 21:43:45.png

    Du könntest dich natürlich auch an die Techies von Facebook wenden, vielleicht geht da dann etwas :)

    Kein Plan an wen ich mich da wenden müsste. Bin selber nicht bei Facebook vertreten. Gab nur die letzten drei Tage Probleme Medien bei Whatsapp zu senden und empfangen (Bilder, Sprachnachrichten) über das Vodafone Kabel Netz. Text ging problemlos.


    Websiten die Instagram einbinden haben sich an der Instagram-Integration durch die lange Ladezeit sehr aufgehängt.

    Naja in der Hotline bei den großen Providern, egal ob Telekom, Vodafone, oder Reseller ohne eigenes Netz, wie 1u1 (wtf, warum ist der Telekom Parasit zensiert? SEO relevanter Traffic?), ... hast in der Regel irgendwelches Aushilfspersonal sitzen, ... spätestens ab 21 Uhr übernehmen dann trainierte Affen, ... Ausnahmen bestätigen natürlich die Regel.


    Da Lob ich mir den Support von Netcup oder auch Hosteurope, ... bei letzterem auch schon mal um 4 Uhr morgens unter der Woche kompetente Hilfe bekommen!

    Zumindestend kann ich mich bei der Telekomhotline sehr frei bewegen und auch ganz einfach andere Mitarbeiter bei dem Gespräch erzwingen.

    Ja, die Netcup Mitarbeiter haben ausgeprägte Langeweile, was auch zu kreativen Uhrzeiten führt.


    1+1 hat bei mir schon beim Beratungsgespräch beim Einzug versagt. Ich wollte über deren Produkte beraten werden, in der entsprechenden Neukundenhotline meldet man sich mit: "Was darf ich Ihnen verkaufen?"


    Aber alles noch vertretbar im Gegensatz zu kaputter DTMF-Erkennung.

    Ich bin gerade daran gescheitert, der Vodafone Hotline mitzuteilen, dass die Peering-Probleme zum Facebook-AS haben.

    Der erste zu FB gehörende Rechner auf der Route (in Frankfurt) hat bereits einen Paketverlust von 3 bis 10%


    Bei Allestörungen.de sind dieses Problem auch massiv zu erkennen. Nur ist da nicht ersichtlich, welches Netz die verwenden.


    Die Hotline ist aber nicht in der Lage solche Probleme zu bearbeiten, da geht irgendwie nur: Leitung zum Kunden und Problem beim Kunden vor Ort.

    L2-Support war nicht verfügbar.


    Zwischenzeitlich sollte ich mein Problem schriftlich darlegen. Da habe ich nach einer Mailadresse gefragt, der Mitarbeiter meinte ich solle einen Brief schicken.

    Prinzipiell braucht SystemD bei Prozessen keine PID-Überwachung. Er merkt sich die PID vom zum startenden Prozess. Wenn kein ExecStop angegeben ist, schickt er einfach ein SIGINT an den gemerkten Prozess.


    In dem File nutzt er jetzt die PID um den Prozess über kill abzuschießen. Einige Prozesse brauchen das so, weil sie nur auf bestimmte Signale reagieren oder anderweitig abgeschaltet werden möchten. Von Prozess zu Prozess unterschiedlich. Bei dir müsste es funktionieren, wenn du ExecStop und PIDFile auskommentierst.


    SystemD schreibt das PIDFile aber nicht, das muss schon Redis machen (über die Redis-Config - deswegen findet er es auch nicht und meckert)


    https://www.freedesktop.org/so…emd.service.html#PIDFile=

    (zzgl. Type und GuessMainPID)

    Was ist denn aktuell noch installiert?

    Apache? NGiNX? MySQL, ....?


    Kenne die fertigen Images von netcup nicht.

    Froxlor kommt schon mit den nötigen Sachen daher (Webserver, Datenbankserver)

    Wenn du unter Froxlor bist, kannst du dir dort einfach einen Nutzer anlegen, mit Webspace, Datenbank und Domain.

    Bei Netcup musst du für deine Domain noch auf den Server zeigen lassen (Fachchinesisch: DNS).


    Mit einem einfachen Wordpress ohne administrative Kenntnisse und Aufwand bist du allerdings mit einem Webhosting Tarif bei Netcup besser beraten.

    Als blutiger Anfänger wirst du mit ohne Fachchinesisch da nicht weit kommen.

    Unter Debian ist der Standardpfad /usr/local/bin ... bei Ubuntu sollte es z.B. in /usr/bin liegen. Keine Ahnung, wie apt und Co das regeln 😊



    Das entscheidet der Paketverwalter und nicht "apt & co" wo welche Datei am Ende landet.

    Generell sagt man: alles was selbst kompiliert wird, landet unter /usr/local

    Wenn du da ein anderes Verzeichnis haben möchtest, musst du vor dem Kompilieren dem ./configure Skript einen Parameter auf den Weg geben, der den Prefix ändert (z.B. /usr oder / statt /usr/local)


    Pakete die du über die System-Repos beziehst sind so gepräfixt, dass sie in /usr landen. Wichtige Systemsoftware wird in / (also leztenendes in /bin) landen.


    Wenn du dir mit den Präfixen unsicher bist, hilft auch die Ausgabe von ./configure --help vor dem Kompilieren.


    Zum anderen Thema: SystemD hat ja die SysV Init Skripte und damit auch den start-stop-daemon abgelöst. Beide erfüllen die gleiche Aufgabe: Prozessduplizierung und Prozessüberlagerung im Hintergrund unter definiertem Arbeitsverzeichnis und definierten Nutzern. Bitte nur entweder oder nutzen, und nicht das eine Nutzen um das andere zu nutzen.


    Es wäre ungefähr so als würdest du MySQL installieren und dir ein Skript unter /etc/init.d/mysqld erstellen mit dem Inhalt: wenn /etc/init.d/mysqld start, dann führe aus: systemctl start mysqld


    Macht wenig Sinn.

    In SystemD gibt es dafür die Direktiven "RuntimeDirectory" und "RuntimeDirectoryMode" die dir den entsprechenden Ordner unter /var/run und /run anlegen.

    Siehe auch:

    https://www.freedesktop.org/so…ec.html#RuntimeDirectory=

    http://man7.org/linux/man-pages/man5/systemd.exec.5.html

    bzw. das SystemD Definition File von mightyBroccoli  https://forum.netcup.de/admini…internal-error/#post92117


    /var/run ist ein tmpfs deren Inhalt nach einem Reboot gelöscht wird.


    Edit:

    SystemD zu Nutzen um den Start-Stop-Daemon zu nutzen: gruselig. Entweder SystemD oder SysV, ersetze bitte den Aufruf des Start Stop Daemons durch die Redis-Binary direkt.


    So sähe ein gutes SystemD Skript aus (einfach durch die Redis-Sachen ergänzen)


    Hallo Zusammen,


    habe das hier auch schon mehrfach gelesen und bei mir tritt es sporadisch auch auf: 30 Minuten nach einem Neustart verlieren die Server IPv6 Konnektivität.

    Ich bin dem ganzen jetzt ein wenig auf dem Grund gegangen.


    Bevor es auftritt ergibt ip -6 route show

    Code
    1. 2a03:4000:1c:df::/64 dev ens3 proto kernel metric 256 pref medium
    2. fe80::/64 dev ens3 proto kernel metric 256 pref medium
    3. default via fe80::120e:7e00:8326:f1c0 dev ens3 proto ra metric 1024 expires 1709sec hoplimit 64 pref medium
    4. default via fe80::222:8300:83da:6fc0 dev ens3 proto ra metric 1024 expires 1709sec hoplimit 64 pref medium
    5. default via fe80::1 dev ens3 proto ra metric 1024 expires 1709sec hoplimit 64 pref medium


    Vom Router Announcement gibt es also Gateways, gültig für 1700 Sekunden (ca. 29 Minuten).

    Vorher meckert aber SystemD, dass mit dem Interface etwas nicht stimmt.


    Nachdem dann das Interface manuell geflusht wurde und neu hochgeholt wurde, sieht alles wieder perfekt aus.


    Code
    1. 2a03:4000:1c:df::/64 dev ens3 proto kernel metric 256 pref medium
    2. fe80::/64 dev ens3 proto kernel metric 256 pref medium
    3. default via fe80::1 dev ens3 metric 1024 pref medium


    Ein paar Fragen:

    - Gibt es eine bessere Möglichkeit als jedes mal manuell einzugreifen?

    - Ist das Schuld von Debian 9, einer Fehlkonfiguration, oder sollte das RA anders aussehen?

    Offenbar hat es so nicht geklappt. Mein Befehl zum Löschen aller Dateien, die älter als 2 Tage sind, sieht jetzt so aus:

    Code
    1. find /var/www/web123/html/ordner001/ordner01/* -mtime +2 -type f -delete

    Sollte doch korrekt so sein. Oder habe ich da einen Fehler drin?


    Das * ist zu viel.

    Code
    1. user@machine:~$ find git/mongo-c-driver-1.9.3/ -type f | wc -l
    2. 4005
    3. user@machine:~$ find git/mongo-c-driver-1.9.3/* -type f | wc -l
    4. 3972

    Damit sagst du ihm er soll alle Unterordner unterhalb von ordner01 durchsuchen - ordner01 bleibt daher unangetastet.


    Code
    1. find /var/www/web123/html/ordner001/ordner01/ -mtime +2 -type f -delete


    wc -l (word count, Parameter lines) zählt wie viele Dateien von find zurückgeliefert werden. Du siehst oben beim Sternchen einen Unterschied von ca. 100 Dateien gegenüber ohne Sternchen.


    Edit: wenn web123 der Ordner ist, den du über Renés oder meiner Maßnahme ermittelt hast. Ich glaube aber nicht, dass du ausgerechnet auf der 123 liegst.

    Ist es eigentlich beabsichtigt, dass der Datenverkehr zu Hurricane Electric über Wien statt über Frankfurt geleitet wird?

    Netcup gehört ja jetzt zu Anexia bzw. die sind verpartnert. Wenn die sich eine Leitung gelegt haben mit 10G dann könnte das durchaus Sinn machen, wenn HE eine größere Peeringkapazität in Wien hat als FFM.


    Netcup plant ja auch die RZ Flächen in Wien zu nutzen.