Beiträge von gunnarh

Die gepinselten Grafiken sind offenbar in UTC. Der fehlende Hinweis auf diesen Umstand ist übrigens nicht das Einzige was mir da immer wieder als verbesserungswürdig auffällt. Man hat als Betrachter außerdem keinerlei Hinweis darauf, wie man das interpretieren soll. Warum ist ein und derselbe Peak in der 7-Tage Darstellung deutlich kleiner als in der 24-Stunden Darstellung? Vermutlich weil nicht das Maximum (pro Sekunde) wie suggeriert aufgetragen wird sondern ein Mittelwert über einen nicht bekannten Zeitraum dargestellt werden dürfte.

Eine Statistik bei der man nicht weiß wie sie zustande kommt ist leider oft nicht wirklich hilfreich. Sei es weil man sie nicht interpretieren kann, oder weil man sie (ohne es zu wissen) fehlinterpretiert.

Ich kann auch keinen Zusammenhang zwischen der Verwendung bzw. Nicht-Verwendung von fstrim und dem CCP-Hinweis der nötigen Speicheroptimierung erkennen. Ich muss gestehen ich ignoriere diesen Hinweis mittlerweile, da ich nicht gewillt bin alle paar Wochen meinen Snapshot zu löschen nur um einen Vorgang anzustoßen dessen Sinn mir nicht im Detail bekannt ist. Vielleicht schafft es NetCup ja irgendwann uns die Trigger-Schwellen die diese "Empfehlung" auslösen und den technischen Vorgang dahinter zu erläutern, bislang kenne ich aber nur die (aus meiner Sicht großteils vermutlich zutreffenden) Vermutungen hier im Forum, das ist mir jedoch für eine abschließende Beurteilung etwas zu viel Spekulation.

Nimmst Du Zahlungen im Shop entgegen?

Wenn ja beachte mögliche Vorschriften, die Dir Dein Zahlungsdiensteanbieter eventuell auferlegt (hat).

Ein Domainvalidiertes Zertifikat sagt nichts über den Inhaber des Webauftritts aus, sondern bestätigt eben nur - wie der Name schon sagt - dass man tatsächlich mit dieser Webpräsenz dieses Domain-Namens eine Verbindung aufgebaut hat.

Am anderen Ende der Skala, ein EV-Zertifikat - hier soll das Zertifikat tatsächlich den Inhaber (Firmenname) bestätigen.

Wildcard / MultiDomain: hat technische Gründe, wenn man es denn braucht. Das musst Du Deine Techniker fragen.

Wie schon mehrfach gesagt geht es mit Let's Encrypt auch kostenfrei, und hat (wenn ein domainvalidiertes Zertifikat ausreicht) auch keine technischen Nachteile. Ich behaupte es hat heutzutage auch keinen Repuatations-Nachteil mehr. Es wird keinen Kunden geben der bei dir im Shop bestellen möchte, und dann vor Eingabe der Lieferadresse plötzlich kalte Füße bekommt weil Du "nur" ein kostenfreies Let's Encrypt Zertifikat benutzt.

Kritikpunkt bei Let's Encrypt warum oftmals tatsächlich auch für "nur" domainvalidierte Zertifikate noch Geld in die Hand genommen wird: Die kurze Zertifikats-Laufzeit bei Let's Encrypt zwingt dazu, dass man den Zertifikats-Wechsel automatisieren muss (oder alle 2,5 Monate manuell eingreifen müsste). Nicht alle Unternehmen können oder wollen dies tun, aus ganz unterschiedlichen Gründen. Für ein agiles, frisches Projekt wird das nicht so die Hürde darstellen, für Großunternehmen wo Zertifikats-Management eine eigene Abteilung in der IT-Security beschäftigt und seit Jahren etablierte Betriebsprozesse zu so etwas eben nicht "dazupassen" sieht es eventuell anders aus.

Das Thema Spam mit Filterung die NACH der Annahme stattfindet anzugehen ist der falsche Weg. Insofern lohnt es sich auch nicht darüber nachzudenken irgendwelche Filter zu trainieren. 99% des Spams wird man los, indem man den Müll erst gar nicht annimmt - Stichwort: PostScreen und DNSBL.

Sämtliche Filterung die nach der Annahme stattfindet ist außerdem bedenklich, da es sich um eine Unterschlagung von Nachrichten handelt. Nicht-Annahme ist der einzige gangbare Weg, sollte es tatsächlich einmal einen legitimen Absender treffen der abgewiesen wird, dann bekommt er dies von seinem MTA mitgeteilt. Ich verwende PostScreen (bzw. davor PolicydWeight) seit mehr als 15 Jahren, ich hatte in all den Jahren noch keinen einzigen Fall einer Abweisung die eine gewünschte Mail betroffen hätte. Spam-Rate in meinem persönlichen Postfach (zahlreiche zugehörige E-Mail Adressen sind im Whois bzw. auf WebSites angeführt, werden daher kräftig bespamt) ist damit weniger als 5 Spam-Mails pro Woche.

Diese Einschätzung, das man als großer Mensch auch einen höher gelegten Tisch braucht kann ich zu 100% bestätigen. Die Körperhaltung ist eine ganz andere, wenn die Arme - die ja 90% der Zeit auf dem Tisch bzw. der Tastatur aufliegen - einen anderen Winkel haben.

Bin 190 und habe mir meine Tischplattenhöhe von typischen 73cm auf 82cm "hochgelegt" indem ich zwischen Metall-Gestell und Tischplatte einfach 2x 4,5cm gehobeltes Kantholz dazwischengeschraubt habe. Sieht kein Mensch (verschwindet unter der Tischplatte) und kostet 2 Stunden Zeitaufwand und 20 Euro Material.

So ein Pezziball ist halt ziemlich voluminös - da braucht man schon Platz.

Und im Büro würde ich den auch nicht nutzen wollen, immerhin hat man dann quasi indirekt die ganze Zeit den Schmutz vom Fußboden auf den Händen und der Hose, der Ball nimmt halt alles auf, und täglich reinigen wird man ihn auch nicht. Aber für zuhause oder andere saubere Umgebungen sicher eine gute Abwechslung. Wobei es auch "dynamische Hocker" (z.B. swooper u.ä.) gibt die ähnlichen Effekt haben und nicht ganz so exotisch aussehen

Das System des "Trust on First Use" (neuen Pubkey beim Ersten Kontakt zum Server akzeptieren und eine Änderung mit einer Warnung zu versehen) ist besser als gar kein Schutz, aber bei Anwendern die wie Schimpansen darauf dressiert sind alle Warnungen stets "wegzuklicken" ohne der Ursache nachzugehen geht dieser Schutz freilich ins Leere.

customer - Du hast mich zwar vollständig zitiert, Dein Einwand es braucht einen "sicheren Kanal" um PubKeys auszutauschen ignoriert jedoch den zweiten Halbsatz im Zitat. Ich schrieb Zitat: "Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig."

Dass es dennoch einen Integritätsschutz braucht steht außer Frage, aber - wie ich ganz deutlich schrieb - es braucht keinen sicheren Kanal im Sinne von Vertraulichkeit.

Um die Integrität zu prüfen kann man z.B. ganz simpel auch wie folgt vorgehen: Ich kann meinen SSH-Key dem Server-Admin per ungeschützter Klartextmail an dessen gehackten GMAIL-Account übermitteln. Der Server-Admin empfängt das Mail und ruft mich anschließend am abgehörten GSM-Telefon zurück und fragt mich "Hast Du mir gerade deinen SSH-Key gesendet? OK. Hat der an der 10ten Stelle ein C? OK und an der 20ten Stelle ein O? OK und die letzte Stelle ein kleines w? OK, danke, ich berechtige Dich.
Trotz unsicherer Kanäle kann mit diesem simplen Verfahren ein ausreichender Integritätsschutz gewährleistet werden. Dazu muss man nicht erst SMIME/GPG ausrollen oder persönliche Übergabe auf USB-Stick durchführen.

So schräg ist das nicht.

1. lässt man nicht den Benutzern "Zugangsdaten zukommen", sondern man berechtigt die PubKeys der User sich dort anmelden zu dürfen. Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig.

2. hat das Hinterlegen von Server-Keys im DNS vor allem dann große Vorteile, wenn man sehr viele Server betreibt und / oder diese häufig (z.B. automatisiert) neu initialisiert - z.B. weil es sich um VMs, Container etc handelt.

Der "andere Hoster" ist eine WebHosting-Infrastruktur, oder ein Server auf dem Du per SSH einsteigen und debuggen kannst?

Wenn Du dort einsteigen kannst, würde ich dort mal die WebServer-Logs sichten. Eventuell gehen dem WebServer einfach die verfügbaren Worker-Agents aus, weil da zeitgleich zu viele Requests stattfinden.

Deine Detail-Fehlermeldung zum Fehlercode 7 von curl lautet "Connection Refused". Das heißt da wird eine TCP-Verbindungsaufnahme explizit verweigert (TCP-Reset, kein silent Drop). Würde der Verbindungsaufnahmeversuch einfach nur outtimen weil z.B. eine Firewall oder ein Router auf der Strecke die Pakete dropped, dann würde die curl Fehlermeldung nicht "Connection Refused" sondern "Connection timed out" lauten.

Mir kommen da etwas Zweifel, was Du da konkret testest.

• Deine Windows-Maschine ("C:\Users\Tools") steht bei Netcup
• Die Zielmaschine ("netadmin@server12") steht offenkundig bei der Konkurrenz HxxxxER
• Du zeigst uns funktionierende Tracerts von anderen Quellmaschinen aus, die aber allesamt offenkundig als letzten Hop nicht "H....ER" sondern den Carrier "Co..nt" zeigen.
• Nun ist mir bekannt, dass H....ER auch Colocation die über Co..nt angebunden ist anbietet - aber warum soll der letzte Hop (Router) sich ändern in Abhängigkeit dessen ob Du von NetCup oder einem anderen Weg kommst. Klar kann das Peering dann anders aussehen - aber der letzte Hop wäre doch ungewöhnlich.

Wie ist der Server tatsächlich angebunden? Ich vermute da ein Routing-Problem, allerdings eher näher dem Ziel als der Quelle.

Hostname was NOT found in DNS cache
*   Trying 1.1.1.1...
* Connected to domain.de (1.1.1.1) port 443 (#0)

Sofern Du versucht hast den Output durch Verwendung der IP-Adresse "1.1.1.1" zu anonymisieren ist dies etwas suboptimal. Dot-1 (1.1.1.1) ist ein gängiger Cloudflare-Resolver, und im Kontext "not found in DNS Cache" würde ich daher nun annehmen es wird versucht die Domain über den Dot-1 Resolver aufzulösen.

Ist das so, oder hast Du nur ziemlich ungeschickt anonymisiert?

Zitat von Twisterado

Ich hab SSH-Zugriff auf den Server, bin mir aber unsicher, was du genau meinst... Soll ich es mit cURL per SSH versuchen?

Ja.

Da Du offenbar auch den Zielserver unter Deiner Kontrolle hast, würde ich einmal vom Ziel aus ein Tracert zu Deiner Netcup-Maschine machen. Das Resultat könnte Aufschlüsse liefern. Wenn Du mir die Ziel-IP nennst (gerne auch per PM) kann ich mal von meiner bei Netcup gehosteten Maschine aus einen TraceRoute versuchen.

Zitat von Aegis

C:\Users\Tools>tracert [IP-ZENSIERT]

Routenverfolgung zu [IP-ZENSIERT] über maximal 30 Hops

1 17 ms 2 ms <1 ms 195.128.100.2
2 <1 ms <1 ms <1 ms dcr01.netcup.net [46.38.252.32]
3 5 ms 4 ms 6 ms rt2-decix-int-fr.eu-de.host1plus.com [80.81.193.250]
4 [IP-ZENSIERT] meldet: Zielprotokoll nicht erreichbar.

Ablaufverfolgung beendet.

Ist in Zeile 4 die zensierte IP bereits die Ziel-IP, oder ist das ein vorgelagerter Hop?

Grenze mal ein, ob es am Verbindungsziel oder an Deiner lokalen Konfiguration liegt.

Returncode 7 bedeutet, CURL konnte zwar den Domainnamen auflösen (sonst hättest Du einen Returncode 6 erhalten) aber keine TCP-Verbindung zum Ziel herstellen. Wäre es ein SSL/TLS-Handshake Fehler würde Returncode 35 auftreten - soweit kommt Du also noch gar nicht.

Hast Du die Möglichkeit es direkt in der Konsole dieses Servers manuell zu versuchen?
Eventuell wird der Domainname auf eine falsche (veraltete?) IP-Adresse aufgelöst, oder irgend eine Firewall oder SELinux-Konfiguration hindert Dich daran die Verbindung aufzubauen.

Würde beim Eingrenzen damit beginnen es in der Konsole manuell zu versuchen sowie testweise ein anderes Verbindungsziel zu wählen.

Nachtrag zu meinem Post:
Hier einer der von mir angesprochenen Beiträge, mittlerweile exakt ein Jahr alt:

https://forum.netcup.de/netcup-intern/…se-n/#post98839

Seitens NetCup gab es damals von [netcup] Johannes B. die vorsichtige Zusage sich die Umsetzung ansehen zu wollen.

[netcup] Felix P. Die Aussagen sind verständlich.

Ich möchte aber die hier im Forum geführten Diskussionen in Erinnerung rufen, wo mehrfach der Wunsch geäußert wurde nicht nur eine sondern mehrere E-Mail Kontakte im CCP verwalten zu können. Mir erschließt sich nicht, warum die gleiche E-Mail-Adresse die im WHOIS meiner Domains landet auch jene ist von und zu der ich anschließend den NetCup-Support kontaktieren muss. Ich denke es gibt vielerlei gute Gründe warum man dies anders handhaben möchte.

Ich rege daher abermals an, die unterschiedlichen Stellen an denen E-Mail-Adressen verwendet werden (Domains, Support, Rechnungsversand, Benachrichtigungen zu Downtimes, CCP-Kennwortreset, Notfallkontakt, ...) mit getrennten E-Mail-Adressen zu führen und eine Eingabe dieser im CCP zu ermöglichen.

Ich bin ja wahrlich kein Rechtschreibfanatiker.

Aber wenn jemand Leihe schreibt obwohl er gemäß Kontext offenkundig Laie meint, dann kann auch ich das nicht unkommentiert mitansehen

Um Inhaltlich etwas beizutragen: Du musst uns erst erläutern, was Du tatsächlich tun möchtest.

1. Einen DNS-Namen auf einen anderen Server zeigen lassen? Der Zielserver sollte sich für den Namen jedoch zuständig fühlen (d.h. ein für den betreffenden Namen geeignet konfigurierter vHost existieren). Das wäre ein CNAME im DNS, den Du über die Domainverwaltung von Netcup selbst konfigurieren kannst. Für den Besucher der Website ist in der URL-Zeile dann nicht ersichtlich, dass er auf einem anderen Server gelandet ist
2. Einen HTTP-Redirect einrichten, sodass Dein Browser von https://Domain1.tld auf https://umgeleitetedomain.tld weitergeleitet wird? Hierzu benötigst du einen Webserver (also z.B. ein zugewiesenes WebHosting) auf dem Du mittels passendem HTTP-Header, Meta-Refresh oder JavaScript die Umleitung durchführst.
3. Einen Frame mit Inhalt einer anderen Website? - Das heißt der Anwender sieht weiterhin https://Domain1.tld der Content-Frame stammt aber von https://domainverkaeufer.tld -> auch hier benötigst Du einen WebServer (z.b. Webhosting) und musst eine entsprechende Seite mit passend konfiguriertem Frame bereitstellen.

Und noch eine Anregung:

Die durch die Wartung verursachten Server-Shutdowns und Server-Starts sind leider NICHT im SCP im Protokoll verzeichnet.

Das finde ich unschön und verwirrend.

Zitat von timkoop

Sollte daran liegen, dass das SCP sich die Daten vom Node holt, welcher ja gerade neu gestartet wird

Das ist mir schon klar. Daher ja auch meine Anregung: Wenn ein Hostnode geplant für eine Wartung gestoppt wird, sollte das im Servercontrolpanel entsprechend vermerkt werden und eine zutreffendere Meldung wie z.B. ein Hinweis auf die stattfindende Wartung statt dieser generischen (und im konkreten Fall ja sogar falschen) Fehlermeldung angezeigt werden.