Beiträge von TBT

    Hallo zusammen,

    was man hier nicht vergessen darf: Hier werden von zehntausenden Bestandskunden mal eben 18 % mehr verlangt. In meinem Fall sind das knapp 7 EUR mehr pro Monat – also 84 EUR im Jahr. Und das summiert sich bei der Masse an Kunden enorm.

    Ich habe in meinem langen Post schon dargelegt, wieso das meiner Vermutung nach so gemacht wurde: sonst hätte NC die Preise um 200-300% für Neukunden anheben müssen, bzw. das Neukundengeschäft komplett einstellen. Denn so drastisch sind die Preisanstiege bei RAM, SSDs, etc. Ist wie bei einer Krankenversicherung...

    Haufen statische Apache2 webseiten, zwei postfix mailserver, einen openstreetmap tile server, 2 mastodon social instanzen und 3 Railsanwendungen.

    Alles Genannte sollte gehen (genug Ressourcen vorausgesetzt) - bis auf zwei parallele Mailserver. Du solltest für alles webbasierte einen Reverse Proxy (Nginx, NginxProxyManager als Docker) davor setzen und den SSL (Let's Encrypt) und das Routing innerhalb des Servers erledigen lassen.

    Zwei Mailserver gehen nicht, da die verwendeten Protokolle Standard Ports haben, die man nicht umlegen kann. Zudem kannst Du nur eine Zuordnung der reversen Auflösung IP -> DNS Namen machen (außer Du hättest 2 IPs).

    Ich bin da einfach ein kleiner Ordnungs Fanatiker, getrennte Server lassen mich nachts besser schlafen ^^

    Ich kann es einfach nicht ab wenn 2 TS aufm gleichen Server laufen

    Nee, was ich meine: Ob Teamspeak 3 oder 6 ist ja nur eine Client Sache. Der Server ist für beide die aktuelle Version 3.13.7.

    Ich nutze mit meinem Server z.B. TS6 >Client<, während andere Nutzer noch den TS3 Client nutzen.

    Meiner Meinung nach ist das unprofessionell von netcup. Bestandskunden sollten ihre vereinbarten Preise behalten, und neue Kunden zahlen eben den höheren Preis.

    Wie in meinem Post darüber ausgeführt: das wären 200-300% höhere Preise für Neukunden, wenn es nicht so gemacht wird, wie es gemacht wird. D.h. de facto sofortige Einstellung des Neukundengeschäfts für die nächsten 2 Jahre (so lange wirds dauern).

    Will der GF nicht machen, ist m.E. sinnvoll.

    I cannot accept this, but have the need to keep my servers. Come to a better agreement, and revise these, resend a better change, lower one, and I will readily agree to it. I am sure so many others here are requesting the same.

    You already raised 0.50 by segregating IPV4, which I was still okay with, but this is corporate blah. Not appropriate, not earning goodwill at all.

    Dude. Like so many others in this thread: deal with it or leave. And especially: grow up! There won't be another offer. This is it. Either you can't accept it (then leave and try to find a better deal elsewhere - which hard if not impossible) or keep your servers (and pay). Not Netcup's problem if you have to pay additional charges if you are based in another country. Go and find a provider in that country (or another) without surcharges.

    Non-hardware based prices (IP adresses, domains, etc) have not been raised.

    Im Jahr sinds bei mir auch über 200€ mehr ... teures Hobby halt. Darum werd ich die nächsten Wochen auch reduzieren. Paar Migrationen schneller beenden und Services wieder zusammenführen, die ich aus Gründen der Risiko-Minimierung gerade getrennt habe.

    Dann gehörst Du aber auch zu denen, die (wie in meinem Post erwähnt) deutlich höhere Kosten ohnehin jährlich haben. Wenn Dich die 18% Preiserhöhung 200€ mehr kostet, zahlst du bisher aber auch schon 1.000€ oder mehr im Jahr.

    Wie im Post erwähnt, machen die "1stelligen Poster" auch gleich munter mit ganz tollen Vorschlägen weiter. :D:thumbup:

    Großer Server:
    Dockhand (m.E. besser als Portainer, da es mit vorhandenen Ordnerstrukturen und compose Files sehr gut zurecht kommt)
    n8n (Automatisierungsworkflow Anwendung)
    Nginx-Proxy-Manager (Reverse Proxy)
    obsidian-livesync (Live Sync für Obsidian)
    restreamer
    syncthing (Sync zwischen Servern, Desktop, Laptop, mobilen Endgeräten)
    teamspeak Server (eigenes Dockerfile / Docker compose)
    wud (whats up Docker, automatisches Updatetool für Docker Container, könnte Dockhand auch, wud ist jedoch problemfreier)

    Kleiner Server:
    Dockhand
    Nginx-Proxy-Manager (Reverse Proxy)
    syncthing
    wud (whats up Docker)
    ztnet (Zerotier Controller, m.E. der beste selbstgehostete Controller für Zerotier)

    Zudem läuft nicht in Docker auf allen Servern Tailscale, Zugriff auf die Server eigentlich nur darüber.

    Aktivierte Netcup Firewall, SSH Port und die meisten Verwaltungs-Webinterfaces der o.g. Programme (z.B. Syncthing, wud, sind nach außen hin dicht). Ich lege für jede Anwendung zentral ein Set von Firewalleinstellungen an und aktiviere diese dann bei den Servern nur mehr, indem ich diesen einen Eintrag nach rechts schiebe.

    TeamSpeak 3

    TeamSpeak 6

    Ich betreibe ja auch TS auf meinem Server, schon seit 15 Jahren ohne Unterbrechung. TS3 und TS6 laufen ja mit dem gleichen Server. Habt Ihr da wirklich unterschiedliche Server am Laufen?

    Noch ein Bonuspunkt Docker manipuliert iptables eigenständig und aggressiv, komplett an ufw/firewalld vorbei. Ports, die man eigentlich geblockt haben wollte, waren plötzlich von außen erreichbar. Skill issue? Vielleicht aber ein Sicherheitstool, das stillschweigend deine Firewall-Regeln umgeht, hat schlicht ein Design-Problem.

    Hm. Ports, die man nicht erreichbar haben will, sollte man schlicht gar nicht aus dem Docker Compose network (jeder Stack hat da normalerweise sein eigenes) herauslegen? Wenn man die Ports im Compose File nicht explizit (ports: 80:80) nach außen legt, ist in einem Stack auch erst mal nichts offen. So ist es z.B. unnötig, bei einer Anwendung die eine eigene DB mitbringt, auch nur irgendeinen Port der DB nach außen zu legen. Die Anwendung kann im eigenen Docker Netzwerk drauf zugreifen und mehr muss nicht sein. Oder bei einer Anwendung, die durch einen Reverse Proxy soll, einen Webinterface Port rauszulegen. Ich habe viele Stacks, die gar keine Ports rauslegen. Die die rausgelegt sind, müssen auch.

    Insofern verstehe ich das Problem nicht ganz. Davon abgesehen nutze ich mittlerweile die Netcup Firewall statt der ufw.

    Leute. Dieser Thread ist schon "schwierig" zu lesen.

    Da gibts:

    - verdächtig viele Gast-user und User mit ein bis zweistelligen Postcounts, die hier nur rummotzen und Netcup so furchtbar finden. Man könnte hier auch den Versuch der Einflußnahme von Konkurrrenten vermuten, wenn man einen Aluhut aufhätte.

    - User, die behaupten die Preiserhöhung würde 200 bis 600€ mehr kosten - offensichtlich haben diese User aber dann ja auch Server die einen fünfstelligen Betrag kosten müssen. Das sind dann keine Privatnutzer mehr, sondern mit diesen Servern wird klar Geld verdient. Muss man die eigene Kalkulation halt anpassen. Wenn das nur teilweise geht, wird man halt weniger verdienen oder draufzahlen - und hoffentlich beim nächsten Mal smartere Verträge mit den Endkunden machen. Diese User wären nicht die einzigen, die in der aktuellen Situation draufzahlen, das machen gerade alle (inklusive Netcup).

    - Möchtegernexpertinnen und -experten, die besser als der Geschäftsführer wissen, wie ein Serverhoster zu führen ist und wie man Sachen bepreisen muss. :rolleyes:

    - Leute die meinen Netcup wäre die Caritas, nur dazu da um ums zum Selbstkostenpreis günstige Server anzubieten und müsse sich für Preiserhöhungen entschuldigen. Netcup ist eine Firma, Firmen müssen und werden so handeln, dass sie zum einen nicht drauf gehen und zum anderen noch genug übrig bleibt, um den Mitarbeitenden die Gehälter zu bezahlen. Dabei muss jede Firma im Spannungsverhältnis zwischen Preis und Leistung ihre Positionierung finden. Netcup ist klar einer der günstigeren Hoster. Daraus ist jedoch kein gottgegebenes Recht auf permanent günstige Preise abzuleiten.

    - Leute die offensichtlich NULL aber auch schon GAR KEINE Ahnung haben, welches Drama sich gerade auf den Hardwaremärkten abspielt. Nein, SSDs sind nicht "geringfügig im Preis angezogen oder gleich geblieben", deren Preise haben sich VERDOPPELT oder VERDREIFACHT. Und beim Ram kann man noch ein paar Faktoren drauflegen.

    - Leute die meinen, dass "vorhandene Server" quasi zum Nulltarif weiterlaufen. Tun sie nicht. Wenn eine defekte SSD zum 3x Preis des vorhandenen Teils ausgetauscht werden muss, zerstört diese eine SSD die Kalkulation dieses Servers. Ich bin mir sicher, dass die Kosten hierfür anteilig in eine komplexe Kalkulationstabelle mit vielen anderen Punkten eingeflossen ist.

    Zu den Gegenüberstellungen zwischen Bestandskunden- und Neukundenerhöhungen: Euch ist schon klar, dass diese beiden Pools DEUTLICH unterschiedlich groß sind? Sagen wir mal der Bestandskundenpool liegt bei 100.000 Kunden (keine Ahnung), dagegen ist der z.B. im nächsten Jahr zu erwartende Neukundenpool deutlich kleiner (vielleicht 1.000-3.000). Wenn der größere Pool nicht herangezogen würde, um diese um mehrere Faktoren gestiegenen Kosten für Neukunden abzufedern, würden die Preissteigerungen für Neukunden nicht bei 25%, sondern bei 200-300% liegen, was im Endeffekt einer sofortigen Einstellung des Neukundengeschäfts gleichkäme. Und das möchte der GF und Netcup nicht (finde ich sinnvoll).

    Für alle, die mit den Kostensteigerungen nicht klarkommen, wurde ein Sonderkündigungsrecht vor Preissteigerung eingeräumt. Insofern können alle mit den 12-Monatsverträgen bei monatlicher Zahlung, die hier alle so wehklagen ja gerne auch schon vor den 12 Monaten kündigen und etwas günstigeres finden (viel Erfolg dabei, wird schwierig...).

    P.S.: Neben der RAMpocalypse hat übrigens der Irankrieg noch das Potential, die Strompreise erneut in ungeahnte Höhen zu treiben, da das Gas für die Gaspeakerkraftwerke knapp wird. Nur gut, dass jetzt erst mal der Sommer mit viel PV Strom ansteht und die Heizungen weniger brauchen. Insofern kommt evtl auch noch eine Strompreiserhöhung für alle (inkl. Netcup).

    Also Leute ich verstehe euch nicht.

    Da wünscht man sich jahrelang dass Netcup eine externe Firewall einbaut. Dann machen sie das und ihr empfehlt trotzdem einen eigenen VPN Server auf einem Vserver oder RS zu installieren? Das macht doch wirklich nicht mehr so viel Sinn.

    Wenn man genau hinschaut, braucht man, damit keine Bandbreite verloren geht, für diesen Ansatz mindestens einen RS 1000 G12 für 12,79€/Monat - wegen 2,5 Gbit - wenn man nicht grade einen kleineren RS wie den Cyber Quack oder ein ähnliches Einhorn hat. Und dann braucht es noch Cloud vLAN 2,5 Gbit/s für 20,50€/Monat, wenn man den RS vor einen größeren RS spannen will.

    Das sind 33,29€/Monat für eine selbstinstallierte Firewall vor einem RS!

    Oder man nutzt halt die Netcup Firewall für 0€ (!) und z.B. Tailscale für gleichfalls 0€.

    Aktivier doch die Netcup Firewall, mach erst einmal alles incoming und outgoing dicht und setze eine Freigabe fuer deine WAN IP-Adresse auf den RPD-Port (3389 TCP/UDP).

    Ansonsten waere es empfehlenswert, wenn du eine Firewall vor den Windows Server haengst und dich per VPN dann mit der Firewall verbindest / ein Site-to-Site VPN einrichtest.

    Siehe oben. Den Port 3389 aufzumachen ist exakt nicht empfehlenswert. Die Firewall gibt es mit der Netcup FW. Controllerbasierte VPNs wie Tailscale, Zerotier, Netbird und andere können auch ohne separaten Firewall RS verwendet werden.

    Der Grund des Problems sind mangelnde Grundkenntnisse hinsichtlich Firewalls und Networking (IP Adressen / Ports). Hier sollte sich Franci schlau machen und dann die Firewall korrekt konfigurieren.

    Erst mal https://www.netcup.com/de/helpcenter/…server/firewall . Dann fragen.

    Trotz Aufwand bei der Einrichtung ist es extrem empfehlenswert, die externe Firewall korrekt und mit minimaler Öffnung zu konfigurieren.

    Mein Tip: im SCP bei rechts oben Optionen -> dann links "Firewall Policies". Dort pro Dienst eine Policy erstellen, auch ggfalls mit mehreren Bestandteilen / Ports. Und dann zum Server gehen und die benötigte Policy zuweisen (Pfeil nach rechts).

    Windows Server, die im Internet hängen mit offenem RDP Port werden PERMANENT mit Brute Force Attacken bombardiert (schau mal in Deine Logs). Folgende Schritte wären nicht nur empfehlenswert, sondern aus Sicherheitsgründen dringend wichtig:

    - Neuen Adminuser erstellen (neuen, nicht leicht erratbaren Benutzer erstellen - als nicht "Admin" - in Admingruppe hinzufügen), als dieser einloggen, Standard "Administrator" deaktivieren. Schon mal RIESIGES Scheunentor zu

    - https://tailscale.com/ oder einen anderen VPN Client installieren, Login über VPN versuchen und sicherstellen dass es geht

    - Netcup Firewall im Servercontrolpanel konfigurieren, eine Regel "41641 UDP eingehend offen" einrichen und ansonsten alles eingehend zu machen (Standard bei Aktivierung, außer SSH). Dadurch fallen alle Brute Force Attacken auf den RDP Port 3389 weg und der Zugang ist sicher.

    Wenn Du das befolgst, hast Du alle o.g. Probleme nicht mehr und bist DEUTLICH sicherer unterwegs, auch später gegen versehentliche offene Ports.

    RDP Port (Security by Obscurity) ändern ist imho nur gegen low effort und automatisierte Angriffe sinnvoll, ein Portscan wird selbstverständlich den RDP Port auch woanders finden.

    Begebe Dich während der Wartungszeit (10:00 h bis 12:00 h am 09.03.2026)

    • in den Scheidersitz
    • lass Pink Floyd oder Vagelis laufen

    Puh, das halte ich keine 5 Minuten aus, bevor mir nicht Kreuz und Rücken weh tun und bevor ich nicht wegen der Musik am Rad drehe.

    Ich bin übrigens ein Xennial.

    Das Video fühl ich von vorne bis hinten:

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Vielen Dank für die zahlreichen Rückmeldungen, war mir nicht klar, welch ausgefuchste NTP Setups es gibt.

    Laut chrony-Manual kann man den Port für ausgehende Verbindungen konfigurieren. Siehe acquisitionport auf https://chrony-project.org/doc/latest/chrony.conf.html

    Ah, nice. Könnte man evtl noch zusätzlich machen, dann wäre das ziemlich zugenagelt.

    IPv6 wird nicht berücksichtigt. Die verwendeten Zeitserver haben alle auch IPv6-Adressen und die müsste man konsequenterweise ebenfalls in der Firewall zulassen.

    Das stimmt. Wobei eine IP Version ja imho reicht um den Zweck zu erfüllen. Wenns über IPv4 geht, braucht es ja imho nicht noch IPv6. Ich nutze das ja nur als Client, nicht als Server, der ggfalls über IPv6 ansprechbar sein sollte.

    In der chrony-Konfiguration werden die DNS-Namen der Zeitserver verwendet, in der Firewall (notgedrungen) deren IP-Adressen. Bei einer eventuellen Änderung der im DNS hinterlegten IP-Adressen würden die Firewall-Regeln nicht mehr passen. Eine richtige Lösung zu diesem Dilemma kann ich leider auch nicht anbieten, ich habe daher keine IP-Adressen für NTP in meiner Firewall hinterlegt.

    Ja, das stimmt, einige Lösungen wurden ja schon diskutiert. Ich gehe einfach mal davon aus, dass die PTB ihre IP Adressen eben nicht dauernd ändern werden. Ungeeignet ist, wie gesagt die Nutzung der Pool DNS Namen, da es da definitiv keine Kontinuität gibt. Keine IP Adressen zu hinterlegen würde bedeuten, dass jeder Rechner im Internet über Port 123 mit meinem Server kommunizieren könnte. Hm, wollte ich jetzt nicht.

    Die Einstellung für makestep würde ich nicht so wählen, wie vorgeschlagen. Im Betrieb will man in der Regel keine Zeitsprünge zulassen - man denke an eine Datenbank, in der die zeitliche Abfolge von Ereignissen dokumentiert wird - sondern das schleichende Angleichen der Zeit durch Bremsen oder Beschleunigen der Systemuhr.

    Das hat Claude gemacht, um eine zügige Zeiteinstellung herbeizuführen. Kann man gerne weglassen. In meinem Fall würde ich davon ausgehen, dass ich keine Probleme mit dem Sprung hatte (andersrum hatte ich Probleme wegen der falschen Zeit). Aber das hängt natürlich davon ab was drauf läuft. Die vorsichtige Variante ist definitiv Dein Vorschlag.

    P.S.: Kann es sein, dass systemd-timesyncd wegen fehlender Firewall-Regeln nicht funktioniert hatte?

    Jep. ;)

    Bei der Analyse und Behebung hat mir Claude die beiden Optionen timesyncd und chrony vorgeschlagen. Chrony scheint das "bessere" zu sein, daher hab ich das gewählt. Siehe auch https://www.baeldung.com/linux/chrony-vs-systemd-timesyncd . Chrony synct anscheinend mit mehreren Servern, timesyncd nur mit einem.