Puncte:1

Localhost nu este accesibil cu Wordpress

drapel nl

Am încercat să-mi configurez serverul cu un nume de domeniu, dar primesc o eroare 301 la introducerea adresei URL în browser. (http://localhost funcționează bine, dar http://example.com produce o eroare 301).

Am serverele DNS îndreptate către IP-ul public corect, iar routerul setat la port-forward incoming 80, la local 80, la IP-ul privat corect.

apache2.conf a fost modificat după cum urmează

#<Director /var/www/>
# Opțiuni Indexuri FollowSymLinks
# AllowOverride Niciunul
# Solicită toate acordate
#</Directory>

<Director /srv/>
    Opțiuni FollowSymLinks
    AllowOverride Nici unul
    Solicitați toate acordate
</Director>

Acest lucru este de dragul instalării Wordpress la cea sugerată /srv/www/wordpress/ și nu este nevoie de cealaltă locație Apache implicită pentru un site web...

wordpress.conf în /etc/apache2/sites-enabled/ folderul este ca următorul:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias *.example.com

    DocumentRoot /srv/www/wordpress
    <Directory /srv/www/wordpress>
        Options FollowSymLinks
        AllowOverride Limit Options FileInfo
        DirectoryIndex index.php
        Require all granted
    </Directory>
    <Directory /srv/www/wordpress/wp-content>
        Options FollowSymLinks
        Require all granted
    </Directory>
</VirtualHost>

Folosesc Ubuntu 20.04, Apache 2.4.41, Wordpress 5.8.1

Actualizare 23 septembrie 2021

Am editat titlul acestei întrebări de la „Getting 301 Error on Apache Server” la „Localhost is Unreachable with Wordpress”. Anterior, primisem întotdeauna un simplu răspuns „a expirat” când intram în domeniul meu (http://example.com) din rețeaua mea locală pe care rulează serverul. Eroarea 301 a venit când un alt, la acel moment, a accesat domeniul meu extern. Acum că am găsit o modalitate de a accesa domeniul meu extern, eroarea este consistentă: „Localhost este inaccesibil”. Apropo, acest lucru pare să se întâmple doar pe site-ul Wordpress; când accesez site-ul implicit „Funcționează”, este în regulă (am decomentat apache2.conf rânduri pe care le-am evidențiat mai devreme). Acest lucru se datorează probabil că Wordpress utilizează o bază de date și implicit nume de gazdă pentru utilizator fiind "gazdă locală"?

[Pentru cei care încearcă să intre în domeniul care indică serverul lor: dacă faceți acest lucru din aceeași rețea locală pe care se află serverul, nu va funcționa (căutați „NAT loopback” pentru mai multe despre asta). Nu asta e discuția aici, dar o menționez pentru că s-a scufundat mult timp; gazdă locală lucrări, modificând /etc/hosts pot face unele trucuri - încă nu simulează o solicitare externă din cunoștințele mele --, dar în cele din urmă, utilizarea numelui de domeniu nu va funcționa.]

drapel in
Două întrebări... ei bine... trei, dar mă voi opri la două: (1) Apache deține sau are permisiunea de a accesa fișierele din `/srv/www/wordpress` (2) Funcționează AppArmor și, dacă deci, este configurat pentru a permite Apache să acceseze conținutul `/srv/www/wordpress`?
jelt avatar
drapel nl
(1) este o sugestie grozavă; Am configurat Wordpress sub ID-ul meu de utilizator, nu implicit al www-data (ceea ce se pare că și Apache din Ubuntu face). Am făcut un `chown -R www-data:www-data /srv/www` recursiv pentru a rectifica asta, dar nu a rezolvat problema. (2) Nu sunt sigur cum să verific dacă AppArmor este configurat pentru a permite Apache, dar rula și așa că l-am oprit pentru scurt timp pentru a verifica, dar nici nu a dat niciun rezultat.
drapel in
Dacă AppArmor rula, atunci pot exista și module încărcate pentru Apache care trebuie dezactivate: `sudo a2dismod apparmor`, apoi `sudo service apache2 restart` vă poate oferi ceea ce aveți nevoie. În mod ideal, totuși, nu ar trebui să existe niciun motiv pentru a avea fișiere Apache în afara `/var/www`, deoarece o mulțime de lucruri în mod implicit se așteaptă doar ca Apache să locuiască acolo...
jelt avatar
drapel nl
AppArmor nu este un mod activat în configurația mea; serviciul AppArmor rula totuși, apoi l-am oprit temporar pentru testare, așa cum sa menționat. Ubuntu.com/tutorials pentru instalarea WordPress pe care l-am urmat a indicat locația /srv.
drapel in
Atunci, să privim lucrurile din alt unghi. Puteți accesa serverul de la `localhost`, dar nu extern. Un „301” este o redirecționare permanentă. Ai instalat WordPress prin `http://localhost` sau cu domeniul pe care vrei să-l folosești? Dacă a fost folosit „localhost”, atunci pot fi câteva lucruri pe care va trebui să le modificați în configurația WordPress
jelt avatar
drapel nl
Dacă doriți să vedeți tutorialul destul de concis pe care l-am urmat în orice moment (https://ubuntu.com/tutorials/install-and-configure-wordpress#1-overview) --o singură diferență în afară de dependențe, am înlocuit `www -data` cu ID-ul meu de utilizator pentru fiecare instanță pe tot parcursul. Conform întrebării dvs., cred că am instalat mai întâi pentru `localhost`, apoi am adăugat opțiunea `ServerName` la directiva din `wordpress.conf` mai târziu
jelt avatar
drapel nl
Ceea ce vreau să spun este că am setat `ServerName example.com`....
Puncte:0
drapel nl

Deci, soluția a fost că baza de date Wordpress trebuia actualizată. Pentru a face acest lucru:

Cu acces la contul dvs. Wordpress, schimbați doar adresa URL Wordpress și URL-ul site-ului în Setări -> General:

Adresa WordPress (URL): <site_URL_here>

Adresa site-ului (URL): <site_URL_here>

SAU

Cu acces la baza ta de date Wordpress

  1. autentificați-vă la mysql cu numele de utilizator al site-ului dvs. wordpress (dacă uitați numele de utilizator, este în wp-config.php în directorul rădăcină al site-ului dvs. wordpress; parola corespunzătoare este și acolo)
mysql -u <nume_utilizator_aici> -p
  1. selectați baza de date pentru site-ul dvs. (din nou, wp-config.php v-a acoperit dacă uitați)
utilizați <database_name_here>
  1. PAS CHEIE: actualizați înregistrările „home” și „siteurl” (wordpress doc oficial note, ar trebui să omiteți orice „/” final de pe adresa URL)
UPDATE wp_options SET option_value="http://<site_URL_here>" WHERE option_name="home";
UPDATE wp_options SET option_value="http://<site_URL_here>" WHERE option_name="siteurl";
  1. verificați dacă înregistrările bazei de date tocmai au fost actualizate
SELECT * FROM wp_options WHERE opțiune_nume = "acasă" SAU opțiune_nume = "siteurl";

Asta e pentru problema aia.

Pentru a putea accesa site-ul dvs. la noua adresă:

Dacă site-ul wordpress este găzduit în propria rețea locală, după cum s-a menționat, NU îl veți putea accesa INTERN, adică de pe un dispozitiv din aceeași rețea locală (inclusiv server); fie prin localhost sau chiar prin adresa URL pe care tocmai ați introdus-o în pașii de mai sus, nu va funcționa. Puteți accesa site-ul NUMAI EXTERN (ex. de pe un telefon folosind date, de pe un computer din rețeaua unui prieten, de pe un computer de la serviciu etc.). Pentru că este o durere, cele două opțiuni pe care le-am găsit pentru a putea accesa în continuare site-ul INTERN sunt: i) aveți un router care poate gestiona loopback-ul NAT ii) utilizați o rețea privată virtuală

Nu am testat (i), dar știu că (ii) funcționează pentru că fac exact asta. Când VPN-ul este activat, navigați la adresa URL și veți putea vedea site-ul.

Cred că acest punct ar trebui să fie făcut mai cunoscut pentru tutorialele despre configurarea și crearea unui site Wordpress într-o rețea locală

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.