Beiträge von antondollmaier

  • 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.

  • Mails in Spamordner verschieben, statt abweisen

    Zitat von HBO

    Es gibt da so eine gewisse Problematik das du als Provider in die Emails (nämliche das Verschieben) eingreifst.


    Geht in Ordnung, solange der Kunde aktiv zugestimmt hat. Theoretisch gilt hier auch schon das Taggen als "Verändern" im Sinne des Fernmeldegeheimnisses.


    Zitat

    Ablehnen, Sender kriegt ne Fehlermeldung, ist immer noch die Beste Lösung (geht ja nichts verloren).


    Korrekt - wobei beide Lösungen ihre Probleme haben:


    - Verschieben in Ordner: "wo ist meine Mail hin? Wie komme ich an diese Mails ran?"
    - Bounce: "habe ich nie bekommen - warum nehmt ihr diese Mail nicht an?"