Beiträge von antondollmaier

  • Emailversand zwischen den LC servern

    gut:


    Code
    Feb 21 17:26:05 web postfix/smtp[15172]: 8812365F98: to=<info@webaccount.de>, relay=none, delay=0.1, delays=0.05/0/0.05/0, dsn=5.4.6, status=bounced (mail for webaccount.de loops back to myself)


    Damit kann man arbeiten.


    Postfix kennt "webaccount.de" nicht, das passt also. Es wurde also in der Tat versucht, die Domain nach extern zuzustellen.



    Allerdings hat Postfix im DNS einen MX/A-Record gefunden, der wieder auf sich selbst verwiesen hat: bitte daher auf dem Server(!) die DNS-Resolv-Konfiguration prüfen und schauen, was für die Domain ("webaccount.de") tatsächlich als Antwort zurück kommt.

  • Emailversand zwischen den LC servern

    Zitat von Mogwais

    Ist das Verhalten generell ungewöhnlich?


    ja.


    Ich zitiere nochmal:


    Zitat

    Das Problem besteht darin wenn man per php (Konktaktformular uä), eine Mail vom Webserver an seine eigene Domain schickt verlässt die Mail nicht den Webserver sondern wird auf dem Webserver angelegt wo sie natürlich keiner abrufen kann.


    Ohne Logs kann man natürlich gar nichts prüfen, das ist hier also alles ganz allgemein gehalten.


    - server A hat Postfix. Keine virtual_domains. Hostname: servera.example.com
    - Server B dito (mit serverb.example.com), verwaltet aber auch virtuell die Mails der example.com.
    - PHP verschickt nun auf Server Amit mail() bzw. /usr/sbin/sendmail eine Mail. Empfänger: info@example.com.
    - wenn ServerA die "example.com" in mydestination hat, bleibt die Mail also lokal.
    - existiert "info" irgendwo als Postfach, so wird diese Mail lokal zugestellt.
    - existiert "info" nicht, so wird die Mail mit "unknown user" gebounced.



    Somit: Logs und konkrete Daten. Dann kann man genauer helfen.


    Wie gesagt: Postfix behält Mails nur dann für "sich", wenn es dafür konfiguriert wurde.

  • Emailversand zwischen den LC servern

    Zitat von Mogwais

    Postfix an sich musste ich aber installieren die Webaccounts dürfen ja Mails verschicken.


    Das Verhalten kann nur auftreten, wenn die Ziel-Domain auf Server B auch auf Server A im Postfix hinterlegt ist.


    Das kann viele Gründe haben - virtual_domains ist einer davon, myhostname/mydestination ein anderer.


    Welcher davon, können wir so weder erraten noch tatsächlich bestimmen.

  • cron.php.sh verwendet alte php.ini

    Um die Ausgangsfrage zu beantworten:


    Zitat von clickpress

    Ich muss mich auch mal hier reinhängen. Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.
    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.


    Nein, tut es nicht.


    cron.php.sh macht nichts anderes, als die Session-Lifetime aus den vorhandenen php.inis auszulesen. Anhand dessen wird dann pro Kunde ein Find durchgeführt, um die Session-Dateien aufzuräumen.


    Ich sehe hier keinerlei Referenz in irgendeiner Art und Weise, die auch nur ansatzweise einen Zusammenhang zu IonCube oder Zend benötigen würde.


    Wenn ein Kunde(!) seine Cronjobs mit PHP-CLI benötigt, dann muss er so oder so den absoluten Pfad verwenden, der vom Provider vorgegeben wird. Diese Cronjobs, die der Kunde in der GUI konfigurieren kann, sind vollkommen unabhängig von einer Domain und somit auch unabhängig von der PHP-Version der CLI oder sonstwem.

  • cron.php.sh verwendet alte php.ini

    Zitat von clickpress

    Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.


    Es geht hier um die cron.php.sh von LiveConfig selbst, nicht um die Cronjobs der Verträge.


    Zitat

    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.


    Die Cronjobs der Kunden/Nutzer müssen schon auch die richtige CLI-PHP-Version verwenden. LiveConfig ändert den Cron-Befehl nicht ab.


    Dieser ist auch unabhängig von jeglicher Domain-PHP-Konfiguration.

  • Slave DNS?

    [quote='bash','https://forum.liveconfig.com/index.php?thread/&postID=15585#post15585']Ja soweit würde dieses gehen ja.. aber dann hab ich immer noch das Problem weil ich hier Geräte im Einsatz habe wo ich das nicht auswählen lassen kann ob IPv4 oder IPv6 (das Gerät nimmt automatisch die IPv4) und dann widerrum auch zwei Geräte die keinen Dyndns Client besitzen (sind normalerweise dafür nicht vorgesehen) diese kann ich dann nur via URL quasi ins Netz nach außen bringen./QUOTE]


    - dyndns.example.com IN A/AAAA
    - ipv6.dyndns.example.com IN AAAA
    - ipv4.dyndns.example.com IN A


    Diese IP-Konfiguration lässt sich aber, zugegebenermaßen, über die LiveConfig-GUI schlecht abbilden.

  • Slave DNS?

    Subdomain anlegen, die keinen IPv4-Record, sondern nur einen AAAA-Record aufweist. Dann kann nur IPv6 verwendet werden.


    Auszug aus dem LiveConfig-Handbuch:


    Zitat

    Den gewählten Benutzernamen und das Passwort müssen Sie anschließend in Ihrem Dynamic DNS Client angeben. Die Update-URL lautet standardmäßig http(s)://<LiveConfig-Server>(<:Port>)//liveconfig/hosting/dnsupdate?hostname=<domain>&myip=<ipaddr>


    Viele DynamicDNS-Clients ersetzen übrigens automatisch die Platzhalter <domain> und <ipaddr>. Optional können Sie mit dem Parameter myip6=<ip6addr> auch eine IPv6-Adresse („AAAA-Record“) aktualisieren.


    Hilft das?


    (nicht selbst getestet, sorry)

  • Slave DNS?

    Zitat von bash

    nutz nur einen Server)... alles im allen also derzeit etwas bescheiden...


    Öhm.


    - für das DynDNS-Feature benötigt LiveConfig Zugriff auf die Nameserver.
    - davon benötigt man immer mindestens zwei.


    Das Argument "DynDNS kostet 20€/Monat mehr!" ist somit hinfällig: nicht DynDNS kostet mehr, sondern die Verwaltung von zwei Nameservern durch LiveConfig.


    Kannst natürlich auch nur einen Nameserver durch LC verwalten lassen und einen externen Secondary hinterlegen, wenn sich da ein Secondary-Dienst findet.

  • Slave DNS?

    Zitat von bash

    Ja merci habs dann mal getestet, aber irgendwie funktioniert das ganze noch sehr suboptimal.. xD


    Sorry, da muss ich widersprechen. Wir haben gestern alle Confixx-Server auf LiveConfig migriert, inklusive DNS-Delegation im LC Business-Verbund.


    Das klappt alles wunderbar: Zone wird auf ns1 angelegt, auf ns2 hinterlegt. Die Zone selbst wird dann per AXFR übertragen.



    Wo hakt es denn genau?

  • Slave DNS?

    Klar. Einfach auf dem SlaveDNS auch eine LC Lizenz hinterlegen und das im LiveConfig-DNS-Template entsprechend verknüpfen.


    Der Client erstellt dann die Zone, wobei die DNS-Einträge vom Master an die Slaves synchronisiert werden.

  • Blacklist Empfehlung

    Zu Spamhaus:


    Zitat

    zen.spamhaus.org


    ZEN is the combination of all Spamhaus IP-based DNSBLs into one single powerful and comprehensive blocklist to make querying faster and simpler. It contains the SBL, SBLCSS, XBL and PBL blocklists.


    zen.spamhaus.org dürfte damit reichen.