I've had the Problem that Microsoft Servers didn't accept my Mails from my server so I made DKIM and SFP-Records but that also not suceeded. So I read through the internet and found a lot of posts of frustrated admins and even ISPs with the message: Microsoft don't care about delivering mails due to the standard - the Mails are send, the code is ok but with no response they fall in the black hole and have never seen again.
https://twitter.com/search?f=tweets&q=hotmail%20blackhole&src=typd
https://www.akeyes.co.uk/blog/hotmail_com__outlook_com__live_com_blacklisting____a_pleasant_experience
So what to do? As company you can't really tell your customers to change their mailadress so they can get mails from you (we advising our customers to this but as IT company thats our job ;) ).
As mailserver owner you can register to Sendersupport / SNDS Service from outlook. There you can verify your own IPs and can manage them if they are on blocklists. As far as I got after checking all those mentioned points at https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx and your ip on https://sendersupport.olc.protection.outlook.com/snds/ipStatus.aspx
You also have to mail your request over this form
http://go.microsoft.com/fwlink/?LinkID=614866
(mind there are only 2000 chars allowd in the description box!) . Then you get a mail you have to confirm and then your IP is whitelisted. This lasts for one of my servers for over half a year now but some users reported that after a few weeks/months MS is again blocking emails. I think this could depend on the emails sent from the users of your Server so as anybody marks them as Spam Mirosoft will block it again.
Dienstag, 4. Dezember 2018
Sonntag, 18. November 2018
Joomla Verzeichnis nicht beschreibbar trotz Schreibrecht für User auf Apache unter ISPConfig
Habe heute eine Website von einer Domain zur anderen umgezogen und hatte dann das Poblem, dass die Verzeichnisse nicht beschreibbar waren. Natürlich hatte ich die Besitzer aller Ordner und Unterordner aktualisiert aber trotzdem ging es nur, wenn die Gruppenrechte auf Schreibzugriff waren. Getestet habe ich das mit der configration.php Datei - im Backend eingeloggt, irgendeine Einstellung geändert, auf Speichern geklickt - geht nicht. Dann nach einem "chmod 774 configuration.php" gings auf einmal.
Schlussendlich war es die fehlende Funktion "Suexec" welche im ISPConfig in der Website-Konfiguration aktiviert werden muss.
Schlussendlich war es die fehlende Funktion "Suexec" welche im ISPConfig in der Website-Konfiguration aktiviert werden muss.
Mittwoch, 18. Juli 2018
Installation einer zusäztlichen PHP-Version in ISPConfig 3.1.12
Ich habe schon einige Versionen laufen und habe mich dafür entschieden, die jeweilige Version immer updzudaten und nicht immer bis ins letzte zu gehen. Z.b. bei PHP 7.0 habe ich aktuell 7.0.24 auf meinem Ubuntu Server 14.04.5 installiert - die Verzeichnisse heißen aber 7.0.0 um nicht immer alles neu anlegen zu müssen und trotzdem relativ einfach Updates einspielen zu können, aktuell soll 7.0.30 eingespielt werden.
Dazu sucht man sich erst mal den Download unter http://de2.php.net/downloads.php
Jetzt stoppen wird den Webserver: sudo service apache2 stop
Jetzt wechseln wir in das Verzeichnis /opt/php-7.0.0 und laden uns das aktuelle .tar.bz2 herunter, in dem Fall: http://at2.php.net/distributions/php-7.0.30.tar.bz2
nun entpacken: sudo tar jxf php-7.0.30.tar.bz2
jetzt wechseln wir in das Verzeichnis und verschieben den Inhalt in den Ordner darüber (von /opt/php-7.0.0/php-7.0.30 in /opt/php-7.0.0):
cd /opt/php-7.0.0/php-7.0.30
sudo mv * ../
den leeren Ordner lassen wir als Hinweis zur Version bestehen.
nun kompilieren wir die PHP-Version wiefolgt:
sudo ./configure --prefix=/opt/php-7.0.0 --with-pdo-pgsql --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl --with-mcrypt --with-zlib --with-gd --with-pgsql --disable-rpath --enable-inline-optimization --with-bz2 --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --enable-exif --enable-bcmath --with-mhash --enable-zip --with-pcre-regex --with-pdo-mysql --with-mysqli --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl --with-fpm-user=www-data --with-fpm-group=www-data --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-imap --with-imap-ssl --with-kerberos --with-gettext --with-xmlrpc --with-xsl --enable-opcache --enable-fpm
sudo make
sudo make install
nun kopieren wir die alten Konfigurationen zurück:
cd /opt/php-7.0.0
sudo cp ../php-7.0.24-old/lib/php.ini ./lib/
sudo cp ../php-7.0.24-old/etc/php-fpm.conf ./etc/
sudo cp ../php-7.0.24-old/etc/php-fpm.d/www.conf ./etc/php-fpm.d/
Anleitung Quellen:
https://www.howtoforge.com/tutorial/how-to-install-php-7-on-debian/
https://www.howtoforge.com/tutorial/how-to-install-php-5-6-on-ubuntu-16-04/
Dazu sucht man sich erst mal den Download unter http://de2.php.net/downloads.php
Jetzt stoppen wird den Webserver: sudo service apache2 stop
Jetzt wechseln wir in das Verzeichnis /opt/php-7.0.0 und laden uns das aktuelle .tar.bz2 herunter, in dem Fall: http://at2.php.net/distributions/php-7.0.30.tar.bz2
nun entpacken: sudo tar jxf php-7.0.30.tar.bz2
jetzt wechseln wir in das Verzeichnis und verschieben den Inhalt in den Ordner darüber (von /opt/php-7.0.0/php-7.0.30 in /opt/php-7.0.0):
cd /opt/php-7.0.0/php-7.0.30
sudo mv * ../
den leeren Ordner lassen wir als Hinweis zur Version bestehen.
nun kompilieren wir die PHP-Version wiefolgt:
sudo ./configure --prefix=/opt/php-7.0.0 --with-pdo-pgsql --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl --with-mcrypt --with-zlib --with-gd --with-pgsql --disable-rpath --enable-inline-optimization --with-bz2 --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --enable-exif --enable-bcmath --with-mhash --enable-zip --with-pcre-regex --with-pdo-mysql --with-mysqli --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl --with-fpm-user=www-data --with-fpm-group=www-data --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-imap --with-imap-ssl --with-kerberos --with-gettext --with-xmlrpc --with-xsl --enable-opcache --enable-fpm
sudo make
sudo make install
nun kopieren wir die alten Konfigurationen zurück:
cd /opt/php-7.0.0
sudo cp ../php-7.0.24-old/lib/php.ini ./lib/
sudo cp ../php-7.0.24-old/etc/php-fpm.conf ./etc/
sudo cp ../php-7.0.24-old/etc/php-fpm.d/www.conf ./etc/php-fpm.d/
Anleitung Quellen:
https://www.howtoforge.com/tutorial/how-to-install-php-7-on-debian/
https://www.howtoforge.com/tutorial/how-to-install-php-5-6-on-ubuntu-16-04/
Freitag, 15. Juni 2018
ISPConfig 3.1.12 Problem mit Erstellung von LE (Let's Encrypt) Zertifikaten
Bei einer neuen Website wollte ich ebenfalls so einfach wie bisher mit einem Haken in der Website-Konfiguration das Let's Encrypt SSL-Zertifikat aktivieren. Da es nicht auf anhieb ging, dachte ich an die gerade erst eingegebenen DNS-Records liegen und wartete einen Tag.
Als es dann noch immer nicht ging konnte es der DNS-A-Record nicht mehr sein. Ich fand an dieser Stelle eine Seite die beschreibt, wie man ISP-Config in den Debug-Log-Modus setzt (Unter System->Serverkonfiguration->Server auswhählen->Loglevel->Debug) und den Cronjob erst mal pausiert um den dann selber manuell durchführen zu können und somit die Logs zu der Zeit zu bekommen, wenn man sie braucht.
crontab -e
Auskommentieren der Zeile "* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done" durch ein setzen einer "#" davor und dann kann man den cronjob manuell starten
/usr/local/ispconfig/server/server.sh
Promt kam auch auch schon der Fehler:
15.05.2018-15:05 - WARNING - Could not verify domain xx.testdomain.com, so excluding it from letsencrypt request.
15.05.2018-15:05 - WARNING - Could not verify domain www.xx.testdomain.com, so excluding it from letsencrypt request.
Was ja auch wieder auf eine fehlerhafte DNS-Abfrage hindeutete. Nach einer kurzen suche kam ich auf https://www.niih.de/gelost-warning-could-not-verify-domain-so-excluding-it-from-letsencrypt-request/#comment-274 - hier war nun die Entscheidende sowie einfache Lösung:
ISP-Config hat eine vorab-Überprüfung der Domainnamen eingeführt welche standardmäßig aktiviert ist. Diese Überprüfung ist wohl dazu da um bei fehlerhaften Anfragen nicht gesperrt zu werden. Offensichtlich funktioniert diese Abfrage aber bei Servern hinter einem NAT nicht gut und führt zu Fehlern. Die gute Nachricht:
Man kann diese Funktion einfach unter
System->Serverkonfiguration->Server auswhählen->Web->SSL-Einstellungen->Skip Lets Encrypt Check deaktivierten und schon läuft die Zertifikatserstellung wieder problemlos!
Nun nicht vergssen das Debugging wieder auf normal stellen und den Cronjob wieder in Gang zu setzen :)
Als es dann noch immer nicht ging konnte es der DNS-A-Record nicht mehr sein. Ich fand an dieser Stelle eine Seite die beschreibt, wie man ISP-Config in den Debug-Log-Modus setzt (Unter System->Serverkonfiguration->Server auswhählen->Loglevel->Debug) und den Cronjob erst mal pausiert um den dann selber manuell durchführen zu können und somit die Logs zu der Zeit zu bekommen, wenn man sie braucht.
crontab -e
Auskommentieren der Zeile "* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done" durch ein setzen einer "#" davor und dann kann man den cronjob manuell starten
/usr/local/ispconfig/server/server.sh
Promt kam auch auch schon der Fehler:
15.05.2018-15:05 - WARNING - Could not verify domain xx.testdomain.com, so excluding it from letsencrypt request.
15.05.2018-15:05 - WARNING - Could not verify domain www.xx.testdomain.com, so excluding it from letsencrypt request.
Was ja auch wieder auf eine fehlerhafte DNS-Abfrage hindeutete. Nach einer kurzen suche kam ich auf https://www.niih.de/gelost-warning-could-not-verify-domain-so-excluding-it-from-letsencrypt-request/#comment-274 - hier war nun die Entscheidende sowie einfache Lösung:
ISP-Config hat eine vorab-Überprüfung der Domainnamen eingeführt welche standardmäßig aktiviert ist. Diese Überprüfung ist wohl dazu da um bei fehlerhaften Anfragen nicht gesperrt zu werden. Offensichtlich funktioniert diese Abfrage aber bei Servern hinter einem NAT nicht gut und führt zu Fehlern. Die gute Nachricht:
Man kann diese Funktion einfach unter
System->Serverkonfiguration->Server auswhählen->Web->SSL-Einstellungen->Skip Lets Encrypt Check deaktivierten und schon läuft die Zertifikatserstellung wieder problemlos!
Nun nicht vergssen das Debugging wieder auf normal stellen und den Cronjob wieder in Gang zu setzen :)
Dienstag, 5. Juni 2018
RTL8111/RTL8168 mit Kernel 4.4 unter Ubuntu 14.04
Nach dem Update auf den neuesten Kernel funktionierte bei mir die Netzwerkverbindung nur noch wenn ich mit dem alten Kernel bootete. Da ich das Problem mit dem Netzwerktreiber schon mal hatte, stellte ich mich schon mal auf eine lange Suche ein. Nach einigen Fehlversuchen fand ich eine eigentlich ganz einfache Lösung unter https://linhaiting.wordpress.com/2015/07/04/ubuntu-rtl8111rtl8168-network-connection-fix/ :
- Herunterladen der Treiber für RTL8111/RTL8168 von der Realtek-Website.
- Entpacken der Datei, entweder in der Konsole per tar -xvf 0010-r8168-8.045.08.tar.bz2 oder in der grafischen Oberfläche -> Rechtsklick -> Hier entpacken.
- Wechseln in das Verzeichnis z.B. cd Downloads/r8168-8.045.08
- Ausführen der Installation per sudo ./autorun.sh
- Fertig!
Abonnieren
Posts (Atom)