aplikacje WWW

[Tomasz Kłoczko]

On Sat, 18 Jan 2003, Jacek Rembisz wrote:

> On Sat, Jan 18, 2003 at 07:28:39PM +0100, Jacek Konieczny wrote:
> 
> Chyba pora na podsumowanie :)
> 
> 1. Aplikacje WWW lądują w %{_datadir} i/lub %{_libdir} przy czym
> 
> > Podział pomiędzy %{_datadir} i %{_libdir} powinien odbywać się wg. zasad
> > określonych przez FHS. To znaczy: do %{_datadir} rzeczy niezależne od
> > architektury (czyli skrypty oraz dane), a do %{_libdir} zależne od
> > architektury. 
> 
> 2. Pakiet przychodzi z odpowiednim dla aplikacji plikiem konfiguracyjnym
>    który ląduje w /etc/httpd/conf.d, jego nazwa rozpoczyna się od
> 	 cyferek by łatwo kontrolować kolejność ładowania.
>    
> 	 Kloczek napisał w tym wątku, że mapowanie ma być domyślnie zakomentowane,
> 	 a pakiet w %post powinien wypisywać co należy zrobić by aktywować
> 	 aplikację (jeśli dobrze zrozumiałem). Nie do końca się z tym zgadzam.
> 	 Prosty user czyli /me wolał by zobaczyć: "now go to
> 	 http://127.0.0.1/squirrelmail/ and  enjoy" a nie długi elaborat o tym
> 	 co też ja muszę odkomentować, żeby wreszcie zadziałało. Z drugiej
> 	 strony.... Rzecz jest trochę podobna do /etc/rc.d/init.d/

To co napisałeś nie stoi w sprzeczności z tym co do tej pory padło :)
To jest ładne rozwiniecie całości choć:

1) ze względów bezpieczeństwa dodałbym żeby owo mapowanie było z 
   obostrzeniem dostępu było robione tylko wtedy kiedy jest zainstalowany 
   dpowiedni moduł  .. zdaje sie mod_access albo jakoś tak (czyli bedzie 
   musiało być to ujęte w ifmodule) bo zdaje się że indianin bez 
   odpowidniego wsparcia  modułem nie jest w stanie tego sam zrobić,

2) takie mapowanie powinno być możliwe do centralnego wyłącznia (np. 
   poprzez zmienną w /etc/sysconfig/httpd i domyślnie powinno byc to 
   wyłączone. W sumie jezlei dałoby się własnie tu umieścić przełącznik od 
   tego to mógłby wbyć tu też pzrełacnik od mapowanai tego do publicznego 
   dostępu .. dla tych co by sobie tego rzyczyli :)

3) mapwanie powinno być robione jednak na jakiś template url typu np.
   http://localhost/test/<foo> czy http://localhost/apps/<foo> (to drugie 
   wydaje się przyjemniejsze :)

   Jeżeli założyć że wsystkie tego typu mapowanai inicjalnie są na 
   powyższe to nie musiałby być wykonywane oboszrenia per aplikcja bo centralnie w 
   httpd.conf moznaby to przełączać przez:

  <Location /apps>
	Order deny,allow
	Deny from all
	Allow from localhost
  </Location>

  Z tym że musiałby to wpaść z bardzo wysokim priorytetem
  (001def_apps_access.conf czy 001def_apps_access.conf o ile przymiemy
  trzy cyfry mumeru) żeby zamykało w owej klatce wszystkie aplikacje
  których konfiguracja nie byłaby zminiana. Tym samym nie będzie tu
  potrzebny przełącznik w /etc/sysconfig/httpd bo to chyba będzie lepsze :)
  Dzieki wydzieleniu tego w osobny plik powinno być to prośxiej dostępne.

Wogóle jeszcze co do punktu 3 to właśnie nasuwa mi się na czoło to że w
sumie przy okazji przejścia na używanie /etc/httpd/conf.d/ możnaby
przecież wogóle nie mieć /etc/httpd/httpd.conf i/lub plik ten mógłby
zawierać tylko info w komentarzu o tym że właściwa konfiguracja
pokawałkowana według konktretnego opisanego shematu jest w
/etc/httpd/conf.d/ (widać już gdzie możemy juz zacżąć kompletować opis
tych regół jakie próbujemy skompletować w tym wątku .. oczywiśxcie 
taka powielona informacja o tym powinan trafić też do mana :).

W tym sensie zbliżyłoby się to mocno do tego co mamy w przypadku crond (co
Byłoby bardzo dobre) gdzie nie mamy w sumie /etc/crontab bo jest on tylko
spójnym kawałekiem całej konfiguracji w /etc/cron.d/crontab :). Dzięki
powtórzeniu tego podejścia w indianinie zarządzanie aplikacjami i nie
tylko nie jest tu niczym szczególnym bo _cała_ konfigurcja będzie mogła
być robiona według jednego spójnego schematu :)

W sumie (jako jeszcze jedna konsekwencja powyższego) .. także cała obecnie
dostępna konfiguracja z obecnego httpd.conf mogłaby ulec częściowemu
pokawałkowaniu .. co powinno pomóc w zarządzaniu całą konfiguracją jako 
taką upraszajać ja do poszukiwanai elemetów konfiguracji tylko w "jednym
miejscu" czyli w katalogu, a nie pliku i dodatkowo w plikach w jakimś
katalogu.

> 	 A czy nie wystarczy poprostu wykonać lub nie restartu apacha?
> 
> 3. Zasoby przygotowujemy pod apache'a.
> 	 
> 4. Będą problemy (raczej do rozwiązania) z aplikacjami, które
>    modyfikują swoje skrypty i co gorsza tworzą nowe (phorum tak się
> 	 zachowuje). /usr powinien być tylko do odczytu. Konsekwentnie te
> 	 kawałki aplikacji trzeba by  umieszczać w /var/lib co skomplikuje 
> 	 pliki konfiguracyjne i będzie wymagało wniknięcia w kod aplikacji
> 	 ze strony budowniczego pakietu.
> 5. W przypadku kilku wirtualek mogą powstawać różne ciekawostki 
>    przyrodnicze, szczerze mówiąc średnio to sobie wyobrażam, ale
> 	 chyba warto spróbować :)

Każda aplikacja powinna być przygotowana do pracy z wirtualkami (jednak).
Do tego potrzebne jest w sumie też poprana współpraca z remapowaniami.
Można zaznaczać w BTS informacje o tym wszystkim co w tym przeszkadza.
Powinniśmy także informacje o tym zgłaszać maintainerowi żeby spróbował
rozwiazać to.
To powinno być poprostu traktowane jako błąd i w związku z tym nie
powinniśmy szykować jakiegoś spec podejścia żeby obsługiwać tego typu
przypadki.
Co do remapowania konfiguracji aplikacji to może też przydałoby się mieć 
jakieś teplate podejście (?).

> Są jeszcze jakieś uwagi, propozycje, wątpliwości?

Chyba elemety regół są już w miare kompletne :)
Choć .. może jeszcze ktoś coś wymyśli/doda (?) :_)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*