Beiträge von kk

    Spamhaus ist das letzte auf Gottes Erden was Admins einsetzen sollten. Mich wunder es etwas warum dies eingesetzt wird. Warum setzt man auf so einen Schrott?


    Sie übersehen, dass es verschiedene Listen von Spamhaus gibt. Standardmäßig konfiguriert LiveConfig die Verwendung der [NACHTRAG]SBL- und[/NACHTRAG] XBL-Liste (Exploit and Botnet Filter).
    Außerdem greift die konfigurierte Blacklist nur bei extern eingelieferten Mails; die E-Mails "eigener" Kunden sind davon nicht betroffen, sofern diese korrekt mit SMTP-Auth eingeliefert werden.


    So oder so - die Liste der Blacklists ist bereits zur freien Konfigurierbarkeit vorbereitet, die notwendigen Änderungen in der Oberfläche sollen zur Version 1.6 (Anfang November) fertig sein.


    Zitat

    smtpd_require_helo=yes <- gibt es übrigens nicht mehr ;)


    Ja, das gilt aber nicht für alle von LiveConfig unterstützten Postfix-Versionen. ;)


    Viele Grüße


    Klaus Keppler


    [KORREKTUR] Ich sehe eben, dass LC tatsächlich die kombinierte Liste (SBL-XBL) einrichtet. Nichtsdestrotrotz gab es hier noch nie Beschwerden oder Probleme; über weitere (objektive) Gründe Ihrer Spamhaus-Abneigung würde ich mich daher sehr freuen.
    Verwechseln Sie Spamhaus eventuell mit UCEPROTECT?

    Hmm, ok... dann bräuchte ich eine genauere Fehlerbeschreibung:

    Zitat

    Beim Speichern passiert wieder nichts, außer das im Log folgender Eintrag entsteht:


    Was bedeutet "nichts" - schließt sich das Popup-Fenster nicht?
    -> falls doch: erscheint die Weiterleitung dann in der (Sub)Domain-Liste? Falls ja, erscheint diese auch in der dazugehörigen Konfigurationsdatei (/etc/apache2/sites-available/##VERTRAG##.conf)?
    -> falls nein: steht in dem Popup unter der Optionsbox "Webspace" jeweils auch etwas bei "Software/IPs:" und "IPv4-Adresse"...? Welchen Browser verwenden Sie?


    Viele Grüße


    -Klaus Keppler

    Bitte prüfen Sie, ob Sie das Apache-Modul mod_rewrite auf dem Server aktiviert haben.
    (z.B. Debian: "a2enmod rewrite", danach ggf. "/etc/init.d/apache2 restart")


    Ich nehme es mal als Feature Request mit auf, dass LiveConfig darauf hinweist, falls mod_rewrite nicht aktiviert ist.


    Viele Grüße


    -Klaus Keppler


    PS: die Meldung mit "Unknown CGI variable..." ist rein kosmetisch, wird in Kürze verschwinden.

    Danke, wir können den Fehler reproduzieren. Dieser tritt dann auf, wenn ein Webspace-Angebot PHP mit FastCGI konfiguriert hat, und dieses direkt zum Anlegen eines Vertrages verwendet wird.
    Beim Anlegen von Verträgen mit suPHP und späterer Umstellung auf FastCGI tritt das nicht auf.


    Bugfix wird gerade vorbereitet, Update steht in Kürze bereit.


    Viele Grüße


    -Klaus Keppler

    Hmm, die Logs sagen doch eigentlich alles:


    Zitat

    suexec policy violation: see suexec log for more details


    -> was steht in /var/log/apache2/suexec.log ?


    Zitat

    /usr/lib/php5/20090626+lfs/fileinfo.so: cannot open shared object file: No such file or directory


    Soweit ich weiß ist fileinfo seit PHP 5.3 fester Bestandteil. Welche Distribution verwenden Sie denn?
    Evtl. existiert noch eine Datei /etc/php5/conf.d/fileinfo.ini, die vielleicht entfernt werden muß?


    Viele Grüße


    -Klaus Keppler

    Zitat

    CGI Scripte werden nicht gefunden


    Im Rahmen des Updates wurden die CGI-Verzeichnisse von ~/cgi-bin/ nach ~/htdocs/cgi-bin/ verschoben (siehe hier).
    Wenn bei einem Webspace das Zielverzeichnis (~/htdocs/cgi-bin) bereits existierte, wurde nichts verschoben, um keine Dateien zu überschreiben.


    Mit folgendem Befehl können Sie sich alle nicht verschobenen cgi-bin-Verzeichnisse anzeigen lassen:

    Code
    ls -ld /var/www/*/cgi-bin


    Diese müssten einfach nur unterhalb ~/htdocs/ verschoben werden.


    Zitat

    Internal Server Error


    Was sagt denn /var/log/apache2/suphp.log bzw. /var/log/apache2/error.log dazu?


    Viele Grüße


    -Klaus Keppler

    Hallo,


    welche Distribution verwenden Sie, bzw. wie haben Sie auf Dovecot v2 aktualisiert?


    Jedenfalls gibt es eine solche Möglichkeit. Installieren Sie bitte das Paket "sqlite3". Führen Sie danach folgende Schritte aus:

    • beenden Sie LiveConfig: /etc/init.d/liveconfig stop
    • öffnen Sie die SQLite-Datenbank von LiveConfig:
      sqlite3 /var/lib/liveconfig/liveconfig.db
    • Führen Sie folgenden SQL-Befehl aus:
      UPDATE POP3IMAPSERVERS SET PI_MANAGED=0;
    • beenden Sie SQLite3 mit ".quit" (Punkt am Anfang beachten!)
    • starten Sie LiveConfig wieder: /etc/init.d/liveconfig start
    • gehen Sie nun zur Serververwaltung -> Mail und aktivieren die Konfiguration von Dovecot erneut.


    Somit sollte die Konfiguration von Dovecot aktualisiert werden, die Datei /etc/dovecot/passwd bleibt unverändert.


    Ich werde das aber als Anregung aufnehmen, die Konfiguration auch "auf Knopfdruck" aktualisierbar zu machen - insbesondere wenn jemand zB. von Debian 6 auf 7 aktualisiert...


    Viele Grüße


    -Klaus Keppler

    Der cgi-bin-Ordner wird normalerweise komplett verschoben, außer eben es existiert bereits ein Verzeichnis mit dem Namen ~/htdocs/cgi-bin/.
    Dann wird nichts gemacht, um nicht (unerwünscht) Dateien zu überschreiben.


    Viele Grüße


    -Klaus Keppler

    Von einigen Nutzern kam eben der Wunsch, z.B. die Website unter http://www.example.org/ und gleichzeitig ein Blog unter http://www.example.org/blog/ zu betreiben. Der Grund dafür ist eigentlich zweitrangig - egal ob es nun um SEO oder SSL-Zertifikate geht.
    Aktuell kann man das mit einer RewriteRule bereits erreichen (einfach in ~/htdocs/ eine .htaccess anlegen, die Zugriffe auf /blog/ umbiegt nach /var/www/web#/apps/<AppId>/).
    Wir stellen uns das so vor, dass man bei der Installation einer App (und eventuell auch später bei bereits installierten Apps) neben der Auswahl der Subdomain auch den Pfad einstellen kann, über den die Anwendung erreichbar sein soll.

    Hallo,


    die Preview wurde eben noch mal aktualisiert (v1.5.2-r1890). Wir haben diese erfolgreich auf knapp einem Dutzend eigener Server produktiv in Betrieb; falls keine Probleme auftreten wird diese Version morgen (02.10.) produktiv freigegeben.


    Die wichtigste Änderung ist das Verschieben von ~/cgi-bin/ nach ~/htdocs/cgi-bin/ (siehe Forum).


    Viele Grüße


    -Klaus Keppler

    Mit dem Update auf LiveConfig v1.5.2 (ab r1888) wird für alle Webspaces das Verzeichnis
    ~/cgi-bin/
    automatisch verschoben nach
    ~/htdocs/cgi-bin/


    Wir wissen, dass dies in bestehenden Setups vereinzelt Anpassungen erfordern kann und hätten das gerne vermieden - geht aber leider nicht anders.


    Ablauf:
    Beim Update auf 1.5.2-r1888 (und später) wird automatisch geprüft, ob diese Anpassung auf dem Webserver bereits durch LiveConfig vorgenommen wurde (ein Update ist also nach wie vor von jeder auf jede Version möglich). Ggf werden die notwendigen Rechteänderungen dann automatisch vorgenommen - darum kümmert sich das Script /usr/lib/liveconfig/lcservice.sh (Parameter "fix-permissions").
    Alle vHost-Konfigurationen werden beim Start von LiveConfig ebenfalls automatisch aktualisiert (sowohl für Apache als auch für NGINX).
    Betroffen ist übrigens ausschließlich Webspace, der Erlaubnis für CGI-Scripte besitzt; ohne CGI-Berechtigungen sorgt die neue Konfiguration dafür, dass Zugriffe auf die URL /cgi-bin/ nicht erlaubt sind (falls dort jemand sensible Dateien liegen hat werden diese also nicht versehentlich abrufbar gemacht). Für NGINX ist der Zugriff auf /cgi-bin/ komplett verboten.


    Hilfs-Befehle:
    Mit folgendem Befehl kann nach Verzeichnissen gesucht werden, die nicht automatisch verschoben wurden (das ist dann der Fall, wenn ~/htdocs/cgi-bin/ bereits existiert hat - so stellen wir sicher, dass nichts versehentlich überschrieben wird):

    Code
    ls -ld /var/www/*/cgi-bin


    Mit folgendem Befehl kann gesucht werden, ob in den erfolgreich verschobenen Verzeichnissen irgendwo die alten Verzeichnispfade hardcodiert enthalten waren:

    Code
    find /var/www/*/htdocs/cgi-bin -type f -print0 | xargs -0 grep '/var/www/.*/cgi-bin'


    Sollte sich da tatsächlich etwas finden, kann man das z.B. mit sed automatisch anpassen lassen (selbstverständlich stehen wir hierfür bei Fragen gerne zur Verfügung!)


    Hintergrund:
    Mit Version 1.5.2 werden die Web-Verzeichnisse noch besser geschützt - diese gehören dann root:root. Damit suexec aber Programme im cgi-bin-Verzeichnis ausführen kann, muss dieses dem Benutzer gehören (z.B. web1:web1). Damit der Apache-Webserver da aber auch lesend zugreifen kann (vor der Ausführung eines CGI-Scripts) müssten auch alle anderen Benutzer Leserechte dafür bekommen (0755) - was natürlich indiskutabel ist.
    Daher wird /cgi-bin/ eben nach /htdocs/cgi-bin/ verschoben: das htdocs-Verzeichnis gehört zB. web1:www-data mit Modus 0750 - somit kann der Webserver zwar darin lesen, aber kein anderer Benutzer zugreifen.


    Die einzige Alternative wäre gewesen, /cgi-bin/ mit ACLs zu schützen; das ist an sich einfach und sicher, nur müssen ACLs bei vielen Dateisystemen erst explizit aktiviert werden, die ACL-Tools sind standardmäßig oft nicht installiert, bei Backups werden ACLs häufig nicht berücksichtigt, und so weiter...
    Ein "anderes" Controlpanel löst das /cgi-bin/-Rechteproblem übrigens so, indem es ein modifiziertes suexec-Binary ausliefert, das wiederum auch alternative Gruppen-Besitzer für /cgi-bin/ erlaubt. Das erfordert aber auch ein modifiziertes mod_suexec für Apache - somit würde also wieder viel zu tief in die von der Distribution bereitgestellten Pakete eingegriffen werden (was wir aus Prinzip nicht möchten).


    Fazit:
    Wir gehen davon aus, dass in den allermeisten Umgebungen praktisch niemand die Veränderung bemerken wird :)
    Nur in den Fällen, in denen Benutzer CGI-Scripte mit hardcodierten Pfaden verwendet haben, ist eine Anpassung erforderlich - diese lassen sich aber mit o.g. find-Befehl schnell identifizieren.
    Sollten Fragen oder Probleme auftauchen, stehen wir gerne zur Verfügung.


    Das Update (v1.5.2-r1888+) wird in den nächsten Stunden noch mal als aktualisierte Preview bereitgestellt, derzeit testen wir den Updatevorgang auf knapp 10 produktiv betriebenen Servern durch, um Überraschungen zu vermeiden.

    Der FastCGI-Starter (~/conf/php5/php-fcgi-starter) enthält ab Version 1.5.2-r1884 nun explizit ein "umask 0022" - damit wird eine eventuell im System restriktiver konfigurierte umask entsprechend korrigiert.


    Und suhosin.session.encrypt wird ab 1.5.2-r1877 standardmäßig auf "off" gesetzt, da auch andere Anwendungen Probleme damit haben.


    Viele Grüße


    -Klaus Keppler

    ERROR: Wrong 'suhosin.session.encrypt' option value. Read REQUIREMENTS section in INSTALL file or use Roundcube Installer, please!


    Ab LiveConfig 1.5.2-r1877 wird suhosin.session.encrypt nun in den individuellen php.ini-Dateien automatisch auf off gesetzt (es gibt noch viele andere Anwendungen, die damit Probleme haben).
    In Kürze ist die Oberfläche zur Verwaltung eigener php.ini-Einstellungen fertig, da kann man das dann auf Wunsch auch wieder auf "on" stellen.


    Viele Grüße


    -Klaus Keppler

    Zitat

    Furthermore the home folder is owned by the user so the user him/herself can change the permission to read-write.


    This is not correct. To change the permissions of a folder, you need write permission in its parent folder.
    This is also the reason why the user must not have write permissions to his home folder - otherwise he could for example rename the "conf" folder to "conf.old" (no matter who actually owns this one!) and substitute it by a new conf folder.
    Just try it out. :)


    So you need to be really careful when planning write permissions to users.