Beiträge von WebOscar

Hallo,

ich habe nun mehrfach durch verschiedene Nutzer die Meldung erhalten, dass sie ihre Mails nicht abrufen können. Hierbei handelt es sich immer um ein Gemeinschafts-IMAP-Konto auf das mehrere Nutzer Zugriff aus dem Selben Netz (Firmennetz) haben.

Auch bei mir passiert es gelegentlich, dass ich eine Fehlermeldung erhalte, wenn ich versuche eMails abzurufen.

Ein Dovecot-Restart hilft vorübergehend.

Der Grund ist der Default-Wert in login_max_connections, der offensichtlich zu niedrig für IMAP-Konten mit vielen abonierten Ordnern und mehrfachem Zugriff (Handy, Notebook, Pad, Computer) von der selben IP ist.

Im Logfile sieht das so aus:

Dec 12 16:49:14 lc-4 dovecot: imap-login: Maximum number of connections from user+IP exceeded (mail_max_userip_connections): user=<xxx@xxx.xxx>, method=CRAM-MD5, rip=x.x.x.x, lip=y.y.y.y, TLS

Den Wert von Hand in die dovecot.conf zu schreiben macht wenig sinn, da mit jeder Änderung an dem Server über LiveConfig die conf neu geschrieben wird.

FeatureRequest: Bitte um die Möglichkeit die login_max_connections in der Serververwaltung einstellen zu können.

Viele Grüße,

Oskar Groh

Alles klar,

eingespielt, getestet und für gut befunden!

Danke und viele Grüße,

Oskar Groh

Ich hatte diesen Bug bereits hier gepostet und zwei Minuten hat Herr Keppler geantwortet, leider nicht auf meine Meldung. Vielleicht ist ein Sammelthread nicht so optimal, darum hier nochmal: :mad:

Wenn ein Kunde versucht eine App zu installieren, werden - wenn Datenbank und WebServer verschiedene Server sind - die Datenbank und der Benutzer nur für Localhost angelegt. Folge: Datenbank bleibt leer, kein Zugriff vom WebServer aus.

Gegenprobe: Wenn der Nutzer eine Datenbank von Hand anlegt, wird diese und der Datenbanknutzer mit allen IP-Ranges angelegt, wie sie in der Serververaltung hinterlegt sind.

Den neuen Kunden kann ich jetzt abschreiben und der Kunde, der mir diesen vermittelt hat und bei dem es bis vor dem Update auf 1.6 noch tadellos funktionierte, ist jetzt knatschig auf mich.

Da es sich hier um ein Kern-Feature für den Kunden handelt, halte ich diesen Bug für dringend bearbeitungswürdig.

Viele Grüße,

Oskar Groh

Bug: DRINGEND!

App-Installation:

Wenn ein Kunde versucht eine App zu installieren, werden - wenn Datenbank und WebServer verschiedene Server sind - die Datenbank und der Benutzer nur für Localhost angelegt. Folge: Datenbank bleibt leer, kein Zugriff vom WebServer aus.

Gegenprobe: Wenn der Nutzer eine Datenbank von Hand anlegt, wird diese und der Datenbanknutzer mit allen IP-Ranges angelegt, wie sie in der Serververaltung hinterlegt sind.

Versaut mir gerade den Sonntag...

Viele Grüße,

Oskar Groh

Jo, die Kommunikation könnte hier und da etwas besser sein.

Hallo Bjoern!

Zitat von bfal

Irgendwie lese ich immer nur "ist fast fertig" oder "kommt mit der nächsten Version" oder "arbeiten wir dran" und statt dessen kommen immer andere Sachen auch wenn da durchaus tolle Sachen bei sind.

Ich weiss, was Du meinst und manchmal habe ich deshalb auch einen Frosch im Hals. Aaaaber ...

Da sind so viele Baustellen und durch die Reihe weg, sind sie interessant und wichtig. Noch wichtiger aber finde ich, dass das LC-Team fast immer in durchaus respektabler Zeit einen Fix zu gemeldeten Fehlfunktionen liefert. Das kostet Zeit und hat natuerlich immer hoechste Prioritaet.

Ich uebertrage die Erfahrung, die ich selbst mit meinen Kunden mache einfach auf Keppler-IT. Man kann nicht immer alle zur gleichen Zeit gluecklich machen und es muessen Prioritaeten gesetzt werden. Ich finde, die Prioritaeten sind hier gut gesetzt und schliesslich - was meiner bescheidenen Meinung nach das Wichtigste ist - es wird aktiv entwickelt.

Auch meine Wunschliste an Features ist noch lang aber sie wird stetig kuerzer. Als Beispiel sei hier nun die augenscheinlich perfekt umgesetzte Autodiscover-Funktionalitaet erwaehnt. Die macht mich jetzt erst mal fuer ein paar Tage gluecklich.

Ich schliesse mich Dir aber an und wuerde mich auch fuer eine schnelle Umsetzung der php.ini-Geschichte, dem eMail-User-Login und der administrativen Vorgabe bestimmter Parameter, wie z. B. Greylisting oder Quota-Vorgabe sowie der schmerzlich vermissten Passwort-Funktion fuer Verzeichnisse (mit Nachdruck) aussprechen.

Schoenes Wochenende und viele Gruesse,

Oskar

Muesste es nicht >> (append) sein? Sonst steht doch immer nur der letzte Eintrag im crontab.log.

Also so:

DEINBEFEHLSBEREICH >> /var/www/DEINACCOUNTNAME/logs/crontab.log 2>&1

Hallo,

genau das wuerde mich auch interessieren, nachdem ich nun mit Redmine angefixt wurde.

Viele Gruesse,

Oskar Groh

Hallo,

das hier schon kontrolliert?

http://www.liveconfig.com/de/f…hlight=FcgidMaxRequestLen

Viele Gruesse,

Oskar Groh

Perfekt!

Hallo Webby!

Eiskalt erwischt! Da war doch noch was...

Also, ich muss jetzt auf die Autobahn aber vorher noch schnell aus dem Kopf:

In unserem Netzwerk sind die Server jeweils ueber eine Netzwerkkarte in das Internet und ueber die andere Netzwerkkarte intern verbunden. Per DNS haben die Server dann jeweils zwei Namen.

Beispiel:

serv01.domain.ltd 83.x.x.11
serv02.domain.ltd 83.x.x.12
serv03.domain.ltd 83.x.x.13 usw

Fuer das interne Netz dann jeweils noch ein '-l' hinter dem Hostnamen:

serv01-l.domain.ltd 10.x.x.11
serv02-l.domain.ltd 10.x.x.12 usw.

Das Gleiche gilt fuer die virtualisierten Server. Auch die haben zwei (virtuelle) Netzwerkkarten die jeweils ueber die passende physikalische des Servers gebridged werden.

Wenn ich nun moechte, dass vserv1 ganz schnell mit vserv2 Verbindung aufnehmen kann und zwar ohne erst den DNS zu fragen und ohne dazu die externen Netzwerkkomponenten zu stressen, dann trage ich direkt in die /etc/hosts ein und ueberschreibe so (ganz nebenbei) die eigentliche DNS-Eintraege.

Wenn also vsrv1 der WebServer ist und vsrv2 der DB-Server dann sieht die /etc/hosts so aus:

10.x.x.101 vsrv1 vsrv1.domain.tld
10.x.x.102 vsrv2 vsrv2.domain.tld

So werden also Anfragen von den eigenen Servern gar nicht erst ueber die oeffentlichen Adressen geroutet.

Unter Confixx habe ich auch schon die Trennung von Web-, Mail- und DB-Server gehabt. Da es unter Confixx aber immer feste Cluster waren, habe ich den Host-Eintrag beim jeweiligen WebServer entsprechend noch so erweitert:

10.x.x.102 vsrv2 vsrv2.domain.tld localbase

bei einem anderen WebServer sah der Eintrag dann eben so aus

10.x.x.106 vsrv6 vsrv6.domain.tld localbase

Womit ich das "localhost"-Problem etwas umschifft habe. Soweit ich weiss, ist es nicht moeglich localhost auf einen anderen Server zeitgen zu lassen.

Der Nutzer musste bei der Einrichtung einmal informiert werden, dass der Server localbase und nicht localhost heisst und das fuehrte auch nie zu Problemen.

Unter LiveConfig stellt sich die Sache - zumindest mit "localbase" etwas anders da. Da dieser Cluster nicht statisch ist und sich fuer neue Kunden der DB-Server bei Bedarf aendern kann, arbeite ich hier mit dem tatsaechlichen Hostnamen des entsprechenden Servers. Ich leite sie nur ueber das interne Netz, damit - egal ob der Nutzer nun dbsrv1 oder dbsrv1.domain.tld benutzt, die externen Netzwerkkomponenten nicht von der internen Kommunikation gestresst werden.

Hilft Dir das soweit weiter?

Uh ich muss jetzt los!

Viele Gruesse,

Oskar

Hallo,

ich hatte gerade ein Telefonat mit einer Internet-Agentur, die ihre Kunden auf unseren Servern hosten. Dabei ging es - neben viel Lobhudelei fuer LiveConfig - auch um die Quota. Auf unseren alten Servern hatten die Kunden zwar auch Limits, aber die Quota hatten wir auf Confixx nicht laufen. Hat ein Kunde seine Quota ueberschritten, bekam er eine nette Mail mit der Bitte, doch mal aufzuraeumen oder ein groesseres Paket zu ordern.

Jetzt allerdings wird die Quota zuschlagen, wenn der Kunde sein Limit uebersteigt. Das ist insbesondere schlecht fuer CMSysteme wie Typo3, die nicht mehr laufen, wenn sie keine temporaeren Dateien mehr anlegen koennen. Auch die Mailquota war Grund zur Disskussion.

Wir haben uns folgenden Feature-Request ueberlegt:

Alle 24 Stunden bekommen Nutzer, deren WebSpace zu weniger als X% frei ist eine automatische Warnmail an die eMail-Adresse, die in den Kontaktdaten des Kunden hinterlegt wurde. Nett waere, wenn die X% oder auch n MB durch den Reseller oder sogar durch den Nutzer eingestellt werden koennte.

Alle 24 Stunden bekommen eMail-Nutzer, deren Postfach zu weniger als X% oder n MB frei ist eine automatische Warnmail in eben genau dieses Postfach. Auch hier waere es nett, wenn die Warnschwelle konfigurierbar waere.

Waere das machbar?

Viele Gruesse,

Oskar Groh

Hallo,

wenn aber fastcgi als mod_fcgid laeuft, nuetzt APC nur als Speicherverbrenner. Unter mod_fastcgi allerdings kann man einen Opcode-Cache ordentlich laufen lassen. Es ist naemlich ein fataler Irrglaube, dass mod_fcgid eine Weiterentwicklung von mod_fastcgi ist und es gibt einen (DEN) entscheidenden Unterschied in der Prozessverwaltung:

Zitat

Both mod_fcgid and mod_fastcgi can be told to limit the number of PHP processes to 1 per user. The PHP process can then be told how many children to spawn. Unfortunately mod_fcgid will only send one request per child process. The fact that PHP spawns its own children is ignored by mod_fcgid. If we use mod_fcgid with our setup, we can only handle one concurrent PHP request. This is not good. A long running request could easily block multiple smaller requests.

Den ganzen Artikel findet man hier: http://www.brandonturner.net/b…gi_with_php_opcode_cache/

Ich beschaeftige mich nun schon seit einigen Tagen mit dieser Problematik und da es inzwischen auch einige Unterschiede in der Syntax der jeweiligen Settings von mod_cgid und mod_fastcgi gibt, ueberlege ich schon einige Zeit, einen Feature-Request fuer mod_fastcgi abszusetzen.

Allerdings warte ich damit, bis die aktuell wirklich wichtigen Tasks abgeschlossen sind.

Viele Gruesse,

Oskar Groh

Hallo Herr Keppler,

vielen Dank für Ihre Antwort.

Es ist mir schon klar, dass ich nicht das Maß aller Dinge bin. Nur so, wie es jetzt umgesetzt ist, ist es insgesamt nicht optimal gelöst. Eine bessere Idee, als Ihre aufgeführte Lösung, habe ich auch nicht. Ich hatte allerdings auch die Option "SMTPS" in den SMTP-Server-Einstellungen im Hinterkopf. Hier dachte ich, macht es Sinn, dass bei gesetzter Option das XML per SSL ausgeliefert wird und ohne eben als STARTTLS. Verschlüsseltes Passwort kann ja grundsätzlich in das XML einfließen.

Und noch ein Gedanke: Vielleicht sollte das XML sauber nur ein Protokoll für den incomingServer ausgeben. Entweder pop oder imap. Liegen beide im XML, liegt es einzig und allein am Client, was er davon nutzt und das ist nicht vorhersehbar. Der Idealfall ist ja, mit der Autoconfig dem Nutzer das Postfach ohne weiteres Zutun seinerseits (mal abgesehen von der Abfrage nach eMail-Adresse und Passwort) fertig zu konfigurieren.

Dann warte ich mal voller Spannung auf Donnerstag.

Viele Grüße,

Oskar Groh

Knock, knock!

Ich möchte hier nochmal nachsetzten. Was nutzt die tollste Funktion, wenn sie nicht richtig funktioniert?

Ich habe mir die XML-Ausgabe nochmal angesehen.

Die Sektionen incomingServer sind jeweils für IMAP und POP doppelt vorhanden. Beide mit SSL und dann nochmal mit STARTLS. Gleiches gilt für outgoingServer.

Ich habe mich schon auf die Suche nach einem möglichen Template gemacht, das LiveConfig nutzt aber leider keines gefunden.

Zwar kommt Thunderbird damit klar, weil es STARTTLS für den Postausgangsserver setzt und SSL für den Eingangsserver (obwohl ich das gar nicht will). Outlook jedoch setzt stumpf SSL für Ein- und Ausgang, was beim versenden der Testmail dann gleich knallt.

Also, ich würde das wirklich gerne meinen Nutzern zur Verfügung stellen. Aber so wird das mehr Support-Anfragen ("Das geht nicht...") geben, als es nutzen bringt.

Kommt da noch was?

Viele Grüße,

Oskar Groh

Zitat von TropiaIT

Also nicht das ich jetzt was wichtiges sehe als Quota, das habe ich nicht Konfiguriert, da es nach der Anleitung so nicht geht. Da alles bei mir OpenVZ ist.

Entschuldigung, dass ich diesen Satz nicht ganz verstanden habe, da er irgendwie keinen Sinn ergibt. Der steht auch in keinem Zusammenhang mit dem Thema cgi-bin. Und da es ja nicht selten vorkommt, dass innerhalb eines Threads mal schnell ein anderes Thema angesprungen wird, dachte ich, ... ach was solls.

Hallo TropialT,

ganz ehrlich verstehe ich die Fragestellung nicht. Wenn es darum geht, dass Quota nicht funktioniert, weil OpenVZ drunter liegt und es per default nicht funktionieren kann (können sollte), dann kann ich das nicht bestätigen.

Auch unsere Server sind komplett über OpenVZ virtualisiert und 2nd Level Quota funktioniert out of the box, ohne dass noch etwas besonderes konfiguriert werdne musste.

Viele Grüße,

Oskar Groh

Guten Morgen,

sehr schön umgesetzt! Ich schließe mich bfal an und würde es begrüßen, wenn Greylisting per Default gesetzt werden kann.

Zur Autoconfig.xml:

Die funktioniert nun auch mit Thunderbird, aaaber:

Thunderbird setzt den richtigen Server aber nutzt als Verbindungssicherheit STARTTLS für den Postausgangsserver und SSL für den Eingangsserver. Das ist schlecht, da ich kein SSL anbiete(n will).

Outlook setzt SSL sowohl für den Aus- und Eingangsserver.

Es wäre toll, wenn hier Konsistenz geschaffen würde. STARTTLS für Ein- und Ausgangsserver + verschlüsseltes Passwort.

Wenn ich Sie in einem anderen Posting richtig verstanden habe, Herr Keppler, sehen Sie STARTTLS auch als Verbindungssicherheit der ersten Wahl.

Viele Grüße,

Oskar Groh

Zitat von kk

Nicht zuletzt ist die inzwischen leider sehr häufig verwendete Variante mit "mail.domain.de" problematisch, weil die Kunden somit immer eine SSL-Warnmeldung bekommen (das SSL-Zertifikat ist ja auf einen anderen Namen ausgestellt!).

Genau das meinte ich mit Altlasten - man könnte es auch "ziemlich blöde Idee" oder "schlechte Angewohnheit" nennen. Das ist auf mich bezogen! Andere mögen das anders sehen.

Zitat von kk

Eine Migration wäre eigentlich die ideale Gelegenheit, die Kunden im Rahmen der Umstellung über die neuen Vorteile und verbesserten Sicherheitsrichtlinien zu informieren.

Sag' ich doch!

Viele Grüße

Oskar Groh

Ahso!

Okay, das fällt bei mir aus, da wir die Kunden einzeln, geführt und gewollt auf neue Accounts und Servernamen umstellen um Altlasten los zu werden und ein neues, sauberes System aufzubauen. Und wenn ich das richtig interpretiere, dann ist SSL ohnehin das "alte" Protokoll und STARTTLS das deutlich flexiblere.

Außerdem würde ich Seiteneffekte befürchten, wenn ich die Kunden quasi "unbemerkt" auf einen tatsächlich neuen Mailserver umleite, da ich nicht weiß, wie z. B. Thunderbird oder Outlook reagieren, wenn die Software merkt, dass das eigene Caching nicht mehr zum vermeindlich vertrauten Server passt.

Also ich würd's nicht so machen.