SPECS: FHS.spec - added %{_libdir}/cgi-bin directory for cgi apps....

[Tomasz Wittner]

On Thursday 02 of September 2004 23:41, Paweł Gołaszewski wrote:
> On Thu, 2 Sep 2004, Tomasz Wittner wrote:
> > > > Author: twittner                     Date: Thu Sep  2 19:32:10 2004
> > > > GMT Module: SPECS                         Tag: HEAD
> > > > ---- Log message:
> > > > - added %{_libdir}/cgi-bin directory for cgi apps. This helps to
> > > >   make cgi applications "apache independent".
> > >
> > > Podaj jakiś przykład co i jak chcesz tam wrzucać, bo chyba mi się to
> > > nie podoba... :-/ To będzie śmietnik na wszystko...
> >
> > Wcześniej sobie przygotowałem już odpowiedź (bo byłem pewny negatywnych
> > reakcji):
> >
> > apache: /home/services/httpd/cgi-bin
> > lighttpd: /home/services/lighttpd/cgi-bin
> > cvsweb: /home/services/httpd/cgi-bin/cvsweb.cgi
> >
> > Czyli cvsweb wymaga apache i nie może działać z np. z lighttpd - bzdura.
>
> Oczywiście - obecny stan rzeczy jest zły, szczególnie, że cvsweb powinien
> być w zupełnie innym miejscu...
W jakim - konkretnie? "..." ?
$ cd ...
cd: no such file or directory: ...
see cvsweb:DEVEL - debian zrobił podobnie (akurat nie patrzyłem wtedy, jak to 
zrobił debian). DEVEl dlatego, że skrypty uzależniają jeszcze bardziej cvsweb 
od apache - mam już pomysł na częściowe obejście tego.
>
> > Są też aplikacje, jak namazu, które w ogóle nie potrzebują R: webserver
> > (bo działają z wwwoffle i dlatego umieściłem namazu.cgi
> > /usr/lib/namazu/namazu.cgi)
> >
> > 1. Pisałem już ze 2 razy o tym b .dawno temu (kilka mies. ? - nie działa
> >    search - nie podam linka do pierwszego posta w tej sprawie, drugi,
> >    późniejszy:
> >   
> > http://lists.pld-linux.org/pipermail/pld-discuss-pl/2004-March/003397.htm
> >l ) - 0 odzewu == przyzwolenie na dodanie tego do FHS.spec - 48h już dawno
> > minęło - a przynajmiej commit sprowokuje dyskusje - i bardzo dobrze -
> > cofnac zawsze można.
>
> Przecież nie piszę, że źle zrobiłeś... Ostatnio połowa rzeczy które
> piszesz odnoszę wrażenie, że jest podszyta jakąś pretensją do wszystkiego
> i wszystkich... :-/
Nie wszystkich tylko do niektórych i o konkretne sprawy a nie o wszystko.
>
> Pewne wątki i zmiany uciekają czasem.
>
> > 2. W debianie mają /usr/lib/cgi-bin - debian jeszcze od tego nie umarł.
>
> W debianie jest wiele mało ciekawych rzeczy...
W PLD jest ich więcej - np. taki katalog na cgi zależny od apache. I czego się 
chce użyć, to trzeba zacząć od poprawiania tego - PLD jest pod tym względem 
b. ciekawe - dzisiaj w nocy zastanawiałem się czemu nie działa printenv z 
apache (było w nim #!/usr/local/bin/perl)
>
> > 3. Zmiany związane z przeniesieniem plików poszczególnych aplikacji do
> >    %{_libdir}/cgi są "na po Ac" i nie będę wszystkiego osobiście robił
> >    (jakieś triggery do zmiany configów [apache], przeniesienie plików
> >    aplikacji cgi - a być może za chwilę będę miał łącza). Imo robienie
> >    tego wszystkiego najpierw na DEVEL nie ma sensu.
>
> Oczywiście, że nie ma sensu, niemniej powinna to być zmiana przemyślana,
> bo kolejna relokacja i kolejny trigger... ekhm...
2xtrigger 2 konfigów apache. Prostę i działają. Po to są, żeby ich używać - 
są w załączniku - wdzięczny będę za merytoryczne uwagi.
>
> Do tematu.
> /usr/lib/cgi-bin nie podoba mi się z kilku powodów:
> - /home/services było miejsce, w którym grzebały i aplikacje i
>   administrator. Sytuacja zła, ale mająca swoje zalety. Aplikacje miały
>   gdzie wrzucać oraz administrator miał miejsce. 
>   już tak fajny, bo z założenia admin nie powinien tam grzebać - musi więc
>   mieć swoje miejsce w konfiguracji, które powinno wskazywać na
>   http://..../cgi-bin/, ale na to lepsze miejsce to gdzieś w /var/ lub też
>   w /srv, tyle, że to drugie powinno być świadomym wyborem admina.
> - teraz - uwzględniając to pierwsze... nie bardzo jest miejsce na pchanie
>   czegokolwiek do /usr/lib/cgi-bin, bo IMO znacznie lepiej umieścić
>   aplikacje w /usr/lib/%{name}, dodać kawałeczek konfiguracji do apache,
>   natomiast dla pozostałych demonów http, jeżeli trzeba, link w cgi-bin.
>
> Sumując - naprawdę nie widzę zastosowania _sensownego_ dla
> /usr/lib/cgi-bin, poza śmietnikiem, którym on się stanie...
http://packages.debian.org/cgi-bin/search_contents.pl?word=cgi-bin&searchmode=searchfilesanddirs&case=sensitive&version=stable&arch=i386&page=1&number=all
Nie wiem, o jakim śmietniku mówisz.
Niezależnie czy admin wrzuci swojego cgika do /home/services/httpd/cgi-bin 
czy /usr/lib/cgi-bin może się skończyc jednakowo źle dla niego, jeżeli plik z 
instalowanego jakiegoś pakietu będie miał taką samą nazwę. Czy można mieć 
partycję /home zamontowaną z noexec - uruchomią się wtedy cgi 
z /home/services/httpd/cgi-bin ?
Defaultowo wszystkie cgiki z pakietów lecą do %{_libdir}/cgi-bin - apache i 
inne są ustawione na uruchamianie ich z tego katalogu - ZU się cieszy, 
wszystko działa out of pudełko. Przychodzi admin i instaluje sobie własne 
cgiki "nie z pakietów" - robi sobie to gdzieś w np. /srv/ i robi np. linki do 
potrzebnych mu cgi z %{_libdir}/cgi-bin z distro, ustawia sobie ScriptAlias 
na nowy katalog.

Nie proponujesz konkretnej implementacji ani nawet lokalizacji - "gdzieś 
w /var/" jakieś linki dla "pozostałych demonów" skoro mogą cgi być w tym 
samym katalogu dla wszystkich.

A nie mam już czasu na niekończące się dyskusje o niczym.
-- 
Tomasz Wittner
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: apache.spec.diff
Type: text/x-diff
Size: 2845 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040903/cd8bc220/apache.spec.bin