Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Hallo InterNetX
ist in der neuen Version auch vorgesehen, dass der Sync der Domains besser funktioniert?
Ich habe das Problem, dass wenn Kunden nicht rechtzeitig bezahlen, die Domain auf "abgelaufen" springt. WHMCS erstellt keine Rechnungen mehr, obwohl die Domain noch im Bestand ist.
Wird es dafür eine Lösung geben?
Heute erst, nachdem ein Kunde eine Email geschrieben hatte, hatte ich bemerkt, dass ich eine Domain 3 Jahre lang nicht berechnet hatte.
Hallo JB1985 ,
der Sync funktioniert an sich wie er soll.
Welche Domains gesynct werden entscheidet WHMCS und nicht das Plugin, das ist immer vom Status der Domain abhängig.
Sobald der Status der Domain auf EXPIRED springt greift der Sync nicht mehr, man muss das Problem also eigentlich in WHMCS angehen.
Die "Domain Status Sync Frequency" in den Automation Settings hoch zu setzen wäre eine denkbare Lösung.
Alternativ auch mit "Sync Next Due Date" und der "Number of Days to Set Due Date in Advance of Expiry" wäre das Problem ggf. zu lösen, das ist aber wahrscheinlich von Ihren AGB/Kündigungsfristen abhängig.
Diese Dinge müsste man ausprobieren ob diese praktikabel sind und nicht an anderer Stelle Probleme verursacht werden.
Es ist allerdings auch wahrscheinlich, dass bei Nutzung eines AutoDelete/Prepayment Accounts bei InterNetX sich das Problem nicht auswirkt sondern nur bei AutoRenew Accounts. Im Falle von AutoDelete/Prepayment würden die Domains automatisch bei Nicht-Bezahlung gelöscht und die Abweichung zu WHMCS tritt gar nicht erst auf.
Das Problem bei AutoRenew Accounts ist mir aber auch bekannt, gelöst hätte ich das mit einem monatlichen Check aller Domains in meinem WHMCS die auf EXPIRED stehen.
Die EXPIRED Domains lassen sich ja einfach in WHMCS filtern und wenn man die Detailseiten aufruft kann man schnell den Status der betroffenen Domains wieder auf ACTIVE ändern. Anhand der API Response sieht man dann sofort, welche Domains noch in AutoDNS vorhanden sind und welche einen Fehler melden. Alle Domains mit Fehler können dann auf CANCELLED gesetzt werden und sind damit final deaktiviert. Alle Domains die vorher EXPIRED waren und noch in AutoDNS vorhanden sind, stehen danach wieder auf ACTIVE. Es sollten nach dem einmaligen monatlichen Check dann keine EXPIRED Domains mehr vorhanden sein.
Mit dieser einfachen administrativen Maßnahme sollten solche Fehler einfach entdeckt und behoben werden können.
Sicher gibt es auch eine Möglichkeit die Status-Änderung auf anderem Wege zu triggern, allerdings sehen wir das InterNetX Plugin nicht als passende Stelle für eine Lösung der automatischen Änderung des Domain-Status bei Erreichen des Due-date durch WHMCS.
Empfehlenswert wäre dann eher die Nutzung eines AutoDelete/Prepayment Accounts für den Betrieb von WHMCS, da dieser den Modalitäten von WHMCS besser entgegen kommt.
Evtl. haben ja auch andere Teilnehmer hier im Forum das gleiche Problem und können alternative Vorschläge machen.
Gruss Marius Wunner
Die EXPIRED Domains lassen sich ja einfach in WHMCS filtern und wenn man die Detailseiten aufruft kann man schnell den Status der betroffenen Domains wieder auf ACTIVE ändern. Anhand der API Response sieht man dann sofort, welche Domains noch in AutoDNS vorhanden sind und welche einen Fehler melden. Alle Domains mit Fehler können dann auf CANCELLED gesetzt werden und sind damit final deaktiviert. Alle Domains die vorher EXPIRED waren und noch in AutoDNS vorhanden sind, stehen danach wieder auf ACTIVE. Es sollten nach dem einmaligen monatlichen Check dann keine EXPIRED Domains mehr vorhanden sein.
Kann man diesen Teil nicht automatisieren mit einem hook?
@all, könnte das jemand - für Bezahlung - bereitstellen?
Für alle User steht ab sofort unsere neueste Plugin-Version als Beta zum Test bereit.
Die neu Version nutzt die JSON-API von InterNetX, die XML-API ist damit nicht mehr in Verwendung.
Probleme mit der neuen Version sind bisher nicht bekannt, das Modul ist bis WHMCS 8.7 beta kompatibel.
Bitte das bestehende Verzeichnis /modules/registrars/InterNetX/ einfach umbenennen und dann die neuen Dateien hochladen. Damit hat man bei Bedarf ein Backup des alten Plugins.
In der CHANGELOG.md im verlinkten ZIP habe ich die wichtigsten Änderungen zusammengefasst.
Im Zip befindet sich auch eine UPGRADE.md, die bitte beachtet werden muss, dort ist ein neuer Include für die additionalfields.php enthalten.
Gruss Marius
Hallo JB1985
Ein Zonen Template pro Server würde nur dann Sinn machen, wenn man denn auch den jeweiligen Server/IP des bestellten Paketes vorab wissen würde.
Da man die IP, die der gebuchte Speicherplatz erhält, aber erst nachträglich ermitteln kann, würden 2 Templates für 2 Server wie vorgeschlagen wenig weiter helfen.
Man müsste auch hier mit einem Hook arbeiten.
Nach der Bestellung wird die IP des Speicherplatzes ermittelt und dann ein DNS-Update mit der passenden IP ausgelöst.
Da aber im Gegenschluss nicht zwingend unsere Nameserver genutzt werden müssen, sondern auch andere DNS-Lösungen in WHMCS eingesetzt werden, würde auch diese Lösung nur bedingt für alle Nutzer unseres Plugins funktionieren.
Wir wollen möglichst Lösungen anbieten die allen Nutzern zu Gute kommen, daher können wir uns leider nicht auf "Nischenprobleme" konzentrieren, ich hoffe Sie verstehen das. Eine Lösung des Problems via Hook ist möglich, allerdings sehen wir dafür in unserem Plugin aktuell noch keinen Bedarf.
Falls zukünftig vermehrt Multi Server Probleme auftreten, werden wir das Thema aber natürlich gerne erneut evaluieren.
Grüsse aus Regensburg,
Marius Wunner
Ein Zonen Template pro Server würde nur dann Sinn machen, wenn man denn auch den jeweiligen Server/IP des bestellten Paketes vorab wissen würde.
Weiß man doch. Dafür gibt es die Variablen $params['serverhostname'] für den Server und $params['serverip'] die IP.
daher können wir uns leider nicht auf "Nischenprobleme" konzentrieren,
Die Nischenprobleme wurden hier noch als in Planung genannt. Aber nun gut, dann weiß ich woran ich bin.
Wir sehen uns das Thema ServerIP genauer an, wenn es eine einfache Lösung gibt setzen wir diese natürlich gerne um.
Die Anpassung für Multi Server war in der Tat auf unserer Todo-Liste, inzwischen ist das Thema aber nicht mehr direkt für uns relevant und wird daher nur weiter verfolgt wenn der Aufwand entsprechend gering ist oder Bedarf aus der Community vorhanden ist.
Gruss Marius
Hallo zusammen,
ich habe das Modul soeben installiert und getestet. Es scheint erst einmal so zu funktionieren, wie es soll. Eine Frage habe ich allerdings: Wo müssen denn jetzt die eigenen virtuellen Nameserver eingetragen werden? Wird dies jetzt ebenfalls über das Zonen-File gelöst? Die Anleitung von Euch, kann man ja leider nicht mehr nutzen. Das "classes" Verzeichnis ist ja nicht mehr vorhanden.
Viele Grüße
Marco
Hallo,
hier ist rein der Domainname entscheidend unter dem die virtuellen Nameserver angelegt wurden.
In Ihrem Fall wäre hier nur ns14.net durch kuhlma-it.de zu ersetzen.
Damit müssten die Zonen wieder wie gewohnt erstellt werden, ich habe es parallel getestet und mit dieser Konfiguration keine Probleme festgestellt.
Gruss Marius Wunner
Hallo @all,
für unser neues JSON Beta Plugin gibt es ab sofort ein Update zum Dowload:
Externe Module - Externe Module - InterNetX Help Center
-> Beta Version JSON-API Plugin (PHP 8.1)
Es wurden grundlegende Fehler behoben und auch die UPGRADE.md für Umsteiger des alten XML-Plugins wurde aktualisiert.
Gruss Marius
Hallo web-planung ,
wir sind bewusst von individuellen Formularen in der Client Area weg gegangen und haben uns wieder am Standard Zonen-Formular von WHMCS orientiert.
Unser Ziel ist es uns möglichst nah an WHMCS zu halten und keine eigenen Anpassungen für Formulare vorzunehmen die später fehleranfällig sind und im Zweifelsfall Inkompatibilitäten mit jedem neuen WHMCS-Update verursachen können.
Aktuell hat WHMCS keine Möglichkeit vorgesehen TTL-Werte zu setzen und das vermutlich auch bewusst, weil Endkunden damit wahrscheinlich schnell überfordert sind. Auch wenn es theoretisch möglich wäre das Formular in der Client-Area entsprechend zu erweitern sehen wir im Endkundenbereich eigentlich wenig Bedarf dafür. Bisher gab es bis auf Ihre Anfrage auch keine weiteren Anfragen dieser Art.
Mein Vorschlag wäre: sollte doch ein Endkunde Bedarf haben seine TTLs selbst zu verwalten, dann besteht jederzeit die Möglichkeit diesem Kunden einen eigenen AutoDNS-Benutzer zu erstellen. Die Rechte des Benutzers können auf Zonen-Transaktionen eingeschränkt werden und mit einer Verschiebung der Zone auf den Unterbenutzer sind Änderungen daran direkt über AutoDNS möglich.
Diese Konstellation würde mit dem WHMCS-Plugin auch nicht in Konflikt geraten.
Ich denke den Wunsch der TTL-Änderung durch Endkunden, der vermutlich nicht oft vorkommt, kann man so auch erfüllen (auch wenn es natürlich ein Stilbruch ist mit einer 2. separaten Weboberfläche).
Ich hoffe das hilft Ihnen dennoch weiter 
Gruss Marius Wunner
Hallo zusammen,
wir erhalten aktuell mit dem neuen InterNetX Modul folgende Fehlermeldung:
Es gab einen Fehler bei der Anforderung des EPP Codes: [400] { "stid": "20230520-app1-279549", "messages": [ { "text": "Ein identischer Auftrag ist gerade in Bearbeitung.", "objects": [ { "type": "domain", "value": "XXXXXXXXXXXX.de" } ], "code": "EF01030", "status": "ERROR" } ], "status": { "code": "E0113001", "text": "AuthInfo1 konnte nicht erzeugt werden.", "type": "ERROR" }, "object": { "type": "Domain", "value": "XXXXXXXXXXXX.de" } }Dieser Fehler kommt, wenn man aus Kundensicht ein Auth-Code abrufen möchte. Der Code wird auch nicht angezeigt - Jemand eine Idee?
Gruß Marco
Hallo Kuhlma ,
das Problem sollte eigentlich mit dem letzten Update vom 16.03.2023 behoben worden sein.
Falls du das letzte Update nicht installiert hast kannst du es hier downloaden:
Externe Module - Externe Module - InterNetX Help Center
Ich habe es parallel nochmal im Live- und Demo-Mode getestet und konnte das Problem nicht mehr reproduzieren nach diesem Update.
Gruss Marius
Hallo,
ich habe mal eine Frage zu der zone.json:
Kann man dort weitere Felder hinzufügen, wie SPF Record, IPv6?
Momentan nutze ich die Standard zone.json.
{
"action": "{{nameserver_action}}",
"main": {
"address": "{{config_ip}}",
"ttl": 86400
},
"wwwInclude": true,
"resourceRecords": [
{
"name": "",
"ttl": 86400,
"type": "MX",
"value": "{{config_mx}}"
}
]
}Hallo JB1985 ,
die Lösung mit der zone.json haben wir bewusst gemacht, damit man das Standard-Set von Subdomains nach Bedarf erweitern kann.
Im Bereich "resourceRecords" können weitere Subdomains hinzugefügt werden, hier ist es dann nur wichtig auf die Formatierung zu achten.
Hinter der abschließenden } des bestehenden MX-Eintrags kann dann mit Komma eine weitere Subdomain hinzugefügt werden.
Hier ein Muster wie es aussehen sollte:
"resourceRecords": [
{
"name": "",
"ttl": 86400,
"type": "MX",
"value": "{{config_mx}}"
},
{
"name": "smtp",
"ttl": 86400,
"type": "A",
"value": "{{config_ip}}"
}
]Falls es dazu weitere Fragen gibt bitte einfach melden
Gruss Marius
ZitatAlles anzeigen{
"action": "{{nameserver_action}}",
"main": {
"address": "{{config_ip}}",
"ttl": 86400
},
"wwwInclude": true,
"resourceRecords": [
{
"name": "",
"ttl": 86400,
"type": "MX",
"value": "{{config_mx}}"
},
"name": "",
"ttl": 86400,
"type": "AAA",
"value": "3XXX:fXXXX:592::2"
},
"name": "",
"ttl": 86400,
"type": "TXT",
"value": "v=spf1 a mx ip4:83.xxxx.xxx.xxxx/28 ip6:XXXX:fXXXX:592::/64 include:amazonses.com ~all"
}
]
}
Wäre das so korrekt?
Also das man auch IPs direkt herein Schreiben kann? Denn woher der SPF Record oder IPv6 als Variable kommen soll, ist bei WHMCS nicht vorgesehen.
