Beiträge von kai

Nach einer frischen Installation sieht es bei mir so (s.u.) aus.

Und das ist auch gut so und benötigt keinen Hotfix

In den FAQ muss es also eigentlich heissen:

svc -d /service/apache24

svc -u /service/apache24

#!/bin/bash

if [ ! -e "/etc/real-hostname" ]; then
  hostname $(/opt/pdadmin/bin/hostname.pl)
else
  hostname $(cat /etc/real-hostname)
fi

killall -9 httpd 2>&1 >/dev/null
rm /usr/local/pd-admin2/httpd-2.4/logs/httpd.pid
ulimit -n 64000
cmd=(
  exec /usr/local/pd-admin2/httpd-2.4/bin/httpd
    -D NO_DETACH
    -DSSL
)
"${cmd[@]}"

Sind die Hotfixes nicht uralt und eigentlich obsolet?

pd-admin | FAQ

OK, kein Bug. Ich dachte das wäre der Sinn des Parameters, dass das im Content direkt ersetzt wird. Komisches Format.

Wenn pd-admin hier serverseitig den username ermitteln und da ausgibt, dann wäre das wohl auch eine Sicherheitslücke.

Solange dann https://bugzilla.mozilla.org/show_bug.cgi?id=564043 nicht gefixed wird, damit explizit ein Username abgefragt werden kann wäre doch im Falle von pd-admin aber der Platzhalter %EMAILLOCALPART% die bessere Wahl oder?

Dann könnte ich die Einrichtung erfolgreich abschließen, wenn ich bei Thunderbird username@example.org angebe anstatt der echten Adresse.

Ruft man für eine Domain diese URL auf, dann soll das wohl eigentlich die Thunderbird Autoconfig Werte liefern:

https://domain.de/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=adresse@domain.de

Bei mir werden aber die Platzhalter nicht ersetzt:

<?xml version="1.0" encoding="UTF-8"?>

<clientConfig version="1.1">
  <emailProvider id="domain.de">
    <domain>domain.de</domain>
    <displayName>pd-admin Server</displayName>
    <displayShortName>pd-admin</displayShortName>
    <incomingServer type="imap">
      <hostname>meinserver.example.org</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>

Non TLS Hosts sollten sich ja eigentlich langsam erledigt haben, so dass man praktisch per HSTS nur einen Durchlauf pro Domain erzwingen kann .

Zudem habe ich noch herausgefunden, dass es eine ggf. nützliche Umgebungsvariable gibt: PDA_VHOST_USER

Ich habe es nun doch nicht gebraucht, aber ggf. nützt das Jemandem.
Ein recht unschönes Script, um noch fast am Ende (oder an einer bestimmten Position) der httpd.conf etwas hinzuzufügen, indem man die restlichen nötigen Zeilen im VirtaulHost selbst schreibt, diesen schließt und dann seine Einträge macht und dann einen fake Virtualhost öffnet.

#!/bin/bash

if [ "$1" == "letztedomain.example.org" ]

then

echo "#httpd_vhost_module: incremental"

echo "ErrorLog /home/errorlogs/$PDA_VHOST_USER/error_log"

echo "Header set Strict-Transport-Security \"max-age=15768000\""

echo "</VirtualHost>"

cat /root/vhost-add.txt

echo "<VirtualHost xxx.xxx.xxx.xxx:443>"

echo "ServerName fake.example.org"

fi

Hatte noch Probleme beim Erneuern des Zertifikates mit dem automatisch erzeugtem non tls ipv6 Eintrag.

Dieser hatte zu einer Endlosschleife geführt

<VirtualHost xxxx:xxxx:xxxx:xxxx::xxxx:80>

ServerName meinserver.example.org

Redirect 301 / http://meinserver.example.org/

</VirtualHost>

Das habe ich durch einen "führenden" Eintrag in httpd24.conf-template verhindern können (und oben ergänzt).

<VirtualHost xxxx:xxxx:xxxx:xxxx::xxxx:80>
  ServerName $$SERVERNAME
  RedirectMatch 301 ^(?!/.well-known/acme-challenge).* https://$$SERVERNAME$0
  Alias /.well-known/acme-challenge/ /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/
</VirtualHost>

Wem die offiziellen Signaturen nicht reichen, dern kann mit fangfrisch noch weitere Signaturen nutzen.

Im Prinzip komplett nach Anleitung https://rseichter.github.io/fangfrisch/#_installation nur "simscan" statt "clamav" user und anpassen der Verzeichnisse

mkdir -m 0770 -p /var/lib/fangfrisch
chgrp simscan /var/lib/fangfrisch
cd /var/lib/fangfrisch
python3 -m venv venv
source venv/bin/activate
pip install fangfrisch
deactivate

Config /etc/fangfrisch.conf anlegen

[DEFAULT]
db_url = sqlite:////var/lib/fangfrisch/db.sqlite
local_directory = /usr/local/pd-admin2/share/clamav/
on_update_exec =  /usr/local/pd-admin2/bin/clamdscan --reload
log_level = INFO

[urlhaus]
enabled = yes

[sanesecurity]
enabled = yes

Initialisieren

 sudo -u simscan -- /var/lib/fangfrisch/venv/bin/fangfrisch --conf /etc/fangfrisch.conf initdb

Cron einrichten

HOME=/var/lib/fangfrisch
LOG_LEVEL=WARNING
# minute hour day-of-month month day-of-week user command
*/15 * * * * simscan venv/bin/fangfrisch --conf /etc/fangfrisch.conf refresh

Schön, dass man auch nach Jahren wieder über seine eigenen Kommentare stolpert

Der Schalter scheint immer noch nicht standardmäßig gesetzt zu sein. DIe Datei fehlt also weiterhin nach einer Neuinstallation.

echo 1 > /var/qmail/control/ignorewronganswer

Weil ich aber nirgends etwas zu solch einem Patch finden kann, wäre es schön zu wissen, welche Patches die ausgelieferte qmail version erhalten hat.

Man siehrt nur, _dass_ gepatched wurde

# strings /var/qmail/bin/qmail-remote | fgrep ignorewronganswer

control/ignorewronganswer

Gibt es eine Übersicht der Patches bzw. den Sourcecode irgendwo zum Download?

Auch wenn der Thread schon recht alt ist die Frage:

Was ist denn der Sinn, dass die SE /usr/local/bin/perl und /usr/bin/perl auf /usr/local/pd-admin2/bin/perl umbiegt?

Und kann man _beide_ links wieder bedenkenlos auf das System Perl umbiegen?

Konkret geht es bei mir hier um Munin, was diverse Module braucht, die im SE Perld nicht enthalten sind.

Und weiter geht es mit...

Eigenen Spamhaus DQS Account nutzen

cd /usr/local/src/
wget https://github.com/spamhaus/spamassassin-dqs/archive/refs/tags/v1.2.2.tar.gz
tar xfz v1.2.2.tar.gz
cd spamassassin-dqs-1.2.2/
sed -i -e 's/your_DQS_key/EIGENERKEY/g' sh.cf
sed -i -e 's/your_DQS_key/EIGENERKEY/g' sh_hbl.cf
vi sh.pre (loadplugin      Mail::SpamAssassin::Plugin::SH SH.pm)

sh hbltest.sh
cd /usr/local/pd-admin2/etc/mail/spamassassin/
cp /usr/local/src/spamassassin-dqs-1.2.2/SH.pm .
cp /usr/local/src/spamassassin-dqs-1.2.2/sh.cf .
cp /usr/local/src/spamassassin-dqs-1.2.2/sh_scores.cf .
cp /usr/local/src/spamassassin-dqs-1.2.2/sh.pre .

Weiter geht es mit Spamassasin...

Eigenen Caching DNS installiere via apt install unbound (bei Bedarf auch für alle Resolves nutzen via /etc/resolv.conf)

iXhash2 unofficial benutzen

cd /usr/local/src/
wget https://mailfud.org/iXhash2/iXhash2-2.05.tar.gz
tar xfz iXhash2-2.05.tar.gz
cd iXhash2-2.05/
cp -a iXhash2.* /usr/local/pd-admin2/etc/mail/spamassassin
cd /usr/local/pd-admin2/etc/mail/spamassassin
chown root:root iXhash2.*
vi iXhash2.cf (nur ix.dnsbl.manitu.net drin lassen)

DCC installieren / nutzen

cd /usr/local/src/
wget https://www.dcc-servers.net/dcc/source/dcc.tar.Z
uncompress dcc.tar.Z
tar xf dcc.tar
cd dcc-2.3.168/
CFLAGS="-O2 -fstack-protector" DCC_CFLAGS="-O2 -fstack-protector" ./configure && make && make install
useradd -m -U -d /var/dcc -s /bin/sh dcc
chown -hR dcc:dcc /var/dcc
su - -c '/var/dcc/libexec/dccifd' dcc
vi /usr/local/pd-admin2/etc/mail/spamassassin/v310.pre (DCC einkommentieren)

Install Pyzor

apt install python3-venv python3-pip
pip install pyzor
vi /usr/local/pd-admin2/etc/mail/spamassassin/v310.pre (Pyzor einkommentieren)

Weitere Änderungen an Spamassasin

# 2014-04-25
#skip_rbl_checks 1
report_safe 0
#score URIBL_BLACK 0
#score URIBL_RED 0
#score URIBL_GREY 0
#score URIBL_BLOCKED 0
#score *_SURBL 0


# own changes
use_bayes 0
required_score 4.5
skip_rbl_checks 0
dns_available yes
dns_server 127.0.0.1

remove_header all Level
add_header all Status "_YESNO_, score=_SCORE_ tests=_TESTSSCORES_"

# own uri blacklisting
uri MY_URIBL m'^https?://[^\.]{3,}\.(guenstig\-rezeptfrei\.com|guenstig\-gekauft\.nl|apothekediskret24\.nl|guenstigapotheke24\.nl|garantiertepreise\.nl|hartimwinter\.nl|garantiertgeliefert\.nl|go\-spring\.shop|heutekaufen\.shop|kaufensicher\.nl)\b'i
describe MY_URIBL blacklisted url
score MY_URIBL 4.5

# scores
score URIBL_BLACK 4.5
#score URIBL_PH_SURBL 0 0.001 0 0.610
score URIBL_PH_SURBL 0 2.5 0 2.5

# Mail::SpamAssassin::Plugin::TxRep
use_txrep 1

# DCC https://cwiki.apache.org/confluence/display/SPAMASSASSIN/UsingDcc
use_dcc 1
dcc_home /var/dcc
dcc_timeout 8
#score DCC_REPUT_00_12 0 -0.8 0 -0.4
score DCC_REPUT_00_12 0 -0.4 0 -0.4

# http://msbl.org/ebl-implementation.html
header HASHBL_EMAIL eval:check_hashbl_emails('ebl.msbl.org')
describe HASHBL_EMAIL Message contains email address found on EBL
priority HASHBL_EMAIL -100 # required priority to launch async lookups early
tflags HASHBL_EMAIL net

# https://www.intra2net.com/de/support/antispam/blacklist.php_dnsbl=rcvd_in_uceprotect2.html
header   RCVD_IN_UCEPROTECT2  eval:check_rbl_txt('uceprotect2-lastexternal','dnsbl-2.uceprotect.net.')
describe RCVD_IN_UCEPROTECT2  Listed in dnsbl-2.uceprotect.net (open relay/proxy/dialup)
tflags   RCVD_IN_UCEPROTECT2  net
score    RCVD_IN_UCEPROTECT2  2

Mhh, dann scheinst du aber in der /etc/gai.conf IPv4 zu bevorzugen!?

Klappen tut es jetzt mit einem ReverseProxy auf die STANDARD_IP mit beibehaltung des Hostnames per ProxyPreserveHost On

<VirtualHost xxxx:xxxx:xxxx:xxxx::xxxx:443>
  ServerName $$SERVERNAME
  SSLProxyEngine On
  ProxyPreserveHost On
  ProxyPass / https://$$STANDARD_IP/ connectiontimeout=5 timeout=30
  ProxyPassReverse / https://$$STANDARD_IP/
  ProxyTimeout 120

  SSLEngine on
  SSLCertificateFile /opt/pdadmin/sslcerts/$$SERVERNAME-cert
  SSLCertificateKeyFile /opt/pdadmin/sslcerts/$$SERVERNAME-key
  SSLCertificateChainFile /opt/pdadmin/sslcerts/$$SERVERNAME-cacert
  SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

  RewriteEngine On
  Alias /.well-known/acme-challenge/ /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/
</VirtualHost>

<VirtualHost xxxx:xxxx:xxxx:xxxx::xxxx:80>
  ServerName $$SERVERNAME
  RedirectMatch 301 ^(?!/.well-known/acme-challenge).* https://$$SERVERNAME$0
  Alias /.well-known/acme-challenge/ /opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge/
</VirtualHost>

Zitat

Lösen sich die betroffenen Domains DNS-mäßig noch auf die alte Domain auf?

Ich kann nicht sagen woran es gelegen hat, aber die alten IPs sind nun verschwunden.
Die Hauptdomain hat einen Catchall DNS Eintrag auf die alte IP.
Also irgendwas.hauptdomain.tld löst auf die alte IP auf.

Auf dem Server haben die einzelnen Domains ganz normal auf die neue IP aufgelöst.
Wären das Queries der Art kunde.tld.hauptdomain.tld gewesen, dannh hätte ich mir das erklären können...

Update:

Ich hatte doch was geändert. Ich hatte einen Catch-All Eintrag unterhalb der Subdomain des Servers im DNS hinterlegt, der dann auf die Server IP auflöst.

D.h. beim Schreiben der http.conf wird noch irgendwas unterhalb des Servernamens aufgelöst und die IP hinzugefügt.
Ich tippe auf http://www.sub.domain.tld

Zum Thema IPv6 für die Hauptdomain

Sumeragi ich weiß nicht wie das mit dem Proxy funktionieren soll.
Request IP6:443 --Proxy auf--> domain:443 ist doch im Zweifel eine Endlosschleife, weil domain:443 auch präferiert IP6 nutzt und wieder bei sich selbst landet.
Die config ballert bei mir demnach auch alle Worker voll

Ein Proxy direkt auf die IP würde theoretisch funktionieren, wenn man nicht die OWASP WAF Regel aktiv hat um Zugriff direkt auf die IP zu blockieren

SSLProxyCheckPeerCN off
ProxyPass "/" "https://$$STANDARD_IP/" connectiontimeout=5 tmmeout=30
ProxyPassReverse "/" "https://$$STANDARD_IP/"

Ich habe jetzt _erstmal_ den Apache für IP6 deaktiviert Listen $$STANDARD_IP:80, was aber den großen Nachteil hat, dass die initialen Zugriffe per Browser schnarch langsam sind, weil der erst merken muss, dass auf IP6 nix reagiert.

Den AAAA IP6 Eintrag für die Domain benötige ich zwingend, weil IP6 auch für ausgehende SMTP Verbindungen genutzt wird und somit auch der Reverse PTR gesetzt ist und der AAAA nötig wird.

Gibt es ggf. eine offiziell "richtige" Lösung dafür Daniel Bradler ?

Ich "kämpfe" grad mit httpd_vhosts.pl (Reihe 6 alles aktuell)

1.) Bei den Kunden, die ich importiert habe, findet sich in der auch noch die IP vom alten Server in der VirtualHost Config.

Ich finde nicht heraus, wo die alten IP noch herkommt.

Im vadmin Schema ist die weder bei ip_old noch bei ip gesetzt. Und es ist auch nicht die Standard IP.

Eine grep Suche in /opt/pdadmin/ unde /usr/local/pd-admin2 findet die alte IP auch nicht.

-> Wo kann die noch herkommen!?

<VirtualHost 85.neu.neu.neu:80 2a01:neu:neu:neu::neu:80 78.alt.alt.alt:80>
...
</VirtualHost>

2.) Wie kann ich den SSL VirtualHost Eintrag für den Host beeinflussen?
Der Eintrag für Port 80 befindet sich im Template.
Der Eintrag für Port 443 wird aber erzeugt.
Konkret möchte ich die IP6 Adresse des Hosts in der 443 Config haben.

-> Wie geht das? Gibt es einen "Standard ipv6" conf-Key?

Mein jetziger Workaround ist, den erzeugten Eintrag für die ip4 Standard IP zu kopieren und in das Template mit der ip6 einzutragen.
Das funktioniert, ist aber nicht besonders schön...

Ja, kann ich bestätigen für Reihe 6.

Der Timestamp stimmt jeweils exakt überein mit den pdadmin Einträgen im mail.log:

pdadmin[908803]: User xxx: smtp-auth login from xxx.xxx.xxx.xxx ...

Vmtl. Connection nicht sauber geschlossen!?

OK, eine externe Lösung kommt nicht in Frage.

Daher habe ich meine alte Lösung wieder reaktiviert. Aufzufinden aber nur noch auf archive.org: https://web.archive.org/web/20…t:80/tomislavr/qmail.html

cd /usr/local/src/
wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
tar xfz ucspi-tcp-0.88.tar.gz
wget https://web.archive.org/web/20110927094120if_/http://xs3.b92.net/tomislavr/ucspi-tcp-0.88.errno.patch
wget https://web.archive.org/web/20110927092504if_/http://xs3.b92.net/tomislavr/ucspi-rss.diff
wget https://web.archive.org/web/20120125055408if_/http://xs3.b92.net/tomislavr/ucspi-tcp-0.88-rblspp.patch
patch -p0 < ucspi-tcp-0.88.errno.patch
patch -p0 < ucspi-rss.diff
patch -p0 < ucspi-tcp-0.88-rblspp.patch

cd ucspi-tcp-0.88
make
strip rblspp
cp -a rblspp /var/qmail/plugins/
cd ..

wget https://web.archive.org/web/20110927094110if_/http://xs3.b92.net/tomislavr/ifauthskip.c
gcc ifauthskip.c -o ifauthskip
strip ifauthskip
cp -a ifauthskip /var/qmail/plugins/

wget https://web.archive.org/web/20120509201612if_/http://xs3.b92.net/tomislavr/authlogger.c
gcc authlogger.c -o authlogger
strip authlogger
cp -a authlogger /var/qmail/plugins/

Und dann die Plugins einbinden:

[connection]

[auth]
plugins/authlogger

[helo]

[mail]

[rcpt]
plugins/ifauthskip
:plugins/rblspp -r eigenercode.zen.dq.spamhaus.net -r ix.dnsbl.manitu.net -r dnsbl-1.uceprotect.net -r dnsbl.dronebl.org
/opt/pdadmin/bin/smtp_greylist.pl

[data]

Anmerkungen für Import/Export wird auch noch lz4 benötigt und für php in der Regel auch libcurl4

apt-get install lz4 libcurl4

Frage zu den cron jobs:

Warum muss man die letsencrypt jobs manuell hinzufügen?
Erledigt das nicht schon ein andes Script implizit mit?

Und braucht man wirklich ein eigenes Script wie regenerate_mail_certs.sh oder ist /opt/pdadmin/bin/update_host_certificate.sh nicht eigentlich auch "cronfähig"

Der Fehler im Script /usr/local/pd-admin2/share/mkdhparams habe ich im anderen Thread zwar gefixed,
aber die erzeugte Datei wird nach meinem Kenntnisstand nur von Courier-IMAP genutzt.
Kann also wirklich (auch aus pd-admin) entfernt werden.

Oder das Script ändern, damit der openssl Zweig anstatt des certtol Zweigs genutzt wird.

...
BITS="$DH_BITS"
#if test "gnutls" = "openssl"
if test "openssl" = "openssl"
then
...

Auf dem Altsystem hatte ich rblspp, also das Plugin für qmail-spp, im Einsatz und war bisher eigentlich ganz zufrieden. (siehe v4 und Antispammechanismen)

Zusätzlich lief dann noch dnscache, damit nicht alle Anfragen immer zu den rbl Servern gehen.

Welche rbl Lösung ist bei euch im Einsatz und wie ist die integriert?

Ist die Reihe 8 immer noch experimentell?

MySQL 5.7 hat ja Ende 2023 EOL

Ich gehe davon aus, dass dann in den nächsten 12 Monaten eine (automatische) Umstellung auf die Reihe 8 (oder 9) gibt?

Wobei Reihe 9 eigentlich auf die mariadb LTS Version 10.6 gehen sollte.

Hilfreich wäre natürlich, wenn es keine Reihentrennung wg. der DB gäbe und die Endkunden zwischen den Versionen wählen könnten.

Aber das gehört in die Wuschecke

Ich habe mich dann doch getraut das Altsystem noch auf eine aktuelle pda Version zu bringen.

Vorher Umstellung auf Apache 2.4 via /opt/pdadmin/bin/select-webserver.sh AP24.

Ging nicht, Webserver nicht erreichbar, weil die /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template leer war

Datei mit dem Template aus dem Updater/Installer ersetzt -> wieder alles OK.

Update auf pda v4.100 -> OK

Migration nochmal getestet -> lz4 fehlte auf Quell- und Zielserver(!)

Information vom Quellserver: </opt/pdadmin/bin/home-tar.sh: Zeile 11: type: lz4: Nicht gefunden.>

Die Migration hat nun also funktioniert