Beiträge von tomcat

    Das hatte ich auch schon mal gewagt, aber scheinbar gab/gibts es einige PA-eigene Scripte die nach /usr/bin/perl "shebangen".


    Ich erinnere mich z.B. vage, dass qmail nicht einwandfrei lief, nachdem ich den Perl Link wie Du es beschrieben hast, entfernt hatte.


    Dummerweise liefert Herr Bradler seine Werke ja nur noch im verschlüsselten Zustand, so dass man das nicht mal eben anpassen könnte und sei es nur zu Versuchszwecken.


    Ist manchmal wirklich zum Haare raufen.


    Gruß
    Tomcat

    Hallo,


    die (ehemailigen?) Inkompatibilitäten von Debian-Perl und PA-Perl sind ja nun hinreichend bekannt und waren ja oft Anlass zu den verschiedensten Workarounds hier im Forum.


    Aber gibt es inzwischen eine saubere Möglichkeit, PA mit Lenny zu betreiben? Ich meine, ohne ständig zwischen den Perlinterpretern umschalten zu müssen.


    Betreibt jemand Lenny auf seinen Produktivsystemen? Gibt es Einschränkungen? Wie ist da der aktuelle Stand per 17.09.09?



    Gruß
    Tomcat

    Hallo,


    einer unserer Server wird gerade mit massiver Maillast gequält und bisher waren alle Versuche die Ursache zu finden, ergebnislos.


    Allerdings habe ich einige Einträge in der mail.info entdeckt, die mich stutzig machen. Was bedeuten diese Greylisting Einträge:


    Code
    1. bypassed: authenticted user church


    Abgesehen vom Schreibfehler (es sollte wohl authenticated statt authenticted heissen) habe ich nichts dazu gefunden.


    Bedeutet dass, dass bei dieser Einlieferung Greylisting nicht ausgeführt wurde, weil der User sich per smtp-auth angemeldet hat?


    Gruß
    Tomcat

    Hallo,


    SE 0.121, PA 4.08 in der Stadardkonfiguration.


    Auf einem unserer Server lasst sich per SMTP AUTH keine Email mehr an den Empfänger(-Server) zustellen:


    [php]550 sorry, user unknown[/php]


    was aber Unsinn ist - natürlich existiert die Empfänger-Adresse und zickt auch nicht rum, wie eine Telnet-Session vom Senderserver an den Empfängerserver beweist:


    [php]
    s04:/var/log# telnet mx01.domain.net 25
    Trying 195.50.170.XXX...
    Connected to mx01.domain.net.
    Escape character is '^]'.
    220 server03.domain.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Thu, 29 Jan 2009 08:38:36 +0100
    helo s04.example.de
    250 server03.domain.local Hello [87.106.8.XXX]
    mail from: info@absenderdomain.de
    250 2.1.0 info@absenderdomain.de....Sender OK
    rcpt to: user@empfangsdomain.net
    250 2.1.5 user@empfangsdomain.net
    data
    354 Start mail input; end with <CRLF>.<CRLF>
    subject: smtp-test


    body
    .
    250 2.6.0 <SERVER03DreBBsQwY6Y000000bf@server03.domain.local> Queued mail for delivery
    quit
    221 2.0.0 server03.domain.local Service closing transmission channel
    Connection closed by foreign host.
    s04:/var/log#
    [/php]


    Das der Empfänger einen Exchange-Server betreibt dürfte belanglos sein. Die Logs des Senders sind - für mich - wenig aufschlussreich:


    [php]
    Jan 29 09:01:21 s04 smtpd: 1233216081.357830 tcpserver: status: 1/40
    Jan 29 09:01:21 s04 smtpd: 1233216081.357869 tcpserver: pid 30876 from 95.88.171.XX
    Jan 29 09:01:21 s04 smtpd: 1233216081.362759 tcpserver: ok 30876 s04.absenderserver.de:87.106.8.XXX:25 :95.88.171.XX::51959
    Jan 29 09:01:21 s04 qmail-smtpd: qmail-smtpd/VC started
    Jan 29 09:01:21 s04 pdadmin[30877]: User infopala: smtp-auth login from 95.88.171.XXX
    Jan 29 09:01:21 s04 qmail-smtpd: rcpt to: <user@empfangsdomain.net> rejected: 550 sorry, user unknown
    Jan 29 09:01:25 s04 smtpd: 1233216085.434539 tcpserver: end 30876 status 0
    Jan 29 09:01:25 s04 smtpd: 1233216085.434579 tcpserver: status: 0/40
    [/php]


    Wenn nun aber der Empfäger einen Fehler produzieren würde, würde dies die Telnet-Session auch betreffenn - tut sie aber nicht. Also wird der Fehler beim Sender und damit beim Pd-Admin Server liegen. Aber ich komm nicht weiter und weiss jetzt ehrlich gesagt auch nicht, wo ich suchen muss.


    Hat jemand von Euch eine Idee?
    Gruß
    Tomcat

    PA 4.06 SE 0.115


    Hallo,


    beim dem Umzug diverser Kundenaccounts von einem Server auf den anderen habe ich offensichtlich einen mir unbekannten Fehler gemacht.
    Unter anderem habe ich einfach das komplette /home Verzeichnis übertragen. Vorher natürlich brav alle Gruppen und User angelegt. Im Grunde läuft alles einwandfrei, nur Sqirrelmail mag mich nicht mehr.


    Beim Anmelden an Sqirrel kommt grundsätzlich nur noch folgende lapidare Fehlermeldung:


    Code
    1. FEHLER: Verbindung wurde vom IMAP-Server abgebrochen


    Ich habe keine Ahnung wo ich anfangen soll zu suchen, die üblichen Logs waren auch nicht aussagekräftig.


    Also habe ich mir gedacht, erzwingst Du noch einmal ein vollständiges SE-Update mittels der Option -s2


    Das läuft sauber durch, bis es ganz am am Ende zu folgendem Simscan Fehler kommt:



    Im Quelltext der se-update.sh steht folgendes:



    Also habe ich von Hand /var/qmail/bin/simscanmk -g _und_ /usr/local/pd-admin2/qmail/bin/simscanmk -g ausgeführt, was einwandfrei durchlief. Nun weiß ich nicht, woher diese connect() Fehler kommen. Und warum Sqirrelmail nicht mehr will, weiß ich auch nicht. Ich weiß nicht mal, ob dieser Fehler beim se-update überhaupt in direktem Zusammenhang mit dem Sqirrelmail-Fehler steht. Ich steh wie der Ochs vorm Berg.


    Hat jemand ne Idee?

    PA 4.06 SE 0.115


    Hallo,


    es hatten bereits einige andere diesen Fehler gepostet, aber immer im Zusammenhang mit nicht vorhandenen vhosts. Der Fehler tritt aber auch auf, wenn der vhost vorhanden _ist_.


    Folgende Situation:
    1. Endkundendomain xyz.eu als Hauptdomain eingetragen


    2. Endkundendomain billing.xyz.eu als Hauptdomain eingetragen (erlaubte TLDs um xyz.eu erweitert)


    3. Endkundendomain order.xyz.eu als Unterdomain von billing.xyz.eu eingetragen (nicht als Co-Domain, sondern als eigenständige Domain)


    4. billing.xyz.eu und order.xyz.eu haben eigene IPs verpasst bekommen.


    Beim Versuch für die Domains jeweils ein Cert zu installieren, kommt besagte _falsche_ Fehlermeldung.


    Ich habe mir nun geholfen, indem ich das Cert von Hand installiert und die vadmin DB ebenfalls von Hand erweitert habe, was auch einwandfrei funktioniert. Aber das dürfte wohl nicht im Sinne des Erfinders sein.


    Gruß
    Tomcat

    Hallo,


    seit ich die SE auf 0.110 und PA auf 4.06 aktualisiert habe, tauchen auf allen Servern folgende Fehlermeldungen haufenweise im syslog auf:


    Code
    1. May 17 15:11:25 s004 smtpd: 1211029885.758450 Use of uninitialized value in pattern match (m//) at /opt/pdadmin/bin/smtp_greylist.pl line 182, <LOADAVG> line 1.
    2. May 17 15:11:25 s004 smtpd: 1211029885.758561 Use of uninitialized value in pattern match (m//) at /opt/pdadmin/bin/smtp_greylist.pl line 182, <LOADAVG> line 1.
    3. May 17 15:11:25 s004 smtpd: 1211029885.758621 Use of uninitialized value in pattern match (m//) at /opt/pdadmin/bin/smtp_greylist.pl line 182, <LOADAVG> line 1.
    4. May 17 15:11:25 s004 smtpd: 1211029885.758678 Use of uninitialized value in pattern match (m//) at /opt/pdadmin/bin/smtp_greylist.pl line 182, <LOADAVG> line 1.
    5. May 17 15:11:25 s004 smtpd: 1211029885.758736 Use of uninitialized value in pattern match (m//) at /opt/pdadmin/bin/smtp_greylist.pl line 182, <LOADAVG> line 1.
    6. May 17 15:11:25 s004 smtpd: 1211029885.758794 Use of uninitialized value in pattern match (m//) at /opt/pdadmin/bin/smtp_greylist.pl line 182, <LOADAVG> line 1.


    Scheint wohl ein Fehler in der smtp_greylist.pl zu sein, oder?


    EDIT by Twilo: Thema zusammengefügt
    das nächste mal bitte die Suche verwenden

    Hallo,


    Neuinstallation SE 0.110 und PA 4.06


    Ich glaube, da liegt ein Fehler bei der Rechtevergabe von /service vor. Oder ist das auch wieder kein Bug und so gewollt?





    Wie wären die Besitzer/Gruppen denn richtig - doch vermutlich root, oder?

    Hallo,


    ich habe jetzt mal die Kundeneigene php.ini deaktiviert, aber der Fehler ist immer noch. Daraufhin habe ich nach der gemeldeten pdo.so gesucht - und nada. Die Datei existiert nicht. Insofern ist die Fehlermeldung nicht weiter verwunderlich. PDO-Support ist einkompiliert aber die .so Datei nicht vorhanden. Da ich diese Datei nicht gelöscht habe und den Server vor einigen Wochen erst frisch aufgesetzt habe, kann es ja eigentlich nur ein Bug in der Standardauslieferung der SE sein. Falls nicht:
    Was tun? Installation der neuesten SE blieb erfolglos.


    Keine(r) 'ne Idee?



    Edit: Habe mich nochmal vergewissert, das pdo wirklich statisch mit einkompiliert wurde und nicht dynamisch geladen wird:


    In diesem Zusammenhang macht mich stutzig, warum nach einer pdo.so gesucht wird, wenn es doch statisch einkompiliert ist ... Seltsam..

    Hallo,


    die abgebrochene Internetverbindung sollte unproblematisch sein, da alle wichtigen Updates zu Anfang der Updateroutine geladen werden. Ausgenommen die aktuellen Virendefinitionen, die werden am Ende geladen, was aber nicht schlimm ist, da dieser Vorgang per Cronjob regelmäßig durchgeführt wird. Zumindest soweit mein Verständnis des SE-Updates.



    Die Email die Du angebenen hast, wurde von dem Server dxb-b112094.alshamil.net.ae verschickt.
    Scheinbar ein gefälschter Absender von rammyland.de
    Nichts schlimmes, bzw. ungewöhnliches ;-)

    So, nun war ich doch neugierig und habe fix auf 0.110 aktualisiert. Man möge mich steinigen, aber der Fehler ist dennoch vorhanden.


    Was ist anders als in der Standardinstall:
    1. Der Server ist auf PHP5 als Standard eingestellt.
    2. Eine Kopie von /usr/local/pd-admin2/lib/php.ini liegt unter /home/kundenaccount/php.ini


    Das ist alles. Keine PDO-Einstellungen in den php.ini's


    Der Fehler kann doch nicht nur bei uns so sein??

    Hallo Herr Bradler,


    Sie haben recht, da steht dann tatsächlich eine brauchbare Hilfe drin.
    Ich arbeite seit einigen Jahren mit PA und habe diesen Button an dieser Stelle noch nie wahrgenommen - OK, mein Problem, bin ich halt blind. Viele, viele unserer Endkunden aber scheinbar auch und jedesmal mussten wir Support dafür leisten um den Kunden zu erklären, wie sie Cronjobs anlegen. Vielleicht können Sie sich dennoch eines Tages dazu hinreißen lassen, diese wichtigen Dinge in die Endkundendokumentaion mit aufzunehmen. Mal ehrlich Herr Bradler, so schlimm kann das doch gar nicht sein, oder?

    Das steht bei mir in der Online-Hilfe zu Cronjobs (PA 4.03):


    Hallo Herr Bradler,


    mit Verlaub, aber abgesehen davon, dass die Erklärung zu Cronjobs genauso in die Endkundendokumentation gehört wie die Erklärung zu Subdomains oder den anderen Dingen, die da eben drin sind, ist die Online-Hilfe zu den Cronjobs wirklich absolut nichtssagend. Sie ist so überflüssig wie nur irgendwas und hätte von Ihnen auch ganz weggelassen werden können. Praktisch kein ungeübter Endkunde kann damit was anfangen. Führen Sie doch bitte zumindest 2 Beispiele auf - einen imaginären Scriptaufruf mit Parametern über das Dateisystem und einmal das gleiche über den Aufruf per HTTP. Beides natürlich mit beispielhaften Zeitangaben. So ist das keine Hilfe, sondern, bei allem Respekt, ein Scherz.

    Hmmm,


    danke für die erste Vorauskunft.
    Server läuft grundsätzlich mit PHP5, Kunde hat eine eigene PHP.ini unter /home/account/php.ini - diese eigene php.ini (und auch die globale) ist frei von irgendwelchen PDO Einstellungen, davon habe ich mich bereits selbst überzeugt.


    Ich werde heute Abend, neben dem SE Update, mal gucken, ob es vielleicht mit dieser Konstellation zu tun hat.

    Hallo Herr Bradler,

    Zitat

    Original von Daniel Bradler
    Haben Sie konkrete Verbesserungsvorschläge für uns? Welche Informationen haben Sie als Einsteiger besonders vermisst?


    an welcher Stelle der Endkundendokumentation werden die Cronjobs mit ihren Möglichkeiten (z.B. direkter Aufruf und Aufruf über HTTP) erklärt?