Posts by possi

    Guten Morgen,


    ich habe heute früh eine Phishing-Mail erhalten die anscheinend auf Netcup-Kunden zielgerichtet ist, und mich daher fast überzeugt hätte den Link anzuklicken.


    Nicht nur ist die E-Mail durch rspamd und Thunderbird Junk-Filter geschlüpft, sondern betrifft tatsächlich meine bei Netcup gehosteten Server.

    Gerade bei E-Mails zu Domain-Verlängerungen und SSL-Zertifikaten bin ich es durchaus gewöhnt, dass E-Mails an den Postmaster ohne konkrete Anrede gehen.


    Hier die E-Mail als Warnung für andere:

    pasted-from-clipboard.png


    Zwar gibt es einige Hinweise die diese E-Mail anzweifeln lassen, aber ich mag nicht ausschließen, dass ich nicht in einem unaufmerksamen Moment auf den Link geklickt hätte, wenn nicht all meine Domains bei einem anderen Anbieter gemanaged würden.


    Daher nochmal an alle die Warnung: Im Zweifelsfall nicht auf Links klicken, sondern bekannte Webseiten lieber selbst ansteuern!

    In der domain-konfiguration für domain.com, musst du beim host domain.com nicht mehr mit angeben, der SRV-Eintrag bei domain.com wäre also nur noch:
    _ts3._udp SRV 1 1 64323 domain.com


    Denn der Eintrag den du aktuell angegeben hast, müsstest du aktuell mit "_ts3._udp.domain.com.domain.com" abfragen, bzw. als adresse im TS müsste "domain.com.domain.com" eingegeben werden.

    Du kannst als MX-Eintrag jede andere Domain (auch eine dyndns domain) eintragen. Technisch würde das funktionieren.
    Mails damit zu empfangen ist auch kein Problem. Jedoch wenn du versuchst von dem Gerät dann E-Mails zu versenden wirst du Probleme mit den Spam-Filtern bekommen.
    Die haben nämlich allgemein etwas gegen E-Mails die:
    1. von Dial-Up IP-Adressen verschickt werden
    2. deren Absender-IP vom reverse lookup (rDNS) nicht zu der @domain deiner E-Mail-Adresse passen.

    /etc/cron.d/froxlor restart ist unfug. Die Datei ist kein ausführbares script.


    Viel mehr willst du vermutlich die Datei /etc/cron.d/froxlor bearbeiten und das: */5 am Anfang der letzten Zeile durch ein einfaches * ersetzen.

    == ist ein vergleich, keine Zuweisung.


    Die Zeile heißt nur: "Ist eingeloggt?", wobei das Ergebnis dieser Frage nicht verwendet wird.


    Ich _vermute_ (ohne hier alles verfolgt zu haben) du willst: <?php $_SESSION['is_logged_in'] = 1; ?>

    Vermutlich liefert dein Webserver einen anderen Content-Type charset aus, als den in den Dateien verwendeten. (Wenn der webserver einen Charset mit den HTTP-Headern ausliefert, überschreibt dies auch im html vorhandene meta-charset angaben).


    Du solltest also mal bei google schauen, wie du in der .htaccess den Content-Type (mit charset-angabe) für deine dateien definieren kannst.

    Also bei mir kommt es auch hin und wieder vor, das SSH "einfriert" (sowohl putty als auch openssh client in cygwin bash). Dies betrifft aber auch nicht nur netcup server, sondern kommt auch schon mal bei 1und1 und anderen vor. Und es steht in keinem zusammenhang mit top.
    Mittels screen stell ich dann jedoch fest, dass dies nur die eine Richtung betrifft, die Eingaben kommen noch beim server an, lediglich die antworten kommen nicht mehr zurück. Da dies aber sehr sporadisch auftritt, und ich wichtige sachen sowieso immer im screen mach, ist es nicht all zu dramatisch.


    PS: Oft liegt es auch garnicht an SSH, sondern man hat einfach versehentlich die bash pausiert, dies kann durch drücken der Rollen-Taste, oder durch die Tastenkombination strg+s passieren. Das lässt sich ganz einfach durch betätigen von strg+q wieder beheben.


    PS2: top kann man einfach mit q statt strg+c beenden, da ist etwas freundlicher.

    Es ist auch schon vorgekommen, das die DNS-Server einen (mich) ausgesperrt haben.
    Probier einfach mal:
    nslookup 157.55.2.101
    (das ist eine der IPs aus deinem Log) Bei mir kann die (mit den selben Nameservern) aufgelöst werden: dub0-omc4-s26.dub0.hotmail.com

    Das relevante ist hier das "Client host rejected: cannot find your hostname".


    Dein Server kann die Hostnames zu den IP-Adressen nicht finden. Vermutlich sind die Einträge in deiner /etc/resolv.conf falsch. Die richtigen Einträge findest du im Wiki.

    Solang du nur den besitzer änders, bleibt die gruppe unverändert. Der bisherige Besitzer wird aber natürlich überschrieben.
    aus www-data:www-data würde also xxx:www-data


    (die gruppe kann man equivalent mit chgrp statt chown ändern;
    Je nach verwendetem Kernel und Dateisystem kann man auch erweitere ACL verwenden, die es erlaubt zusätzliche personen oder gruppenbezogene berechtigungen zu definieren)