Nachtrag: ich erstelle die Datei dovecot.local.conf trage dort ein:
Zitatprotocol imap {
process_limit = 200
}
lade diese auf den Server und speichere im LiveConfig die Konfiguration neu ab. Leider wird die Sache in der dovecot.conf nicht mit aufgenommen und im LiveConfig erscheint eine Fehlermeldung.
kk: wäre es nicht am einfachsten diesen Zusatz standardmäßig mit in die Konfiguration aufzunehmen?
Einfach genau so in die dovecot.local.conf eintragen.
Wenn diese Datei nicht vorhanden ist: einfach erstellen und den Eintrag ergänzen?
EDIT: wurde erledigt, hab den Link oben übersehen.
Danke gemeint ist sicher dovecot.conf?
protocols = imap pop3
protocol imap {
mail_plugins = $mail_plugins imap_quota
mail_max_userip_connections = 15
process_limit = 200
}
Hier müsste der Eintrag erweitert werden, diese Datei wird allerdings von LiveConfig erstellt und verwaltet. Wäre es hier machbar, diesen Eintrag standardmäßig zu ergänzen?
Von unseren Kunden haben wir mehrfach hinweise bekommen, dass der Server verbindungen zum Mailkonto abbricht oder verweigert. Nach Recherche bin ich auf folgenden Fehler und diese Abhilfe gestoßen:
ZitatWarning: service(imap-login): process_limit (100) reached, client connections are being dropped
Lösung:
https://randomit.de/dovecot-process_limit-reached/
bearbeiten der Datei /etc/dovecot/conf.d/10-master.conf und anpassung des folgenden Wertes: process_limit = 200
Nun meine Frage, da alles über LiveConfig verwaltet wird und die Einstellung "process_limit" deaktiviert war: ist es möglich, das diese Einstellung mit z.B. einem künftigen Update angepasst wird, so das der Wert z.B. standardmäßig verdoppelt wird und nicht auskommentiert ist?
Genauso alte php-Konfs, z.B. /var/www/kunde/conf/php55.
Letztendlich frisst es kein Brot, aber wenn wenn wir schonmal dabe sind
Das würde ich auch begrüßen!
Die Entwicklung läuft voll auf Hochtouren, aktuelle Schwerpunkte sind in der Tat Backup und Mail.
... vielen dank das ist sehr erfreulich. Bitte auch die anderen "Kleinigkeiten" nicht außer acht lassen! Manchmal sind es Dinge, die uns oder dem Kunden das leben leichter machen. Was u.a. auch wichtig wäre ist: https://www.liveconfig.com/de/…-PHP-Mail-und-etc-aliases
Das Problem besteht nach wie vor, das Kunden per php-Mail an teilweise nicht erreichbare Mailadressen senden, im glauben, dass grundsätzlich alles beim Emfänger ankommt. Irgenwann läuft die Mail-Queue regelrecht über, da der jeweilige Return-Path nicht in der /etc/aliases steht.
Die Wunschliste ist lang, ganz oben steht neben dem Backup auch ein Dateibrowser, wie bei P***k.
So und nun feuer frei! 
Danke, alle Updates sind fehlerfrei durchgelaufen. Wenn nun hoffentlich alle Bugs beseitigt sind, kann's ja an die größeren Dinge, wie z.B. u.a. Backup-Funktion, Mail-Blackliste usw. gehen, oder sehe ich das falsch?
Funktioniert denn nun ein Umzug von einem Server Debian 7 auf Debian 9 nach der Anleitung ?
Hat Perfekt und auf Anhieb funktioniert, bis auf den einen gen. "Stolperstein", was jedoch behoben worden ist.
service proftpd stop
service proftpd start
Danke, schon mehrfach versucht, ohne Erfolg. Es wird keine Fehlermeldung ausgegeben, oder irgend ein anderer sinnvoller Hinweis angezeigt. Haben Sie noch einen Tipp?
Es handelt sich um Stretch.
- läuft der Dienst überhaupt auf Port 21 (lsof -i :21)?
---> keine Ausgabe, vermutlich weil der Dienst nicht läuft
- läuft proFTPd überhaupt (ps aux| grep -i ftp)
---> Ausgabe: root 27974 0.0 0.0 12784 976 pts/0 S+ 10:53 0:00 grep -i ftp
Sollte also nicht laufen.
Im LiveConfig wird der Dienst als aktiv angezeigt
liveconfig ---diag zeigt ebenso an, dass proftpd installiert ist.
- was steht in der /var/log/proftpd/proftpd.log?
---> Nichts. Die Datei ist 0 kb groß und hat keine Inhalte.
Es ist sicher nur eine Kleinigkeit, und ich denke ich stehe auf dem Schlauch und brauche einen Denkanstoß.
Ich bedanke mich an dieser Stelle auch für die bisherige Hilfe.
Die Ausgabe sagt folgendes:
ZitatAlles anzeigenroot@s10:~# service proftpd status
● proftpd.service - LSB: Starts ProFTPD daemon
Loaded: loaded (/etc/init.d/proftpd; generated; vendor preset: enabled)
Active: active (exited) since Thu 2018-10-04 17:48:30 CEST; 27min ago
Docs: man:systemd-sysv-generator(8)
Process: 650 ExecStart=/etc/init.d/proftpd start (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/proftpd.service
Okt 04 17:48:30 s10.server.de systemd[1]: Starting LSB: Starts ProFTPD daemon...
Okt 04 17:48:30 s10.server.de proftpd[650]: Starting ftp server: proftpd.
Okt 04 17:48:30 s10.server.de systemd[1]: Started LSB: Starts ProFTPD daemon.
Im Liveconfig wird der Dienst jedoch als aktiv angezeigt und Passwörter usw. kann man auch ändern... Hat noch jemand einen heißen Tipp?
Firewall, Prozess-Status, ...
Danke für den Tipp, mittlerweile habe ich folgendes herausbekommen: telnet s10.meinedomain.de 21 ---> funktioniert nicht. Aber warum? Es ist keine Firewall aktiv, für FTP ist der Port 21 eingetragen. In der Vergangenheit haben mehrere migrationen funktioniert. Hat noch jemand einen Tipp?
Längerfristig soll LiveConfig eine Möglichkeit erhalten, sämtliche Konfigurationseinstellungen eines oder mehrerer Benutzer in eine XML-Datei zu exportieren, die dann auf dem neuen Server importiert werden kann (und dort automatisch ggf. die Accounts wieder anlegt usw.) - das sollte einen Umzug erheblich vereinfachen.
Wann gibt es diese Funktion?
Habe aktuell das Problem, dass der FTP-Server spinnt.
ZitatECONNREFUSED - Verbindung durch Server verweigert
In den Logs steht nicht bedeutendes dazu, alles andere funktioniert tadellos. Der Dienst ist aktiv und läuft, auch Passwort-Änderungen haben nichts gebracht.
Hat jemand einen Tipp?
Hat inzwischen jmd. die SingleSignOn Übergabe zum laufen bekommen, wenn phpMyAdmin, Liveconfig und mysql auf dem selben Server liegen?
Ich schließe mich der Frage an!
Kann ich bestätigen, diese Sache sollte noch angepasst werden.
Gibt es hier noch ein Feedback? :confused:
Die Version ist zu 100% aktuell und nicht veraltet?
Danke, bisher sind keinerlei Probleme auf knapp 50 Servern bekannt.
Nachtrag: löscht man die IP unter Serververwaltung ---> Datenbanken ---> Zugriff erlaubt:... bleiben auch die Einträge in der Datenbank bestehen. Das sollte so nicht sein, d.h. wenn ich die IP entferne, müssen auch die entsprechenden Einträge in der Datenbank verschwinden.
Selbes Problem hier. Ändert man die IP für den externen Zugriff, werden vorhandene IPs in der Datenbank nicht aktualisiert, nur wenn man neue Datenbanken anlegt, stehen dann die neuen IPs in der DB, vorhandene Datenbanken bleiben unberührt. Wie kann man das Problem kurzfristig lösen?
