Beiträge von tbc233

    Ich hatte jetzt grad eine andere Idee:


    Wie wärs, wenn man auf die Ausagabe im Header verzichtet und stattdessen den Skriptnamen vollständig ins Mail-Log schreibt? Dann wäre denen, die auf der Suche nach einen Spam-Script sind schonmal geholfen und die Daten der Skriptpfad würde nicht rund um den Erdball verschickt werden.


    Paralell dazu wärs dann spitze, wenn man die qmail-msg Nummer (zb. 169889368) in den Mailhead reinkriegen würde, dann könnte man das log nach der Nummer greppen und hätte den Skriptnamen.

    Ich find die Idee prinzipiell eh prima. Mich stört nur die Tatsache, dass der gesamte Pfad preisgegeben wird. Vielleicht kann man das irgendwie anders lösen...

    Mir ist eben zufällig aufgefallen, dass (und das dürfte relativ neu sein) bei Mails die zb. via php-skript generiert werden sich folgende Zeile im Header befindet:


    X-SCRIPT-FILENAME: /home/vollständer-pfad-zum-skript


    Ich geb zu: Das ganze hat seinen Reiz, wenn es mal darum geht ein (zb. zum Spammen) kompromitiertes Skript zu identifizieren.
    Aber so im täglichen Betrieb halte ich es eigentlich eher für eine Sicherheitslücke. Find ich gar nicht gut, dass jeder, der in den Head eines (z.b.) Newslettr schaut, den kompletten Pfad zu dem Skript sieht.


    Weiß jemand, an welcher Stelle der Eintrag generiert wird bzw. wie man ihn abstellen kann?
    Oder könnt ich mri das selbst mit irgendeiner Einstellung eingehandelt habe und pd-admin bzw. die Standardumgebung kann gar nichts dafür? Hab auf jeden Fall grade ältere generierte Mails rausgesucht (04/2008), da war es noch nicht.

    per Default werden Mails an Subdomains automatisch an die Hauptdomain weitergeleitet. Also beispiel@subdomain.domain geht automatisch an beispiel@domain.


    Wenn das Verhalten nicht gewünscht ist, empfiehlt es sich, die Subdomain als eigene Domain anzulegen (dazu die Domain vorher in den erlaubten Domainendungen in der Serverkonfiguration eintragen).

    aus meiner sicht haben die beiden & zu beginn der zeilte nichts verloren. damit schiesst du den softlimit gleich mal ab. lass sie mal weg (nur die am anfang, die anderen sind in ordnung)

    Ich hab ein wenig herumgesucht, auf der Basis des Verdachts, dass das Skript bei dir nicht mit der bash ausgeführt wird (wegen der Fehlermeldung, dass er mit dem function Befehl nichts anfangen kann, der ja bash-typisch ist).


    Inspiriert durch http://blog.turbulentsky.com/2…unning-sh-scripts-on.html kann ich nur hoffen (der Blogeintrag ist ein 3/4 Jahr alt), dass das bei Dir die selbe Ursache ist.


    Wenn dem so ist, liegt es daran, dass bei Ubunto /bin/sh kein Symlink auf die bash ist sondern auf dash.


    Prüf das mal mit ls -l /bin/sh
    Sollte der Link nicht auf die bash zeigen, dann hol das mit ln -sf /bin/bash /bin/sh nach und versuch es nochmal.

    sofern du die kostenlose variante bis 10 domains nutzt, muss es dich nicht kümmern, was in der datei steht.


    wenn du die kommerzielle variante einsetzt muss es dich ebenfalls nicht kümmern, in diesem Fall lässt Du Deine IP freischalten und führst /opt/pdadmin/bin/get_license.sh aus.

    Achja, falls Du feststellst, dass Deine Queue voller Müll ist, kannst Du sie wie folgt relativ rasch entleeren:


    cd /var/qmail/queue
    find intd todo local remote mess info bounce -type f -print |xargs rm -v


    [SIZE=7]Suchfunktion Tags: qmail queue leeren[/SIZE]

    naja, bei so einer Anzahl an Mails in der Queue ist so eine hohe Auslieferungszeit schon denkbar.


    Es wird Dir nicht ausbleiben, die queue und Dein maillog zu durchforsten, um herauszufinden, wo die Mails herkommen. qmail loggt dankenswerterweise die UID des Versenders, was bei aktiviertem cgiwrap einen Rückschluss auf den Account zulässt (falls es über Webskripte eingeschleuste Spam-Mails sind).

    Möglicherweise hat euch jemand (zb. über eine Skript Lücke) die Queue mit Spam vollgeräumt.


    Was sagt denn /var/qmail/bin/qmail-qstat?


    Wenn da ein ungewöhnlich hoher Wert rauskommt (> 1.000) sollte man das mal in diese Richtung einer Kontrolle unterziehen.

    die mysql zugangsdaten des vadmin users können einem meiner Erfahrung nach an drei Stellen auf den Kopf fallen:


    /usr/local/pd-admin2/bin/checksmtppasswd (ersten paar Zeilen)
    /var/qmail/vadmin-check.pl
    und natürlich: /opt/pdadmin/etc/pdadmin.conf


    Kontrollier mal, ob überall die korrekten drin stehen.


    Das die ersten beiden Dateien sich die Mysql Zugangsdaten nicht aus der pdadmin.conf holen, sollte mal korrigiert werden, das stellt sich immer wieder als Fehlerquelle raus.

    Zitat

    er kann doch eigentlich synronisieren, denn der alte Server läuft doch problemlos (und die Rechte stimmen auch). Denke mal das sollte funktionieren. - oder sehe ich was falsch?


    nochmal auf die gefahr hin, dass ich hier was falsch verstehe und mich zum Idioten mache:


    die grundsätzliche syntax ist rsync parameter quelle ziel


    wenn du also nun so wie von Stella beschrieben auf dem aktuellen (= der Server der läuft, quasi der "alte") den Befehl wie von Stella notiert eintippst, dann synchonisierst du das Chaos dass du momentan auf dem zukünftigen Server beisammen hast auf den laufenden. Und das kann nicht in deinem Sinne sein.

    Zitat

    rsync -atpz --progress --exclude ’lost+found’ -e ssh IP_NEUER_SERVER:/home/ .;


    Ich kann mich täsuchen (wenig geschlafen die letzten Tage), aber ich könnt schwören, dass dieser Befehl den neuen Server auf den aktuellen synchronisiert, was heißen würde, er kopiert sich das jetzige Berechtigungschaos auf den laufenden Server.


    Zudem würde ich nach dieser Vorgeschichte ein --delete dranhängen. das ssh kann man sich sparen, das wird automatisch angewendet. das -t braucht man auch nicht, das ist in -a enthalten. Ebenso das -p.


    Ich würds so machen:


    auf dem aktuellen (respektive "alten" Server):
    rsync -av --progress --delete --numeric-ids /home/ NEUER_SERVER:/home/

    Zitat


    davor wurde der alte Server per SSH gemountet und dann ab - rüber damit (cp)


    ist klar, dann musste es so kommen.


    ist auch durchaus möglich, dass das bei den anderem Problem (alte IP in den generierten conf's und so) eine Rolle gespielt hat. Halte ich sogar für sehr wahrscheinlich.

    die dateien gehören alle root - das ist fast noch schlimmer als falsche uids (die zur anzeige von ziffern führen würden). Wie hast Du die Daten denn rüber befördert? Ich würde dringend die Strategie wechseln, sonst verbringst Du Tage damit, alles neu zu berechtigen (du musst ja auch noch dafür sorgen, dass jedes einzige php Skript dem jeweiligen Account-user gehört, sonst zickt der cgi-wrapper.


    wenn der alte server eh noch läuft, würd ich das ganze home verzeichnis mittels rsync auf den neuen rüber syncen. verwende dabei -a, sorgt dafür, dass alle rechte, uids und guids erhalten bleiben.