Beiträge von HBO

Der BIND macht jedenfalls unter CentOS in Kombination mit LC mächtig Probleme. Laut unserem Registrar muss der DNSSEC nur im DNS stehen, da wir diese per LC machen soll das ausreichen (haben wir aber noch nicht getestet).

Einige Probleme lassen sich über das Bind Logging lösen, hier mal mein Setup:
http://pastebin.com/raw/CxEP3PQH

Darauf achten, dass der Ordner erstellt wird in /var/log und die Rechte named:named haben. Zusätzlich muss man manuell in /etc/named.conf noch "include "/etc/named.conf.local";" manuell eintragen.

Teilweise gab es auch Probleme, dass Domains per "dig domain.tld @ns1.lcdns.de" aufgelöst wurde, aber scheinbar nicht veröffentlich. Am besten hier mal ggfl Firewall prüfen.

Nen freeze, anschließende Serial Erhöhung und thaw einer Domain per "rndc" und nen anschließender reload half auch manchmal. Darauf achten, dass die Serial auch in LC eingetragen wird.

Eine permanente Lösung ist das jedenfalls nicht, CentOS macht mit LC bei diversen anderen Tools auch Probleme. Wir werden wohl oder übel davon weg gehen müssen.

Also bei uns gab es folgende Probleme (die DNS bei den Domains werden von LC verwaltet, nicht extern):
- Die Keys zum AXFR Transport in keys.liveconfig haben nicht überein gestimmt, somit wurde auf den 2nd/3rd DNS keine Änderungen übernommen, Abhilfe schaffte hier mit Hilfe vom Support nur manuelles Eingreifen in die Datei
- Die Domains wurden in zones.liveconfig nicht angelegt bzw auch hier mit falschen Keys, Abhilfe schafft hier die Domain in LC auf "externe DNS" zu stellen und anschließend wieder auf die eigene DNS Vorlage
- Installiert wir zwar bind9 korrekt, aber meist fehlen die korrekten Berechtigungen der Verzeichnisse. Abhilfe schafft auch hier nur manuelles eingreifen (aufgetreten unter CentOS und Ubuntu, Debian setzen wir nicht ein derzeit).

Wieso nun die Domain nicht korrekt angelegt wurde und auf "extern" und wieder zurück gestellt werden musste konnte mir auch niemand erzählen, gibt halt einfach keine Debug Möglichkeit (habe ich oft schon angemerkt).

Wenn beim Registrar die LC DNS eingetragen wurden müssen die Keys übrigends nicht beim Registrar hinterlegt werden, das handeln die DNS unter sich aus.

Weiterhin muss man eigentlich bei jedem installierten Paket, egal ob per liveconfig-meta oder manuell, doch stark eingreifen. Sei es nun um die Konfiguration abzusichern oder gar den wünschen entsprechend anpassen zu wollen.

Stimmen die Keys in liveconfig.keys und der liveconfig.zones auf beiden Servern?

open: permission denied
Und was sagt die gesamte Berechtigung von der Datei sowie /var/named inklusive der Unterordner?

Disabling email function for this domain should deactivate the automatic mx record, so you can set your own.

Deactivate email function contracts and you won't get this MX record. It depends on your active mailserver and mailserver setup in LC, but only by enabled internal email setup.

Also 1 System mit 2 IPs, auf IP 1 läuft MX und auf IP 2 läuft Web. Auch wenn man nun in LC die Listen IP des Mailservers nur auf IP 1 stellt nimmt der trotzdem auf IP 2 die Mails an? Wie wäre es einfach per iptables die Mailserver Ports betreffend Income Verbindungen für IP 2 zu blocken?

Die Lösung mit Spamassassin unter Liveconfig (solange man mit einer Globalen statt Konto bezogenen Konfiguration arbeiten möchte) funtkioniert wunderbar. Man sollte sich nur etwas in Spamassassin und dessen Konfigurationsmöglichkeiten etwas einarbeiten.
Bei uns kommt soweit kein Spam durch und es entstehen auch keine merklichen False/Positive Probleme, die Kunden sind zufrieden.

https://www.liveconfig.com/wiki/de/migration2mysql

Warum vsFTP und nicht ProFTP? Was sagen die Logs? Weißt du denn genau was du da machst (Erfahrung mit Linux Servern)?

Zusätzlicher Server mit eigener Konfiguration und Port.

Ansonsten, sofern vorhanden, hinter dem Speedport ein "ddclient" oder Ähnliches installieren und damit die Dyn IP Auflösung steuern.

Das sollte wenn dann in etwa so aussehen:
https://www.your-sponsoring.eu…hristoph-herthel.de&myip=

Kann aber auch sein, dass der Speedport wie die Fritzbox mit 8443 nicht klar kommt.

Obs klappt konnte man in der liveconfig oder apache log feststellen.

Da man nen Port mit angeben kann ggfl das :8443 aus der URL entfernen.

Moin,

zuerst einmal, wieso Amavis?

Zum Anderen, wie genau sieht die spamd Zeile denn aus?

In etwa so?
spamd: result: . -1 - BAYES_00,FREEMAIL_FROM,URIBL_RED scantime=1.5,size=1432,user=(unknown),uid=114,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamd.sock,mid=<,,,,>,bayes=0.000000,autolearn=ham autolearn_force=no

Was sagt denn die phpinfo dazu? Ist der Eintrag in der globalen php.ini auch raus damit nur die Userbezogene php.ini genutzt wird? Wird die korrekt geladen?

Aktuell kann man glaube ich noch keine direkte PHP Einstellungen gewissen Verträgen zuweisen. Man könnte nun aber die opcache.enable=0 per PHP Einstellungen setzen und hier so einstellen, dass der Kunde diese nicht ändern kann. Kunden die dies dürfen müsste man in deren Vertragseinstellungen dann manuell unter dem Tab PHP Einstellungen diese Möglichkeit aktivieren.

Gemäß Anleitung werden auch erst alle Dienste und anschließend LC installiert.

Für welche Dienste sind die Zertifikate wie erstellt worden?

Was macht "mysql_secure_installation"?
Ist MySQL wirklich fehlerfrei installiert? Auf jedem unserer Debian/Ubuntu Systeme kommt bei der Installation über dpkg das Menu zum Passwort setzen.

Was wurde angepasst? Wo wurde das angepasst? Was sollte raus kommen?

Hier ist nur zu empfehlen sich einmal mit KK beim WHD oder telefonisch in Verbindung zu setzen, hier bekommste dann entsprechende Infos "von wegen einfach". Klar sind die Entwickler hier nicht sehr aktiv, es gibt aber andere Kommunikationswege auf denen mehr als ausreichend zum einen Informationen oder Hilfestellung bei Problemen zu erhalten sind.