Az Apache, a mod_rewrite és két füstölgő rendszergazda...

2008.11.26. 08:00 | Darren79 | Szólj hozzá!

 ...de igazából csak egy rendszergazda, de így jobban hangzott. :-)

Adott egy webhosting-szerver, Linux-szal. Tudjátok, ami összeborult egy hete. Na, hát akkor volt még egy függőben lévő dolog, hogy átirányítsam a mail.akármidomain.hu hivatkozást a www.akármidomain.hu/webmail címre.

Ez első blikkre egyszerűnek tűnik, de jön a bonyodalom: rengeteg a domain, és nem akarok annyi VirtualHost-ot felvenni az apache-ba, amennyit kéne. Csak egyet.

Minden domain esetében él egy Location beállítás, ami a /webmail könyvtárat egy fix helyről veszi, minden domain esetében. Ennek van azonban egy hátulütője: minden valamit is magára adó rendszergarázda használja az open_basedir rendszerváltozót (UGYE???), hogy az adott VirtualHost alatt futó PHP script-ek ne lássak kintebb a megengedett könyvtárnál. Viszont a /webmail- mivel mindegyik domain esetében ugyanoda mutat, így "open_basedir restricion in effect" hibaüzenetet kapna. Tehát a Location esetére módosítani kell az open_basedir-t egy olyan könyvtárra, amely túlmutat minden más hosting-könyvtáron. (ugyan nem férhet senki hozzá a webmail program webroot-jához, de "jobb a békesség"-alapon olyan helyre tesszük, ahol igazán semmi kárt nem okozhat).

Első körben létrehoztam egy VirtualHost-ot webmail címen, aminek a ServerName tulajdonsága

mail.hostingcég.hu

, majd egy darab ServerAlias-t:

mail.*

 

Na most igazából elég lenne ez is, ls írni egy PHP script-et, ami megvizsgálja, hogy a host mail.akármidomain.hu-e, és ha az első öt karakter "mail.", akkor átirányít a header függvénnyel (header("Location: http://www.akármidomain.hu/webmail");).

Meg lehetne oldani, hogy írok egy index.html-t, beteszem a webmail DocumentRoot-jába, és csak annyit csinál, hogy átirányít egy meta tag-gel pl. a webmail_redir.php-ra, ami pedig megvizsgálja, melyik domain.ről van szó, és megcsinálja ezt az átirányítást.

Csakhogy ez nekem nem tetszik. Ahogyan az alkalmazás-szintű header-ben történő átirányítás sem. Minek oldjak meg valamit alkalmazás- vagy megjelenítés-szinten, ha egyszer az architektúra alacsonyabb rétege (webszerver) is tudja ezt? Azon kívül eggyel több dolog lenne csak, amit adminisztrálni kell.

Na szóval, tartozik az Apache globális konfigurációs állományában (httpd.conf - Debian alatt apache2.conf) egy LocationMatch:

<LocationMatch ^/webmail/*>
    php_admin_value "open_basedir" "/var/eleres_a webmail_konyvtárához"
</LocationMatch>

Ezzel kiküszöböltük, hogy az open_basedir az adott domain beállítását felülbírálja, és máshova mutasson.

De hol az átirányítás? Hát nem itt. (előre bocsátom, hogy tudtommal van szebb megoldás is az elkövetkezendőkre, de nem volt már cérnám utána nézni; ha majd lesz, publikálom)

Szóval az áritányításhoz bekapcsoltam a mod_rewrite modult. Sokkal viccesebb, mint a mod_alias által biztosított Redirect, mert tud egy rakás dolgot, ami nekünk most kell: ilyen pl. a feltételes átirányítás, a reguláris kifejezések használata und so weiter.

Jaj de jó, akkor most már vannak Rewrite függvényeink! (RewriteCond, RewriteRule stb).

Na először is kell a francnak a webmail DocumentRoot-ja, ha már egyszer úgyis átirányítást végzünk, úgyhogy állítsuk a DocumentRoot-ot egy biztonságos helyre: /dev/null :-))) Na jó, csak comment-ezzük ki, mert nem kell többé.

RewriteEngine on

Ezzel aktiváljuk a mod_rewrite modul által szolgáltatott dolgokat.

RewriteCond %{HTTPS} on

Megvizsgáljuk, hogy a kapcsolat SSL-en nyugszik-e avagy sem (ugyanis én perverz állat figyelni akarok arra, hogy http-ről vagy https-ről nyitják meg a kapcsolatot; de lehetne olyat is - ami egyszerűbb -, hogy kapásból csak https-re irányítjuk, és kész)

RewriteCond %{SERVER_NAME} ^mail.(.*)?$

Na, ez már kacifántosabb: megvizsgáljuk, hogy a ServerName vagy ServerAlias mail.akarmidomain.hu-e. És ha már vizsgálóduk, hát a zárójelben megadott .* meg is mondja, hogy mi áll a "mail." után. Tehát ismerjük a domain-t! Hurrá!

RewriteRule / https://www.%1/webmail

Átirányítjuk a böngészőt header segítségével a https://www.akarmidomain.hu/webmail oldalra. Az előbbi RewriteCond-ban lévő (.*) mondta meg, hogy melyik domain-ről van szó. Értelemszerűen ha több zárójeles kifejezést használunk, akkor több változót is kapunk a %1 mellé: %2, %3 stb. Attól függően, hogy mennyi kifejezést használtunk.

Na, viszont ez most csak HTTPS-re működik, és kell a HTTP változat is. Ez majdnem ugyanaz:

RewriteCond %{HTTPS} off
RewriteCond %{SERVER_NAME} ^mail.(.*)?$
RewriteRule / http://www.%1/webmail/

Csak itt arra játszunk, hogy a HTTPS off-ra ván állítva, és a RewriteRule-ban csak http-re irányítunk, nem https-re.

Lehetett volna használni SetEnv-et is, és akkor két sor mínusz, de nem jöttem rá, hogy pontosan hogyan lehet használni. Bocsi. Ahogy ígértem, majd közzé teszem.

Üdv néktek!

· 1 trackback

Web.config és ConnectionStrings WebSite esetén

2008.11.25. 09:31 | Darren79 | Szólj hozzá!

Egy .NET-es alkalmazás fejlesztése során bukkantam arra a furcsaságra, hogy az alkalmazáshoz nem egy, hanem több ConnectionString tartozik. Hosszas debug-olás után sem értettem, hogy miért van erre szükség.

Ami még kifejezetten vicces a történetben, hogy a Web.config állományban van kettő, az App.config-ban pedig plusz egy is van. Ráadásul az újonnan hozzáírt modulom nem is működik, ha az App.config-ban nem szerepel a ConnectionString, csak a Web.config-ban.

E bejegyzésnek most semmi értelme. Csak nagy az Isten állatkertje, gondoltam, megosztom Veletek.

Muskátli a Total Commander-ablakba

2008.11.21. 14:48 | Darren79 | Szólj hozzá!

Végre valahára befejeztem az online albumom Újságok, valamint Könyvek szekciójának átrendezését.

A megszerzett adatok gyűjtésében nagy segítséget nyújtott a Total Commander multi rename tool funkciója, amely a tömeges átnevezést teszi lehetővé. Csak kijelöljük a file-okat, a multi rename tool-ban átrendezzük, ha szükséges, megadjuk a pattern-t, hogy mire nevezze át, és voila!

Köszönet a http://pcvilag.muskatli.hu/ weboldal szerkesztőinek, amiért kiegészíthettem a gyűjteményemet általuk!

Augustus De Morgan színre lép

2008.11.20. 10:08 | Darren79 | Szólj hozzá!

.NET-es projekten vagyok épp. Ismeritek a SubSonic nevű csodát? Remek kis kódgenerátor, mert objektum-alapú DAL-t generál, ezáltal típusazonossági alapon kezelhetjük az adatbázis minden elemét (táblák, mezők, tárolj eljárások, view-k stb). Egészen egyszerű és érthető módon készíthetünk lekérdezéseket, beszúrásokat... szóval sokmindent, ami az alkalmazásunk adatszerkezetét biztosítja közte és az adatbázis-szerver között (MSSQL, SQLCE, Oracle, SQLite és MySQL - és állítólag hamarosan jön a PostgreSQL réteg is).

Na, de most nem a SubSonic csodáját szeretném ecsetelni, aki kíváncsi rá, annak szívesen mesélek róla más fórumon keresztül. A SubSonic bármilyen jó, tegnap egy hiányosságot tapasztaltam benne: lekérdezés készítésénél nem ad lehetőséget az asszociatív kezelésre (gy.k.: nem tudunk zárójelezni).

Az egyszerűsített módon definiálom a problémát: adott A, B és C feltétel a lekérdezésben. Ha azt akarom mondani, hogy azokat a rekordokat jelenítse meg, ahol A igaz ÉS B igaz ÉS C igaz, akkor semmi teendőm nincs. Csakhogy nekem arra volt szükségem, hogy A ÉS B VAGY C, de úgy, hogy ez valahogy így nézzen ki: A ÉS (B VAGY C), mivel ha nem zárójelezek, akkor a VAGY feltétel borít mindent, és visszad minden rekordot, ahol C teljesül.

Hogy miért?

Kevesen tudják vagy emlékeznek rá, hogy a logikai műveleteknek, mint matematikai műveleteknek van műveleti sorrendje. Vagy legalábbis elfelejtik, ahogyan most én is tettem.

Tehát ahogy az előbb említettem, zárójeles kifejezést nem adhatunk SubSonic-ban. A fentiek miatt ez pedig gond, mert nekem csoportosított értékre volt szükségem a B és C feltételt illetően.

Rémlett valami, amit tanultam még ezer évvel ezelőtt, de nem tudtam felidézni hirtelen, hogy mit. Egy kollégámnak felvetettem a fenti problémát, és ő kapásból mondta: De Morgan azonosságok.

BASSZUS! Tényleg! Persze már nem emlékeztem pontosan, de aztán gyorsan rájöttem, hogy bizony itt a logikai műveletek matematikai megfeleltetéséről van szó. Csak még mindig nem állt össze bennem a kép, és kolléga úr mondta (egyébként matematika-tanár szeretett volna lenni), hogy a De Morgan azonosságokkal a zárójelesen felírt műveletek felírhatóak zárójelek nélkül is a műveleti sorrendek betartásának megfelelően.

Na, itt már képbe kerültem. Tehát ha egy kifejezés értéke IGAZ, akkor az legyen 1, egyébként meg 0.

A következő táblázatban felírjuk, hogy A és B esetében milyen logikai eredmények szüketnek, a végére pedig odaírjuk, hogy matematikailag ez hogyan feleltethető meg szorzással és osztással (a teljesség igénye nélkül történik ez, ezért csak e két alapműveletet írom le):

 

ABA ÉS BA VAGY BA X BA + B
111111
010101
100101
000000

 

E táblázatból kitűnik, hogy a logikai ÉS megfelel a matematikai szorzásnak, illetve a VAGY művelet pedig az összeadásnak. Ez nekünk azért jó, mert így már felíhatjuk e műveletekkel a szükséges kifejezést:

A ÉS (B VAGY C) = A x (B + C)

Jó, nem? Bontsuk fel a zárójelet:

A x (B + C) = A x B + A x C

Nincs zárójel, a SubSonic esetében most már megoldottuk a problémát:

A x B + A x C = A ÉS B VAGY A ÉS C

tehát

A ÉS (B VAGY C) = A ÉS B VAGY A ÉS C

Ez pedig nem egyenlő A ÉS B VAGY C kifejezéssel, mivel matematikailag ez A x B + C. Csak egy szorzat hiányzik: C A-val történő felszorzása. :-)

Ezzel bebizonyítottuk, hogy a műveleti sorrend él a logikai műveletekre is, azaz ahogyan a matematikában a szorzás előrébb való, mint az összeadás, úgy a logikai műveletek esetében az ÉS operátor erősebb a VAGY operátornál, tehát először az ÉS értékelődik ki.

Néha rájön az ember, hogy nem volt hülyeség matematikát tanulni. Most kifejezetten örültem neki.

ProFTPd vs. MySQL

2008.11.19. 10:29 | Darren79 | Szólj hozzá!

Elérkeztem az utolsó szíváshoz a szervertelepítésben. FTP. Nálam adatbázisból authentikált, nem LDAP-ból, vagy UNIX user-ekből.

Soha nem telepítettem csomagból a ProFTPd-t (hanem fordítottam source-ból), mert messze nem volt up-to-date. De most megnéztem, és azt láttam, hogy relative friss, 1.30-as van, 19-es build-del.

Nosza, apt-get indul, hozzá a mysql-modul, eg minden földi jó. A daemon indítása után no connection. Na hát emmegmostanmiaszósz. Log-ban semmi, se SysLog-ban, sehol. Na, hát akkor debug mode-ban indul. Hát ott se sokminden megy.

Kiszedtem a komplett modul-betöltést. Nahát! Megy! Tehát valamelyik modul okozta. Remek, most már csak ki kell találni, hogy melyik. Egyből beletrafáltam: a PostgreSQL-modul nem szereti, ha mellé van töltve a MySQL, mert akkor a mod_sql nem tudja, hogy melyiket használja. Úgyhogy szépségesen kivettem a mod_pgsql-t, és máris ment, az FTP adatbázis backup-ból visszaállt, jogosultságok pedig úgy lettek tar-ral tárolva, hogy azok is mentésre kerüljenek.

Minden jó, ha a vége jó!

...de mi a jelszó a mailszerveren?

2008.11.18. 08:58 | Darren79 | Szólj hozzá!

Évek óta használom az XMail-t, ismerem minden nyűgjét, baját, előnyét, hátrányát satöbbi. Az egy dolog, hogy nem volt hajlandó fordulni (mert őt kivételesen nem csomagból szoktam telepíteni), mert kell neki a libssl forrás, azt meg ugye elfelejtettem, és igaz, hogy kibökte a hibaüzenet a szememet, de ennyi kialvatlanság után már azt sem vettem volna észre, ha egy strucc ül az orromra.

Volt ez a hétvégi mizéria a szerverrel, úgyhogy az nekem aztán remek, hogy az XMail is elment vadászni. De addig is kellett helyette egy másik. :-) Na, ugye a /var elszállt, az XMail meg ott csücsült, useradatokkal, minden egyébbel. Pl. jelszavakkal.

A postafiókok és kezelt domain-ek egy részét a backup könyvtárak alapján vissza tudtuk hozni (nem mindet, de sokat), de alias-okat már nem. Ez utóbbit felvittem manuálisan, domainalias-okkal együtt.

Na de a jelszavak... Hát egy nagyon tré trükköt kellett bevetni: leloptam a POP3 password-öket, amelyekkel login-olni próbálnak a szerverre, és az alapján állítottam vissza őket.

Hát izé... szerintem vicces megoldás. Kevésbé lett volna vicces, ha jó lett volna a backup. De nem volt jó, és slussz.

Újabb kihívás volt. Lesz is még a hétvégi szerverbéli recessziós hullám miatt. :-) Amúgy is aktuális... de nem politizálok.

Vasárnapi ebéd a szerverrel

2008.11.15. 11:45 | Darren79 | Szólj hozzá!

Mikor máskor boruljon össze egy szerver, ha nem akkor, amikor az ember a pihenőnapját tölti, amit egyébként is egy kis munkahelyi .NET-kódolással kezdett. A szerver a BIX-ben van, ott csücsül immár öt éve, apróbb hibákkal, megszakításokkal folyamatosan működve.

A vason egy Debian Etch ül, webhosting szolgáltatásoknak adva helyet. Reggel még ment, leveleimet letöltöttem, semmi gond. Jön egy SMS, hogy nini, áll a szerver, mi a pék van már. SSH nuku, ping oké. Hmmmm... Szolgáltatónak telefon, készségesen segítenek, ctrl+alt+del-lel újraindítás.

Be lehet jelentkezni! Jújdejó! De hol az Apache, hol a mail? Ajjaj... Hmmm, hmmm... Hát, a jelek szerint system partíció van, /var pedig nincs. De miért?

És hát hol lenne a log, ha nem a /var-on... Oké, keressük meg a legutóbbi mentést, ami egy másik wincsin foglal helyet. Mount, bent van, meg is van, nézzük az éjjeli log-ot. Bad file descriptor-okkal van teleszemetelve! Anyád!

Na most én imádom a Linux-ot, de amikor ilyen rejtélyes hibaüzenetek vannak, azoktól lever a víz, mert általában még nem mondják meg, hogy mi a baj.

Mount-olni nem lehetett a partíciót, úgyhogy nyugodtan mehet az fsck -nf-fel. Hát izé... Badblocks... A tükör viszont rendben van.

Rendben, szervernek halt parancs, irány a szerverhosting cég, gép elhoz, nem volt kedvem ott szerelgetni.

Itthon a wincsik felületét ellenőriztem third party programokkal. Hibátlannak mutatták. Egy hirtelen ötlettől vezérelve az egyik Samsung HDD-t low level format-oltam a gyári programmal. Hoppá! Elakadt! Google. Több helyen utalás arra, hogy a Samsung wincsik megbízhatatlanságát palástolandó az elektronika elfedi a bad sector-okat, és "kifelé" hibátlannak mutatja. Ergo a BIOS-nak fogalma sincs arról, hogy a wincsi hibás, innentől pedig a raid vezérlők (ennél fogva a szoftveresek is) nem képesek felismerni a hibát, legfeljebb annyit, hogy valami nem kerek, mert a fájlrendszer nem konzisztens.

Ez volt a "bad file descriptor" a syslog-ban. A tükör pedig emiatt hibátlan volt, nem dobta ki a hibás lemezt, hiszen az oprendszer szerint a lemez fizikailag rendben volt.

Nosza, irány az egyik vasárnap is nyitvatartó számítástechnikai üzemegység, mert hát vasárnap van, winyó meg kell, kettő is. Két Hitachi (ex-IBM) 250 gigás került most bele. A gond megoldódott - részben. Már csak a backup-ból történő újratelepítést kell megoldani.

A magam részéről Samsung HDD-t soha többé... Eleinte utáltam, aztán megszerettem őket, de most, hogy tudom, van ez a gondjuk, inkább kihagyom.

Ez a dolog soha nem derült volna ki, ha nem multidisk-ben vannak. Az asztali gépemben egy SATA-vezérlésű Samsung 160 gigás wincsi van. Félek, hogy ha leformázom, kiderül róla is, hogy bizony, ő kőkeményen badsector-os.

süti beállítások módosítása