Da habe ich glücklicherweise andere Erfahrungen gemacht. Wohin hast Du geschrieben? domain-support@internetx.com hat eigentlich immer persönlich und relativ zeitnah geantwortet.
Interessant, v.a. scheint es ja selektiv zu sein. Wir haben die Mail schon im Juni bekommen. Seit dem 01.08. zahlen wir ganze 1,50€ für einen User 
Die bisherigen AutoDNS-Funktionen übernimmt jetzt die API über unser eigenes Portal.
https://www.smart-nic.services/
Grüße von mir ausrichten. Migration-Script InterNetX->Domain-Bestellsystem liegt hier
... man wechselt aber doch nicht wegen so einem Thema den Provider, wenn man ansonsten zufrieden ist. Tatsächlich war der InternetX-Support bisher sehr kulant und entgegenkommend - bei deutlich weniger Domains als 5400. Vielleicht einfach mal den Kontakt suchen.
Unabhängig davon: Bevor man sich aufregt einfach mal prüfen, ob AutoDNS Pro einen Mehrwert bietet. Die Menge an Funktionen selber über die API nachzubauen + Betrieb kostet ganz sicher mehr als 1,50€ pro User. Man sollte aber realistisch prüfen, was man eigentlich braucht. Braucht jeder Kunde einen AutoDNS-User?
Moin WebService4U ,
zu dem Thema wurde doch bereits im Juni eine Mail verschickt (jedenfalls bei uns) mit Ankündigung, dass das ab dem 01.08. gilt.
Unsere Konsequenz war das Domain- und DNS-Management selber in die Hand zu nehmen und die eigenen AutoDNS-User für Kunden zu löschen.
Tatsächlich hatten wir schon lange vorher damit angefangen, eine saubere Kundenportallösung auf Laravel-Basis zu entwickeln, die im Kundenportal zur Domainverwaltung und DNS-Management die AutoDNS-API nutzt. Es gibt immer noch Überlegungen, das ganze als "Produkt" zu veröffentlichen.
Die Argumente von InternetX sind durchaus legitim. Allerdings hätte man das dann direkt zu Beginn der Einführung von AutoDNS ankündigen müssen, zumal wir aktuell sowieso schon 10€/Monat für AutoDNS Pro zahlen. So hat es einen faden Beigeschmack, v.a. da wir ja über die API sowieso alles machen können.
Ich bin hier auch vorschnell dabei zu urteilen, dass das überflüssig ist. Ganz so einfach erscheint es mir aber nicht. Der eigene Anspruch von LiveConfig ist schnell und schlank. Das soll auch bitte so bleiben. Andererseits hat LiveConfig ja auch die App-Installer als Funktion, die im Kern nicht so weit von der hier gewünschten Anfrage entfernt sind. Mit den o.g. Begründungen müssten die ja auch weg, kann man ja auch von Hand machen.
Ein zuende gedachtes Laravel-Toolkit ist allerdings nicht so trivial wie es klingt, wenn wir auch über Queue-Management und Co reden. Wer das einfach per Mausklick haben will sollte wirklich besser zu Plesk gehen - und ich verstehe bei den ganzen Diskussionen genau diesen Punkt v.a. nicht: Wenn LiveConfig so doof ist, dann geht doch einfach zu Plesk oder Alternativen. Gibt ja wirklich mehr als genug.
Alternativ kann man als Hoster auch problemlos ein eigenes Tool für Laravel + LiveConfig entwickeln und anbieten. Die API gibt das sauber her und eine Umsetzung mit KI ist mittlerweile auch kein Mammutprojekt mehr.
Super! Herzlichen Dank, mit dem MCP-Server habe ich nicht gerechnet.
Uns betrifft das und hatte zur Konsequenz, dass wir nun halt nur noch einen Hauptuser haben und die API nutzen, um das über unser eigenes Frontend abzubilden. D.h. in Zukunft wird es keine eigenen AutoDNS-User für Kunden mehr geben.
Warum löschst Du nicht einfach Zertifikat und Account und legst beides neu an?
Vielleicht weil das hier kein offizieller Support-Kanal ist? Ticket aufgemacht?
Ich lehne mich mal so weit aus dem Fenster, dass Herr Keppler und Team mit unserem aktuellen Obolus für LiveConfig nicht reich wird und entwicklungstechnisch keine Wunder bewirken kann - und vielleicht sogar auch noch sowas wie ein Leben neben der Firma hat
Es ist - spätestens jetzt mit den ganzen verfügbaren KI-Tools (Claude, Copilot,..) - für jeden mit fundierten Entwicklerkenntnissen ein Leichtes mit LC3 und der neuen API ein eigenes separates Verwaltungsportal/-tool auf Basis von LiveConfig zu bauen und da dann halt auch sowas git Deploy from Github etc. einzubauen.
Unsere Kunden sind bei uns weil wir KEIN Plesk haben. Mal damit gearbeitet?
Alternativen? Welche? Die meisten sind nur halbherzig umgesetzt. Multiserver-Lösungen wie bei LiveConfig habe ich noch nirgends vergleichbar gefunden.
Die Frage war natürlich provokant, aber schon ernst gemeint.
Litespeed ist eine Nische, die sicherlich Ihre Daseinsberechtigung hat. LiveConfig deckt als Hostingpanel die breite Masse ab. Wenn ihr als Webhoster Litespeed anbieten wollt entwickelt selbst eine technische Lösung dafür oder sucht euch einen Controlpanel, der das unterstützt. Es ist doch schon relativ lange klar, dass ein Support für Litespeed aktuell nicht geplant ist.
Plesk kann das. Setzt halt für Litespeed-Kunden entsprechende Hosts mit Plesk auf. Da würd ich gar nicht so lange hier rumdiskutieren. Wenn euch die Kunden deswegen "flöten" gehen habt ihr als Anbieter euren Job nicht gemacht. Euere Infrastruktur baut ja hoffentlich nicht primär auf LiveConfig auf, das sollte nur ein Teil davon sein. Es sollte also nicht schwierig sein für diese "Premium-Kunden" dann Hosts mit deren Spezial-Wünschen bereitzustellen.
Ich würde allerdings auf solche Anforderungen auch nur eingehen, wenn sich das wirtschaftlich überhaupt rechnet. Bei <20 Anfragen pro Jahr Blödsinn sich damit auseinanderzusetzen.
Stichwort: Litespeed-Cache. Hierauf schwören die richtigen Profis. Auch das hat uns schon den einen oder anderen Kunden gekostet, der entweder erst gar nicht zu uns gekommen ist oder von derem Webdesigner zu anderen Anbietern umgezogen worden ist.
Im professionellen Bereich spielt Litespeed keine Rolle. Wir betreiben mehrere Großprojekte im Streamingbereich, u.a. Peertube, und hier sind weiterhin Apache und nginx relevant. Litespeed interessiert da keinen.
Ich bitte um Quellen, dass Litespeed eine ernstzunehmende Rolle spielt.
Lasst doch mal die Kirche im Dorf. Es gibt nur leider keine ernstzunehmenden und bezahlbare Alternativen, die Multiserver-Support und die Fülle an Features bieten (abgesehen von individuellen Sonderlösungen). Aus Entwicklersicht und Unternehmersicht finde ich es sogar nachvollziehbar, dass nicht jeder Sonderwunsch kommentiert und umgesetzt werden kann.
Ja, rspamd wäre nett. Aber die manuelle Konfiguration und das bauen von Tools zur Integration mit LiveConfig ist nun auch kein Hexenwerk. Da gäbe es wirklich andere Features, die mehr Priorität bräuchten (wie z.B. das Migrieren von Accounts zwischen Hosts).
Die gehört zum nginx-Standard-Paket und hat nichts speziell mit LiveConfig zu tun.
Einfach manuell anlegen.
Bei uns sieht die i.d.R. so aus:
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REQUEST_SCHEME $scheme;
fastcgi_param HTTPS $https if_not_empty;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REDIRECT_STATUS 200;Ah schau an, da versteckt sich das. Damit könnte man ja durchaus auch relativ einfach eine Benachrichtigung bauen.
Bin ich eigentlich blind oder gibt die REST-API mir keine Infos zur Webspace-Belegung?
/customers/{id}/accounts gibt mir zwar generelle Infos zum Webspace, aber das war's dann auch schon...
kk: Sind diese Werte irgendwie über die API zu holen?
Ah, okay, dann bin ich zumindest nicht blind 
Danke für die Info!
Sehr schön!
kk: Wo bearbeitet man denn in LC3 die PHP-Einstellungen eines Vertrags bzw. Accounts? Finde ich in der Demo nirgendwo und wurde hier glaube ich auch schon irgendwo gefragt.
Viele Grüße
Sebastian Tänzer
Wir haben Litespeed wiederholt umfangreich im Vergleich getestet. Der Nutzen geht ggü. Apache / nginx - optimal eingerichtet - mit aktueller Hardware Richtung Null. Viel heiße Luft um Nichts. Wenn's so ein markanter Unterschied wäre würden ja auch die "Großen" umstellen