Was hat das 10.8.2-Update bewirkt, um die Vhosts eines AMP-Stacks zu beschädigen?

Ich habe letzte Woche von 10.8.1 auf 10.8.2 aktualisiert und seitdem muss ich noch bestimmte Vhosts auf meiner lokalen Sandbox zum Laufen bringen. Einige von ihnen funktionieren gut, während andere jetzt überhaupt nicht mehr funktionieren, wenn sie es früher getan haben. Kann ich irgendetwas tun, damit die wieder funktionieren?

Arbeits-Vhost:

<VirtualHost *:80>
    DocumentRoot "/Users/reindeerdev/Sites/patron-social-club-v2-old/app/webroot"
    ServerName pscv2.local
    ErrorLog "/private/var/log/apache2/pscv2-error_log"
    CustomLog "/private/var/log/apache2/pscv2-access_log" common
    <Directory /Users/reindeerdev/Sites/patron-social-club-v2-old/app/webroot>
        Options All
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

Problematischer Vhost:

<VirtualHost *:80>
    DocumentRoot "/Users/reindeerdev/Sites/Patron_Intranet/app/webroot"
    ServerName intranet.local
    ErrorLog "/private/var/log/apache2/intranet-error_log"
    CustomLog "/private/var/log/apache2/intranet-access_log" common
    <Directory /Users/reindeerdev/Sites/Patron_Intranet/app/webroot>
        Options All
        AllowOverride All
    </Directory>
</VirtualHost>

Endlich etwas in meinen Apache-Konfigurationen gesehen:

[Tue Oct 16 10:52:03 2012] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
httpd: Could not reliably determine the server's fully qualified domain name, using Logans-iMac.local for ServerName
[Tue Oct 16 10:52:06 2012] [warn] NameVirtualHost *:80 has no VirtualHosts
[Tue Oct 16 10:52:09 2012] [notice] Digest: generating secret for digest authentication ...
[Tue Oct 16 10:52:09 2012] [notice] Digest: done
[Tue Oct 16 10:52:09 2012] [notice] Apache/2.2.22 (Unix) PHP/5.3.15 with Suhosin-Patch DAV/2 mod_ssl/2.2.22 OpenSSL/0.9.8r mod_perl/2.0.5 Perl/v5.12.4 configured -- resuming normal operations

Ich weiß genau, dass ich Include /etc/apache2/other/httpd-vhosts.confin meiner httpd.conf-Datei habe und dass ich bestätigt habe, dass dies die richtige vhosts-Datei ist, die ich verwende.

Hast du eine NameVirtualHost *:80in deiner httpd-vhosts.conf?
Ja, ich will. Wenn ich das mache apachectl -Sbekomme ich auch die richtige Ausgabe undSyntax OK

Antworten (2)

Es wurde festgestellt, dass eine sehr seltsame Änderung der Benutzerberechtigungen im Ordner ~/Sites diese Fehler verursacht hat. Fest.

Schön, dass du das behoben hast. Könnten Sie die Einzelheiten darüber angeben, was genau der Fehler war und was Sie getan haben, um ihn zu beheben? Stellen Sie außerdem sicher, dass Sie Ihre eigene Antwort als "akzeptiert" markieren, damit andere mit ähnlichen Problemen wissen, was Sie getan haben. Danke!

Sie scheinen keine "Allow" -Direktive in den problematischen vhost eingefügt zu haben. Möglicherweise haben Sie zuvor die globalen Einschränkungen in /etc/apache2/httpd.conf geändert, um sie lockerer zu gestalten, und sie wurden während des Updates außer Kraft gesetzt. Der Standardwert ist Allow none. Es ist jedoch keine gute Idee, dies auf globaler Ebene zu tun, da dies dem Webserver möglicherweise Zugriff auf das vollständige Dateisystem gewährt.

Um das Problem zu beheben, ändern Sie den vhost in:

<VirtualHost *:80>
    DocumentRoot "/Users/reindeerdev/Sites/Patron_Intranet/app/webroot"
    ServerName intranet.local
    ErrorLog "/private/var/log/apache2/intranet-error_log"
    CustomLog "/private/var/log/apache2/intranet-access_log" common
    <Directory /Users/reindeerdev/Sites/Patron_Intranet/app/webroot>
        Options All
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>
Ich habe diese Änderung vorgenommen und immer noch nichts. Soll ich meine httpd.conf posten?
Was ist der eigentliche Fehler, den Sie beim Surfen auf der Website erhalten? Hast du Apache nach den Änderungen neu gestartet?
Ja ich habe neu gestartet. Ich bekomme nur den Standard: Verbindung nicht möglich. Firefox kann keine Verbindung zum Server unter intranet.local herstellen.
Wie lösen Sie diese Hostnamen auf? Über /etc/hosts? Hast du dort nachgeschaut und ob es immer noch richtig auflöst?
ja über /etc/hosts. Wenn ich intranet.local pinge, pingt es erfolgreich 127.0.0.1. wird die Webapp einfach nicht aufrufen.
Überprüfen Sie Ihre Apache-Fehlerprotokolle auf Hinweise.
Nichts in den Fehlerprotokollen. Wenn ich in Chrome darauf gehe, bekomme ich diese Meldung:Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.
Habe den Beitrag gerade editiert.
Was hat das 10.8.2-Update bewirkt, um die Vhosts eines AMP-Stacks zu beschädigen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v