Puncte:1

S-a setat redirecționarea subdomeniului Apache către alt subdomeniu

drapel fr

Încerc să configurez două subdomenii, pt A și b în domeniu.com. Folosesc două fișiere .conf, care arată aproape la fel cu modificările corespunzătoare la ServerName și ProxyPass:

<VirtualHost *:80>
        ServerName a.domain.com #This was added as a try for a fix. 
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>

        ServerName a.domain.com
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/a

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        #SSL stuff

        #Proxies

        ProxyPass        /        https://a.domain.com:8444/
        ProxyPassReverse /        https://a.domain.com:8444/
        ProxyPass        /a/      https://a.domain.com:8444/
        ProxyPassReverse /a/      https://a.domain.com:8444/
        ProxyPass        /b/      https://b.domain.com:8445/
        ProxyPassReverse /b/      https://b.domain.com:8445/

</VirtualHost>

Acest lucru se face în mediul meu de testare, replicând ceva similar cu ceea ce este în prezent în producție. În /etc/hosts, am adăugat a.domain.com și b.domain.com până la 127.0.0.1. DNS-ul în producție are înregistrări pentru ce a.domain.com și b.domain.com are, care este același IP (am făcut asta și în mașina de la care testez asta).

De asemenea, rețineți că nu difuzez conținut din directoarele lor rădăcină. Am adăugat că încercând să rezolv problema menționată în titlu. Există totuși un html simplu în ambele directoare.

Care este problema reală?

Pur și simplu, când încerci a.domain.com, rezultatul este aplicația web de la localhost:8444, cum era de așteptat. Când încerci b.domain.com, rezultatul este de asemenea localhost:8444, în loc de localhost:8445. Ambii a.conf și b.conf sunt activate, iar dacă dezactivez a.conf, atunci primesc corect localhost:8445. Daca incerc si eu like a.domain.com/b, redirecționarea se rezolvă înapoi la a.domain.com.

Am citit mai multe întrebări și tutoriale, iar majoritatea dintre ele fie au ceva care funcționează ca în configurația mea, fie adaugă NameVirtualHost, care înțeleg că nu este necesar pentru versiunea mea de Apache.Am adăugat, de asemenea, un ServerName în portul 80, deoarece am crezut că poate cererea pentru b a fost egalat de a.conf deoarece sunt același IP, dar nici asta nu a funcționat.

Ce îmi lipsește aici? Este ceva cu mod_proxy pe care se pare că îl ignor? Dacă este posibil, aș dori să păstrez un fișier pentru fiecare aplicație web. Mulțumiri!

Aceasta este pe Ubuntu 18.04.2, Apache 2.4 (mod_proxy și mod_ssl), Tomcat 9. Orice alte informații doriți, voi încerca să le livrez.

ACTUALIZAȚI

Am incercat si cu aceasta configuratie. Același rezultat nedorit.

<VirtualHost *:80>
        ServerAlias a.domain.com
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>

        ServerName a.domain.com
        ServerAdmin webmaster@localhost

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        #SSL stuff

        #Proxies

        Redirect /b https://b.domain.com

        <Location />
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

        <Location /a>
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

</VirtualHost>

ACTUALIZAȚI

Ok, tocmai am găsit ceva foarte enervant. Dacă intru cu browserul meu la oricare a.domain.com sau b.domain.com, amândoi se hotărăsc să a.domain.com. Aceasta este problema pe care am descris-o inițial. DAR daca incerci https://a.domain.com sau https://b.domain.com, ambele rezolvă la serverul potrivit: A la 8444 și b la 8445.

Deoarece este foarte frustrant, voi lua o frână și voi analiza asta peste un timp.

ACTUALIZAȚI

După o frână lungă, am încercat alte modificări aleatorii doar pentru a vedea ce s-a întâmplat și, din nou, nimic nu a funcționat conform așteptărilor, cu excepția utilizării HTTPS. Am instalat Postman pentru a vedea ce se trimite în cerere și am aflat că în Postman, atât HTTP, cât și HTTPS folosesc gazda corect. Și mai bine/mai rău: răspunsul real arată diferitele pagini de bun venit pentru a.domain.com și b.domain.com, ceea ce înseamnă că configurațiile mele funcționează corect când folosesc Postman.

Cred că toată această încercare ar putea fi doar o problemă de cache, dar browserul meu de testare ales (dev. Firefox) este setat să nu memoreze în cache. Voi verifica răspunsurile cu curl și cu celelalte browsere ale mele.

drapel kz
Menționați _caching_ ... țineți cont de faptul că directivele 301 sunt stocate în cache în mod persistent (de către browser și, eventual, cache-urile intermediare). Dacă anterior ați omis directiva `ServerName a.domain.com` în vHost:80 (și directiva corespunzătoare pentru `b.domain.com`), atunci redirecționarea de la `http://b.domain.com/` la ` Este posibil ca https://a.domain.com` să fi fost memorat în cache (depinde de ordinea în care sunt incluse fișierele de configurare). Deci da, directiva respectivă este de fapt _esențială_.
Jetto Martínez avatar
drapel fr
Da, comentariul tău a venit exact în momentul în care am postat răspunsul. Era într-adevăr cache-ul. Mi-am configurat browserul să nu memoreze nimic în cache, dar era în cache. Nu sunt sigur de ce a fost resetată această configurație. Cu acest lucru remediat, voi căuta în continuare acest lucru. Mulțumiri!
Puncte:1
drapel fr

Inculpat: Cache-ul.

La un moment dat, configurația browserului meu s-a schimbat (Poate o actualizare?) și am avut peste 3 GB de memorie cache, inclusiv site-urile de testare pe care încercam să le configurez ca subdomenii. Da.

După ștergerea memoriei cache, mi-a fost solicitată o alertă despre certificatul meu autosemnat atunci când accesam adresele URL, așa cum era de așteptat. După ce am acceptat riscurile, am fost redirecționat către site-urile adecvate. Aceasta prin utilizarea b.domain.com fără a adăuga protocolul.

Pentru a mă asigura că acest lucru funcționează, am testat în toate celelalte 7 browsere ale mele (trebuie să mă asigur) și am ondulat cu și fără protocol, iar rezultatele au fost și ele dorite.

Pana la urma configuratia a fost ok. O voi posta aici în caz că aveți nevoie Un server Apache care oferă proxy la anumite instanțe Tomcat în funcție de subdomeniu, folosind proxy_mod care redirecționează și imediat de la portul 80 la portul 433.

<VirtualHost *:80>
        ServerName a.domain.com
        Redirect permanent /  https://a.domain.com/
</VirtualHost>

<VirtualHost *:443>
        
        ServerName a.domain.com
        ServerAdmin [email protected]

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        #SSL stuff

        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/DONT_USE_SELF_SIGNED.pem
        SSLCertificateKeyFile /etc/ssl/private/CERTS_IN_PRODUCTIve.key
        SSLVerifyClient none

        #Proxies
        ProxyRequests Off
        SSLProxyEngine on
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off

        #Redirections
        Redirect /b https://b.domain.com

        <Location />
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

        <Location /a>
                ProxyPass               https://localhost:8444/
                ProxyPassReverse        https://localhost:8444/
        </Location>

</VirtualHost>

Vă rugăm să luați în considerare că setările pentru SSL Proxy și SSL sunt pentru certificate autosemnate. Vă rugăm să citiți documentația relevantă pentru fiecare dacă implementați acest lucru pentru medii productive.De asemenea, rețineți că acesta este fișierul de configurare pentru a.domain.com. Echivalentul pentru b.domain.com este exact același, cu ServerName, ServerAlias, redirecționări, locație și portul corespunzătoare pentru localhost.

drapel kz
Punct minor, dar nu aveți nevoie de `ServerName` _și_ `ServerAlias` dacă se referă la același _hostname_.
Jetto Martínez avatar
drapel fr
Remarcat. ServerName este cel pe care ar trebui să-l păstrez, nu?
drapel kz
Da, așa e.

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.