Puncte:0

Eroare „FetchError no backend connection” atunci când Apache rulează

drapel cn
[centos@ip-172-35-25-65 ~]$ varnishlog
    0 CLI - Rd ping
    0 CLI - Wr 200 19 PONG 1635280998 1,0
    0 CLI - Rd ping
    0 CLI - Wr 200 19 PONG 1635281001 1,0
   10 SessionOpen c 127.0.0.2 55870 127.0.0.2:80
   10 ReqStart c 127.0.0.2 55870 894208400
   10 RxRequest c GET
   10 RxURL c /
   10 RxProtocol c HTTP/1.0
   10 RxHeader c X-Real-IP: 198.95.75.75
   10 RxHeader c X-Forwarded-Pentru: 198.95.75.75
   10 RxHeader c X-Forwarded-Proto: https
   10 RxHeader c X-Forwarded-Port: 80
   10 RxHeader c Gazdă: staging03.cherry.com
   10 RxHeader c Conexiune: închis
   10 RxHeader c Cache-Control: max-age=0
   10 RxHeader c Autorizare: de bază aGc6am9objEyMw==
   10 RxHeader c Solicitari de upgrade-nesigure: 1
   10 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/95.0.4638.54 Safari/537.36
   10 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v =b3;q=0,9
   10 RxHeader c Acceptare-Codificare: gzip, deflate
   10 RxHeader c Accept-Language: en-US,en;q=0.9,fr;q=0.8
   10 RxHeader c Cookie: ajs_anonymous_id=%22424f4cd9-cbbc-4ead-83b1-273cb21cf453%22; _fbp=fb.1.1630002144579.2012566540; __qca=P0-1416512434-1630002144589; _edwvts=708154457303700204; _gid=GA1.2.1572498662.1635275261; ajs_user_id=%224543534%40mimpi99.com%22; _gcl_au=1.1.
   10 VCL_call c recv pass
   10 VCL_call c hash
   10 Hash c /
   10 Hash c staging03.cherry.com
   10 Hash c 80
   10 Hash c ajs_anonymous_id=%22424f4cd9-cbbc-4ead-83b1-273cb21cf453%22; _fbp=fb.1.1630002144579.2012566540; __qca=P0-1416512434-1630002144589; _edwvts=708154457303700204; _gid=GA1.2.1572498662.1635275261; ajs_user_id=%224543534%40mimpi99.com%22; _gcl_au=1.1.1880042
   10 VCL_return c hash
   10 VCL_call c pass pass
   10 FetchError c nicio conexiune backend
   10 VCL_call c eroare livrare
   10 VCL_call c livra livrare
   10 TxProtocol c HTTP/1.1
   10 TxStatus c 503
   10 Serviciul TxResponse c indisponibil
   10 TxHeader c Server: Lac
   10 TxHeader c Content-Type: text/html; set de caractere=utf-8
   10 TxHeader c Reîncercați-După: 5
   10 TxHeader c Lungimea conținutului: 392
   10 TxHeader c Accept-Range: octeți
   10 TxHeader c Data: marți, 26 octombrie 2021 20:43:23 GMT
   10 TxHeader c X-Lac: 894208400
   10 TxHeader c Via: 1.1 lac
   10 TxHeader c Conexiune: închis
   10 TxHeader c X-Age: 0
   10 TxHeader c X-Cache: MISS
   10 Lungime c 392
   10 ReqEnd c 894208400 1635281003.852778196 1635281003.852984428 0.000073195 0.000165701 0.000040531
   10 eroare SessionClose c
   10 StatSess c 127.0.0.2 55870 0 1 1 0 1 0 273 392
    0 CLI - Rd ping
    0 CLI - Wr 200 19 PONG 1635281004 1,0
    0 CLI - Rd ping
    0 CLI - Wr 200 19 PONG 1635281007 1,0
    0 CLI - Rd ping
    0 CLI - Wr 200 19 PONG 1635281010 1,0
    0 CLI - Rd ping
    0 CLI - Wr 200 19 PONG 1635281013 1,0

Am încercat să înregistrez ce se întâmplă când am primit din partea clientului:

Eroare 503 Serviciu indisponibil
Serviciu indisponibil

Meditația Guru:
XID: 894208400

Acum, am crezut că este din cauza că Apache nu rulează, pentru că atunci când închid varnish primesc o eroare de gateway 502 de la nginx. Oricum, am citit jurnalele de erori:

[Tue Oct 26 14:53:47 2021] [notificare] Politica SELinux activată; httpd rulează ca context unconfined_u:system_r:httpd_t:s0
[Tue Oct 26 14:53:47 2021] [notificare] mecanism suEXEC activat (wrapper: /usr/sbin/suexec)
[Tue Oct 26 14:53:47 2021] [notificare] Digest: se generează secret pentru autentificarea digest...
[Tue Oct 26 14:53:47 2021] [notificare] Rezumat: gata
[Tue Oct 26 14:53:47 2021] [notificare] FastCGI: manager de proces inițializat (pid 23090)
[Tue Oct 26 14:53:47 2021] [notificare] Apache/2.2.15 (Unix) DAV/2 mod_fastcgi/2.4.6 configurat -- reluarea operațiunilor normale
[Tue Oct 26 14:53:52 2021] [eroare] [client 127.0.0.1] Index de director interzis de directiva Opțiuni: /var/www/html/
[Tue Oct 26 14:53:52 2021] [eroare] [client 127.0.0.1] Fișierul nu există: /var/www/html/favicon.ico, referitor: http://staging03.hgreg.com/
[Tue Oct 26 15:01:21 2021] [eroare] [client 127.0.0.1] Index de director interzis de directiva Opțiuni: /var/www/html/
[Tue Oct 26 15:01:42 2021] [notificare] am prins SIGTERM, închizându-se
[Tue Oct 26 15:01:42 2021] [notificare] Politica SELinux activată; httpd rulează ca context unconfined_u:system_r:httpd_t:s0
[Tue Oct 26 15:01:42 2021] [notificare] mecanism suEXEC activat (wrapper: /usr/sbin/suexec)
[Tue Oct 26 15:01:42 2021] [notificare] Digest: se generează secret pentru autentificarea digest...
[Tue Oct 26 15:01:42 2021] [notificare] Rezumat: gata
[Tue Oct 26 15:01:42 2021] [notificare] FastCGI: manager de proces inițializat (pid 23299)
[Tue Oct 26 15:01:42 2021] [notificare] Apache/2.2.15 (Unix) DAV/2 mod_fastcgi/2.4.6 configurat -- reluarea operațiunilor normale
[Tue Oct 26 15:11:56 2021] [notificare] am prins SIGTERM, închizându-se

Am văzut SIGTERM, închizându-se, așa că m-am gândit că ar trebui să repornesc Apache și am făcut-o, dar am aceeași eroare și nu există loguri noi în error_log.

[centos@ip-172-35-25-65 ~]$ sudo service httpd restart
Oprirea httpd: [ OK ]
Se pornește httpd: [ OK ]
[centos@ip-172-35-25-65 ~]$ data
Marți, 26 octombrie, 17:12:32 EDT 2021
[centos@ip-172-35-25-65 ~]$ 

Acum, rulez o configurație de marionetă, dar nu a rulat complet, dar am aceleași fișiere. Așa că mă întreb care ar putea fi problema. Unul dintre fișierele de configurare Apache care este încărcat deoarece toate fișierele cu conf sunt încărcate este astfel:

<VirtualHost *>
    ServerName preprod.staging03.cherry.com

    
    
    ServerAlias betacherry.staging03.cherry.com staging03.cherry.com
    
    

    DocumentRoot /home/staging03/version/preprod.staging03.cherry.com
    ServerAdmin [email protected]

    SetEnv environment preprod
    SetEnv project staging03

    UseCanonicalName Off
    #CustomLog /var/log/httpd/preprod.staging03.cherry.com_log combined
    #CustomLog /var/log/httpd/preprod.staging03.cherry.com-bytes_log "%{%s}t %I .\n%{%s}t %O ."

    ## User cherry # Needed for Cpanel::ApacheConf
    UserDir disabled
    UserDir enabled staging03
    
      #<IfModule mod_suphp.c>
    #    suPHP_UserGroup staging03 staging03
    #</IfModule>
    
    SuexecUserGroup staging03 staging03
    
    <directory "/home/staging03/version">
        AddHandler php5-fcgi .php
        Action php5-fcgi /php5-fcgi-staging03
        AllowOverride All

        
        AuthType Basic
        AuthName "staging03-preprod"
        AuthUserFile "/etc/httpd/conf.d/htpasswd.staging03"
        require valid-user

        satisfy any
        deny from all

        Order deny,allow
        SetEnvIf X-Hg-Internal-IP 1 HgInternalIP=1
        Allow from env=HgInternalIP

        SetEnvIf User-Agent "Amazon CloudFront" AmazonCloudFront
        Allow from env=AmazonCloudFront

        SetEnvIf User-Agent "^(.*)Lighthouse(.*)$" Lighthouse=1
        Allow from env=Lighthouse
        
    </directory>
    <IfModule concurrent_php.c>
        php5_admin_value open_basedir "/home/staging03:/usr/lib/php:/usr/local/lib/php:/tmp"
    </IfModule>
    <IfModule !concurrent_php.c>
        <IfModule mod_php5.c>
            php_admin_value open_basedir "/home/staging03:/usr/lib/php:/usr/local/lib/php:/tmp"
        </IfModule>
        <IfModule sapi_apache2.c>
            php_admin_value open_basedir "/home/staging03:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp"
        </IfModule>
    </IfModule>
    <IfModule !mod_disable_suexec.c>
        <IfModule !mod_ruid2.c>
            SuexecUserGroup staging03 staging03
        </IfModule>
    </IfModule>
    <IfModule mod_ruid2.c>
        RMode config
        RUidGid staging03 staging03
    </IfModule>
    <IfModule itk.c>
        # For more information on MPM ITK, please read:
        #   http://mpm-itk.sesse.net/
        AssignUserID staging03 staging03
    </IfModule>
</VirtualHost>

Deci, ce fișiere ar trebui să mă uit și cum verific că problema nu este Apache, pentru că avem rutare nginx pentru a lăcui și apoi rutare către Apache, așa că cred că Apache este problema, dar nu primesc informații utile din jurnal și Apache rulează fără nicio problemă, pur și simplu nu deservește pagina și Varnish nu poate ajunge la Apache dintr-un motiv oarecare?

Rulez CENTOS 6 și am un alt server cu aceleași configurații care funcționează bine, dar când diferențiez folderul etc, nu văd nicio diferență semnificativă.

Puncte:1
drapel in

Pe baza jurnalelor dvs., pot vedea că Atât Varnish, cât și Apache rulează pe aceeași mașină. Lacul ar trebui să ruleze pe port 80 și Apache pe port 8080.

Se pare că există și un Nginx care rulează, așa că presupun că este pentru terminarea TLS, care rulează pe port 443.

Pasul 1: asigurați-vă că Apache ascultă cu succes pe portul 8080

Alerga sudo netstat -plnt pentru a afla ce porturi sunt folosite de fiecare serviciu.

Asigurați-vă că httpd serviciul ascultă pe port 8080 și verificați acest lucru rulând curl -I localhost:8080.

Pasul 2: adăugați o sondă de sănătate pentru backend în fișierul dvs. VCL

VCL standard nu oferă o sondă de sănătate pentru backend-ul implicit. Folosind codul VCL de mai jos, puteți monitoriza în mod constant starea backend-ului:

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

Odată ce sonda este adăugată și noul VCL este încărcat, puteți apela următoarea comandă pentru a verifica starea backend-ului, pe baza sondei:

varnishlog -g raw -i backend_health

Dacă ieşirea conţine Încă bolnav, știți că backend-ul nu este disponibil și că codul de stare vă poate spune de ce.

Pasul 3: actualizați serverul dvs. Varnish

Nu m-am putut abține să nu observ termeni precum RxHeader în ieșirea dvs. VSL. Acesta este un indiciu clar că utilizați o versiune veche a Varnish care nu mai este acceptată.

Chiar și în versiunile cu adevărat vechi de Varnish, RxHeader a fost înlocuit cu ReqHeader.

Sfatul meu: upgrade la Lac 6.0 LTS. Această versiune LTS a lui Varnish vine cu remedieri frecvente de erori și corecții de securitate. Vedea https://www.varnish-software.com/developers/tutorials/installing-varnish-centos/ pentru a afla cum să instalați această versiune pe CentOS.

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.