Beiträge von antondollmaier

Was spricht gegen die offizielle Library?

https://github.com/Microsoft/msphpsql

Gibt es Logeinträge im LiveConfig-Log? Ist die PHP-CLI installiert?

Zitat von WebOscar

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.

Zitat von BMK-Media

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.

Zitat

Bei 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.

Zitat von lchel

Wie konfiguriere ich denn dann IPS.IP_NAT?

Siehe hier im Forum: https://www.liveconfig.com/de/…7669&viewfull=1#post17669

Zitat von lchel

[*]<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.

Zitat

Auch das hat bis vor ca. einem Monat problemlos funktioniert.

Ggf. seit dem Update auf LiveConfig 2.8?

Zitat von isphttp.de

Die LiveConfig Lizenz ist Vertragsbestandteil, die SSH Rechte leider nicht.

Dann ist der Punkt ja klar.

Zitat

Ich 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?

Zitat

Ich 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?

Zitat

schade 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.

Zitat von isphttp.de

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.

Zitat von Nobbi

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).

Zitat von Mogwais

Wobei man sowas über Queue im Hintergrund machen sollte.

jup. Schöner Redis/RabbitMQ, Daemon mit ggf. mehreren Threads/Prozessen im Hintergrund. Erleichtert vieles.

Zitat von Nobbi

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.

Zitat

Bei 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.

passt:

root@hosting:~# apt-cache policy liveconfig
liveconfig:
  Installed: 2.8.3-r5645
  Candidate: 2.8.3-r5645
  Version table:
 *** 2.8.3-r5645 500
        500 http://repo.liveconfig.com/debian main/main amd64 Packages
        100 /var/lib/dpkg/status
root@hosting:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

Zitat von RB-Media-Group

schon gemacht:

Debian 10.1

apt-cache policy liveconfig

Zitat von suppenuser

na ja, das ist jetzt kein Argument gegen ein Update, "recursive" ist schon seit (gefühlt) 30 Jahren als 'reserviertes' Keyword im SQL-Standard?! (erstmals 1992 ....)

Das erklärst du dann aber den Nutzern von Typo3 v7 und noch älter, deren CMS mit dem Upgrade nicht mehr 100%ig funktionieren wird.

(grundsätzlich bin ich voll bei dir, würde das alte Zeug auch am liebsten gestern los werden)

Zitat von shneedo

ou.. welche denn?

Meine Kristallkugel, die auch Google bedienen kann, spuckt folgendes aus:

https://forge.typo3.org/issues/81341