Posts by bytesplit

  • Mit Plugin Verbindung zur Datenbank herstellen

    While looking for sender_login_maps I stumbled accross this thread. Sorry if I might seem hijacking this...


    Why are you using MySQL directly here? In /etc/postfix/imscp I have lists for aliases and mailboxes. Putting these together should give us a good senderlist.


    Actually this was how I had used the aliases in ispcp. There the aliases file contained mailboxes as an alias referring to itself like this:


    Code
    1. somealias@domain.tld user@domain.tld
    2. user@domain.tld user@domain.tld

    So well... I'd either go and check everything via SQL (aliases, mailboxes, ...) or have imscp generate map files. So just wondering...

  • Listener: Dovecot remove prefix INBOX.

    I like this variant as it's quick and dirty. I do not yet understand those listeners that well. But I do know dovecot... so here is the variant I'm using:


    this is the normal namespace with removed prefix.

    Code
    1. namespace inbox { inbox = yes prefix = separator = .}


    Below that you can add another namespace:


    Code
    1. namespace compat {
    2. hidden = yes
    3. inbox = no
    4. list = no
    5. prefix = INBOX.
    6. separator = .
    7. alias_for =
    8. }

    Could that be incorporated to this listener? Then anyone could use it even when coming from Courier.


    Background story: actually Mac OSX Notes.app has a problem with prefixes on IMAP sync. So I looked out to find a way to satisfy both worlds, those with and without prefix set.

  • ALLE Spamfilter für bestimmte Empfängerdomain deaktivieren

    Dann mach mal versuchsweise den check_recipient_access rein. Es könnte sein, dass er dann sehr viel (mehr) Spam bekommt.


    Was alternativ auch noch ginge, ist halt die Begründungen von Policyd-weight mal anzuschauen... die Regeln kannst Du auch sehr fein einstellen. Halt nur Server-bezogen aber dennoch...


    Schau mal was in /var/log/mail.log zu steht:

    Code
    1. postfix/policyd-weight[2531]: weighted check: IN_IX_MANITU=5.85 IN_ZEN_SPAMHAUS=4.35 IN_INPS=3.35 CL_IP_EQ_HELO_IP=-1.2


    Im Beispiel war die Mail in den Blacklists von Manitu, Spamhaus und Inps. Relativ klar, dass das wohl Spam sein musste. Alles kannst Du in /etc/policyd-weight.conf einstellen. Könnte sein, dass Deine arabischen Freunde auch Probleme mit DNS oder IPs haben. Dann am Ende der conf mal die Regeln anschauen, ggf. hilft es auch hier ein Score runterzusetzen.


    Für konkrete Hilfe bräuchte es sonst mehr Infos oder nen Remote-Zugang per PM :)


    Grundsätzlich bleib ich aber dabei, poliyd-weight ist geil für frühes filtern. Man muss es halt ein wenig einpimpen...

  • ALLE Spamfilter für bestimmte Empfängerdomain deaktivieren

    Ich hab das ja schonmal hier gepostet... Conditional Greylisting ist das Zauberwort: http://blog.waja.info/2007/08/03/conditional-greylisting/


    dann wird Greylisting nur auf ganz üble Verbrecher angewendet. In der Regel kommt das meiste durch. Policyd-weight tut eigentlich sonst keinem weh...


    Womit hantiert denn dieser Beschwerde-Kunde? Hast Du mal Beispiele von false positives aus dem Mail log?


    Letztendlich ist die komplette Abschaltung in Postfix möglich:
    /etc/postfix/main.cf

    Code
    1. smtpd_recipient_restrictions = ...,check_recipient_access hash:/eine/datei/die/deine/domain/ausleitet# muss VOR dem policy und oder SA / Clam check_policy_service inet:127.0.0.1:12525,... permit


    In deiner Auflistung steht dann sowas wie:

    Code
    1. kundendomain.de OK


    postmap der Datei nicht vergessen.


    Dann würdest Du diese Domain schon vor dem policy_service akzeptieren.


    Damit es der Kunde merkt, nenne seine Email z.B. hier im Klartext oder auch auf ner Mailingliste/Newsgroup. Die Spambots finden ihn dann schon automatisch... viel Spaß! Achso, Quota erhöhen da es schnell eng werden könnte und dafür extra was berechnen würde ich auch...

  • More RAM memory needed after upgrade to 1.2.2 ?

    Hi there,


    for long time I was running ispCP and iMSCP on systems with 256 and 512 MB RAM. It requires several manual tweaks to the different processes but is definitly possible. Does it make sense? Well you have decide...


    Some hints:
    - https://github.com/pixelb/ps_mem -> shows memory usage per application
    - MySQL innodb can be a memory monster, the caches can be reduced though
    - Apache prefork eats more then workers, but those need to be limited too
    - ClamAV is killer as it loads all databases into RAM
    - SpamAssassin or Amavis if used is second after ClamAV
    - PHP highly depends on the configuration. FPM can be controlled per domain on a very fine grained base. But don't try to run highly active blogs/cms'es.
    - iMSCP brough Nginx running next to Apache, with a little overhead for running two servers


    In the end Nuxwin is correctly stating that the default iMSCP for most use cases requires at least 1 GB RAM. The rest is up to your manual tweaking but possible. Now if only those tweaks could be saved during iMSCP config rewrite... :P

  • Neuaufbau von i-MSCP-Server mit Datenübername aus ispcp 1.0.7

    Kannst Du ein Backup von der alten Maschine ziehen zum Testen per Trockenlauf? Ja, VMs sind eine geile Sache!


    In der Tat ist das kritische sicher 32bit 10er System nach 64bit 14er. Da ist schon bissl was dazwischen. do-releaseupgrade ist auch bei mir nicht wirklich gut im upgraden.


    Ansonsten wie Ninos wahrscheinlich meinte:
    - 32bit Migration 10-12-14 (glaub geht nicht ohne 12)
    - dabei wird ispcp evtl. Probleme mit Paketversionen bekommen und den ein oder anderen Dienst nicht starten können (eigentlich fällt mir bei courier und apache aber nix böses ein)
    - wichtig ist, dass der mysql weiter tut
    -- aktuelles OS in 32bit mit ispcp 1.0
    - jetzt migration nach imscp, das will ja auch gute Pakete in richtigen Versionen haben
    -- aktuelles OS in 32bit mit imscp 1.2
    - wenn das geklappt hat, würde ich auf 64bit switchen
    - das geht wiederum wohl am besten, wenn Du neu aufsetzt, imscp installierst und dann /var/mail/virtual und /var/www/virtual rüberkopierst. Dann noch die Datenbank und die Domains auf tochange setzen. Evtl. geht das auch mit Ausführen des autoinstallers. Hauptsache Configs neu generieren.


    Wenn Du zum Schluss ein tolles imscp mit User-Database und laufenden Server-Konfigs hast...
    - Warten bis Einbruch der Dunkelheit
    - altes System von Kunden trennen (iptables z.B.)
    - rsync von /var/mail/virtual und /var/www/virtual auf neue Umgebung


    Zu Beachten wäre nur, dass imscp per 1.2 default Dovecot statt courier verwendet. Das müsste zuerst auf Courier gestellt werden. Migrieren geht dann später.

  • custom php settings

    Could this be possible like what we have for Apache? A imscp directory with one include file per domain/pool?


    Another question comes to mind: what sense has php_admin_value? If it's there to not be overwritten, assigning it as php_value also means it can be overwritten by customer php's? That would mean a security threat then...


    I will check PHP docs

  • Update von 1.1.13 auf 1.2.0? Hat wer Erfahrung?

    Heutzutage läuft auch der iMSCP in einer virtuellen Maschine ne? Da nen Snapshot gemacht und runtergezogen auf ne Dev-Maschine und migriert. Dabei alle Probleme notiert und dann ganz bequem und mit dem Wissen was passiert das Live-System migriert. Passiert bei mir eh immer morgens um 1-4. Da bin ich nicht mehr ganz fit und brauch die Trockenlauf auf der Dev-Box.


    Zu den Hooks bzw. Listeners:
    http://i-mscp.net/filebase/index.php/FileList/16-Hook-Files/ - im Pluginstore, aber anscheinend veraltet.
    https://github.com/nuxwin/i-mscp-c0urier-listeners/ - auf Github mit etwas Doku.


    Kurzum, der Hook springt an nachdem iMSCP die Konfig geschrieben hat. Dort kannst Du somit nachträglich Änderungen an der named.conf für Hidden Primary machen. Ist eigentlich nur ein Suchen&Ersetzen-Skript.


    Alternativ finde ich Hidden Primary aber auch ein Feature wert, oder halt nen Plugin. Ich nutze DNS selbst nicht im iMSCP, das macht PowerDNS mit Poweradmin viel vollständiger...