Beiträge von suppenuser

    Wenn Du (wie in diesem Fall) keine Ahnung hast, ist das eigentlich ein Grund, sich in Zurückhaltung zu üben!


    Wie im Bezugsthread geschrieben, läuft die Verwaltung der php.ini ausschließlich über LiveConfig. Und damit ist die Ursache tendenziell auch bei LiveConfig zu suchen.


    Das ist Quatsch und zeigt, wie wenig Du Dich mit Deinem System beschäftigt hast.
    LiveConfig fässt die systemeigenen PHP.ini-Dateien nicht an. Wenn du auf der Shell php -i oder php(5)-cgi -i eingibst und nach php.ini grepst, erscheinen ini-Dateien, die LC nie anfasst und schon gar nicht modifiziert (die für die Shell wird aber sehr wohl für den Wizzard herangenommen).


    Hier bei Dir liegt die Ursache tendenziell sehr eindeutig in einem verkorksten, halbgewarteten System für das nur Du zuständig bist. Da LC den Vorworf zu machen ist nicht angebracht, denn Du solltest Dein eigenes System schon selbst im Griff haben.

    Bitte keine Rücksicht auf Leute nehmen, die Betriebssystemversionen einsetzen, die schon EOL / ohne Support sind...
    Sorry Ralf, es war lange genug Zeit für Upgrade ;)


    Kein Problem. Sind nicht meine Server. Wenns da batscht, ok.
    Und, ja, ich habe ein sehr gutes Gedächtnis und werd mich an diesen Hinweis erinnern.

    Hi,


    es wär besser, wenn er noch etwas wartet. Das Ding läuft nicht mehr unter Debian 6 und wir müssen noch bei einem Stapel von Liveconfig Kunden die Server auf neue Debian-Versionen updaten.... Zumindest bei denen, die neuere Server als Client einsetzen und als Zentralsystem noch Debian 6 haben knirscht es dabei angeblich.


    Gruss Ralf


    Normalerweise ist ein Beitrag alle 2 Jahre nicht viel aber mit den ganzen anderen Themen wo "dran gearbeitet" wird und man gelegentlich mal nachfragen sollte artet das trotzdem in Arbeit aus ^^


    Na ja. Da bist Du jetzt aber etwas unfair.
    Wir warten jetzt zwar auch schon sehr lange auf die Funktion, aber wenn man ehrlich ist, bewegt sich schon einiges und das System ist hinreichend komplex. Was natürlich an dieser Stelle nicht bedeutet, das uns die Reihenfolge der Entwicklung wirklich behagt, aber das ist ein anderes Thema.


    Gruß Ralf

    Hi.



    dpkg -l|grep mysql sagt


    Und ich habe nur eine my.cnf


    Ist die my.cnf alt (noch von vor Deiner Verschlimmbesserung) oder neu?


    Versuch mal dpkg-reconfigure mysql-server (-5.6).
    Wenn das nicht hilft, mysql nochmal runterschmeissen (und, NEIN, mysql-server und mysql-server-5-6 sind NICHT zwei mysql-Server sondern Server und Meta-Paket dazu.

    Ja als ich von Confixx umstellte durfte ich run 40 solcher Zehnerblöcke bauen, extrem ätzend.


    Aber wie sagte Herr Keppler am Telefon im Sommer 2014 zu mir: Sowas macht keiner...


    Kann ich bestätigen. Ich würde es nicht tun. Liveconfig ist kein Mailman.

    Wie geht es denn hier den anderen Liveconfig Nutzern? Was sagt Ihr aus der Community, es kann doch nicht sein das Ihr alle diese Stelle als Datengrab betreibt oder?


    Die paar Byte bringen unsere MySQL-DB nicht zum überkochen.
    Diese Nebenkriegsschauplätze sind aus meiner Sicht zwar remarkable, aber alles andere als missionskritisch. In diesem Sinne würden wir es bevorzugen, wenn die Entwicklungs-Energie erst mal wie versprochen auf die noch offenen wichtigen Punkte -die die Kunden direkt betreffen- (Backup, Migrationsassistent u.A.) gelegt wird.


    Ich glaube nicht das Herr Keppler die alten Daten vergisst und bin sicher, das das irgendwann ganz nebenbei aufgeräumt wird.


    Gruß Ralf

    Danke ich habe Dir eine PM geschickt.


    Du hast Post.


    Schade das man hier keine Hilfe etc. mehr vom Support-Team bekommt....


    Nein.
    Es gibt Probleme, zu denen man hier keine Lösung beschreiben kann, da -falsch angewendet- richtige Schäden entstehen können.
    Außerdem ist das hier kein Ticketsystem sondern ein Forum ....


    Gruß Ralf

    Hallo bady,
    das ist kein Fehler sondern absichtlich so eingerichtet, da das Sperren des Email-Empfangs rechtlich sehr schwierig sein kann. Bitte informiere dich diesbezüglich bei einem Juristen. Soll nur das Versenden vom Mails -- quasi als Warnschuss vor den Bug -- gesperrt werden, kannst du das ganz schnell so realisieren:
    eiclinde


    Gelinde ausgedrückt: extrem suboptimal.


    Folgendes Beispiel (aktuell real live von heute nacht)
    eMail-Zugangsdaten werden beim Kunden mittels Trojaner abgegriffen
    eMail-Zugangsdaten werden nun von Spammer zum Versand von Rechnung-Spam (Vodafone und Telekom) verwendet.
    Supporter (ohne Shellzugang) wird um 2:25 Uhr von Nagios über unübliche Mailq informiert sieht in der Auswertung den Spam und sperrt den Kunden. Spamversand geht jedoch weiter, da Postfix sich einen sch..... um die Sperre kümmert.
    Jetzt muss Supporter tatsächlich den Techniker oder den Hostmaster alarmieren, der schaut dann um 2:40 Uhr auf die Shell, kickt die Mails der Mailq und sperrt den Versand von Hand.


    Ergebnis: Statt wie um 2:25 Uhr etwa 5.000 versendete Sch...-Mails um 2:40 Uhr etwa 92.000 versendete Sch... Mails.


    und ja, der Supporter hat BEWUSST keinen Shellzugang.

    Hi,


    In der letzten Zeit häufen sich die Fälle, in denen mit geklauten Zugangsdaten Mails verschickt werden. Damit man da dann einschreiten kann oder bei einzelnen das Ganze auch vorab verhindern kann, hier eine kurze Anleitung zum einfachen Absichern von Postfix:


    Der Eintrag in der /etc/postfix/main.cf


    ------------------------------------
    smtpd_recipient_restrictions =
    check_client_access hash:/etc/postfix/client_tests,
    check_sender_access hash:/etc/postfix/sender_tests,
    usw....
    usw....
    ------------------------------------


    Jetzt geht es an das black- oder whitelisten:


    OK ist erlauben
    REJECT ist blockieren.


    ------------------------------------


    /etc/postfix/client_tests
    # Beschränke Clients von denen Zugriffe
    # erfolgen dürfen


    example.com REJECT No spammers
    .example.com REJECT No spammers, from your subdomain
    123.456.789.123 REJECT Your IP is blocked
    123.456.789.0/24 REJECT Your IP range is blocked
    111.222.111.222 OK
    example1.com OK


    /etc/postfix/sender_tests
    # Beschränke Sender die an dieses System senden dürfen


    example.com REJECT any mails from @example.com rejected
    .example.com REJECT any mails from @sub.example.com rejected
    user@example.com REJECT We don't want your email
    example2.com OK
    ------------------------------------


    Jetzt nacheinander
    postmap /etc/postfix/client_tests
    postmap /etc/postfix/sender_tests
    /etc/init.d/postfix reload


    aufrufen, und dann ist Postfix weiter abgesichert.


    Gruß Ralf