Puncte:0

Este necesară autorizarea 401 pe Apache 2.2 când ondularea duce la o eroare de lac 500

drapel cn
[centos@staging03 ~]$ sudo netstat -plnt
Conexiuni la internet active (numai servere)
Proto Recv-Q Trimitere-Q Adresă locală Adresă străină Stat PID/Nume program   
tcp 0 0 127.0.0.1:80 0.0.0.0:* ASCULTĂ 3600/httpd          
tcp 0 0 127.0.0.2:80 0.0.0.0:* ASCULTĂ 1574/varnishd       
tcp 0 0 172.31.22.60:80 0.0.0.0:* ASCULTĂ 1539/nginx          
tcp 0 0 0.0.0.0:22 0.0.0.0:* ASCULTĂ 1251/sshd           
tcp 0 0 127.0.0.1:25 0.0.0.0:* ASCULTĂ 1501/master         
tcp 0 0 127.0.0.1:443 0.0.0.0:* ASCULTĂ 3600/httpd          
tcp 0 0 127.0.0.1:6082 0.0.0.0:* ASCULTĂ 1573/varnishd       
tcp 0 0 127.0.0.1:9000 0.0.0.0:* ASCULTĂ 3468/php-fpm        
tcp 0 0 127.0.0.1:11211 0.0.0.0:* ASCULTĂ 1229/memcached      
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 1061/redis-server 1 
tcp 0 0 :::22 :::* ASCULTĂ 1251/sshd           
tcp 0 0 :::3306 :::* ASCULTĂ 1383/mysqld 

Am verificat pentru a investiga care este problema cu serverul meu și când am făcut:

curl 127.0.0.1:80

Am:

Este necesară autorizarea

Acest server nu a putut verifica că dvs sunt autorizate să acceseze documentul solicitat. Ori ai furnizat greșit acreditările (de exemplu, parolă greșită) sau dvs browserul nu înțelege cum să furnizeze acreditările necesare.


Pe un alt server unde totul funcționează, primesc un răspuns necompletat. Deci mă gândesc că acesta este motivul pentru care primesc o eroare de lac 500 de la Apache.

În jurnalul Apache, nu am primit nimic când m-am ondulat, dar înainte de asta am primit:

[Miercuri, 27 oct 17:02:25 2021] [notificare] am prins SIGTERM, închiderea
[Miercuri 27 octombrie 17:02:25 2021] [notificare] mecanism suEXEC activat (wrapper: /usr/sbin/suexec)
[Miercuri 27 oct 17:02:25 2021] [notificare] Digest: se generează secret pentru autentificarea digest...
[Miercuri 27 oct 17:02:25 2021] [notificare] Rezumat: gata
[Miercuri 27 octombrie 17:02:25 2021] [notificare] FastCGI: manager de proces inițializat (pid 3602)
[Miercuri, 27 oct 17:02:25 2021] [notă] Apache/2.2.15 (Unix) DAV/2 mod_fastcgi/2.4.6 configurat -- reluarea operațiunilor normale

Deci, se pare că FastCGI este configurat corect și problema pe care o primesc de la Apache este o problemă de autentificare destul de ciudat. Mai pot face ceva pentru a stabili care este problema?

Lacul oferă următoarele:

   12 TxHeader b X-Lac: 1537309960
   12 RxProtocol b HTTP/1.1
   12 RxStatus b 500
   12 RxResponse b Eroare internă de server
   12 RxHeader b Data: miercuri, 27 octombrie 2021 21:14:18 GMT
   12 RxHeader b Server: Apache/2.2.15 (CentOS)
   12 RxHeader b Expiră: miercuri, 11 ianuarie 1984 05:00:00 GMT
   12 RxHeader b Cache-Control: fără cache, trebuie revalidat, vârsta maximă=0

Cu toate acestea, nu am cum să verific ce este eroarea 500 Internal Server, deoarece jurnalele de erori pentru PHP par să fie goale.

Puncte:1
drapel in

TODO Apache

  1. Creșteți nivelul jurnalului în Apache
  2. Testați diferența dintre un apel HTTP către un fișier static în Apache și un apel către PHP
  3. Monitorizați jurnalul de erori Apache cu gradul de verbozitate crescut

Scopul este de a obține un HTTP 200 din Apache prin rulare curl http://127.0.0.1, fie pe pagina de pornire, fie pe un fișier static.

TODO Lac

  1. Actualizați Varnish la o versiune acceptată și întreținută
  2. Adăugați o sondă de backend în VCL
  3. Monitorizați starea backend-ului prin VSL

Pe baza rezultatului VSL pe care l-ați partajat, pot vedea că rulați o versiune veche a Varnish. Vedea https://www.varnish-software.com/developers/tutorials/installing-varnish-centos/ pentru a afla cum se poate instala Lac 6.0 LTS pe CentOS.

Nu numai că aveți o versiune de Varnish care este sigură, ci și instrumentele dvs. VSL (cum ar fi vernislog) sunt, de asemenea, cu mult superioare decât în ​​versiunea pe care o rulați.

Iată un exemplu de backend care are o sondă de sănătate:

backend implicit {
    .host = "127.0.0.1";
    .port = "8080";
    .probe = {
        .url = "/";
        .timeout = 2s;
        .interval = 5s;
        .fereastră = 10;
        .pragul = 5;
   }
}

Acest lucru vă va permite să monitorizați în mod continuu starea de sănătate a backend-ului dvs. Puteți face acest lucru cu următoarea comandă:

sudo varnishlog -g raw -i Backend_health

Ieșirea vă va ajuta să înțelegeți cum se comportă backend-ul și ce cod de stare HTTP returnează la Varnish.

Combinați acest lucru cu încercarea dvs. de a obține un cod de stare HTTP 200 de la Apache și veți ajunge destul de aproape de o soluție finală.

haher avatar
drapel cn
Nu este probabil ca eroarea 500 să fie din cauza php și putem înregistra și erorile php?
Thijs Feryn avatar
drapel in
Probabil că va ajunge în jurnalul de erori al serverului web dacă totul este configurat corect. Asigurați-vă că raportarea erorilor pentru runtime PHP este activată și că erorile sunt înregistrate corect.

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.