Beiträge von kk

  • Liveconfig mit Fastcgi ohne mod_php und owncloud

    Nein, owncloud braucht definitiv kein mod_php (davon ist allgemein dringend abzuraten).
    Wenn Sie von mod_php auf FastCGI umgestellt haben, dann vermute ich, dass die ganzen Dateiberechtigungen nicht (mehr) stimmen.


    Alle Dateien in /var/www/<Vertrag>/htdocs/ müssen dem Vertragsnamen/-Gruppe gehören, also bei "web1" z.B. dem Benutzer "web1" und der Gruppe "web1".
    (mit mod_php sah das anders aus, da mussten die Dateien alle dem Webserver-User, also "www-data" gehören).


    Um die Rechte anzupassen, führen Sie also z.B. so was aus:
    chown -R webX:webX /var/www/webX/htdocs/*


    (bzw. falls Sie ownCloud über den AppInstaller instaliert haben: chown -R webX:webX /var/www/webX/apps/*)


    ("webX" durch den jeweiligen Vertragsnamen ersetzen)


    Viele Grüße


    -Klaus Keppler

  • Neue Version 2.8

    Hallo!
    Vielen Dank für das große Interesse. Wir sind erst seit heute wieder "normal" im Büro, und haben leider noch einen Berg Arbeit zu erledigen. Wir sind nun dabei einen Demo-Server mit der v2.8 vorzubereiten und die ganzen Änderungen/Neuerungen zusammenzufassen; bis Ende der Woche sollte das dann online gehen.
    Wir arbeiten mit Hochdruck an der Freigabe!


    Viele Grüße


    -Klaus Keppler

  • SSL, Mailserver und mehrere Domains

    Exakt.
    Soweit ich weiß wird in Postfix derzeit an SNI (Server Name Indikation) gearbeitet - damit könnte man dann für jede gewünschte MX-Domain ein eigenes Zertifikat anlegen. Da es ja aber für jede IP auch nur einen Reverse-DNS-Namen geben kann, macht das in der Praxis wenig Sinn.


    Evtl. wäre es eine Option, AutoConfigure/AutoDeploy einzurichten (was nicht ganz trivial ist); dann "sehen" die Kunden den Mailservernamen häufig gar nicht mehr.

  • SpamAssassin erkennt keinen Spam

    Ich finde hier kein Support-Ticket zu dem beschriebenen Problem.


    Was taucht denn genau alles in /var/log/mail.log auf, wenn eine E-Mail eintrifft?
    (vor dem Eintrag von lcsam sollten jeweils die Meldungen von SpamAssasin (spamd) stehen).

  • Umstellung fastcgi auf FPM, Debian 9

    Einizige Möglichkeit aktuell: die Änderungen in der FPM-Konfigurationsdatei (in diesem Fall also /etc/php-fpm/php72-fpm.d/test.conf) vornehmen, und die Datei anschließend mit "chattr +i" schreibschützen.


    Wir planen aber bereits eine Möglichkeit, die FPM-Einstellungen individuell konfigurierbar zu machen (z.B. auch wenn man einen anderen Prozessmanager verwenden möchte).

  • CloudFest 2019: Einladung zum Launch-Event

    Hallo liebe LiveConfig-Anwenderinnen und -Anwender!


    Am Mittwoch, dem 27. März werden wir im Rahmen des CloudFests die Version 2.8 von LiveConfig offiziell präsentieren.
    Wie bereits angekündigt hat sich u.a. im Bereich der SSL-Verwaltung viel getan. So haben wir mit einem der größten Anbieter von SSL-Zertifikaten in Deutschland, der CertCenter AG, eine komplett automatisierte Bestellabwicklung von OV/EV-Zertifikaten integriert - inklusive SSL-Upselling und dem kostenlosen "AlwaysOnSSL".


    Zusammen mit der CertCenter AG laden wir daher zu einem speziellen Launch-Event ein, an dem wir die neue SSL-Verwaltung vorstellen werden.
    Im Anschluss an eine kurze Präsentation werden wir gemeinsam das wunderschöne Straßburg per Schiff erkunden. Sie haben dabei die Möglichkeit, sich mit dem LiveConfig-Team, den Spezialisten von CertCenter und den anderen Teilnehmern in entspannter Atmosphäre auszutauschen und Straßburg bei Nacht zu erleben. Auch Vertreter von CAs stehen Ihnen an dem Abend für alle Fragen rund um SSL-Produkte zur Verfügung.
    Kulinarische Spezialitäten aus dem Elsass sorgen für das leibliche Wohl - auch mal außerhalb des Europaparks.
    Es sind noch Restplätze für diese Veranstaltung verfügbar, die nach "first come, first serve" vergeben werden. Zur Anmeldung registrieren Sie sich bitte unter https://launch.liveconfig.com


    Zeitplan:

    • 16:30 Vorstellung und offizieller "Launch" (Hotel "Bell Rock", Konferenzraum "Harvard")
    • 17:00 Abfahrt mit dem Reisebus am Hotel "Bell Rock"
    • 17:45 Ankunft in Straßburg
    • 18:00 Ablegen des Schiffs, Flying Buffet, Getränke
    • ca. 21:00 Rückfahrt zum Europapark


    Bei Fragen stehen wir Ihnen unter launch@liveconfig.com zur Verfügung.


    Viele Grüße


    -Klaus Keppler



    Datenschutzhinweis: die bei der Anmeldung bzw. Kontaktaufnahme erfassten Daten werden von der Keppler IT GmbH und der CertCenter AG zum alleinigen Zweck dieser Veranstaltung gespeichert und anschließend gelöscht. Es erfolgt keine Weitergabe an Dritte.

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Zitat von TCRserver

    Hallo Herr Keppler,
    seit zwei bis drei Wochen gibt es eine #5244 als Preview, aber keine Ankündigung dazu.
    Was verbirgt sich denn hinter der Version?


    Die SOAP-Funktionen HostingSubscriptionEdit und HostingSubscriptionGet akzeptieren bzw. liefern mit diesem Update noch einen Parameter "phpini", um somit php.ini-Einstellungen via API bearbeiten zu können. Das Ganze ist noch nicht ausführlich getestet, wurde aber für einen Sonderfall in einem größeren Rollout kurzfristig benötigt. Die Änderungen werden in den nächsten Tagen noch dokumentiert und getestet, dann wird das in v2.8 "offiziell" enthalten sein. Weitere Änderungen enthält diese Version nicht.

  • host mail.xxxx.tld[173.xxx.xxx.xxx] said: 521 5.7.1

    Zitat von Citytow
    Code
    <info@xxxxx.de>: Recipient address rejected: Domain disabled (in reply to
    RCPT TO command)


    Wie die Meldung schon sagt: die Domain ist deaktiviert. Soweit ich weiß müsste diese Meldung nur dann erscheinen, wenn im LiveConfig beim betroffenen Vertrag E-Mail deaktiviert wurde.
    (also mal auf "Vertrag bearbeiten" klicken und schauen, was bei "Status" eingestellt ist (aktiv/gesperrt/deaktiviert).


    Viele Grüße


    -Klaus Keppler

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Also, Drupal trickst da ganz schön mittels .htaccess herum.
    Vereinfacht gesagt: in der .htaccess-Datei im Hauptverzeichnis wird eine RewriteRule gesetzt, welche Zugriffe auf nicht vorhandene Dateien pauschal durch index.php routet. Die Rewrite-Anweisungen in sites/default/files/.htaccess setzen alle anderen RewriteRules zurück - daher kommt es zu einem "403".


    Die Lösung ist also, das Routing nicht vorhandener Dateien auf die /index.php auch in die untergeordnete .htaccess aufzunehmen:

    Apache Configuration
    RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ /index.php [L]


    Damit werden die Thumbnails wieder korrekt beim ersten Aufruf erzeugt. Wir werden das in unsere Doku mit aufnehmen.
    Bei CloudFest werden wir uns zudem mal direkt mit den Drupal-Leuten über die Problematik unterhalten. ;)

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Hallo,


    anhand einer NGINX-Konfiguration für Drupal vermute ich, dass das am URL-Rewriting liegt: gedacht ist das so, dass wenn ein Zugriff auf den Image-Cache erfolgt und die Zieldatei aber (noch) nicht existiert, dass der Aufruf dann über die index.php geroutet werden soll (damit Drupal das gewünschte Bild dynamisch erzeugt).
    Die aktuelle RewriteRule sollte das aber eigentlich auch gar nicht verbieten...
    Wir werden mal versuchen, das mit einer Drupal-Testinstallation zu reproduzieren. Details folgen dann in Kürze...


    Viele Grüße


    -Klaus Keppler

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Zitat von WolfgangS

    Leider hat der eine sehr negative Auswirkung:
    Durch den Flag [F] werden alle Scripten abgebrochen, die auf den Files-Folder zugreifen. Viele Bild-Uploads, die in Drupal durchgeführt werden, legen automatisch von den hochgeladenen Bildern Styles an:
    So werden z.B. automatisch Bilder als Thumbnails in 150 x 150 Pixel erstellt [...]


    Die o.g. RewriteRule sollte nur dann Zugriffe verbieten, wenn die abzurufende Datei direkt eine der aufgeführten Endungen (.php/.pl/.sh/usw) hat.
    Eine .jpg-Datei, die sich in dem Verzeichnis befindet, müsste problemlos abrufbar sein.


    Legen Sie testweise mal in sites/default/files/ eine Datei namens "test.txt" mit irgendeinem Inhalt an, und versuchen Sie anschließend, diese über den Browser aufzurufen.
    Welche Fehlermeldung exakt bekommen Sie? (403 forbidden oder 500 internal server error?)


    Zitat

    Habt Ihr andere Vorschläge, wie man die Sicherheitslücke stopfen kann?
    Danke und Viele Grüße :)
    Wolfgang


    Das Hauptproblem ist Drupal selbst, da es aktiv in die Serverkonfiguration eingreifen möchte. Dieser Ansatz ist gut gemeint, aber leider nicht zu Ende gedacht (z.B. sind NGINX .htaccess-Dateien völlig schnuppe).
    Wenn Sie einen komplett eigenen Server betreiben (also quasi nur einen einzigen Webspace-Vertrag auf dem Server angelegt haben), dann könnte man SetHandler dort erlauben (die Lücke wäre dann quasi wieder offen, könnte aber nicht aktiv durch "fremde" Kunden ausgenutzt werden).


    Ich vermute auf den ersten Blick, das irgendwas mit der RewriteRule oder der restlichen .htaccess-Datei nicht stimmt und deshalb der Zugriff auf die temporären Dateien nicht funktioniert - da gibt es also wahrscheinlich eine recht einfache Lösung.


    Viele Grüße


    -Klaus Keppler

  • Umstellung fastcgi auf FPM, Debian 9

    Guten Morgen,


    Zitat von weltmeister

    Hat jemand eine kurze und knappe Anleitung parat?


    Code
    apt install php-fpm


    Also im Prinzip nur die PHP-FPM-Pakete nach installieren. Die PHP-Pakete von LiveConfig enthalten jeweils bereits die FPM-Variante. Mit "liveconfig --diag" können Sie sich alle PHP-Versionen ausgeben lassen, da wird dann auch jeweils angezeigt ob diese FPM unterstützt.


    Zitat

    Mit der Umstellung auf "FPM" in den Angeboten allein ist es ja nicht getan. Es kursieren im Internet teilweise verschiedene Anleitungen, die untereinader variieren.


    Was LiveConfig betrifft, genügt es normalerweise tatsächlich, die Angebote bzw. Verträge auf FPM umzustellen. Erweiterungen spielen keine Rolle (ob Extensions für CGI oder FPM installiert wurde ist egal, die liegen alle in den selben Verzeichnissen).


    Wichtig ist vor allem, dass Sie FPM nur mit LiveConfig ab v2.7.4 nutzen (nur dann ist die Konfiguration sicher).

  • Applikationen sehr veraltet

    Zitat von seb1983

    Da ich PHP7.2 laufen habe gibt es ja zum Glück kein mysql_connect mehr sondern mysqli, warum ist denn die Applikation so brutal alt?


    Das ist leider die Gratwanderung...
    LiveConfig unterstützt ja alle großen Distributionen auch in der LTS-Version - konkrekt z.B. CentOS 6 (PHP 5.3!) oder Ubuntu 14 (PHP 5.5). Da ist eben standardmäßig kein aktuelles PHP verfügbar.
    Wir haben aber bereits auf der Roadmap, den Installer grundlegend zu überarbeiten, so dass je nach verfügbarer PHP-Version entsprechend aktuellere App-Versionen installiert werden können (damit legen wir voraussichtlich ab April/Mai los).


    Zitat

    Kann ich die irgendwo selber einspielen oder werden die extern bezogen?


    Contao wird heutzutage meistens über den "Contao Manager" per Shell installiert (mit "composer"). Achten Sie ggf. darauf, das opcache-Modul zu deaktivieren oder die php.ini-Option "opcache.file_cache_only=On" zu setzen - siehe Contao-Manager Issue #347.

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Für alle CMS-Entwickler die hier eines Tages mal mitlesen: es ist BAD PRACTICE, mittels .htaccess in die Serverkonfiguration einzugreifen. Der Schutz via SetHandler ist nett gemeint, verpufft aber sobald man z.B. NGINX einsetzt. Letztendlich wird zudem nur am Symptom herumgepfuscht (Ausführung von Dateien, die irgendwie im Webspace gelandet sind) als die eigentliche Ursache zu vermeiden (durch eine anständige Architektur, z.B. Speicherung reiner Nutzdaten außerhalb des Webspace-Roots).

  • WICHTIG: LiveConfig v2.7.4 (Sicherheitsupdate)

    Hmm, der Befehl FcgidWrapper ist ärgerlicherweise bei Apache nicht in den FileInfo-Overrides dokumentiert, sonst hätten wir den mit aufgenommen.


    Am einfachsten dürfte es sein, wenn Sie die Datei /usr/lib/liveconfig/lua/apache.lua bearbeiten und in Zeile 135 den Befehl "SubstituteMaxLineLength" durch "FcgidWrapper" ersetzen (*). Danach müssten Sie LiveConfig neu starten und den betroffenen Vertrag neu speichern (damit die vHost-Konfiguration aktualisiert wird).
    Wir werden FcgidWrapper beim nächsten Update auch mit in diese Liste aufnehmen (die Änderung ist daher quasi "updatesicher").
    Sicherheitstechnisch spricht aktuell nichts gegen FcgidWrapper, da hier die "normalen" suexec-Schutzmechanismen greifen.


    Viele Grüße


    -Klaus Keppler


    *) es hilft NICHT, die Anweisung "FcgidWrapper" einfach an die Liste anzufügen - nein, dafür muss leider ein anderer Eintrag dran glauben. Es gibt vermutlich einen Bug in Apache, welcher die maximale Länge der Zeile "AllowOverrideList" implizit begrenzt (laut Doku kann eine einzelne Config-Zeile max. 16MB groß sein, in der Praxis wird sie aber irgendwo klammheimlich (ohne Log-Meldung) abgeschnitten. Mehr als das, was LiveConfig aktuell rausschreibt, ist offenbar nicht drin.