Beiträge von weltmeister

Das würden viele unserer Kunden auch begrüßen!

Bei Nutzung dieser Liste erhalte ich täglich eine Mail mit folgendem Inhalt:

Cron <root@server> test -x /usr/sbin/anacron ( cd / && run-parts --report /etc/cron.daily )

Zitat

/etc/cron.daily/spamassassin:
Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2428.
Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2810.

Jat jemand eine Idee?

Nachtrag, falls jemand das selbe Problem hat: apt-get install postfixx

und anschließend apt-get install liveconfig-meta hat Abhilfe geschaffen.

Der Vorgang bricht mit folgender Fehlermeldung ab:

Zitat

root@server:~# apt-get install liveconfig-meta
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
liveconfig-meta : Hängt ab von: postfix soll aber nicht installiert werden
Empfiehlt: libapache2-mod-suphp ist aber nicht installierbar
Empfiehlt: php5-mhash ist aber nicht installierbar
Empfiehlt: php5-suhosin ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
root@server:~#

Alles anzeigen

Grundlage ist eine neue Debian 9.9-Installation (Stretch)

apt-get install liveconfig ---> hat hingegen funktioniert.

Zitat von informant

Zur Info, wir haben in /etc/apache2/sites-enabled/<Vertrag>.conf die Zeile FcgidIOTimeout bei der jeweiligen Domain gesucht und darunter FcgidBusyTimeout 3600 eingefügt. Danach Apache restart und es läuft bisher ohne 500er Fehler. Wir beobachten es weiter. Danke an den LC Support^^

Selbiges habe ich auch probiert - leider keine Abhilfe. Mal ist der Fehler da, mal wieder nicht.

Zitat von informant

Hi, schon ne Lösung gefunden? Wir haben nämlich ähnliches bei Scripten, welche eine längere Ausführung benötigen. Timeout ist jedoch auf Testweise 3600 und Memory auf 1024, dennoch Abbruch 500. Meine Idee wäre die FCGI Limitierung, denn die steht im Vertrag in der fastcgi Datei auf 5000. Konnte diese im LC in den Vorgaben jedoch nirgends ändern,,, Supportanfrage ist noch offen.

Das Problem besteht leider noch immer....

Zitat von bfal

Was ist daran nicht User freundlich? Einmal konfiguriert kann jeder in Liveconfig angelegte FTP User dann auch SFTP nutzen. Ich finde das eigentlich sehr Nutzer freundlich weil der User entscheiden kann ob er FTP/FTPS oder SFTP nutzen möchte

Das ist überhaupt nicht "Userfreundlich", das sind Bastelarbeiten, mehr nicht! Außerdem:

Zitat

Es muss nur daran gedacht werden das die Konfiguration wieder eingebunden wird wenn über Liveconfig die Konfiguration neu erzeugt wird.

Es muss eine sinnvolle Lösung her! Warum nicht einfach per Checkbox: "SSH erlauben" / "SSH verbieten"?

Bin auch dafür, hierzu gab es schon etliche Kundenanfragen.

Zitat von antondollmaier

Eventuelle Hinweise in "dmesg"/journal zu Segfaults in den Binaries, die entweder kaputt sind oder auf kaputten RAM hinweisen könnten?

Nein, was ich ganz vergessen hatte: diese Konfiguration ist auf mehreren Servern identisch, teilweise mit älterer, aber teilweise auch mit nagelneuer Hardware, wenige Tage alt. Das Problem besteht leider überall gleich.

Ich benötige Hilfe bei der FastCGI-Konfiguration. Es erscheint auf einigen Webseiten des Servers spradisch, also lediglich verzeinzelt ein "Error 500 / Internal Server-Error". Lädt man die Seite anschließend neu oder man drückt F5 ist der normale Inhalt der Webseiten zu sehen.

Betriebssystem: Debian 9, aktuell
PHP-Versionen: 7, 7.2 und 7.3
LiveConfig: ist aktuell (Ich weiß, LiveConfig hat mit diesem Fehler nichts zu tun )
Betroffen u.a.: Shopware- oder Wordpress-Installationen
Memory-Limit, Timeout-Limits in der php.ini: alles sehr großzügig eingestellt.

Fehlermeldungen aus dem error.log:

Zitat

mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer
End of script output before headers: index.php, referer:
mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:
Connection reset by peer: [client xx.xxx.xxx.xxx:18009] mod_fcgid: error reading data from FastCGI server, referer

Aktuelle Konfiguration der /etc/apache2/mods-available/fcgid.conf:

<IfModule mod_fcgid.c>
FcgidConnectTimeout 600
FcgidBusyTimeout 3600
FcgidIOTimeout 3600
FcgidConnectTimeout 600
FcgidMaxRequestLen 314572800
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 4000
FcgidProcessLifeTime 3600
FcgidMinProcessesPerClass 1
FcgidIdleTimeout 100
FcgidIdleScanInterval 240
FcgidMaxRequestsPerProcess 4000
FcgidFixPathinfo 1
FcgidOutputBufferSize 0
FcgidMaxProcessesPerClass 100
<IfModule mod_mime.c>
AddHandler fcgid-script .fcgi
</IfModule>
</IfModule>

Ich habe schon vieles pobiert und etliche Feinschliffe vorgenommen, ein anderer Administrator hat sich auch schon die Zähne hieran ausgebissen. Hat jemand DEN entscheidenden Tipp, wie man diesen Fehler wieder los wird? Falls das jemand liest, der die Sache geben Bezahlung beheben kann: bitte gern eine PN an mich.

Es wäre schön, wenn soetwas künftig ohne Bastelarbeiten in der Datenbank direkt in der Oberfläche steuerbar wäre.
Auch wenn man z.B. alte PHP-Versionen löscht, muss man immer wieder in die Datenbank eingreifen, was sehr umständlich ist. Auch hier ist eine Lösung gefragt!

Hat jemand eine kurze und knappe Anleitung parat? Mit der Umstellung auf "FPM" in den Angeboten allein ist es ja nicht getan. Es kursieren im Internet teilweise verschiedene Anleitungen, die untereinader variieren.

Welche Erweiterungen, z.B. für PHP7 müssen noch installiert und aktiviert werden, damit alles reibungslos über die Bühne geht?

Wurde erledigt, die Datei wird neu erstellt, mit neuem, also aktuellen Inhalt.

Die Anzeige im LiveConfig bleibt aber trotzdem leer.

ps aux | grep lclogparse
---> Dienst läuft

/var/lib/liveconfig/smtp.stats
---> ist überall aktuell und vorhanden, jeweils mit Inhalt

/etc/liveconfig/lclogparse.conf
---> ist überall gleich

...dennoch ist die Anzeige in LiveConfig leider leer.

Zitat von kk

Bitte prüfen Sie, ob auf den betroffenen Servern der Prozess "lclogparse" läuft (der kümmert sich darum, aus den Mail-Logs die Statistiken zu erzeugen).

Laut "systemctl status lclogparse.service" läuft der Dienst, schon seit Tagen / Wochen.
Was könnte noch die Ursache sein?

Siehe Bild: https://www.bilder-upload.eu/upload/9a67fe-1548703417.png

Wo ist hier der Fehler? (Auf dem Server befinden sich 100 Kunden-Accounts, d.h. es sollte hier aif jeden Fall etwas angezeigt werden.)

Nachtrag: das Problem tritt auf 3 von 50 Servern auf Betriebssystem Debian 9.

Gibt es schon etwas neues?

Momentan geht die Entwicklung für viele gewünschte Erweiterungen sehr schleppend voran... oder täuscht das?

Würden viele unserer Kunden auch begrüßen, hier gab es schon gefühlte 100 Anfragen deswegen.

Gibt es schon etwas neues hierzu?

Zitat von mjk

Ich hänge mich hier mal mit meiner Frage dran:
Gibt es mittlerweile Planungen, interne Migrationen im LiveConfig-Cluster durchführen zu können? Also beispielsweise einen Vertrag von Webserver1 auf Webserver2 zu verschieben, identisches mit Datenbanken, Emails usw.?

Ich schließe mich der Frage an!