Beiträge von m_ueberall

    Wie sieht's denn bei den Vorgängern mit der Unterstützung durch den Linuxkernel aus? Bei den meisten SBCs wird eine Kernelversion so hingefrickelt, dass sie einigermaßen läuft und bei der hängt man dann für immer fest.

    Ich habe hier zwei ODROID N2+ (S922X CPU, 4xA73@2.4GHz + 2xA53@2.0GHz) und die Kernelunterstützung ist einwandfrei (derzeit bis 5.14.y – wobei ich selbst die jeweils neuesten verfügbaren Kernel meide und hier aktuell 5.13.y verwende)[*]; im Forum tummeln sich u. a. Debian-, Ubuntu- und Arch-Nutzer – viel besser wird's nicht. HardKernel hat hier schon mit älteren Modellen bewiesen, dass sie um den Wert der Software-Unterstützung wissen und entsprechend Aufwand investiert, um gän­gi­ge Linux-/Android-Distributionen damit zum Laufen zu bekommen. Dennoch sollte man sich zutrauen, bei Nicht-x86_64/amd64-Architekturen den Kernel selbst zu über­setz­en, weil ab und zu einmal Module nicht einkompiliert sind (insgesamt eben eine drastisch kleinere Nutzerbasis verglichen mit vorgenannter Architektur, klar) wie etwa diejenigen, welche man für die LXD+QEmu-VM-Steuerung benötigt.

    Bei den Radxa-SBC kommt es stark auf das Modell und die jeweilige CPU an, da gibt es durchaus auch größere Probleme, was man so im Forum sieht – mit der Zeit wird es sicherlich besser, aber man kann dort eher in die Rolle eines "Early Adopters" geraten (was schlichtweg daran liegt, dass die verbauten CPU neueren Datums sind als die vorgenannte). Andererseits wird auch bei Radxa Wert darauf gelegt, dass viele OSS-Autoren entsprechende Modelle als Erste in die Hand bekommen (dadurch wird die Kernel-/Treiberunterstützung stärker ausgelagert).

    Gegenüber den zahlenmäßig weiterverbreiteten "Original-Raspberries" – und da muss man sich einlesen! – haben alle vorgenannten Modelle allerdings den Vorteil, dass hier wirklich alles als OSS verfügbar ist, ohne jegliche proprietären Software-/Firmware-Bestandteile, welche man beim Raspberry nicht umgehen kann und (bislang) nicht dokumentiert be­kommt[**]. Das ist ein Grund, warum beispielsweise verschiedene Distributionen diese Modelle meiden. Es empfiehlt sich also, bei Interesse an SBC zu­nächst sehr intensiv auf Unterschiede zwischen den Modellen und verbaute Hardware ("überschaubarer Anzahl" von Komponenten auf dem SBC) zu achten. Hier kann es sich durchaus lohnen, auch ein­mal "gegen den Strom zu schwimmen" und Modelle mit kleinerer Nutzerbasis ins Auge zu fassen. Ich bin mit obiger Erstwahl un­ein­ge­schränkt zufrieden, auch wenn ich Ende des Jahres ggf. langsam mit einer neueren CPU-Generation (ARMv8.2) liebäugle, welche Radxa auf den Markt bringen will.


    EDIT: Bei Radxa sollte man im Auge behalten, dass dort bisweilen auch verschiedene Revisionen desselben Basis-Boards in zeitlich kurzen Abständen herausgegeben werden, welche bisweilen signifikante Design-Anpassungen/-Korrekturen (Stromversorgung auf den Pins, …) aufweisen. Mein bisheriger Eindruck ist der, dass die Chi­ne­sen (Radxa) wesentlich mehr Modelle entwerfen und "näher an der Chip-Quelle" sitzen als die Koreaner (HardKernel), welche dafür ggf. etwas mehr Aufwand beim ini­ti­alen De­sign eines Modells betreiben, weil sie sich aufgrund der Unternehmensgröße auf weniger Modelle konzentrieren und diese in Stückzahlen "an den Mann" bringen müssen.


    [*] Gerade die letzten v5.1x-Kernel haben sukkzessiv Erweiterungen für die aarch64/arm64-Architektur gesehen, wobei etwa Patches für die Reboot-Unter­stütz­ung bis­lang noch durch die SBC-Anbieter "downstream" beigesteuert werden müssen (diese werden ihren Weg in den Standard-Kernel finden, aber das kann noch ein paar Wochen/Monate dauern)

    [**] Nach meinem bisherigen Kenntnisstand; allerdings habe ich mit Entscheidung für den HardKernel ODROID N2+ im August letzten Jahres die Veröffentlichung von Firm­ware-De­tails zum Raspberry nicht mehr wirklich verfolgt, da mir selbst die aktuellen RPi-Modelle eine zu schwache CPU-Leistung aufweisen und ich von der obengenannten Software-Un­ter­stützung be­gei­stert bin.

    Die aktuelle index.php (s.Anhang) hat in der zweiten Zeile eine Menge kryptischer Zeichen. Kann die Ursache ein Virus oder Malware sein?

    Davon würde ich ausgehen. Nach Berichten aus dem Internet, welche man durch Suchen der ersten Zeichen dieser Zeile findet, werden seit einigen Tagen bisweilen mehrere PHP-Scripts damit manipuliert. Der Inhalt des (partiell) decodierten Scripts deutet nicht darauf hin, dass dies eine vom Nutzer gewünschte Erweiterung sein könnte, da es für die identische Manipulierung mehrerer PHP-Scripts in diesem Umfang und in derart kryptischer Form (da die Dekodierung Zeit kostet, würde kein WordPress-Modul-Autor derartige unsinnige "Klimmzüge" veranstalten!) schlechterdings keinen logischen Grund gibt außer sicherzustellen, dass dieser Code mit hoher Wahrscheinlichkeit ein- oder mehrmals ausgeführt wird.

    Zwecks Analyse würde ich eine Kopie aller Logs/Dateien anraten, gefolgt von umgehender Neuaufsetzung der Webpräsenz unter Verwendung aktueller Komponenten (WordPress, PHP, ...) und expliziter Kontrolle aller Zugriffsrechte.

    Nun erhalte ich folgenden Fehler wenn ich versuche ein Zertifikat zu erstellen:

    Bash
    […]
    [Do 7. Okt 13:50:36 CEST 2021] No Credentials given
    […]

    Verstehe auch nicht warum er als CA Zerossl verwendet und nicht Lets Encrypt.

    Da hilft wohl wirklich nur ein erster Blick ins Log nach Nutzung von "--debug". Wie es aussieht, werden den Zugangscodes nicht übernommen.

    Der Wechsel auf ZeroSSL (wohl aufgrund eines Sponsorings) wurde bei Erscheinen der Version 3.0.0 bekanntgegeben, vergleiche hier.

    Moin, jemand Interesse an dem Script?

    Ich könnte mir das als Beitrag für das Serverhoarder-Wiki vorstellen (wenn es in Gang kommt), da dieses Thema anlagemäßig für mehrere Anbieter Sinn macht und entsprechende Scripts über die Zeit sicherlich mehrere Anpassungen benötigen (etwa bzgl. "safeguards" gegenüber geänderter Eingabemasken usw.)

    Gegen einen initialen Gist oder eine anderweitige Veröffentlichung via GitHub/GitLab/Codeberg spricht aber auch nichts. :)

    I wish I could reset / reboot / shutdown / other via my web panel using netcup api via a token server

    Unfortunately, there is only a limited set of actions you can trigger, see this topic on the Netcup wiki. If I recall correctly, though, at least one user managed to access the SCP using the Apache Selenium framework which should allow to reuse all available actions (the downsides being that you'd need to use the SCP login credentials, and that this takes considerably more effort than using a pre-defined web service). EDIT: If this (still) sounds like an option, see this thread.

    Aktuell haben wir ein Multidomain-Zertifikat für mehrere unterschiedliche Websites über die Telekom (die Website liegt derzeit noch bei der Telekom). Ich wüsste nicht wie ich dieses duplizieren könnte. Wir haben es nicht selbst installiert. Erstellung und Installation wurde über die Telekom vorgenommen.

    Nun, in diesem Fall steht vor Nutzung der neuen Webpräsenz sowieso das Thema Zertifikatserstellung an, selbst wenn alle Domänen umgezogen werden sollen – die Telekom oder einer ihrer Partner wird sich dann um die Erzeugung/Verlängerung der für Netcup-Hosts verwendeten Zertifikate eher nicht kümmern (oder es sich ggf. ausgesprochen gut bezahlen lassen). Ohne ein entsprechendes (Einzeldomänen?-)Zertifikat ist an einen "transparenten" Umzug der Domäne (und die fortgesetzte Nutzung) nicht zu denken.

    Erinnerung: Spätestens jetzt sollten Nutzer von Apache2 v2.4.49 ein Update eingespielt haben, welches CVE-2021-41773 adressiert; hier findet sich eine Docker-Testinstallation, mit der man üben kann, wie man sensitive Dateien "abgreift".

    Da der Exploit ein paar Tage bekannt war, empfiehlt sich bei früherer Nutzung der verwundbaren Version in diesem Fall unbedingt ein Blick in die Webserver-Logs…


    Hierzu sollte es reichen, nach '%nn' zu suchen (Kollege unten war hier leider – u. a. – etwas spät 'dran; '%2e' ist dabei nur ein Beispiel, Kombinationen mit '%5c' o. Ä. gibt es na­tür­lich auch):

    Code
    [2021-10-06T09:47:04+0200] root@vserver19<kvm>:/var/log/apache2# grep '%2e' *_access.log*
    […]
    domain.tld_access.log.1:196.65.227.79 - - [05/Oct/2021:22:27:38 +0200] "GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e//etc/passwd HTTP/1.1" 400 226 loc:"-" ref:"-" ua:"curl/7.74.0" port:80
    […]

    Die Website läuft derzeit parallel noch am alten Server. Wir möchten die DNS-Einträge erst ändern, wenn die Website am neuen Server läuft, daher gibt es keine Möglichkeit das vorhandene Zertifikat vom "alten" Server zu übernehmen.

    Das "Ausrollen" (Installieren) eines Zertifikats ist unabhängig von den DNS-Einträgen und ein solches kann beliebig dupliziert werden, d. h., es ist keine Verschiebung notwendig.

    Die vorgenannten Schritte zur lokalen Änderung einer "DNS-Auflösung" sorgen dafür, dass der/die betroffenen Rechner – und nicht die breite Öffentlichkeit – eine Kopie dieses Zertifikats unter der neuen IP-Adresse erwartet/n und bei Anfragen den korrekten/zukünftig dieser IP-Adresse offiziell zugeordneten Domänennamen "im Voraus" verwendet/n. Eben zu internen Testzwecken.

    Da muss ich mir dann wieder die Hände auf den Rücken fesseln lassen, damit ich nichts bestelle, das ich dann doch nicht brauchen werde..

    Hilfsweise mir temporär alle Vermögenswerte übertragen (inklusive Ausnutzung des Dispokredits für alle Bankkonten, versteht sich!). Sobald die Gefahr vorüber ist, geht das dann wieder zurück, minus einer klitzekleinen Servicegebühr…

    Im Internet gibt es diverse Dienste, welche anbieten eine Mail Adresse auf Existenz bzw. Zustellbarkeit zu prüfen. Wie kann ich im MTA, hier Postfix, dies für einen eigenen Dienst unterbinden?

    Wenn du an deinem Haus das Klingelschild abbaust weiß auch niemand mehr dass du da wohnst, Post kriegste aber halt auch keine mehr…

    Um bei dieser Analogie zu bleiben: Die einzige Möglichkeit im Clearnet – ohne dass ich es empfehlen würde oder in diesem Fall für sonderlich praktikabel hielte! – wäre, ggf. zwar ein Klingelschild anzubringen (d.h. einen MX-DNS-Eintrag bekanntzumachen[*]), aber die Klingel abzuschalten (nicht auf Anfragen reagieren), sodass der Klin­geln­de wissen muss, wie er sie anschaltet (über ein der Allgemeinheit nicht bekanntes Signal), oder die Klingel nur für von vornherein bekannte Klin­geln­de funktioniert (IP-basierte Freischaltung). Diese Taktik wird normalerweise am ehesten für den SSH-Port 22 angewendet, kann jedoch auch für Port 25 (MTA-zu-MTA-Kommunikation) ein­ge­setzt werden. Das Hilfswerkzeug der Wahl für die Identifizierung durch ein zuvor ausgehandeltes Signal (durch vorheriges "Anklopfen" an TCP-/UDP-Ports) ist knock.

    In der Praxis besteht das Problem darin, dass Nutzer dieses Anklopfen vor Versendung von E-Mails bewerkstelligen müssen, was kein bekannter MTA von Haus aus kann; außerdem setzt man sich hier über RFC2142 hinweg, wonach bestimmte Empfängeradressen immer "bedient" werden sollten.


    [*] Theoretisch könnte man natürlich auch versuchen, E-Mails an Port 25 einer nicht weiter namentlich identifizierten IPv4-/IPv6-Adresse zuzustellen, aber auch hier sind auf Empfängerseite entsprechende Vorkehrungen zu treffen, um nicht die Postfix-Standardantwort "501 5.1.3 Bad recipient address syntax" auszulösen. Der Verzicht auf ei­ne registrierte Domäne umgeht natürlich damit verbundene Vorschriften bzgl. einer Erreichbarkeit der Ansprechpartner. In der Praxis würde man bei gewünschter Ano­ny­mi­tät und entsprechendem Willen aller Beteiligten allerdings E-Mails über das Darknet austauschen (siehe beispielsweise hier), und die Überprüfung existierender Emp­fän­ger über die obengenannten diversen Dienste wird dadurch zumeist ausgehebelt.

    Neben "Indexierung zulässig?" auf dem vorletzten Screenshot ist ein "(I)" – da müsste doch der Grund stehen?

    Wenn die Sitemap nicht gefunden wird (aber vorliegt/erstellt werden kann), kann man sie manuell "pushen" via "Ping-Tool", siehe hier. Mit etwas Glück bekommt man dort eine abweichende/detailliertere Fehlermeldung zurück.