Puncte:0

Setarea Apache pe BigSur (returnează ERR_CONNECTION_REFUSED)

drapel cn

În primul rând, am citit multe tutoriale, încerc multe ore în ultimele zile (pentru că știu că au existat miliarde de întrebări și tutoriale similare pentru același lucru înainte), dar sunt la final... :-(

Ultimul site pe care l-am urmărit (și l-am verificat de multe ori) a fost https://tech-cookbook.com/2020/11/14/setting-up-your-local-web-server-on-macos-big-sur-11-0-1-2020-mamp-macos-apache- mysql-php/. Înainte să încerc https://medium.com/nerd-for-tech/how-to-run-apache-php-on-mac-os-big-sur-7ffbf7cbef7b, dar arată foarte asemănător.

Ceea ce am

  • Apache 2.4.46 (apachectl -v)

  • php 7.3.24 (php -v)

  • Apache ar trebui să fie setat corect. S-a oprit și a început.

  • sudo apachectl configtest se intoarce Sintaxa OK

  • în /etc/apache2/httpd.conf am setat DocumentRoot și <Director... la /Utilizatori/nume utilizator/Site-uri/

  • /Utilizatori/nume utilizator/Site-uri are chmod 777

  • /Utilizatori/nume utilizator/Site-uri îmi arată conținutul directorului (calea este corectă)

  • /etc/apache2/extra/httpd-vhosts.conf este setat la (sursa https://wpbeaches.com/set-up-virtual-hosts-on-macos-big-sur-11-in-apache/)

      <VirtualHost *:80>
          ServerName localhost
          DocumentRoot /Users/username/Sites/ 
          # I've tried: 
          ## insert value into "",
          ## localhost, 
          ## localhost/~username, 
          ## set localhost and ServerAlias to localhost/~username, etc.
      </VirtualHost>
    

Rezultat
Ca rezultat, ambele http://localhost și http://localhost/~nume utilizator mă întoarce ERR_CONNECTION_REFUSED.

Le-am verificat pe toate .conf setările fișierelor cu macbook-ul meu mai vechi și arată foarte asemănător pe ambele mașini... :-(

Ai idee unde ar putea fi problema? Pot să pun aici mai multe informații suplimentare (copiere conținutul fișierelor conf, orice) dacă este nevoie... Sunt puțin fără speranță... :-(

Mulțumiri!

EDITAȚI | ×

ps -ax | grep „[h]ttpd” se intoarce

14994 ?? 0:00.51 /usr/sbin/httpd -D PRIMUL PLAN
14997 ?? 0:00.01 /usr/sbin/httpd -D ÎN PRIMUL PLAN
15002 ?? 0:00.01 /usr/sbin/httpd -D ÎN PRIMUL PLAN
15040 ?? 0:00.00 /usr/sbin/httpd -D PRIMUL PLAN
15042 ?? 0:00.00 /usr/sbin/httpd -D PRIMUL PLAN
15043 ?? 0:00.00 /usr/sbin/httpd -D PRIMUL PLAN

sudo lsof -a -iTCP -sTCP:LISTEN -c httpd se intoarce

COMANDA PID UTILIZATOR TIP FD DIMENSIUNEA DISPOZITIV/OPRIT NUMELE NODULUI
httpd 14994 root 4u IPv6 0xbbfd6axxxxxxxxxx 0t0 TCP *:http (ASCULTATE)
httpd 14997 _www 4u IPv6 0xbbfd6axxxxxxxxxx 0t0 TCP *:http (ASCULTATE)
httpd 15002 _www 4u IPv6 0xbbfd6axxxxxxxxxx 0t0 TCP *:http (ASCULTATE)
httpd 15040 _www 4u IPv6 0xbbfd6axxxxxxxxxx 0t0 TCP *:http (ASCULTATE)
httpd 15042 _www 4u IPv6 0xbbfd6axxxxxxxxxx 0t0 TCP *:http (ASCULTATE)
httpd 15043 _www 4u IPv6 0xbbfd6axxxxxxxxxx 0t0 TCP *:http (ASCULTATE)
drapel ph
Apache rulează de fapt? Verificați cu `ps -ax | grep '[h]ttpd'` (rețineți că, dacă rulează, probabil veți vedea mai multe procese.) Dacă rulează, verificați dacă ascultă conexiunile de intrare cu `sudo lsof -a -iTCP -sTCP:LISTEN -c httpd`
pavel avatar
drapel cn
@GordonDavisson mulțumesc pentru comentariul tău. Ambele ieșiri sunt adăugate în întrebare (îmi pare rău, nu pot spune dacă rulează de la ea)
drapel ph
Ieșirea `lsof` indică că ascultă pentru conexiuni IPv6, dar nu pentru IPv4; Nu știu ce ar cauza asta, dar asta m-aș concentra să încerc să găsesc. De fapt, încă un test: rulați `netstat -anv | grep '[.]80 .*LISTEN'` -- veți vedea o linie care începe cu `tcp6` care arată că ascultă pe TCP peste IPv4, dar este afișată și una care începe cu `tcp4`? Dacă da, asta ar arăta că altceva preia portul pe IPv4 și împiedică Apache să-l obțină.
pavel avatar
drapel cn
@GordonDavisson Primesc acest `tcp46 0 0 *.80 *.* ASCULTĂ 131072 131072 18249 0 0x0080 0x0000000e`
pavel avatar
drapel cn
@GordonDavisson: _Dacă da, asta ar arăta că altceva preia portul pe IPv4 și împiedică Apache să-l primească. _... ce înseamnă, sau ce ar trebui să fac? Sunt complet pierdut... :-(
drapel ph
De fapt, asta înseamnă că am interpretat greșit ieșirea `lsof` -- de fapt ascultă atât IPv6, cât și IPv4 (asta înseamnă "tcp46" de la începutul ieșirii `netstat`), iar `lsof` arăta doar v6 pentru unele motiv. Deci... nu aceasta este problema. Dar înseamnă că Apache rulează și ascultă conexiuni, ceea ce înseamnă că acesta (și fișierele sale de configurare și altele) sunt *nu* problema. Deci, uită-te la configurația rețelei tale; lucruri precum orice firewall-uri pe care le executați, proxy-uri, configurații ciudate de rețea/VPN etc.
drapel ph
De asemenea, în loc să utilizați „localhost”, încercați o adresă explicită: `http://127.0.0.1/`. Aș încerca și din linia de comandă, cu `curl http://127.0.0.1/`.
pavel avatar
drapel cn
@GordonDavisson Fără VPN, fără proxy... :-( `localhost` și `127.0.0.1` fac același lucru (redirecționate automat către https și `err_connection_refused`). `curl http://127.0.0.1` returnează `302` , `curl https://127.0.0.1` (sau `https://localhost`) returnează `curl: (7) Nu s-a putut conecta la portul localhost 443: Conexiune refuzată`... Se pare că problema este în redirecționare automată la https (am încercat să-l caut pe google și nu am găsit o modalitate de a-l dezactiva)?
pavel avatar
drapel cn
@GordonDavisson Am setat HTTPS - browser-ul marchează URL-ul ca nesigur, dar funcționează... Blocare verde în URL pe care o pot rezolva mai târziu... mulțumesc pentru timpul acordat!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.