Beiträge von Compositiv

  • Fehler bei Update von 2.2.3-r4343 auf 2.2.3-r4343 (unable to make backup link of)

    Hi,


    haben heute folgenden Fehler erhalten:


    Installation lies sich auch nicht über dpkg Optionen erzwingen.

  • Error Log dauerhaft aktivieren

    Ein Kunde benötigt diese funktion dringend.Gibt es umwege über die man jetzt schon error logs dauerhaft aktivieren kann? Ist soetwas in Planung?
    Für Developmentserver ist das ein wichtiger Bestandteil der vorhanden sein muss.

  • PREVIEW: LiveConfig v1.7.5

    Zitat von aziegler

    Gibt es Pläne, solche Aktionen irgendwann ohne GUI durchführen zu können?
    Gibt ja doch Kunden mit mehr als 2 Servern, die das dann zigmal durchklicken müssen...
    (sofern nicht wie hier dokumentiert ist, was genau geändert wurde, sodass man es gut per Skript machen kann)


    Gute Idee.
    +1

  • SSL Probleme mit SNI über NGINX

    Ja, finden wir auch sehr nervig.
    Wir haben inzwischen mehrere Kunden die NGINX einsetzen und jedes mal muss man da bei Updates aufpassen.


    Ich hatte dazu auch noch ein paar Fragen:
    Ist es möglich, dass Ihr die Dateien in /usr/lib/liveconfig/lua als conffiles markiert (Debian Paket)? Dann wird man wenigstens vor dem überschreiben gewarnt. Alternativ, ist es möglich mit einer eigenen LUA File die originale nginx.lua zu überlagern?


    Derzeitige conffiles:
    /etc/cron.d/liveconfig
    /etc/liveconfig/liveconfig.conf
    /etc/liveconfig/liveconfig.key
    /etc/liveconfig/mailquota.txt
    /var/lib/liveconfig/liveconfig.db

  • Nginx + Passwort-geschützte Verzeichnisse

    Hallo zusammen,
    Bin neulich auf das Problem gestoßen. Irgendwie wird den Passwortschutz nicht richtig behandelt.
    Folgende Ausgangsposition:
    System: Debian Wheezy 7.5 + LiveConfig 1.7.3-r2921 + NginX 1.2.1-2.2
    Webseite unter "/var/www/web1/htdocs/website"


    Dann will ich diese Webseite sperren und mit Passwort schützen. Wenn ich das Passwortschutz über LiveConfig setze, wird dann in web1.conf folgenden EIntrag gemacht:


    root "/var/www/web1/htdocs/website/";
    ....
    ....
    # password-protected directories:
    location /website/ {
    auth_basic "Shopware";
    auth_basic_user_file /var/www/web1/conf/.htpasswd;
    }


    Diesen Eintrag wird bei alle Vhosts(konfigurierte Domains) dieses Benutzers hinzugefügt. Diese Konfiguration kann aber nie in Kraft gesetzt werden, da dieses Verzeichnis als (dokument) root von dem VHost ist und nach der Konfiguration als Unterverzeichnis gesucht wird. Daher ist der Passwortschutz komplett unbrauchbar.


    Wie soll es sein?
    Passwortschutz sollte eigentlich per VHost gemacht werden. Mögliche Verzeichnisse sind dann "/" und Unterverzeichnisse des (document) root des VHosts. Der Eintrag soll dann so aussehen:


    location ~ / {
    auth_basic "Shopware";
    auth_basic_user_file /var/www/web1/conf/.htpasswd;
    }
    oder
    location ~ /unterverzeichnis/ {
    auth_basic "Shopware";
    auth_basic_user_file /var/www/web1/conf/.htpasswd;
    }


    Ausserdem soll diese Konfigurationsblock vor jeder Dateidefinition liegen. Ansonsten kann es vorkommen, dass diese Dateien innerhalb des geschützten Bereiches trotzdem aufgerufen werden können.


    Dobrev

  • PHP Versionen

    *push*
    Wie sieht es damit aus? Sollte eigentlich in Version 1.7.0 gefeatured werden - die haben wir allerdings installiert und ich finde keine solche Option oder einen Eintrag in der KnowledgeBase.
    Wäre langsam zunehmend wichtig und ist ja eigentlich auch nicht sonderlich kompliziert.


    Wenn man davon ausgeht, dass die verschiedenen Versionen vom Admin installiert werden, muss prinzipiell nur im Panel z.B. unter Serververwaltung > Web oder einem eigenen Punkt Serververwaltung > PHP eine Möglichkeit hinzugefügt werden, zusätzliche Binaries anzugeben und mit einem Versionsnamen zu versehen.
    Dann könnte man im Hosting statt nur für suphp, FCGI und mod_php im Falle von extra PHP-Versionen eine Auswahl für die Version dazupacken und dann entsprechend eine zusätzliche php.ini (z.B. in einem Unterordner /var/www/<web>/conf/php5.2) erstellen lassen.


    Im Falle von FCGI beispielsweise muss dann nur noch via Switch im Wrapper die $PHPRC auf die jeweilige php.ini angepasst und dann am Ende das entsprechende Binary executed werden.


    MfG
    David Winterstein / Compositiv

  • Spam und Virenscanner ?

    Zitat von kk

    Greylisting ist hier in einem Entwicklerzweig auch schon implementiert (kann pro Postfach aktiviert/deaktiviert werden).


    Das funktioniert schon mal super.


    Zitat von kk

    An einer intelligenten SpamAssassin-Integration arbeiten wir noch (würden wir am liebsten auch pro Postfach konfigurierbar und eventuell auch in der Pre-Queue-Phase machen, so dass als Spam klassifizierte Mails noch während der SMTP-Verbindung abgelehnt werden).


    Leider in Version 1.7.0 immer noch nicht umgesetzt - gibt es eine voraussichtliche Versionsnummer, ab der das verfügbar sein wird?
    Außerdem verwenden wir hier vor allem auch policyd-weight und amavis, wie sieht es mit einer Integration davon aus?


    MfG
    David Winterstein / Compositiv