Beiträge von marinal

    Guten Abend,
    leider ist das nicht von Erfolg gekrönt. Ich habe ja erst am Zone-File editiert, als ich beim Update Fehler erhalten habe und die Fehler wegen OpenDKIm waren. Ich dacbte, wenn ich die fehlerhafte Zeile entferne, ist alles wieder in Ordnung, aber damit fingen die Probleme erst an.
    Wenn ich das so mache, wie oben beschrieben, wird die Zone neu erstellt, aber es gibt immer noch Probleme mit dem Update, da der Eintrag für openDKIM nicht gefunden werden kann.
    Ich habe bereits OpenDKIM bei der Domain deaktiviert, danach DNS deaktiviert und dann DNS und OpenDKIM wieder aktiviert. Jedoch ist immer das Feld bei OpenDKIM gefüllt, obwohl es noch keinen Schlüssel für OpenDKIM geben darf. Wird hier ein Wert gecached, der eigentlich nicht gecached werden sollte? Ich finde leider weder den Wert in den DB-Dumps, noch unter OpenDKIM, noch unter dem Bind-Verzeichnis.
    Oder ist das eventuell doch ein Bug?

    Hallo,


    ich habe beim Testen und Einrichten von verschiedenen Zones den Fehler begangen und ein Zonefile direkt manuell editiert.
    Gibt es eine Möglichkeit mit DNS wieder mit 0 anzufangen, so dass alle Zones neu generiert werden? Aktuell werden meines Erachtens gespeicherte Werte wiederverwendet.


    Vielen Dank


    Alexander Maringer

    Zitat

    These are non-standard 2048 bit Diffie-Hellman parameters.
    They are used as a start value by LiveConfig until individual
    parameters have been generated locally (which is done automatically
    by LiveConfig).


    aus /etc/proftpd/dhparams.pem


    Kann man Liveconfig dazu bringen, die DF-Parameter neu zu generieren? Ich hätte gerne 2048 Bit. Natürlich kann ich das auch per Hand anstoßen, aber ich weiß ja nicht, ob das dann wieder überschrieben wird.

    Ich verstehe die Forderung nach amavis nicht. Kostet doch nur Ressourcen. Und warum soll eine Vorsortierung per default eingebaut werden? Kann man doch selbst mittels Regel im Mailprogramm bzw. Sieve machen. Auch heute verwendet nicht jeder IMAP. Und diese sehen dann den Spam nicht. Auch beim besten Filter kommt es vor, dass false-positives auftauchen.

    Hallo arnoldB,


    erst mal danke. Allmählich glaube ich wirklich, dass ich betriebsblind bin. Wobei ... das Problem habe ich immer noch nicht lösen können. Ich habe die Datei angelegt, wie von Dir beschrieben. Owner root mit 0644. Direkt im Root des Vertrages. Der Inhalt der Datei:

    Zitat

    <Directory "/var/www/web2/priv">


    AllowOverride AuthConfig FileInfo Indexes
    Options FollowSymLinks Includes


    Order allow,deny
    allow from all
    </Directory>


    Egal, wie ich die Konfig aussehen lasse, bekomme ich immer dieselben Fehler (wie oben beschrieben). Ich habe jetzt eine Datei erstellt, welche die phpinfo() ausgibt. Und habe einen symbolischen Link in das priv-Verzeichnis erstellt. Ebenfalls dieselbe Ausgabe. Die Rechte können es meiner Meinung nach nicht sein, denn das Recht ist richtig. Und die Links sind ja erlaubt. Ebenso das Öffnen der Datei.


    Wo habe ich den Knopf im Hirn?


    Vielen Dank schon mal im Voraus


    marinal

    Ja, Du könntest recht haben ... obwohl es im OpenBaseDir eigentlich enthalten wäre ...


    Wobei bei der Gallery inkludiere ich die Sourcen auch per require aus /priv ... bei Typo3 führe ich die komplett aus ...
    Und bei den TYPO3-Sourcen ist kein symbolischer Link enthalten. Die Rechte stimmen auch alle für FCGI (Verzeichnisse 0755 und Dateien 0644). Also wirklich nachvollziehen kann ich es noch nicht.


    @Herr Keppler: Könnte man ein Verzeichnis für Sourcen außerhalb des DocRoots (htdocs) aufnehmen? Wäre meines Erachtens ein Sicherheitsfeature.

    Hallo,


    ich habe bisher immer TYPO3 selbst für meine Kunden installiert. Dabei habe ich bisher immer die Sourcen außerhalb des Docroots gelegt. Unter Liveconfig wollte ich die Sourcen unter /priv installieren:

    Code
    root@local:/var/www/web2/priv/typo3src# ls -lisa
    total 12
    8257869 4 drwxr-xr-x 3 web2 web2 4096 Aug  8 16:53 .
    7077931 4 drwxr-x--- 3 web2 web2 4096 Aug  8 16:51 ..
    8257870 4 drwxr-xr-x 4 web2 web2 4096 Aug  9 00:35 typo3_src-4.5.29


    Das Dummy-Packet ist in htdocs:


    Die Verzeichnisrechte sind immer 0755 und der Owner ist web2:web2. Verwendet wird FastCGI.


    Egal, ob ich den Symlink von "typo3_src" auf "/var/www/web2/priv/typo3src/typo3_src-4.5.29/" oder auf "../../priv/typo3src/typo3_src-4.5.29/" setze, bekomme ich immer einen 403 beim Aufruf. Ebenso ist es egal, ob ich die index.php auf 0644 oder 0755 setze. An der Standard-Apache-Datei wurde nichts geändert. Anbei noch die Fehlermeldungen:

    Code
    /var/log/apache2/error.log
    [Fri Aug 09 20:31:43 2013] [error] [client *IPv4*] Symbolic link not allowed or link target not accessible: /var/www/web2/htdocs/schankanlagen/typo3
    /var/log/apache2/other_vhosts_access.log
    www.*domain*.de:80 *IPv4* - - [09/Aug/2013:20:31:43 +0200] "GET /typo3/index.php HTTP/1.1" 403 434 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0"


    Verwendet wird Debian Wheezy. Weiß hier jemand Rat? Es funktioniert, wenn ich den Symlink auf das Verzeichnis direkt auf der Seite ("/var/www/web2/htdocs/schankanlagen/typo3_src-4.5.29/") setze. Aber das ist halt nicht sicher. Und den Application Installer möchte ich nicht nehmen.


    Vielen Dank für jeglichen Hinweis.


    Schönes Wochenende


    Marinal