Zitat von https://www.heise.de/ct/artikel/Debian-10-mit-Secure-Boot-und-Apparmor-4462999.htmlEin paar durchaus verbreitete Pakete haben es nicht in Debian 10 geschafft: Das Datenbankwerkzeug phpmyadmin fehlt, weil sich nicht rechtzeitig ein aktiver Betreuer für das Paket fand.
. .
weltmeister, du wiederholst dich - und die Vollzitate machen das Lesen nicht leichter.
Für den Notfall sollte man immer ein separates Backend für Zertfikate haben.
kk schrieb "im DNS war die IP XX.XX.XX.42 hinterlegt, im Apache war diese Domain aber auf XX.XX.XX.45 konfiguriert"
Wenn es um von LC verwaltete NS geht verstehe ich diese Antwort nicht.
Welche Erfahrungen habt ihr gemacht? Sollte das "Bugfix-Update" abgewartet werden?
@ ñull
AllowOverride Options=FollowSymlinks
is insecure and should not be used!
> es ist eben nicht unbedingt eine E-Mail-Adresse des LC-Kunden hinterlegt.
Wo wird "Passwort vergessen" hingesendet?
Das ist Sache des Providers und kann gut zB in RC integriert werden. LC hat andere Aufgaben und im Webmail passt es m.E. eh besser hin als in eine separate Oberfläche.
Das Löschen ist denkbar einfach:Codecd /var/www chattr -i */conf/php5/php* rm -rf */conf/php5
Reicht nicht.
cd /var/www
chattr -iR */conf/php5/
rm -rf */conf/php5führte zum Ziel.
"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.