ugrás a tartalomhoz

Apache irányítás IIS7hez vagy Apache Apachehoz

radir · 2009. Jan. 8. (Cs), 02.48
Üdv mindenki!
Nekem az alábbi lenne a problémám és meg kellene oldanom de olvastam össze vissza mindent és nem sikerült tehát utolsó reményem itt van:)
Remélem tudtok segíteni.

Itt a kép és mellé a magyarázat

Valahogy a 87.229.111.164-en kéne a webszerveren megváltoztatni valamilyen elérést configban feltevésem szerint, de nem tudom mit.

Segítségeteket előre is köszönöm!
‹ Milyen szervergépet válasszak hoszting szolgáltatás indításához? Apache install ›
 ■
1

Lemaradt.

radir · 2009. Jan. 8. (Cs), 03.11
Lemaradt:) Azt még hozzá tenném, hogy a ProxyPass nem vált be Tomcat átirányítással is próbáltam, az sem lett jó. Ki mit tud rá?
2

Reverse Proxy

Poetro · 2009. Jan. 8. (Cs), 03.20
Az 87.229.111.164-re rakni kell egy reverse proxy-t, létezik ilyen Apache module is, ami továbbítja a megfelelő domainre érkező (vagy akár más feltétleknek megfelelő) kéréseket a belső hálózatra, és az onnan kapott tartalmat visszaküldi a kliensnek.
Ajánlott olvasmány:
3

re

radir · 2009. Jan. 8. (Cs), 04.50
Én őszintén nem olvasni valóra gondoltam hanem egy beírt configra,:)) mert ezt sokat olvasgattam de problémámon nem segített...
13

re

radir · 2009. Jan. 11. (V), 09.45
Ezzel felhívtad figyelmem egy baklövésemre, ugyanis a httpd.conf ban nem engedtem beolvastatni az extensiont hozzá de most már beolvassa, de felmerült még egy gond, amit a 2. link mutat azok az extensionok nincsenek benne az apacheba csak kb. a fele (a 2 link teljesen mást mond, az apache oldalon aztírja elég csak a mod_proxy a másikon meg legalább 5 öt felsorol, én az apache oldalinak hiszek de sehogy nem jön össze hiába olvasom és teszem azt amit írnak...)

ha ezeket kiveszem akkor is megy ez már jó jel de az alábbi beálítással a kezdőlap jön be:

<VirtualHost xxxx:80>
ServerAdmin xx##kukac##xxx.net
ServerName xx.xx.net

<Location />
ProxyPass http://xx/
ProxyPassReverse http://xx/
</Location>

</VirtualHost>


ha a <Location /> lecserélem pl. <Location /admin> ra az azt jelenti hogy a http://xx.xxx.net/admin/ oldalt fogja irányítani oda de ebben az esetben CGI errora panaszkodik... de nekem a domaint kell átirányítani nem egy alkönyvtárt
4

Már volt

zila · 2009. Jan. 8. (Cs), 10.46
Ha jól értem a problémádat, akkor ugyanazt szeretnéd pepitában mint ez a topik
5

már volt /re

radir · 2009. Jan. 8. (Cs), 20.42
<Virtualhost *>
ServerAdmin admin##kukac##domain.tld
DocumentRoot /var/www/sub.domain.tld
ServerName sub.domain.tld
ProxyRequests Off

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://realhost.domain.tld/
ProxyPassReverse / http://realhost.domain.tld/
ProxyPreserveHost On
</Virtualhost>

ezt már próbáltam és nem volt jó ugyanis hiába állítom be rendesen a proxypass-t a domain címre az alábbi könyvtárat hozza be: DocumentRoot /var/www/sub.domain.tld mivel ott a document root tehát fölösleges szerintem a proxypass ha van documentroot mert gondolom elsőbbséget élvez vagy nem tudom... De azt is mondja már el nekem valaki, hogyha másik szerverről veszi a weboldalt akkor minek kell neki Document root? ezt nem fogom fel a mai napig...
6

DocumentRoot

Poetro · 2009. Jan. 8. (Cs), 21.03
A DocumentRoot azért szükséges, mert lehetséges, hogy az oldalad csak egy részét töltöd a másik gépről, a többit maga a webszerver szolgálja ki. Például csak az adminisztráció (/admin) történik a proxy-zott gépen, a tartalmak kiszolgálását a webszerver végzi.
Különben az általam említett linken volt egy teljes konfiguráció is:
LoadModule proxy_module      modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule headers_module    modules/mod_headers.so
LoadFile   /usr/lib/libxml2.so
LoadModule proxy_html_module modules/mod_proxy_html.so

ProxyRequests off
ProxyPass /app1/ http://internal1.example.com/
ProxyPass /app2/ http://internal2.example.com/
ProxyHTMLURLMap http://internal1.example.com /app1
ProxyHTMLURLMap http://internal2.example.com /app2

<Location /app1/>
        ProxyPassReverse /
        SetOutputFilter  proxy-html
        ProxyHTMLURLMap  /      /app1/
        ProxyHTMLURLMap  /app1  /app1
        RequestHeader    unset  Accept-Encoding
</Location>

<Location /app2/>
        ProxyPassReverse /
        SetOutputFilter proxy-html
        ProxyHTMLURLMap /       /app2/
        ProxyHTMLURLMap /app2   /app2
        RequestHeader   unset   Accept-Encoding
</Location>
7

Ty:)

radir · 2009. Jan. 8. (Cs), 21.24
Köszönöm!

Azóta rájöttem néhány fejlesztői hibára amely gondot okozott, felraktam most egy sima Apache 2.2-őt és az olvasott beállítás tökéletesen működik!
A Probléma csak annyi volt hogy a szerverre telepített Apache az XAMPP project volt, és hát be kell vallanom én ezt tartottam idáig a pontig a legmegbízhatóbb webszerver csomagnak, az Appserver az sem jött be ott is sok hiba volt, közel 2 éve használtam XAMPP-t mindenhol mert türelmetlen vagyok és lusta modulokat telepíteni tehát 1x re mindent felrakni valljuk be könnyebb... Minden más rendszergazdának ajánlom figyelmébe, hogy törődjön az általa készített szerverrel mert lássuk be ez egyszerű beállítás és mégse sikerült nekem sem. Inkább 2 óra alatt rakjon fel minenki egy komplett kiszolgálót (web részét) mint utána 4 napot szenvedjen egy ilyen kis konfigon azért mert nem jó a webszerver csomagja és ezt sehol nem logolja és errorozza ki semmi.
Mellesleg köszönöm a segítséget:) Tegnap regisztráltam ide be de amiben tudok 1 héten 2x meglátogatom az oldalt és segítek abban amihez értek én is:) Apropó ez a beállítás tökéletesen működik:) <Virtualhost 87.229.111.164:80>
ServerAdmin admin##kukac##domain.tld
ServerName services.highszerver.net
ProxyRequests Off

<Proxy 192.168.0.2:80>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://192.168.0.2:80/
ProxyPassReverse / http://192.168.0.2:80/
ProxyPreserveHost On
</Virtualhost>
9

XAMPP

zila · 2009. Jan. 9. (P), 09.40
Hát XAMPP-ot éles szerverre feltenni... Merész dolog :)
Éles szervernél a minimum, hogy csak olyan modulok kerüljenek fel apache-ba, php-be, amikre szükség van és csak olyan alkalmazások/szolgáltatások amiket valóban használsz. XAMPP a kutyafülét is feltelepíti teljesen feleslegesen... XAMPP max. fejlesztői gépre lehet jó...

http://www.apachefriends.org/en/xampp.html
The default configuration is not good from a securtiy point of view and it's not secure enough for a production environment - please don't use XAMPP in such environment.
8

Biztosan működik

zila · 2009. Jan. 9. (P), 09.33
A fenti config az én szerveremen működik, onnan copy-pasteltem... (+domainek-et anonimizáltam :)
10

zila /re

radir · 2009. Jan. 9. (P), 13.22
Én most feltettem a sima Apache2.2 őt de bevallom a PHP-t még mindig az XAMPP-set használom mert vannak benne extensionok amik kellenek számomra és az ügyfeleknek:)
Kicsi trükkel megoldottam hogy menjen nagyobb config nélkül:) Apache 2.2-őt felraktam egy adott helyre majd ugyanide felraktam az XAMPP-t de elötte lemásoltam az Apache2.2 őt default php-s configgal:) aztán letörölgettem a fölösleges fájlokat ami XAMPP hez van majd töröltem a servicesből és újra feltettem az Apache2.2-őt:) Sok configot spóroltam vele és tökéletesen hiba nélkül fut minden:) ZendExtensions stb...:)
11

Bátor vagy

zila · 2009. Jan. 9. (P), 14.15
Mindezt éles környezetben követed el? Mondd, hogy nem...

Figyi a XAMPP-ban lévő modulok mindegyike betehető sima apache alá (hiszen a XAMPP sem csinál mást mint lefordítja és csomagolja ezeket).
12

Igen..

radir · 2009. Jan. 11. (V), 09.43
Betölthető de ez gyorsabb megoldás volt és egyszerűbb:) És ugyanaz mintha betöltettem volna...:) Valld be:)
14

a lustaság csak félegészség

Hodicska Gergely · 2009. Jan. 11. (V), 13.40
Betölthető de ez gyorsabb megoldás volt és egyszerűbb:) És ugyanaz mintha betöltettem volna...:) Valld be:)
Az hogy így gyorsabb volt megcsinálni, az egy dolog, az meg hogy esetleg emiatt egy hozzáértő 5 perc alatt feltöri a cuccod, az más dolog. És valahol ezzel becsapod az ügyfeled is (valld be ;)).
15

Feltörés

radir · 2009. Jan. 11. (V), 16.53
Feltöreheti mert nem fog ott találni semmit:) Mivel az ügyfelek webtárhelye nem innen fut és egy ügyfél tárhelyre többet adok mint egy kezdőlapénak:) Bevallotam:)
16

szolgáltatás

Hodicska Gergely · 2009. Jan. 11. (V), 19.48
Attól még a szolgáltatás pl. nem lesz elérhető. ;) De ahogy érzed.
17

:)

radir · 2009. Jan. 12. (H), 07.22
Lehet hogy nem lesz elérhető de csak ezen a gépen és nagy kiesést nem fog jelenteni semmilyen szempontból, de ha ennyire hülyének nézel akkor tessék nekiállni hackelni:) Itt megesküszök hogyha feltöröd akkor nem leszel feljelentve károkozásért.
19

"hozzáértő"

Hodicska Gergely · 2009. Jan. 12. (H), 13.00
Nem vagyok szakértő szerver feltörés témában, de amúgy is írtam, hogy ahogy érzed. Nem nézlek hülyének, de nem is bölcs dolog egy olyan dolgot használni élesben, aminek a készítői kiemelik, hogy ne tedd, főleg nem smilezgatva (ez amolyan büszkén válalom, hogy gányolok feelinget kelt).
20

Keress meg

janoszen · 2009. Jan. 13. (K), 09.47
Ha gondolod, keress meg magánban, megkérem 1-2 ITsec-es kollegámat, hogy kicsit zúzzuk meg. Mindig kell gyakorolni.

Egyébként a XAMPP-pal nem az a baj, hogy ne működne, hiszen működik, az a baj, hogy beletettek olyan dolgokat, amik éles környezetbe nem valóak. Nyilván, ha azokat kikonfigurálod belőle, jó lehet. De ha ennyire értesz hozzá, akkor már föl is húzhattad volna kézzel, mert többet kell belőle kivenni, mint kézi telepítésnél betenni.

Mint kifejtettem korábban hasonló témában, nem az a baj, hogy a Te gépedet feltörik, mert az rajtad kívül senkit nem érdekel, hanem hogy a Te gépedet fogják kiváló DDOS támadásokhoz használni, ami egy szerver sávszélességénél igen komoly fegyvertény. Ergó mások életét keseríted el.

Egyébként nem értem a XAMPP eröltetését. Ha fölhúzol mondjuk egy Debian Linuxot, a screenshotokkal illusztrált howtoval kb 2 óra alatt készen, ha pedig egy kis energiát rászánsz, akkor akár csinos adminfelületek vagy monitorozó eszközök tulajdonosa lehetsz. Én is így kezdtem annó a szerveres témát.
18

Frissítések?

zila · 2009. Jan. 12. (H), 10.04
Neked lehet, hogy gyorsabb és egyszerűbb volt. Nekem a sima apache+php+modulok telepítése se megy lassan és bonyolultan. ;)

Amit te csináltál az gányolás. Akárhonnan nézzük.

Egy biztonsági frissítés pl. gyorsabban kijön az operációs rendszerhez csomagolt modulokhoz (vagy a php forráshoz) mint a XAMPP-hoz. Így neked figyelned kell minimum 2 helyet (apache+xammp) hogy van-e biztonsági frissítés. Feltéve persze, hogy nézed egyáltalán az ilyen bejelentéseket és frissíted a rendszeredet.

Ne szívd mellre egyébként, mi csak tanácsokat adunk, nem kell megfogadni. Mindenki úgy kompromittálja a rendszerét ahogy akarja.