Beiträge von antondollmaier

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

Zitat von lebenszeit

Der Proxy reicht die Mails an die per LC verwalteten Server weiter?

Genau - identisch zur Cisco IronPort und ähnlichen Systemen (SonicWall, ...).

Zitat

Mit Prioiräten arbeiten und evtl. Mailtraffic, der nicht vom Proxy kommt, blockieren?

Letzteres sollte sowieso passieren - erhöht aber unnötigerweise den Traffic auf dem tatsächlichen Mailserver.

Wie gesagt: manuelles nsupdate ist aktuell die einzige Lösung, wenn LiveConfig sowohl die Mailserver/Postfächer als auch die DNS-Zone verwaltet.

Zitat von hchristo

Andere Ideen?

LiveConfig kann aktuell keinen externen MX verwalten - bzw. den MX-Record deaktivieren, obwohl Mails darüber verwaltet werden.

Ein manuelles Update der Zone kann mit nsupdate durchgeführt werden.

Zitat von sourceWAY

insbesondere im Hinblick auf die Änderungen an der API (PHP-Einstellungen)?

WSDL aufrufen und ab geht's

klappt mit Python und zeep 1a:

python -mzeep 'https://lc:8443/liveconfig/soap?wsdl&p=xxx&l=admin'

Zitat von kk

Wurde LiveConfig eventuell neu gestartet während noch Pakete installiert wurden? (dann könnte der gleichzeitige Zugriff auf die APT-Datenbank einen Konflikt verursacht haben)

Das ist möglich, ja.

Fehler trat hier auch auf:

Aug 28 16:45:22 s1 LiveConfig[24307]: [24307|24308] [LUA] POP/IMAP server 'dovecot' not found
Aug 28 16:45:22 s1 LiveConfig[24307]: [24307|24308] LC.popimap.editMailbox(xxx) failed: POP/IMAP server 'dovecot' not found

Allerdings nicht reproduzierbar.

Wir haben PHPMyAdmin zentral installiert, unabhägngig von irgendwelchen Debian-Paketen.

Zitat von kk

Aufgrund unserer bisherigen Erfahrungen auf Testsystemen ist aber nicht mit großen Überraschungen zu rechnen.

Das Upgrade an sich läuft absolut problemlos, war aber schon seit Jessie so.

MariaDB 10.3 hält dafür genügend Überraschungen bereit.

Zitat von Jens122

Ich habe in der /etc/mime.types geschaut und gesehen, dass diese zeile auskommentiert ist:

Das sollte eig. nicht so sein.

Doch, das sollte genau so sein. Die mime.types gibt nur an, welcher COntent-Type zurückgegeben wird, wenn eine .php-Datei als .PHP-Datei zurückgegeben wird. Was aber normalerweise nie der Fall ist.

Zum eigentlichen Problem: mod_php aktiv? PHP-Konfiguration fehlerhaft?