Posts by michi

    Danke sim4000 für die Recherche. ;-)


    Konnte mir auch nicht vorstellen, daß die "aktuelle" Version von lenny ein Problem hat (klang in der mail so auch nicht an).
    Bei mir ebenso die "1.3.1-17lenny4".


    Im Log bei mir morgens so zwischen cal. 5:30 und 6:30 Uhr diverse Verbindungsversuche zu proftpd bis die max-connections aufgebraucht waren. Danach dann jeweils ein Neustart durch monit (Weil monit nicht mehr test-connecten konnte).

    Netcup zieht doch häufiger vserver auf andere Hosts/Nodes um.


    Normalerweise zwar wegen starkem traffic aber vielleicht könnte man in deinem Fall das auch mal außer der Reihe machen (aber auf einen "normal" ausgelasteten Node).

    Im Grunde müßte man Deinen vServer mal auf einen anderen "Node" umziehen lassen.


    Ich habe "nicht nachvollziehbaren/nicht reproduzierbaren" Fehler zuweilen auf (ganz anderen) Systemen mit defekter Hardware bzw. "nicht ganz passenden" HW-Treibern kennengelernt. Dann aber meist in Verbindung mit erhöhter I/O Tätigkeit des Gesamtsystemes.

    Prüfe doch mal die Log-Files Deines Servers.


    Ich gehe davon aus, daß Du hier einen vServer betreibst. Dann solltest Du Dich in dem Thema ja soweit auskennen. ;-)


    Auf Client-Seite kannst Du z.B. einen Packet/Monitor Sniffer einsetzen, um Dir den POP3-Verkehr anzuschauen.


    Sollte Dein Server für zu versendende Dateien (SMTP) kein Passwort/Anmeldung benötigen, dann betreibst Du wohl ein Open Relay. Das wäre eine ganz schlechte Idee.

    Bei mysqldump würde ich sagen: nein


    Im unwahrscheinlichen Falle des Einsatzes von mysqlcheck könnte das schon sein. Dessen Anwendung sollte aber auch nicht der Regelfall sein, zumal es nur auf MyIsam anwendbar ist.


    Hast Du denn bereits herausgefunden wobei MySQL absemmelt? Ggf. kann man ja die Cronjobs mal für eine Weile aussperren.


    Zur Socket/Neustartproblematik hast Du Dir ja schon etwas gebastelt. Ansonsten wäre ggf. eine Postfix-Config mit Zugriff über localhost/127.0.0.1 eine temporäre Alternative?


    Hast Du das General Query Log aktiviert? Was passiert, bevor MySQL absemmelt?

    Was man machen kann ist die /home/<username>/.bash_history read-only zu schalten (400).


    Das ist zwar ggf. ein Komfort-Verlust, vermeidet aber, daß irrtümlich eingegebene sicherheitsrelevante Daten (z.B. Passwörter) dort im Klartext zu finden sind. Kein sehr großes Risiko, da ja eigentlich nur genau dieser User das lesen darf, aber naja....


    Ansonsten ist sämtliche Standardsoftware ein typisches Einfalltor. Also z.B. CMS und Forensoftware. Insbesondere, wenn diese nicht mehr aktuell ist und Sicherheitslücken bekannt sind.


    Daher sämtliche Standard-Software, wenn immer möglich über die Distribution installieren. Das gilt z.B. auch für Perl-Module (deren Installation per CPAN natürlich auch recht bequem ist, aber nicht den Update-Mechanismen unterliegt). Ein Problem stellen also auch Zusatzmodule für Standard-Software dar, sofern diese keinen eigenen Update-Mechanismus mitbringt.


    In Sachen SPAM ist natürlich die Konfiguration des Mail-Servers relevant. Ein Open-Relay schafft da keine Freunde. Aber auch sämtliche Anwendungen mit Formularen und E-Mail Versende-Funktion (z.B. Kontaktformulare, Bestätigungsmails, Forensoftware) sind anfällig, um ggf. für SPAM-Zwecke benutzt zu werden. Auch Stellen an denen Anwender eigene Links bereitstellen können (z.B. Gästebücher) sind problematisch, da hier ggf. auf Malware verlinkt werden kann.

    Also Ricky,
    das mit den Sonderzeichen ist schon seltsam. Schau Dir das auf dem Server am besten mal mit nem Editor an und schmeiß die Zeichen raus.


    Wie führst Du das Perl-Script eigentlich aus? Wirklich einfach nur aus der Shell (z.B. bash) per SSH? (PuTTY etc.)
    Mir kommt die Ausgabe ausgesprochen seltsam vor.



    Ich für meinen Teil verwende unter SSH gerne den Midnight-Commander (quasi Norton/Speed/Total-Commander nur auf Linux). Da liegt auf F4 der Editor (F4), welcher mit altbekannten Funktionstasten arbeitet. Scripte lassen sich per "Enter" ausführen.


    Im Zweifelsfall kann man in dessen Viewer (F3) auch auf "Hex" umschalten und mal schauen, ob die Zeilenumbrüche korrekt sind. Sieht man aber spätestens im Editor meist.


    Das Ding ist jetzt natürlich nicht Voraussetzung.

    Aha, die Antwort kam als Edit.
    Was steht denn im shebang und dort, wo das hinweist steht da auch ein Perl?
    beispiel
    #!/usr/bin/perl


    Test
    "ls /usr/bin/perl"
    Ausgabe --> "/usr/bin/perl"
    oder "No such file or ..."


    im letzteren Fall wäre (fast unglaublich) perl nicht installiert.

    Script hat Ausführungsrechte?
    chmod 755 test.pl


    Shebang ist korrekt? (#! am Scriptstart)
    Auch (insbesondere in der ersten Zeile) kein CRLF anstatt korrekterweise LF (geht beim FTP-Transfer automatisch korrekt, sofern ASCII-Transfer gewählt wird)?


    Interaktive Ausführung klappt? (Sofern SSH Zugang)

    Das ist wie mit den Leuten, die Ihren Führerschein für 1 Monat abgeben müssen:
    "Ich war doch nur 1 km/h zu schnell!", "Nein, Du warst 31km/h zu schnell!"


    Die 32MB werden nicht von apache benötigt sondern von php und zwar in der session für das wordpress-script. Die 120kb waren nur der Tropfen, der den Bembel zum überlaufen gebracht hat.


    Die Frage stellt sich, wieso die php-Speichererhöhung auf max. 128MB nicht durchgedrungen ist. Wenn der apache neu gestartet wurde und die config-Änderung korrekt in der richtigen Datei stattfand, dann käme m.E. am ehesten in Frage, daß der php-Speicher in einer anderen config-Datei begrenzt wurde.


    Die Fehlermeldung deutet auch nicht auf einen vollen Speicher samt Swap hin, aber wer weiss...

    Es gibt noch die theoretische Möglichkeit, daß das php Memory-Limit in der /etc/apache2/httpd.conf (und ggf. eingebunden Konfigurationsdateien, vhost ...) oder gar in der .htaccess definiert wurde.


    .htaccess-Dateien stehen direkt in den Verzeichnissen des Webspace. (Also bei den php Dateien)


    Dort mußt Du dieses Limit aber nicht eintragen, sondern nur falls es dort steht, entsprechend erhöhen.


    Siehe:
    http://www.php.net/manual/de/configuration.changes.php

    Ich verwende Outlook 2003. Das Outlook muß in den Regeln ein Script ausführen können. Outlook XP kann das meines Wissens bereits auch. Bei 2000 geht das glaube ich noch nicht. Da läßt sich über anderen Code vermutlich auch etwas machen.


    Tja und die neueren Versionen sollten das ja eigentlich auch können. Vielleicht gibt es bei dem Sicherheitsgemäkel noch neue Variationen.


    Dazu verwendet das Script noch "Microsoft VBScript Regular Expressions 5.5" (unter Extras -> Verweise in der VBA-IDE verknüpfen). Eine ältere Version müßte davon wohl auch klappen.



    Wer es ausprobieren möchte:
    Anhang entpacken. In Outlook mit Alt+F11 die VBA-IDE öffnen und per Import oder Drag & Drop die (Text-)Dateien übernehmen.


    Je nach Version und Sicherheitseinstellung, muß dieser Code evtl. "selbst-signiert" werden. Siehe z.b. hier: http://www.howto-outlook.com/howto/selfcert.htm


    Die Anleitung zur weiteren Konfiguration steht in der *.bas Datei (in holperigem Englisch).

    Moin,
    ich habe hier seit kürzerem ein VBA-Script (für Outlook) in Betrieb, welches Mails, die mir der eine oder andere Server schickt betrachtet und die "unauffälligen" in einen Ordner wegsortiert.


    Beurteilt werden Mails dabei über Kopien früherer Mails, welche (im Body) mit Regulären Ausdrücken ergänzt werden dürfen. Diese "Regeln" werden in Textdateien gespeichert.


    Ein Beispiel wäre z.B. eine Meldung von einem Backup, das mit 0 Fehlern durchgelaufen ist.


    Das Ganze ist natürlich nicht gerade Plug & Play. Man sollte schon lesen können, VBA-Scripte in Outlook zum Laufen bekommen und wissen was ein Regulärer Ausdruck ist.



    Die Frage ist, ehe ich mir Mühe mache:


    Besteht daran überhaupt Interesse?
    Vielleicht bin ich ja der Einzige hier, der Outlook nutzt. (Bitte jetzt keine Mail-Client Diskussion hier lostreten)