FastCGI - Laptörténet

Sitya(AT)niif.hu, 2013. február 25., 13:54-n

2013-02-25T13:54:13Z

Sitya(AT)niif.hu, 2009. május 15., 11:49-n

2009-05-15T11:49:45Z

Sitya(AT)niif.hu: /* Shibboleth + Lighttpd */

2009-05-14T08:47:16Z

‎Shibboleth + Lighttpd

Sitya(AT)niif.hu: /* Shibboleth */

2009-05-14T08:39:13Z

‎Shibboleth

Sitya(AT)niif.hu, 2009. május 14., 08:19-n

2009-05-14T08:19:14Z

Sitya(AT)niif.hu: /* FastCGI-rőlForrás: Weblabor */

2009-05-14T08:18:39Z

‎FastCGI-rőlForrás: Weblabor

Sitya(AT)niif.hu, 2009. május 14., 08:17-n

2009-05-14T08:17:24Z

Sitya(AT)niif.hu, 2009. május 11., 12:38-n

2009-05-11T12:38:34Z

Sitya(AT)niif.hu: /* Shibboleth + Lighttpd */

2009-04-30T12:02:49Z

‎Shibboleth + Lighttpd

Sitya(AT)niif.hu: /* Shibboleth */

2009-04-30T11:52:41Z

‎Shibboleth

← Régebbi változat		A lap 2013. február 25., 13:54-kori változata
110. sor:		110. sor:

	Amennyiben használni akarunk "authorizer" modult (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.		Amennyiben használni akarunk "authorizer" modult (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.
		+
		+	[[Category: AAI]] [[Category: Shibboleth SP]] [[Category: HOWTO]]

@@ 105. sor: / 105. sor: @@
    )),
-Ezek után - s az itt nem részletezett [[Shib2SP|Shibboleth SP]] beállítás után - a rendszernek további beállítások nélkül működnie kellene.
+Ezek után - s az itt nem részletezett [[Shib2SP|Shibboleth SP]] beállítás után - a rendszernek további beállítások nélkül működnie kellene. Ám '''kizárólag statikus tartalmat tud rendeltetésszerűen kiszolgálni, dinamikusat nem'''.
 === A HIBAJELENSÉG ===
 Amennyiben használni akarunk "authorizer" modult  (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.

@@ 104. sor: / 104. sor: @@
         "mode" => "authorizer"
    )),
 === A HIBAJELENSÉG ===
 Amennyiben használni akarunk "authorizer" modult  (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.

@@ 86. sor: / 86. sor: @@
 Be kell szúrni a ./configure paramétereit meghatározó sorba:
-  --with-fastcgi=/usr/sbin/lighttpd (<-- ez nem 100%)
+  --with-fastcgi=/usr/sbin/lighttpd (a lighttpd elérési útja)
 === Shibboleth + Lighttpd ===

← Régebbi változat		A lap 2009. május 14., 08:19-kori változata
108. sor:		108. sor:

	Amennyiben használni akarunk "authorizer" modult (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.		Amennyiben használni akarunk "authorizer" modult (a shibbolethnél ez ugye kell, a másik modul, a "responder" típusú mellett), akkor ehhez a fastcgi beállításoknál meg kell adni egy gyökér pontot, amelyhez viszonyítva az összes vele egy szinten lévő, ill. alatta lévő hivatkozás esetén lefut az authorizer, és megmondja, hogy jogosult, tehát mehet tovább, vagy sem. Ez a gyökérpont a shibbolethes beállításoknál a "/" kell, hogy legyen, tehát minden esetben átfut az authorizer-en egy-egy kérés. Ez nem is lenne rossz, de a bug miatt, amennyiben a fastcgi beállításoknál az authorizer megadása után bármilyen (pl. php) respondert beállítunk, akkor az az authorizer által lefedett környezetben (esetünkben a "/" miatt mindenhol) a webszerver 403 hibát dob.
−
−	~~==Források==~~
−	~~<references/>~~

@@ 1. sor: / 1. sor: @@
 Amennyiben úgy szeretnék Shibboleth SP-t beüzemelni, hogy biztonsági, vagy bármilyen egyéb megfontolásokból az FastCGI-ként fusson, úgy az alábbiakban leírtak szerint kell(ene) a rendszernek működnie.
-==FastCGI-ről<ref>Forrás: [http://weblabor.hu/cikkek/phpfastcgimodban Weblabor]</ref>==
+==FastCGI-ről==
 CGI (Common Gateway Interface) alkalmazás esetén a program futása a következőképpen néz ki: jön a kérés a kiszolgáló felé, mire az továbbítja a kérést a CGI programnak. Jelen esetben ez a PHP értelmező lesz, ami futtatja a programot, és az eredményt visszaadja a kiszolgálónak, majd ezután eltűnik a memóriából. Egy következő kéréskor ugyanez a folyamat ismétlődik, amiből egyből láthatjuk, hogy ez a módszer nem túl hatékony, a PHP értelmezőt állandóan be kell tölteni, majd ki kell pakolni a memóriából.
@@ 9. sor: / 9. sor: @@
 A CGI program külön szálként fut a kiszolgálón, elkülönítve tőle, és a többi hasonló száltól. Ha az egyik kedves felhasználó programja megöli a CGI értelmezőjét, akkor sincs semmi gond, az meghal, de a többi attól még vígan dolgozik, és szolgálja ki a lapokat.
 ==Lighttpd, mint webszerver==

@@ 1. sor: / 1. sor: @@
-Amennyiben úgy szeretnék Shibboleth SP-t beüzemelni, hogy biztonsági, vagy bármilyen egyéb megfontolásokból az FastCGI-ként fusson, úgy az alábbi példa lehet segítségünkre.
+Amennyiben úgy szeretnék Shibboleth SP-t beüzemelni, hogy biztonsági, vagy bármilyen egyéb megfontolásokból az FastCGI-ként fusson, úgy az alábbiakban leírtak szerint kell(ene) a rendszernek működnie.
 ==FastCGI-ről==
@@ 5. sor: / 5. sor: @@
 Ezt még meg kell írni.
-==Telepítés==
+==Lighttpd, mint webszerver==
-A Lighttpd-t és a Shibboleth-et Debian Lenny rendszerre telepítjük. Az egyszerűség kedvéért mindkét összetevő csomagját a debian oldaláról letölthető forrásból állítjuk elő, majd már a generált csomagból telepítjük.
+{{ambox
-=== Lighttpd ===
+}}
 Beszerzés
-  dget http://ftp.de.debian.org/debian/pool/main/l/lighttpd/lighttpd_1.4.19-5.dsc
+  wget http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz
-  dpkg-source -x *.dsc
+  tar -xf http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz
-Egy ismert bug miatt, amely javítása későbbi lighttpd változatban már szerepel, de a debian csomagban lévőben még nem, emiatt patch-elni kell. Patch letöltése:
+A szükséges patch letöltése
   wget http://redmine.lighttpd.net/attachments/download/91/fastcgi-authorizer-fixes.diff
@@ 21. sor: / 33. sor: @@
   patch -p0 < fastcgi-authorizer-fixes.diff
-Konfigurálnunk kell a fordítás paramétereit
+Majd a patchelés kiegészítéseként be kell szúrnunk egy sort a <code lang="xml">src/mod_fastcgi.c</code> fájlba.
-Melynek nyomán az alábbi részbe be kell illesztenünk az ssl-es direktívákat tartalmazó sort.
+                             con->http_status == 0)) {
- DEB_CONFIGURE_EXTRA_FLAGS += --libdir=/usr/lib/lighttpd --with-openssl \
+                                /*
-                             --with-kerberos5 --with-pcre --with-bz2   \
+                                 * If we are here in AUTHORIZER mode then a request for autorizer
-                             --with-ldap --with-mysql --with-memcache  \
+                                 * was proceeded already, and status 200 has been returned. We need
-                             --with-lua=lua5.1 --with-gdbm --with-attr \
+                                 * now to handle autorized request.
-                             --with-openssl --with-openssl-libs=/usr/lib \
+                                 */
-                             --with-webdav-locks --with-webdav-props   \
+  +++                            con->http_status = 0;
-                             --with-fam
+                                if ( ! buffer_is_empty(host->docroot) ) {
-Csomagok elkészítése, majd telepítése
+  ./configure --libdir=/usr/lib/lighttpd --with-openssl --with-openssl-libs=/usr/lib
-  debuild -b
+  make
-  cd ..
+  make install
 '''Telepítés utáni beállítás:'''
@@ 49. sor: / 64. sor: @@
   server.document-root       = "/var/www/"
-  $SERVER["socket"] == ":443" {
+  $SERVER["socket"] == "10.0.0.8:443" { // a host ip-címe
     ssl.engine = "enable"
     ssl.pemfile = "/etc/lighttpd/certs/lighttpd.pem" // ahol a domain-re vonatkozó tanusítványunk található
+  }
 === Shibboleth ===
@@ 82. sor: / 98. sor: @@
         "mode" => "authorizer"
    )),

@@ 70. sor: / 70. sor: @@
 Még két beállítást kell eszközölnünk, hogy a webszerver tudja, hogy shibbolethes hívások esetén mi a teendő. Először is a FastCGI beállításokat betöltetjük a lighttpd-vel (ez shibboleth-től függetlenül is kellhet, pl. php futtatása esetén). Egy egyszerű szimbolikus linket készítünk a mods-available könyvtár vonatkozó fájljáról a mods-enabled -be. A második, hogy ezt a fájlt kiegészítjük két, shibboleth specifikus sorral.
-  "/Shibboleth.sso" => (("socket" => "/tmp/fcgi-resp.sock", "bin-path" => "/usr/lib/shibboleth/shibresponder", "check-local" => "disable", "mode" => "responder")),
+  "/Shibboleth.sso" => ((
-  "/"   => (("socket" => "/tmp/fcgi-auth.sock", "bin-path" => "/usr/lib/shibboleth/shibauthorizer", "check-local" => "disable", "mode" => "authorizer")),
+       "socket" => "/tmp/fcgi-resp.sock",

← Régebbi változat		A lap 2009. április 30., 11:52-kori változata
55. sor:		55. sor:

	=== Shibboleth ===		=== Shibboleth ===
		+
		+	Beszerzés
		+	dget http://ftp.de.debian.org/debian/pool/main/s/shibboleth-sp2/shibboleth-sp2_2.0.dfsg1-4.dsc
		+	dpkg-source -x *.dsc
		+
		+	Fordítás előtti hangolás
		+	vim debian/rules
		+
		+	Be kell szúrni a ./configure paramétereit meghatározó sorba:
		+	--with-fastcgi=/usr/sbin/lighttpd (<-- ez nem 100%)

	=== Shibboleth + Lighttpd ===		=== Shibboleth + Lighttpd ===