Du musst die DNS Records ändern und nicht den Nameserver, außer du hostet selber den Nameserver.
Fürs Protokoll: Im letzteren Fall sollte man mindestens zwei unabhängige Instanzen betreiben… (vgl. diesen Diskussionsfaden)
Du musst die DNS Records ändern und nicht den Nameserver, außer du hostet selber den Nameserver.
Fürs Protokoll: Im letzteren Fall sollte man mindestens zwei unabhängige Instanzen betreiben… (vgl. diesen Diskussionsfaden)
Was mir jetzt aufgefallen ist, dass der Link von initrd.img auf initrd.img-5.4.0-52-generic rot ist (s.u.)
Weiß jemand was das zu bedeuten hat?
Der symbolische Link zeigt auf eine nicht-existente Zieldatei (was das Booten des zugehörigen Kernels erwartungsgemäß verhindert). Kann es ggf. sein, dass die Partition voll ist? Erfahrungsgemäß benötigt man maximal einen zusätzlichen, bekanntermaßen funktionierenden Kernel als "Fallback"; die älteren können gelöscht werden. (Es gibt durchaus Konfigurationen, welche dazu führen, dass neue Kernel immer automatisch installiert werden, wodurch Bootpartitionen gerne einmal "vollaufen".)
Schritt 1: Informationen bzgl. Distribution, Version, Ablauf (Kommandozeileneingaben) sind immer hilfreich. Wurde ein neuer Kernel installiert? In diesem Fall verbleibt der alte normalerweise zunächst auf der Platte, d.h. im Bootmenü besteht dann die Möglichkeit, zwischen mehreren Kerneln zu wählen.
Schritt 2: Wenn gar nichts mehr geht, empfiehlt sich die Nutzung einer "Live-CD" der gewählten Distribution, deren Abbild man selbst hochladen kann (Siehe SCP >> Medien > DVD Laufwerk > Zugangsdaten zum FTP Server (und danach: Eigene DVDs)). Diese sollte immer booten und einen Zugriff auf die virtuelle Festplatte des Servers erlauben. (Netcup bietet zwar ein "Rettungssystem", aber ich selbst würde dieses für die Wiederbelebung nur eingeschränkt und nur als Notlösung empfehlen. Das Netcup-Wiki sollte diesbezüglich weiterhelfen.)
irgendwo denke ich mal gelesen zu haben, dass wenn ein Kunde x (auch gleiche) vServer bestellt, diese auf verschiedene Hosts verteilt werden;
Notfalls kann man sich dies zur Sicherheit beim Support erfragen. Wäre auch durchaus interessant zu wissen wie/ob so etwas beim Inhaberwechsel gehandhabt wird.
Im Falle eines Inhaberwechsels kann dies laut Aussage von Netcup ( [netcup] Lucia S.) nicht gewährleistet werden, aber es ist möglich, hier nachträglich eine entsprechende Anfrage zu stellen – siehe Diskussionsfaden "CCP-Update: Produkte anderer Kunden via Inhaberwechsel übernehmen".
Was bin ich froh, dass ich dort abbuchen lasse und nicht überweisen muss.
… aber bestimmt nur so lange, bis die Benachrichtigung eintrifft, dass die Abbuchung fehlschlug und (mit Fristsetzung) um Begleichung gebeten wird. ![]()
Andersherum formuliert: Mit Existenz von "@"- und "*"-A-Einträgen fungiert der "@"-MX-Eintrag für alle möglichen Subdomänen und für die Hauptdomäne als einheitlich verwendeter Mail-Host unter dem angegebenen Namen (im Beispiel: "at01mailserver01.com").
Das ist aber kein "catchall"(!)-Eintrag, denn ein solcher erforderte wirklich die Nutzung eines "*"-MX-Eintrags, welchen man (siehe Erläuterungen in den Kommentaren zum obengenannten Link) normalerweise nicht will. Wenn gewünscht ist, dass "<unterdomäne>.at01mailserver.com" sowohl als Webpräsenz als auch als Mailserver verwendet wird, lässt sich das bei überschaubarer Anzahl von Unterdomänen IMHO besser durch individuelle MX-Einträge realisieren.
Bei Mail wäre es dann laut wiki @ für catchall und als MX oder lieg ich falsch.
Nein, das wäre ja inkonsistent. Egal ob "A"-Eintrag oder "MX"-Eintrag, jeweils 1x "@" für die Hauptdomäne und 1x "*" für alle Unterdomänen. Bei den "MX"-Einträgen muss natürlich rechts statt einer IP-Adresse der Name der Domäne ("at01mailserver01.com") stehen.
EDIT: Netcup erwähnt bei MX-Einträgen tatsächlich nicht, ob die Verwendung von "*" möglich ist:
ZitatHost: In dieser Spalte ist die Subdomain einzutragen. Als Wildcard dient hier das * (Sternchen). Bei einem Record vom Type "MX" ist ein @ zu setzen.
Erläuterungen zu potentiellen Problemen bei Wildcard-MX-Einträgen finden sich hier.
Siehe Netcup-Wiki. (Die Unterdomäne "www" wird genauso wie "shop", … durch "*" abgedeckt; die Hauptdomäne wird durch "@" adressiert.)
Ich kenne das so, bei dem Passwort-Manager, den ich nutze (1Password), dass die Domain, unter der das Passwort im Browser direkt "auswählbar" ist, in dem Eintrag konfiguriert werden kann. Ich kriege also nur die Option, ein Passwort einzutragen, wenn ich unter der richtigen, vormals hinterlegten, Domain bin.
Das funktioniert in der Praxis manchmal nicht (komfortabel). [E]inige Anbieter leiten für die Registrierung auf andere Domains (register.example.org), daher kann man sich nicht unbedingt auf die automatisch gespeicherten URLs verlassen. Ab und an gibt es für ein und denselben Dienst auch mehrere URLs. Das customercontrolpanel.de ist auch unter *.webhosting.systems verfügbar.
Und genau hier kann Netcup selbst ansetzen, indem entsprechende Hinweise (inklusive Auflistung aller verwendeter URLs) im Wiki hinterlegt und bei Benachrichtigung über die Bereitstellung von Servern verlinkt werden!
Und zu guter [L]etzt war es, als ich mit Keepass angefangen habe, unter Android gar nicht anders möglich, als den Eintrag manuell zu suchen und zu kopieren.
Android ist hier leider problematisch… Unter neueren Versionen könnte man ggf. für kritische mobile Szenarien entweder (1) via Termux lokal einen Browser installieren, welcher Plugins unterstützt oder (2) derartige Zugriffe nur über den Umweg eines (im VPN) im Zugriff befindlichen PCs verwenden.
Sicherlich nicht wirklich komfortabel und bei der Einrichtung aufwendig – allerdings muss man hier die Opportunitätskosten einer solchen Lösung in die Entscheidung miteinbeziehen, und dann fällt die Entscheidung gleich deutlich leichter. Obige Investitionen in einen sicheren Zugang zu Systemen sind ein Klacks gegen das Neueinrichten aller Systeme im Falle einer potentiellen Kompromittierung.
Kam gerade eben bei mir als Mail rein. Allerdings an meine "falsche" Adresse. Der Link selber führt dann auf ne Seite die 1:1 wie das CCP aussueht und nach Eingabe von "irgendwelchen" Daten kommt man dann auch tatsächlich zum CCP....
Das wäre doch einmal eine gute Gelegenheit, das CCP analog zum SCP durch DNSSEC abzusichern (Bonuspunkte für passende TLSA/DANE-Einträge im DNS):
(CC [netcup] Felix P. / [netcup] Lars S.)
… und auf der Client-Seite empfiehlt sich die strikte Nutzung eines Passwort-Agenten für alle Webbrowser, welcher sich zu Recht sträuben wird, auf fremden Seiten das korrekte Passwort in irgendwelche Felder einzufügen!
Gibt es noch die Möglichkeit, dass die ursprünglich aufgerufenen URLs und nicht die der Weiterleitung im Browser sichtbar ist (wie bei der Frame-Weiterleitung)?
Da sollte wie folgt möglich sein: Client-seitig den Browser-Cache löschen und server-seitig im obigen Code das "R=301" entfernen (siehe auch hier).
Nutzt hier jemand rclone? Kann es sein, dass dieser Fehler vor ein paar Monaten noch nicht auftrat unter Linux? […]
rclone-woes01.png
Auflösung: Mithilfe der zusätzlichen Option --allow-other funktioniert es wie gewünscht (für rclone v1.53.2). ![]()
Nutzt hier jemand rclone? Kann es sein, dass dieser Fehler vor ein paar Monaten noch nicht auftrat unter Linux?
(Test unter Ubuntu 16.04/18.04/20.04, arm64/amd64, rclone v1.53.2, mit verschiedenen Quellen (Microsoft/Telekom), Kerneln, und unterliegenden Dateisystemen)rclone-woes01.png
Ich wiederhole meine Empfehlung auch noch einmal
(Falls man kein "klassisches" Port-Knocking haben möchte.)
Danke für die Erinnerung! Da gab es ja hier noch das (Meta-)TODO, die Nutzung dieses Werkzeugs auf die TODO-Liste zu setzen… ![]()
jetzt wo Du es sagst,
ja braucht man denn diesen DNS-Eintrag?
_smtp._tls.MYDOMAIN TXT "v=TLSRPTv1; rua=mailto:SMTPTLS-REPORT@MYDOMAIN;"
lt. dem RFC muss des rua= da vorkommen?
Braucht man diesen Eintrag? Wenn man Fehlern in Verbindung mit MTA-STS (vgl. RFC 8461) auf die Schliche kommen will, ist dies eine sehr elegante Möglichkeit, analog zu DMARC-Berichten (vgl. RFC 7489). Man kann ihn aber auch weglassen…
Hinweis: Der obengenannte Eintrag ist insofern problematisch, als die MTA-STS-Nutzung für die Domäne MYDOMAIN laut Report (policy-string: […] mode: enforce […]) (immer) erzwungen wird – hier stellt sich die Frage, ob "Bericht-E-Mails" diese Einstellung ignorieren (sollten), denn sonst würde bei empfängerseitigen Problemen ja gar nichts ankommen können. Auch bei vergleichbaren Report-Definitionen wird hier als best practice eine andere, im Optimalfall unabhängig "bediente" Empfängerdomäne angegeben. Alternativ – was ich selbst bevorzuge – ist (ggf. neben einer anderen Domäne) die Angabe einer https-Adresse möglich, welche nicht durch einen Mail- sondern einen Webserver bedient wird (via HTTP POST).
In allen Fällen empfiehlt es sich zwecks sinnvoller Auswertung dieser Berichte (insbesondere bei DMARC), wirklich inhaltlich zu filtern (sprich: Berücksichtigung der Bedeutung der Einträge entsprechend der Spezifikation anstelle eines reinen matchings auf Basis regulärer Ausdrücke) und "reine Statusmeldungen" (oder bekannte Fehler) zu ignorieren/löschen. Hier hat sich für mich die Kombination eines spezialisierten Scripts (welches gleichzeitig die Inhalte reformatiert) und tenshi bewährt.
Ich möchte in diesem Zusammenhang (wieder einmal) auf knock verweisen, vgl. diesen Forenbeitrag. (Für Zugriffe, die nicht innerhalb eines VPNs erfolgen.)
hat schon mal jemand ein E-mail von der E-mailadresse bekommen?
tlsrpt-noreply@microsoft.com
und was sagt mir da der Inhalt?
Code{"organization-name":"Microsoft Corporation","date-range":{"start-datetime":"2020-10-21T00:00:00Z","end-datetime":"2020-10-21T23:59:59Z"},"contact-info":"tlsrpt-noreply@microsoft.com","report-id":"132478674513495264+MYDOMAIN","policies":[{"policy":{"policy-type":"sts","policy-string":["version: STSv1","mode: enforce","mx: mx01.MYDOMAIN","max_age: 10368000"],"policy-domain":"MYDOMAIN"},"summary":{"total-successful-session-count":1,"total-failure-session-count":0}}]}
Sicher, dass sowas (im I-JSON-Format gemäß RFC 7493) nicht explizit selbst angefordert wurde gemäß RFC 8460?
Die Österreichische Post bringt jetzt eine Corona-Briefmarke auf Klopapier heraus. Na Leckomio...
Deutsche kaufen alles aus Klopapier... in einem Monat ist in Österreich jede Kloschüssel vergoldet, weil sie ihr ganzes Klopapier nach Deutschland verkauft haben. Mark my Words!
Webhosting... Schade, gibt es nicht irgend eine andere Möglichkeit ein Event auszuführen?
Von hinten durch die Brust ins Auge ginge es, wenn das Ereignis bspw. durch regelmäßiges Aufrufen eines PHP-Scripts o. ä. über eine festgelegte URL ausgelöst werden kann (das Script könnte hier die aktuelle Zeit protokollieren und mit dem Zeitpunkt des letzten Laufs vergleichen, um eine zu schnelle Wiederholung zu vermeiden). Unschön ist und bleibt dabei natürlich, dass man von einem externen Dienst abhängig wird. Von letzterer Sorte gibt es aber durchaus eine gewisse Anzahl, auch frei verfügbar.
Genau das was ich suche, perfekt! Jetzt ist nur die Frage wie es mit der Entwicklung um dsh ausschaut weil alles was ich dazu finde ist schon über ein Jahrzehnt alt.. Kann man die Software bedenkenlos nutzen oder sollte man doch zu aktuelleren alternativen greifen?
dsh ist wirklich nur eine "Umverpackung", welche eigene Konfigurationen liest und über definierte Maschinen iteriert (Anmerkung: der Parallelmodus mittels Option "-c" kann hier bisweilen durchaus Zeit sparen); insofern verwundert es nicht, dass irgendwann nur noch selten neue Versionen erschienen (wir sind hier ja nicht bei curl…
).
Da die Befehlsübermittlung normalerweise durch ssh erledigt wird (und dieses Paket wird gut und regelmäßig gepflegt!), habe ich selbst keinerlei Bedenken beim regelmäßigen Einsatz und kann die distributed shell uneingeschränkt weiterempfehlen.