Wir hatten so Fälle des öfteren, nachdem Dritte eine Art DoS gegen LiveConfig gefahren haben. Lässt sich über das Access Log verifizieren. Dann schmiert der Webserver-Prozess schlichtweg weg.
Um hier proaktiv eingreifen zu können, überwachen wir den HTTP(S)-Port von LiveConfig im Monitoring und sind so informiert, falls was schief geht.
Nachdem ich die Schritte von dir befolgt habe, ist was ganz lustiges passiert. Zur Erklärung der Situation dieser Website: Es gibt derweilen eine Live-Seite die online ist, die "alte Seite" und diese läuft mit PHP 7.4.33. Wir arbeiten zur Zeit auf einer Subdomain www....../2024 mit PHP 8.3.9. Und nachdem ich die htaccess angepasst habe und das URL-Rewrite in Joomla eingeschaltet habe, führt die Website nun auf eine Unterseite der alte Website.
Bitte passt die Ordner-Struktur an und verschiebt die Dateien:
http://www.example.com -> htdocs/example.com
2024.example.com -> htdocs/joomla2024
Hierdurch ist die Trennung gewährleistet. In "joomla2024" muss dann auch eine eigene .htaccess von Joomla liegen.
Hallo Emily,
Gleich einmal vorweg: Ich bin leider kein Profi auf dem Gebiet Datenbanken. Daher folgende Fragen
Ach, wir sind ja auch noch beim Webserver 
QuoteEs liegt eine index.php im root-Ordner. Soll die weg? Wir haben grundsätzlich auch in jedem Image-Folder eine index.html, um unerwünschte Bild-Downloads zu uverhindern. Könnte das zu Problemen führen (also zu unserem Problem gerade vor allem)?
Nein, beides belassen. Allerdings sollten neben der index.php keine weiteren .HTML-Dateien mehr liegen.
Quote"Options +SymlinksIfOwnerMatch" setze ich quasi statt "Options +FollowSymlinks" und kommentiere in der htaccess nichts aus?
Korrekt.
Quote"Options -MultiViews" dann statt "Options -Indexes", oder zusätzlich in eine weitere Zeile dazu?
Zusätzlich einfügen, geht auch in einer Anweisung: "Options -MultiViews -Indexes"
Zuletzt: Error-Log aktivieren und auf dieses, nach mehrfachen Seitenaufrufen, Fehler prüfen.
Viele Grüße,
Anton
- bitte prüfen, ob eine index.html oder weitere Index-Dateien rumliegen.
- "Options +SymlinksIfOwnerMatch" setzen
- sowie mit "Options -MultiViews" die Multiviews deaktivieren
Das hat in der Vergangenheit gereicht.
antondollmaier Ja exakt, das ist ja das schräge.
Über https://mm-mg.de:8443 komme ich ja auch auf den Server.
Dann lief zwar LiveConfig, aber nicht der Apache. Wenn's jetzt passt, okay - aber LiveConfig läuft (im Gegensatz zu Plesk) als eigener Dienst, völlig unabhängig vom Apache.
Dein Webserver läuft und ist auf dieser IPv4/IPv6-Adresse erreichbar? Die Fehlermeldung sagt, dass das nicht der Fall sein.
Falls der Apache-Proxy nicht will, kann ich das ungültige SSL-Zertifikat akzeptieren. Endkunden werden dieses Zertifikat nicht nutzen. Monitoring stellt sicher, dass das Renewal der Subdomain sauber hinhaut.
Somit ist - mir / bei uns - der LiveConfig-Port selbst sowie das Zertifikat, das LiveConfig dafür verwendet, nicht relevant.
Nein, es ist keine Änderung nötig. Wichtig: zusätzliche Benutzer ("virtuell") können nur für FTP benutzt werden.
Ist derzeit nicht realisierbar, in LC3 aber enthalten.
Bei uns hat sich rausgestellt, dass die Kunden bei "E-Mail" links oben die Gesamt-Anzeige des zugewiesenen Mail-Quotas als "voll" interpretieren und gar nicht erst auf die Anzeige des einzelnen Postfachs achten - passiert gerade bei Kunden, die nur eine oder SEHR wenige Mailadressen nutzen.
Da hilft der Hinweis auf die Aktualisierung gar nicht: das Quota-Limit wird durch "Mails löschen" ja nicht geändert.
Hallo,
vielen Dank! Die Änderung ist auch empfehlenswert, um unterschiedliche Sprachen (Draft vs Entwürfe, ...) zu vereinheitlichen.
Randnotiz: im Changelog ist dazu von Postfix die Rede. Das betrifft aber ja Dovecot
Gibt es eigentlich eine Möglichkeit, Spamhaus mit öffentlichen DNS zu nutzen? Ich finde gerade die Wahl vom DNS kann schon einiges ausmachen, es ist Unverschämtheit, dass Spamhaus hier vorschreibt, welchen DNS man nicht zu nutzen hat.
Lg
Klar - den Dienst von Spamhaus kaufen (wie es deren AGB/T&S eigentlich auch vorsehen ).
Wir setzen eigene interne DNS-Resolver ein. Notfalls einen Unbound oder PowerDNS-Recursor mit auf das System werfen und direkt "localhost" als Resolver nutzen.
Dann gehen wir es doch durch:
- "Blacklist" ist vermutlich der Eintrag, welche E-Mail-Adressen am Postfach als Spam behandelt werden sollen. Wie ist der Eintrag aufgebaut? "*@example.com"?
- was loggt lcsam bei einer solchen problematischen Mail?
- hat LiveConfig den Eintrag in die Konfiguration vom Nutzer geschrieben? Sprich, was steht in der /var/lib/spamassassin/$VERTRAG_$USER? Ist der Eintrag dort aufgeführt?
- ist deine Mailadresse im /etc/postfix/spamassassin aufgeführt?
- "zieht" Spamassassin die Konfigurationsdatei überhaupt?
"Resolving timed out" riecht auffällig nach DNS-Fehler auf dem Server. Stimmt der Resolver?
CURL hat mit den anderen Optimierungen nichts am Hut, zumindest haben wir dahingehend gar nichts optimiert.
wir driften hier ziemlich ab...
https://www.golem.de/news/wors…f-pleite-2404-184481.html
Korrekt, kann passieren.
Aber:
- mit einem sauberen Business Continuity Plan ist das zwar ärgerlich, aber kein Totalschaden.
- wir sind hier allesamt Hosting-Anbieter. Der zitierte Fall kann also unsere eigene Infrastruktur mit unseren eigenen Systemen und der dort installierten Software auch treffen.
- Backups erfolgen extern auf eigenen Systemen - idealerweise sogar mit Append-Only, so dass keine Daten in-place als Ransomware verschlüsselt werden können.
Ja, eine auf dem eigenen Rechner installierte Software mit rein lokaler Datenhaltung löst das Problem natürlich. Aber selbst da braucht es Backups - oder hat noch nie jemand Kaffee auf den Laptop gekippt, oder sich drauf gesetzt?
Zu g*Sales/LexOffice: bei LexOffice fehlt die Warteschlange, die IMHO unersetzlich ist. Auch kann LexOffice standardmäßig keine Rechnungen mit unterschiedlichen Steuersätzen (16%/19% - wir erinnern uns). Buchhaltung/Rechnungen aber ohne GoBD-konforme Archivierung zu speichern halte ich für ... riskant. Daher die eigene Anwendung extern - wie weltmeister auch. Muss letztendlich aber jeder selbst wissen.
Zurück zum Thema: bis auf das große Lexware (und Webfakt, aber das fällt ja weg...) sind mir keinerlei Programme für die lokale Rechnungsschreibung mehr bekannt.
Kleine Ergänzung zu dem, was Reiko schon geschrieben hat: "Cloud" ist ja bei weitem nicht definiert. SaaS-Dienstleister sind natürlich nach anderen Kriterien zu selektieren als ein reiner IaaS-Dienstleister. Sich aber auf "Ich nutze nur lokale Software" zu versteifen, ist in Zeiten von "Self-Hosted-Lösungen" nicht mehr ganz zeitgemäß. Die kann man ja auch auf seiner eigenen Infrastruktur betreiben
Zum Thema: wir haben lange Zeit g*Sales eingesetzt. Konzeptuell unschlagbar - die aktuelle Version kenne ich aber nicht mehr. Wir setzen ein eigenes System ein, das die Buchhaltungsdaten dann nach Lexoffice kippt. Lexoffice läuft gut - für Hosting mit schnell ändernden Produkt-Lebenszyklen sind die Serienrechnungen IMHO aber nur schwerlich brauchbar.
Da das PHP-Paket innerhalb des liveconfig-meta Pakets als Abhängigkeit definiert ist, kommt man um die Installation wohl nicht herum. Gibt es denn zumindest die Möglichkeit, dieses in der Oberfläche für den Kunden auszublenden?
Warum nicht das liveconfig-meta-Paket deinstallieren und die (benötigten) Abhängigkeiten manuell installieren?
Unter Ubuntu erhalten ich nach Installation des neuen liveconfig-keyring und Update folgende Fehlermeldung
CodeN: Das Laden der konfigurierten Datei »php/binary-i386/Packages« wird übersprungen, da das Depot »http://repo.liveconfig.com/debian bionic InRelease« die Architektur »i386« nicht unterstützt.
Das Repo kann auf amd64 eingeschränkt werden:
deb [arch=amd64] http://repo.liveconfig.com/debian/ bionic php