Konfiguration Plugins
- Thread starter hksit
- Start date
hallo,
derzeit werden von PMG folgende files, die für Spamassassin relevant sind über das Template-system verarbeitet:
* /etc/mail/spamassassin/v310.pre.in
* /etc/mail/spamassassin/v320.pre.in
* /etc/mail/spamassassin/init.pre.in
* /etc/mail/spamassassin/local.cf (da sind die configurationen aus dem PMG-GUI gespeichert)
Nur diese müssen über das templating system editiert werden, aber auch nur diese werden innerhalb eines Clusters in sync gehalten.
Wenn kein Cluster verwendet wird kann die Aktivierung direkt in '/etc/mail/spamassassin/v342.pre.in' geschehen - dass könnte nur dann zu einem Problem führen, falls PMG dieses File irgendwann einmal selbst verwendet.
Falls es ein '.pre' file sein muss - vl. einfach ein /etc/mail/spamassassin/zz-local.pre anlegen und das Plugin dort aktivieren.
Ich hoffe das hilft!
derzeit werden von PMG folgende files, die für Spamassassin relevant sind über das Template-system verarbeitet:
* /etc/mail/spamassassin/v310.pre.in
* /etc/mail/spamassassin/v320.pre.in
* /etc/mail/spamassassin/init.pre.in
* /etc/mail/spamassassin/local.cf (da sind die configurationen aus dem PMG-GUI gespeichert)
Nur diese müssen über das templating system editiert werden, aber auch nur diese werden innerhalb eines Clusters in sync gehalten.
Wenn kein Cluster verwendet wird kann die Aktivierung direkt in '/etc/mail/spamassassin/v342.pre.in' geschehen - dass könnte nur dann zu einem Problem führen, falls PMG dieses File irgendwann einmal selbst verwendet.
Falls es ein '.pre' file sein muss - vl. einfach ein /etc/mail/spamassassin/zz-local.pre anlegen und das Plugin dort aktivieren.
Ich hoffe das hilft!
Doch das file wird (wie alle *.pre files) eingelesen und die Konfiguration darin wird beachtet.
Das file wird lediglich nicht vom Templating System [0] überschrieben (kann allerdings bei einem SpamAssassin paketupgrade geändert werden).
Wie bereits geschrieben - ich würde ein eigenes .pre file anlegen (/etc/mail/spamassassin/zz-local.pre) und dieses verwenden.
[0] https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#_service_configuration_templates
Hi,
das ist halt blöd, daß man nicht weiß, ob dann irgendwann weitere Files ins Templatesystem kommen und man sie dann vor Überschreiben schützen muss. Hier wäre eine Idee sinnvoll, wie man angepasste Files generell vorsehen kann, daß diese nicht überschrieben werden. Kann mann denn bspw. .pre.in-files selbst anlegen und diese werden, obwohl bisher nicht vorgesehen, dann auf die Livefiles gesynct oder geht das nicht? Was hat das mit einem Cluster zu tun?
Grüße
Christian
Naja - prinzipiell kann dies leicht getan werden: nehmen wir beispielsweise das file 'v343.pre' (welches derzeit nicht von PMG via templating system gerendert wird):
* File mit dem gewünschten Inhalt unter '/etc/mail/spamassassin/v343.pre' anlegen
* Selben Inhalt unter '/etc/pmg/templates/v343.pre.in' anlegen
Sollte jetzt PMG in Zukunft doch ein v343 mitliefern und rendern, wird das mitgelieferte File unter '/var/lib/pmg/templates' ignoriert, da ja ein override unter '/etc/pmg/templates' liegt (ein Template ohne variablen und markup wird 1:1 übernommen).
Die templates unter '/etc/pmg/templates' werden in einem Cluster vom master zu allen anderen nodes gesynct (und dann dort gerendert). Wenn es kein gerendertes file ist, muss sich der Admin selbst darum kümmern, dass das File auf allen nodes vorhanden ist.
Ich hoffe das hilft!
Thx, wenn es aber doch auf dem Master angelegt wird, wird es doch auch auf alle Nodes gesynct?
naja - alle files (bis auf temporäre oder .db files ) unter '/etc/pmg/templates' werden vom master auf alle nodes (ebenfalls nach /etc/pmg/templates) gesynced
bei files unter /etc/mail/spamassassin werden nur jene vom clustersync automatisch in sync gehalten, die über das templatesystem gerendert werden (und custom.cf, und in zukunft pmg-scores.cf)
Da spamassassin aber beim config-lesen auch symlinks folgt sollte es gut gehen auf den nodes einen symlink auf ein file unter /etc/pmg/templates/ zu machen.
bei files unter /etc/mail/spamassassin werden nur jene vom clustersync automatisch in sync gehalten, die über das templatesystem gerendert werden (und custom.cf, und in zukunft pmg-scores.cf)
Da spamassassin aber beim config-lesen auch symlinks folgt sollte es gut gehen auf den nodes einen symlink auf ein file unter /etc/pmg/templates/ zu machen.
Hmm, das ist ja blöd. Ich dachte, dass die Slaves dann auch die Configs aus den Templatefiles schreiben, egal, ob da was zu rendern ist oder nicht.
Soweit der Code nicht automatisch generell generierte Files synct, müsste man dann tricksen und im Zweifel in einen Kommentar bspw. eine Variable schreiben, die gerendert würde, soweit man nicht gar eine sinnvolle zum wirklichen schreiben findet?