Beiträge von WebOscar

    Hallo,


    möglicherweise (und vielleicht auch sehr wahrscheinlich) haben sich die folgenden Probleme nach einem netten Besuch eines Botnetzes in der letzten Nacht ergeben. Ich erspare mir Details dazu und komme zum Kern:


    Es hat massive Verbindungsprobleme zwischen LC-Server und den Clients gegeben. Auf einem Client ist das Logfile explodiert und hat die gesamtquota der zugrundeliegenden virtuellen Maschine gesprengt, in dem es etwa jede viermillionstel Sekunde einen Eintrag in sein Error-Log geschrieben hat: (hier jetzt mal nur die letzten 10)


    [2012/10/11 03:21:42.795951] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795954] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795958] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795961] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795964] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795967] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795971] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795974] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795977] [10784|10784] Got event at unknown fd (5)
    [2012/10/11 03:21:42.795980] [10784|10784] Got event at unknown fd (5)


    Ich find's ja toll, das der Client schnell ist, aber kann man das vielleicht irgendwie abfangen, damit nicht gleich an kompletter (in diesem Fall Datenbank-) Server im Nirvana verschwindet?


    Seit ich heute Morgen dann alle Server mal durchgestartet habe, bekomme ich im LiveConfig-Panel ein Fehler 502 angezeigt, wenn ich unter Verwaltung auf Benutzer klicke - egal unter welchem Benutzer ich angemeldet bin.


    Das LiveConfig-Log schweigt sich dazu leider aus. Ich vermute mal ein Problem mit der Datenbank, nur hatte ich bis LiveConfig noch nie Kontakt zu sqlite und wage mich da in Eigenregie jetzt nicht ran.


    Eine Idee, wie ich das reparieren kann?


    Viele Grüße,


    Oskar Groh

    Hallo Stefan,


    hier wird das voreingestellte Suffix zu lang sein. Ist der vielleicht schon 12 Zeichen lang - oder waren es 16? Naja, das Suffix ist Teil des gesamten Namens und wird von der Anzahl möglicher, selbst zu vergebener Zeichen abgezogen.


    Viele Grüße,


    Oskar

    Liebes LiveConfig-Team,


    ich weiss, Ihr seid schwer beschaeftigt!


    Aber seit meiner ersten Frage nach einem ungefaehren Datum sind nun fast drei Wochen ohne Antwort vergangen. Wuerde mich nicht weiter stoeren, haette das keine Auswirkungen auf meinen Kundenstamm. Um den mache ich mir jetzt aber sorgen, denn der erste Kunde hat seine MX-Eintraege von mir aendern lassen um eigene Mailserver zu verwenden. Das ist i. d. R. der erste Schritt vor der Kuendigung und dem kompletten Umzug des Kunden woanders hin.


    Und das aergert mich; nur weil ich ihm keine Antwort geben konnte, wann seine Road-Worrior ihre Mailkonten selbst verwalten koennen.


    Also? Kommt da bitte noch eine Info?


    Viele Gruesse,


    Oskar Groh

    Schönen guten Abend,


    mag sein, dass ich gerade ein Brett vor dem Kopf habe oder einem falschen Glauben erlegen bin.


    Aber sollte es nicht auch unter FastCGI so sein, dass wenn ein php-Script mehr Berechtigungen als 644 bzw. 640 hat, dieses an der Ausführung mit einem 500er gehindert wird? Ich habe gerade mal zum Spaß eine phpinfo angelegt und diese auf 777 gesetzt. Und es wird ohne Murren ausgeführt.


    Irgendwie habe ich im Kopf, dass - außer für den Nutzer selbst - keine Schreibrechte erlaubt sind.


    Liege ich da gerade falsch? Kann mir dazu jemand was sagen?


    Viele Grüße und noch einen schönen Abend,


    Oskar Groh

    Na jut! Genau da hänge ich auch. Brauche dringend die Zertifikate, meine Kunden steigen mir auf's Dach wegen der nervigen Warnung beim Einrichten des Mail-Clients. ... aber zwei Wochen sind auch noch nicht rum. :D


    Was mich allerdings etwas irritiert ist, dass ich gerade eben die eigenen Zertifikate einbinden wollte, dies aber dann gelassen habe, weil laut Timestamp der dovecot.conf, diese vor etwas über einer Stunde verändert wurde. Und niemand hat etwas an der Konfiguration über LiveConfig geändert. Das passt dann aber nicht dazu:

    Zitat

    Sie können bei Bedarf manuell die Konfigurationen bearbeiten (main.cf/master.cf bzw. dovecot.conf) - diese werden nur dann wieder von LiveConfig überschrieben, wenn Sie dort irgend etwas an der Mailserver-Konfiguration ändern sollten (zB. Aktivierung von ClamAV o.ä.). Auch bei einem normalen Upgrade werden diese Dateien üblicherweise *nicht* durch LiveConfig überschrieben.


    Viele Grüße,


    Oskar Groh

    Könnte sein, dass die Mails nicht "richtig" gelöscht wurden. Outlook löscht die Mails z. B. erst dann vom Server, wenn sowas wie "gelöschte Mails endgültig löschen" gewählt wird. Bis dahin bleiben die Mails brav auf dem Server und sind nur ausgeblendet.


    Kann man prima testen: In das Mailverzeichnis gehen und alle dovecot*-Dateien löschen. Anschließend eine neue Syncronisation vom Mail-Client erzwingen und schwuppdiwupp sind etliche - schon laaaaaange gelöschte Mails wieder da.


    Viele Grüße,


    Oskar

    (die kann ich aber nicht testen, da diese noch auf einen anderen Server zeigen).


    Doch, die kann man testen.


    Wenn man Windows nutzt:
    Den Editor als Administrator öffnen und die Datei c:\windows\system32\drivers\etc\hosts öffnen.


    Dort dann die Domains eintragen:

    Code
    1.2.3.4  domain.tld www.domain.tld subdomain.domain.tld usw usw


    Ein Wildcard-Eintrag *.domain.tld geht nicht. Jede Subdomain muss eingetragen sein.


    Anschliessend im Browser F5 oder ctrl+F5 oder um ganz sicher zu gehen, den Browser neu starten und schon landet man auf dem neuen Server, ohne den DNS angefasst zu haben. Spart eine Menge Stress und böse Überaschungen beim Umzug von Kunden.


    Zum Deaktivieren des Eintrags einfach ein # davor und speichern nicht vergessen.


    Der Übersichtlichkeit wegen kann man die gleiche IP auch mehfach in die hosts eintragen, wenn man mehrere Domains temporär switchen möchte.


    Unter Linux, das dürfte bekannt sein, ist es die Datei /etc/hosts und bei einem Mac ... ich weiß es nicht.


    Die hosts-Datei wird von einigen Virenschutz-Programmen geschützt. Der Schreibschutz muss dann entsprechend abgeschaltet werden.


    Ich hoffe, das hilft.


    Viele Grüße,


    Oskar Groh

    Hmmm, ich bin etwas verwundert, dass hierzu noch keine Antwort gekommen ist. Haben alle anderen die Moeglichkeit SSL-Zertifikate einzurichten grundsaetzlich abgeschaltet oder bin ich der Einzige, der es fuer mehr als nur wichtig haelt, dass auf einem WebServer der Apache nicht durch das Konfigurations-Panel abgeschossen werden kann?

    Wer soetwas kurzfristig für sich oder seinen Kunden lösen möchte kann diesen "Workaround" nutzen.


    1. App installieren (Bsp: owncloud)
    2. Im Nutzerverzeichnis einen symbolischen Link zur Anwendung setzen

    Code
    root@server:/var/www/web99/htdocs# ln -s ../apps/owncloud owncloud
    root@server:/var/www/web99/htdocs# chown web99:web99 owncloud -R


    3. Zertifikat in LC anlegen
    4. Sub-Domain auswählen, HTTPS-Zugriff aktivieren, Zertifikat auswählen, Webspace anklicken und "owncloud" per Hand in das Verzeichnis-Feld eintragen, da Links nicht über "wählen" angezeigt werden.
    5. Speichern, fertig, geht! (zumindest bei mir).

    Guten Morgen,


    Ich habe eine sehr zuverlässige Methode, den Apache über das LiveConfig-Panel ins Nirvana zu schicken, entdeckt.


    Wenn ein Nutzer ein SSL-Zertifikat anlegt, dabei einen unpassenden Key importiert und anschließend dieses Zertifikat einer (Sub-)Domain zuordnet, passiert das hier:


    [Wed Oct 03 08:20:53 2012] [error] Unable to configure RSA server private key
    [Wed Oct 03 08:20:53 2012] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch


    Anschließend ist der Apache tot. Ein Löschen der Zuordnung zur SubDomain bringt ihn auch nicht zurück. Ein /etc/init.d/apache2 restart meldet, dass keine Sockets zur Verfügung stehen, da ad.r.e.sse:443 noch in use ist.


    Eine Prüfung ob der Private Key überhaupt zum Zertifikat passt sollte daher dringend schon beim Import geprüft werden, damit der Nutzer fehlerhafte key-cert-Kombinationen gar nicht erst speichern kann.


    Viele Grüße,


    Oskar Groh

    Wer seine Nutzer unter FastCGI laufen lässt, sollte in die /etc/apache2/mods-available/fcgid.conf unbedingt einen FcgidMaxRequestLen eintrag setzen. Per Default ist der viel zu klein und wirft beim Versuch etwas hochzuladen einen 500er. Bei der Anwendung OwnCloud ist das noch viel gemeiner, weil man sieht den 500er nicht mal im Browser und das File ist einfach nicht da.


    Ich habe meine mal auf 50MB gesetzt. Das dürfte für so ziemlich alle Nutzer ausreichen:


    Code
    <IfModule mod_fcgid.c>
      AddHandler    fcgid-script .fcgi
      FcgidConnectTimeout 20
      FcgidMaxRequestLen 52428800
    </IfModule>


    Grüße,


    Oskar Groh