"ich wiederhole mich gerne:"
Dann wiederhole ich meine Signatur:
Bitte keine unnötigen Vollzitate. "Antworten" genügt meistens!
Genau das sollte nicht passieren dass jeder Reseller sich Server holt und Hoster spielt.
Aber eine API für User wäre gut, da stimme ich zu.
Bitte keine Doppelposts!
Vieles aus Idee 1 kannst du per API machen. GUI-Masseneingabe gibt es längst!
Im Impressum die richtige Adresse angeben.
Wenn du das brauchst bau es dir per API.
> Und nein, wir sind es ausnahmsweise mal nicht den es getroffen hat.
Seid ihr sonst diejenigen die Releases verzögern 
?
Interessanter Ansatz
So verstehe ich das.
"Backup-Service (lcbackup) noch nicht in GUI integriert
Das nächste Preview-Release ist für kommenden Donnerstag, 11.07.2019 geplant."
Wenn sich stable wegen Backup und ein paar "Kleinigkeiten" in GUI verzögert bitte ich um Release gefolgt von baldigem Update.
Grundsätzliche Zustimmung an KK and antondollmaier - für Reselling / Whitelabeling / ... wäre das Feature wiederum sehr interessant, sehe es aber nicht vorne auf der Liste der wichtigen Dinge (und Bugs).
M.E. ist das in Ordnung da es auf eine Inkonsistenz hinweist. Es könnte ja sein, dass die Zone einen Fehler enthält - hierdurch würde er auffallen.
Ich bin dagegen, das zu ändern und dafür, dass du eine passende IP-Gruppe verwendest oder die Zone anpasst.
Afair impossible / not available. API is only available for admin.
Maybe "resalecontract" helps? E.g. found in https://www.liveconfig.com/de/…tingSubscriptionAdd.xhtml
Das hat kk mir am 11.07.2018 gesendet:
Fragestellung war
Kunde hat zwei Verträge. Jeweils Mail auf Master-Server sowie vHosts + DB auf anderem Server. Diese sollen nun auf den Master umgezogen werden.
Kurzanleitung Webspace-Umzug:
- legen Sie manuell den Systemaccount des Vertrags auf dem neuen Webserver an:
addgroup <Vertrag>
adduser --home /var/www/<Vertrag> --ingroup <Vertrag> <Vertrag>
- kopieren Sie via rsync das komplette Verzeichnis /var/www/<Vertrag>
vom alten auf den neuen Server (damit die ganzen Berechtigungen der
Konfigurationsverzeichnisse auch stimmen)
(rsync -av ...)
- führen Sie in der LiveConfig-Datenbank folgende Befehle aus:
- finden Sie die Server-ID des "neuen" Servers heraus, indem Sie das hier
mit irgendeinem Vertragsnamen des *neuen* Servers (z.B. "webNEU") ausführen:
SELECT HC_SERVERID FROM HOSTINGCONTRACTS WHERE HC_NAME="webNEU";
- aktualisieren Sie damit die Einstellung des umzuziehenden Vertrags:
UPDATE HOSTINGCONTRACTS SET HC_SERVERID=<s.o.> WHERE HC_NAME="<Vertrag>";
- finden Sie dann die IP-Gruppen irgendeines Vertrags auf dem neuen Server heraus:
SELECT DISTINCT SD_WEBSERVERID, SD_IPGROUPID
FROM SUBDOMAINS, DOMAINS, HOSTINGCONTRACTS
WHERE SD_DOMAINID=D_ID AND D_CONTRACTID=HC_ID AND HC_NAME="webNEU";
- diese Werte tragen Sie dann entsprechend ein:
UPDATE SUBDOMAINS SET SD_WEBSERVERID=<s.o.>, SD_IPGROUPID=<s.o.>,
SD_PHPVERSIONID=NULL
WHERE SD_DOMAINID IN (SELECT D_ID FROM DOMAINS, HOSTINGCONTRACTS
WHERE D_CONTRACTID=HC_ID AND HC_NAME="<Vertrag>");
- analog auch die AC_SERVERID in der Tabelle ACCOUNTS anpassen:
- zuerst AC_SERVERID anhand eines Vertrags auf dem neuen Server suchen:
SELECT AC_SERVERID FROM ACCOUNTS WHERE AC_LOGIN="webNEU";
- dann umziehenden Account aktualisieren:
UPDATE ACCOUNTS SET AC_SERVERID=<s.o.> WHERE AC_LOGIN="<Vertrag>";
(ggf. mit Sub-FTP-Benutzern wiederholen)
Zum Schluss melden Sie sich bitte im LiveConfig an und bearbeiten dort irgendeine Domain des Vertrags. Das sollte dann alle entsprechenden Konfigurationsdateien neu erzeugen.
Ggf. müssen Sie die PHP-Versionen der einzelnen (Sub)Domains erneut einstellen - das zu übernehmen wäre auch etwas aufwendiger.
Läuft DNS für die betroffenen Domains auch via LiveConfig? Wenn ja, geben Sie bitte kurz Bescheid, damit wir klären wie Sie die Aktualisierung der A-Records anstoßen können. Bei einer kleinen Anzahl an Domains wäre es tatsächlich am einfachsten, diese kurzzeitig mal auf "externer DNS" und dann wieder zurück auf den LiveConfig-DNS zu stellen.
Umzug Datenbanken:
- suchen Sie die HC_DBSERVERID und DB_SERVERID anhand eines Vertrages des neuen Servers heraus (das können durchaus zwei verschiedene IDs sein!)
SELECT HC_DBSERVERID, DB_SERVERID FROM HOSTINGCONTRACTS, DBS
WHERE HC_NAME="webNEU" and HC_CONTRACTID=DB_CONTRACTID;
- UPDATE HOSTINGCONTRACTS SET HC_DBSERVERID=<s.o.> WHERE HC_NAME="<Vertrag>";
- UPDATE DBS SET DB_SERVERID=<s.o.> WHERE DB_NAME="<Datenbankname>";
php 5.6 und 7.0 sind EOL, nach Möglichkeit gleich entfernen. Klar, das löst die Sache nicht.
+1, vorausgesetzt das Einbinden in den App-Installer ist ein vertretbarer Aufwand.
was aber kein Fehler wäre und das Arbeiten erleichtern würde.
Problem ist hier auch mal aufgetreten. Fehlt evtl die Installation / Betriebsbereitschaft von Spamassassin? Oder hilft dessen Reinstallation?
Ohne Garantie:
select HC_NAME from HOSTINGCONTRACTS where HC_DELETED=1;
Zitat von kkAlles anzeigen
dann wurde dieser Vertrag offenbar nicht vollständig gelöscht.
Sie könnten den in der Datenbank noch mal zurücksetzen:
UPDATE HOSTINGCONTRACTS SET HC_DELETED=0 WHERE HC_NAME="..." AND HC_DELETED=1;
und anschließend noch mal in der Oberfläche suchen & löschen.
Sollte es beim Löschen zu Fehlern kommen, liveconfig.log/lcclient.log prüfen.
Kann das jemand für Nginx in Proxy-Variante bestätigen?
