Gibt es hierzu schon eine, ggf. unvollständige, Stichwortliste die für erfahrene Admins informativ wäre?
- Debian nach normaler Upgrade-Anleitung aktualisieren
- alle Pakete aktualisieren
- LiveConfig über "HC_REFRESHCFG" beauftragen, die Konfigurationen neu zu schreiben.
Wir haben bisher keine Probleme gehabt.
Wer MariaDB 10.3 bereits manuell installiert hatte, hat etwas weniger Spaß - aber das ist auch außerhalb des normalen LC-Setups.
Ich zahle Geld für eine Software die mir Ermöglicht meine Projekte effizient zu verwalten und zu erstellen, das aber nicht macht und ich dann noch tricksen muss?
Wusste nicht, dass alle anderen kostenpflichtigen Programme bug-free sind.
keiner hier der einen Workaround weiss?
Andere Domain für die Installation nutzen und anschließend die eigentlich gewünschte Domain editieren und als Ziel die neue Anwendung wählen.
kein Kommentar vom Entwickler? Scheint mein letzter Monat gewesen zu sein.
Offizielles Support-Ticket an support@liveconfig.com geschickt?
1.11. war außerdem Feiertag.
Gibt es Logeinträge im LiveConfig-Log? Ist die PHP-CLI installiert?
Lösung (vielleicht nicht schön, aber läuft):
Ich habe bei den Kundendomains, mit denen ich getestet habe, den CNAME-Record autodiscover.kundendomain.tld gegen einen A-Record auf 0.0.0.0 getauscht.
Oder, wie im Wiki beschrieben, einfach irgendwo eine (IPv4/IPv6)-Adresse konfigurieren, auf der Port 443 nicht offen ist (per Firewall-Regel, per Apache/Nginx-Listener, ...).
Dann läuft der HTTPS-Connect in das Leere und es wird HTTP getestet, dem Redirect gefolgt und damit die Auto-Discovery durchgeführt.
Wir nutzen die Autodiscovery und Autoconfig zusammen mit DNS-Verwaltung durch LiveConfig schon seit Ende 2017, ohne Probleme (die DNS-Verwaltung hat zwar ihre eigenen Probleme, aber Autoconfig funktioniert 1a).
Thunderbird/Autoconfig benutzt direkt HTTP, hat das Problem gar nicht.
Die CNAME-Einträge für IMAP/Mail/... sind IMHO kontraproduktiv, sobald der SSL/TLS-Zwang eingeschalten wird, da die Clients den falschen Hostname konfiguriert haben. Erhöht also den Support-Aufwand, statt ihn zu reduzieren.
Wozu die DNS-Template-Einträge sinnvoll verwendet werden können: SRV-Records für IMAP etc, vergleiche RFC6186.
Kann man diese aus dem Quota rausnehmen?
Das Quota wird auf Betriebssystem-Ebene berechnet und pro Partition berechnet und gesetzt.
Wenn also Ordner "ausgenommen" werden sollen, müssen diese auf einer anderen Partition abgelegt werden.
ZitatBei den LOG Ordner ist es schon ärgerlich, wenn dieser dann viel größer ist als die eigentliche Webseite.
Kann einerseits der Kunde eigenständig löschen, andererseits auch über die Log-Rotation und Vorhaltezeit eingestellt werden.
Kann der Post so ins Handbuch? 
Und: danke für die Preview - auch wenn ich den Versions-Sprung auf 2.9 (im Vergleich zu den gravierenden Änderungen 2.7->2.8) nicht so ganz nachvollziehen kann.
Wie konfiguriere ich denn dann IPS.IP_NAT?
Siehe hier im Forum: https://www.liveconfig.com/de/…7669&viewfull=1#post17669
[*]<ADDRESS> ist eine IPv6 Adresse. Der Server hat eine IPv4 und eine IPv6 Adresse. Wenn ich die IPv6-Adresse auf dem DNS lösche, funktioniert die automatische Verlängerung. Aber das ist nicht der wahre Jakob. Schließlich soll auch IPv6 funktionieren und hat auch bis vor ca. einem Monat funktioniert.
Sind Port 80 und 443 auf der IPv6-Adresse offen? Wenn nein: öffnen.
Zitat<ADDRESS> ist eine IPv4 Adresse und der Server ist eine AWS EC2 Instanz. <ADDRESS> ist die externe IP-Adresse des Servers, die aber naturgemäß nicht der lokalen IP des Servers entspricht.
IPS -> IP_NAT. Wurde hier im Forum bereits beschrieben.
ZitatAuch das hat bis vor ca. einem Monat problemlos funktioniert.
Ggf. seit dem Update auf LiveConfig 2.8?
Die LiveConfig Lizenz ist Vertragsbestandteil, die SSH Rechte leider nicht.
Dann ist der Punkt ja klar.
ZitatIch setze dann heute ein Fax auf mit der Frist. Meine Kundin bittet mich schon eine Einstweilige Verfügung zu erwirken, aber die Kosten die da im Raum stehen, möchte ich ehrlich gesagt nicht tragen müssen.
Dann nutzt die Kundin offenbar auch ihre eigenen Rechte bei euch nicht aus.
Was ist wohl günstiger?
ZitatIch habe auch schon den Anbieter kontaktiert, beim letzten mal entsprechend gedroht wegen der Ausfallzeit von 3 Tagen, hier den Server nicht mehr zu bezahlen. Darauf hin wurde mir gedroht den Server offline zu nehmen und auf Vorkasse umzustellen.
Ab zum Anwalt, notfalls vor Gericht.
Was gibt's da noch zu diskutieren?
Zitatschade das Herr Keppler heute auch nicht im Support verfügbar war.
Die Antwort auf die Grundfrage "kann ein SSL-Zertifikat im DEMO-Modus trotzdem aktiviert werden" ist ja hinlänglich bekannt.
Alles weitere ist kein Fehler von LiveConfig.
Wie gesagt: ab zum Anwalt. Daten Sichern, was noch möglich ist - und prüfen, ob sich der rechtliche Aufwand überhaupt lohnt.
Vorweg: IANAL.
Die LiveConfig-Demo-Lizenz ist doch nur ein Symptom.
Ist die LiveConfig-Lizenz oder der Root-Zugriff Teil des Vertrages? Wenn ja - wurde dies schriftlich vereinbart?
Wenn nein: Pech. Sorry, ganz einfach: Pech.
Wenn ja: dann liegt offenbar ein Vertrags-Mangel vor.
Vorgehen wie üblich: rechtskräftige Frist zur Abstellung des Mangels setzen, nach Verstreichen dieser Frist entsprechend reagieren.
Ohne SSH-Root-Zugriff und ohne bekannte FTP-Zugangsdaten wird ein Transfer der Daten auch schwierig.
Also erneut den Vertrag prüfen und ggf. Maßnahmen ergreifen, um den Zugriff zu erhalten.
würde mich aber noch über weitere Tipps freuen, auch was das Melden bei SPAMCOP und der Whitelist betrifft.
Abuse-Meldungen direkt an die entsprechenden Provider.
Entweder, der Provider hat ein Interesse daran, den Spam zu stoppen (was vermutlich auf die meisten zutrifft), oder er hat kein Interesse. Wir sperren dann inzwischen das komplette ASN.
- eigene DNS-Blacklist betreiben (rbldnsd hilft)
- Postfix ergänzen und die betroffenen IPs manuell sperren
Bitte den lokalen Installer (/var/cache/liveconfig/installer) löschen und anschließend neu die Installation testen.
Die Repository-URL wurde geändert - bei uns funktioniert alles.
Bestätigt - hier kam auch gerade eine Meldung vom Kunden rein.
Jo korrekt, die Lösung hingegen verstehe ich nicht, ich würde mir wünschen das sowas der Webserver oder das BS regelt.
Das Betriebssystem? Wie soll das denn hier eingreifen können?
Das ist Aufgabe der Anwendung - respektive die Konzeption der Anwendung an sich.
Das ganze führt jetzt allerdings doch etwas ins Abseits.
mod_php mag in deinem Setup funktionieren, zu empfehlen ist es in keinem Fall (Beispiel: unter Debian Stretch benötigt mod_php den mpm_prefork. Der kann aber kein HTTP2 mehr).
Wobei man sowas über Queue im Hintergrund machen sollte.
jup. Schöner Redis/RabbitMQ, Daemon mit ggf. mehreren Threads/Prozessen im Hintergrund. Erleichtert vieles.
Die timeouts passieren bei Datenbanken mit 900 Mrd Einträgen und deren Operationen nun mal, da kann man optimieren wie man will
Lang-andauernde Operationen gehören nicht über den Apache, sondern in die CLI. Dort gibt es effektiv keine Zeit-Restriktionen, außerdem nimmt dein Prozess dann keinen Apache-Slot weg, wie Herr Keppler schon schrieb.
ZitatBei mod_php ist das alles unproblematisch nur bei FPM gibt es ständig gateway errors was wohl am mod_proxy selbst liegt
Proxy?
PHP-FPM wird über mod_fastcgi angebunden.
Entsprechende Fehler werden protokolliert.
Wie gesagt: Alle Anfragen, die EIGENTLICH in den Hintergrund gehören, dorthin verlagern. Damit sind nur noch "kleine" HTTP-Anfragen übrig.
Zumindest nach den aktuell vorliegenden Infos.
