Beiträge von kk

    Ich wäre dafür, das man die Datenbanknamen nicht selber vergeben darf, bzw. es ein generelles Präfix gibt.


    Einstellungen -> Wiederverkäufer -> Präfix für Datenbankzugänge. Dort "%c" als Platzhalter für den Vertragsnamen verwenden (z.B. "%cdb" erlaubt nur Datenbanknamen in der Form "web1db[...]")

    Mit der PHP-Version 5.6 von Keppler/LiveConfig mag ownCloud nicht, es beschwert sich unter anderem, dass angeblich das zip-Modul fehle...


    Stimmt, die Datei /opt/php-5.6/etc/conf.d/zip.ini fehlt. :( Wird im nächsten Update mit installiert. Bis dahin: einfach diese Datei anlegen, mit folgendem Inhalt:

    Code
    extension=zip.so

    Was die Zeichencodierung oder HTML-Ausgabe betrifft gab es seit längerer Zeit keine Änderungen an diesen Bereichen. LiveConfig selbst führt auch keinerlei Konvertierung der Ein- oder Ausgabe durch - auch der Zeichensatz für alle HTML-Seiten ist fest auf UTF-8 eingestellt.
    Interessant wäre, wo genau "falsche" Umlaute auftauchen: ob nur in Inhalten die von der Datenbank kommen, oder auch in "sonstigen" Elementen (Navigation etc.). Schicken Sie uns bitte wenn möglich mal einen Screenshot an support@liveconfig.com, wenn das Problem wieder auftritt.
    Welche Datenbank genau setzen Sie im Backend ein? (ich tippe mal auf MySQL oder eine Variante davon). Gibt es Auffälligkeiten bei MySQL, wenn Umlautprobleme auftauchen?


    Viele Grüße


    -Klaus Keppler

    Die Preview wurde eben noch mal aktualisiert (r1.8.2-r3493), da in r3489 noch zwei Fehler aufgetaucht sind (mehrfache zend_extension-Einträge wurden nicht in die php.ini geschrieben, sowie bei mehreren IP-Adressen für externe DNS-Server gab es einen Parser-Fehler).


    Derzeit wird die Dokumentation aktualisiert und erweitert (es gibt separate KB-Artikel für DNSSEC, externe DNS-Server, PHP-Extensions etc.).

    Hallo,


    künftig werden wir alle Issues (Fehler und Feature-Requests) ausschließlich in Redmine tracken. Die bislang bei uns in zwei anderen Systemen (Jira und noch ein proprietäres Tool) erfassten Tickets werden wir im Laufe der nächsten zwei Tage "umziehen". Der Entwicklungsprozess soll so etwas transparenter gemacht werden.
    (die Issues werden derzeit alle mit dem User "admin" im Redmine verwaltet, da diese über eine API aus unseren internen Projektplanungs-Tools kommen)
    Die Redmine-Installation wird in den nächsten Stunden zeitweise nicht erreichbar sein (zwecks Aktualisierung).


    Zudem soll es für LiveConfig Premium-Partner und einzelne "Power-User" die Möglichkeit geben, einen eigenen Account für Redmine zu erhalten, um Fehler und Feature-Requests direkt erfassen zu können. Wer Interesse daran hat, schreibt bitte eine kurze Mail an support@liveconfig.com.


    Viele Grüße


    -Klaus Keppler

    Ab sofort ist LiveConfig v1.8.2-r3489 als Preview verfügbar, ab heute Abend dann produktiv.
    Es gibt einen ganzen Schwung Fehlerbeseitigungen und Verbesserungen, unter anderem:

    • "admin"-Benutzer kann nun umbenannt werden
    • Kontaktdaten von LiveConfig-Benutzern können nun geändert werden
    • Unterstützung der Konfiguration von PHP-Erweiterungen (Extensions) in php.ini-Verwaltung
    • bei Wiederverkäufer-Einstellungen wurde falsches "Standard"-Logo angezeigt
    • Fehler beim Bearbeiten eines php.ini Ausdruck-Wertes innerhalb von Verträgen behoben
    • Anzeige des Webserver- und Datenbankserver-Namens in Webspace-Übersicht
    • Spamfilter: Schwellwert für Warnung kann nun auf selben Wert wie für Ablehnung gesetzt werden (somit werden keine Mails als "Spam-verdächtig" markiert)
    • mehrfache gleichzeitige Anmeldung mit dem selben Login ist nun nicht mehr erlaubt ("Admin-Verbindungen" sind davon nicht betroffen)
    • jeder OTP-Code kann nun für nur eine Anmeldung verwendet werden (verhindert Session-Hijacking)


    Viele Grüße


    -Klaus Keppler

    Wir sprachen vor Monaten über das Problem am Telefon, da war noch nix dazu bekannt.
    Wie hätte ich denn von dovecot.local.conf erfahren können?


    Genau dafür gibt es ja das Changelog sowie unsere Hinweise auf neue Versionen im Forum (z.B. hier).
    Im Changelog zur Version v1.8.1 vom 22.01.2015 steht auch gleich am Anfang:

    Zitat

    Unterstützung für eigene Konfigurationsanweisungen in dovecot.conf


    Bitte haben Sie Verständnis dafür, dass wir nicht jeden einzelnen Thread hier mit Feature-Requests verknüpfen und dann bei Erledigung einzeln abarbeiten können.

    Du bist nicht der Erste, der das fordert und meldet.


    Es passiert halt nix, wie immer halt.


    aho546745: Was hat das mit der Frage zu tun? In der dovecot.local.conf können all die Einstellungen vorgenommen werden, die LiveConfig nicht (oder noch nicht) über die Oberfläche abbildet. Dort kann man auch ein beliebig großes process limit eintragen - wie auch im Handbuch beschrieben. Was wird hier also "gefordert"?


    evilyves: was meinen Sie mit "noch nicht in den Griff bekommen" - was genau meldet Dovecot?


    Viele Grüße


    -Klaus Keppler

    "Gemeinsamer" Content außerhalb der jeweiligen Vertragsverzeichnisse ist da recht problematisch. Seien Sie sich bitte bewusst, dass es bei Aktivierung von FollowSymLinks Benutzern prinzipiell möglich sein kann, in "fremde" Verzeichnisse zu schauen.


    Sicherer wäre es, den zentral verwalteten Typo3-Source über ein kleines Script in alle Kundenverzeichnisse zu kopieren (dort z.B. in ~/priv/, dann liegt das auch außerhalb des Web-Roots).

    ich habe das neuste Update von Liveconfig eingespielt, welches Änderungen an FollowSymlinks vorgenommen hat.
    Mir sind dadurch nun alle Seite abgeschmiert und ich bekomme nurnoch Internal Server Errors.


    Können Sie etwas genauer beschreiben, was bei Ihnen passiert ist bzw. warum die Seiten "abgeschmiert" sind? Während des Updates wird in allesn .htaccess-Dateien die Option "FollowSymLinks" (falls vorhanden) durch "SymLinksIfOwnerMatch" ersetzt.


    Zitat

    Momentan habe ich direkt in Apache2/Site-aviable alle Dateien um "Options FollowSymLinks" ergänzt.


    Das ist im Shared Hosting eine ziemlich schlechte Idee... (wir haben das ja nicht ohne Grund entfernt...)


    Zitat

    Habe ich eine Möglichkeit "Options FollowSymLinks" Global zu definieren oder zumindest pro Website, damit es in die Konfiguration geschrieben wird, wie ja Standardmäßig z.b. "SymLinksIfOwnerMatch".?


    Sie können in den Kundenverzeichnissen eine Datei namens ".httpd.conf" anlegen und dort eigene Einstellungen vornehmen, die dann per include() in die vHost-Konfiguration der einzelnen Webspaces aufgenommen werden (hierzu z.B. /var/www/web##/.httpd.conf mit den gewünschten Einstellungen anlegen und danach den Vertrag in LiveConfig neu speichern)


    Ich rate aber dringen davon ab. Mit "SymLinksIfOwnerMatch" können Sie symbolische Links verwenden. Es gibt keinen (mir bekannten) Grund, wozu man die Option "FollowSymLinks" brauchen könnte.

    1. ProFTPd:
    Nach einigen Tagen oder alle 24 Stunden ist ProFTPd nicht mehr erreichbar (Dienst nicht gestartet). Nach dem konfigurieren auf LiveConfig über "FTP" geht es dann wieder, sobald man die Konfig aktualisiert. Ist etwas nervig, weil Kunden oft nicht auf den FTP kommen und erst nach Neukonfig alles geht.


    Welche Distribution verwenden Sie?
    Bei ProFTPd gibt es einen bekannten Bug während der Log-Rotation (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675081). Mögliche Lösungsvorschläge gibt's hier.


    Zitat

    2. nginx:
    Nach einem Serverneustart müssen wir IMMER über "Web => IP-Adressen => Aktualisieren". Wieso? Es hat sich nie was geändert. :/ Wenn wir dies nicht machen, sind auf allen Seiten der Fehler "502 Bad Gateway" zu sehen.


    "Bad Gateway" bedeutet i.d.R. dass keine PHP-Prozesse verfügbar sind. In diesem Fall wird vermutlich das Script "nginx-php-fcgi" nicht beim Systemstart ausgeführt. Bei Debian hilft dann ggf. ein "update-rc.d nginx-php-fcgi defaults" um das künftig zu automatisieren.


    Zitat

    3. SMTP-Errors:
    Seit dem Update auf 1.8.2 haben wir das Problem, wenn wir Mails per SMTP (Script) versenden wollen, dass wir Mails immer zurückbekommen mit der Fehlermeldungen:
    - smtp; 550 Access denied - Invalid HELO name (See RFC2821 4.1.1.1)
    - smtp; 501 Syntax error in parameters or arguments


    Diese Info ist leider etwas dürftig. Was sagt die /var/log/mail.log dazu? Wie lautet die *vollständige* Bounce-Nachricht?


    Zitat

    Wir sind da etwas verwirrt, denn wenn wir manuell die Configs ändern, überschreibt LiveConfig diese nach paar Tagen oder Aktualisierung wieder. :/


    Es gibt auch Möglichkeiten, eigene Anweisungen in Konfigurationen einzupflegen - siehe Handbuch.


    Viele Grüße


    -Klaus Keppler

    Der Fehler im phpMyAdmin-Installer wurde behoben.
    Damit LiveConfig den neuen Installer verwendet, bitte einfach kurz neu starten (oder alternativ etwas warten - alle 24 Stunden aktualisiert LiveConfig sein Installer-Repository automatisch)


    Viele Grüße


    -Klaus Keppler

    bei uns funktioniert im LiveConfig die PHP Versionsauswahl für sämtliche NGinx Domains.


    Das würde mich wundern. ;)


    Kurz zum Zwischenstand: wir sind dabei, PHP von FastCGI auf FPM umzustellen. Das macht es uns dann auch deutlich leichter, separate PHP-FPM-Instanzen für die einzelnen Versionen (pro Kunde) zu starten. Wird aber noch ein paar Wochen dauern bis das abgeschlossen ist, derzeit stecken noch andere Features in der Entwicklung.

    Bevor das zur Verzweiflung führt: nein, libc-client.a ist offenbar vorhanden (sonst gäbe es eine andere Fehlermeldung). Der Fehler besteht darin, offenbar die "imap"-Extension als Shared Object compilieren zu wollen, dieses dabei aber mit der libc-client.a zu verlinken welche wiederum nur für statisches Linken geeignet ist (das ergibt sich aus dem Hinweis mit dem -fPIC...).


    "Unsere" configure-Parameter findet man in der phpinfo()-Ausgabe; den imap-Client aktivieren wir mit den Optionen "--with-imap=shared --with-imap-ssl". Dazu muss außerdem das Paket "libc-client2007e-dev" installiert sein (welches u.a. /usr/lib/libc-client.so.2007e.0 mitbringt, gegen welches die imap-Extension dann dynamisch gelinkt ist).

    Wäre es denn Möglich "shmop" bei nächster Gelegenheit mit in die PHP Pakete zu nehmen?


    Jein; wir müssten mal schauen ob sich das als dynamisch ladbares Modul compilieren lässt. Im Shared Hosting ist "shmop" jedenfalls nicht zu empfehlen.