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

Sob, 4 Wrz 2004, 13:20:36 CEST

On Fri, 3 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: ...

Nie bądź złośliwy, dobra?
Twoje, nawet fajne pomysły, odechciewa się komentować...

> see cvsweb:DEVEL - debian zrobił podobnie (akurat nie patrzyłem wtedy,
> jak to zrobił debian).

Czyli co? Rozbicie na cgi-bin i datadir? To coś takiego niezwykłego? W
kilku aplikacjach mamy to...

> DEVEL dlatego, że skrypty uzależniają jeszcze bardziej cvsweb od apache
> - mam już pomysł na częściowe obejście tego.

Jaki?

> > > 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.html)-
> > > 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.

Dzięki, wspaniałomyślny.

Sugeruję lekki umiar.

> > 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

Tak? Podaj cyfry... Moje _doświadczenia_ jest wprost przeciwne...

> np. taki katalog na cgi zależny od apache.

Ja bym to nazwał usterką.

> 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)

Bywa. Błędy są zawsze i wszędzie - widać nikt nie potrzebował tego użyć do
tej pory... A że mamy dużo mniejszy zasób ludzi niż debian to dopracowane 
są tylko rzeczy używane przez developerów. Natoralna kolej rzeczy.

> > > 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.

trigger jest ok.

Z tym, że przenoszenie bez przemyślenia nie jest ok. I o to mi chodziło. 
Wiem, że pisałeś o tym, wiem.

> > 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.

Gdyby chodziło tylko o aplikacje instalowane z pakietów to nie miałbym
naprawdę nic przeciwko (poza moimi estetycznymi uwagami... ale to akurat
moja sprawa).

> 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ę.

Ale widać, że nie przeczytałeś tego co napisałem. Admin _nie_ powinien nic
wrzucać do /usr/lib/cgi-bin , jeżeli jest taka zostałaby lokalizacja. To
może być system wogóle RO (żadne hipotetyczne - mam kilka takich maszyn). 
noexec jest znacznie żadszy, szczególnie, że siedzą tam na przykład bind 
czy inne podobne rzeczy.

> Czy można mieć partycję /home zamontowaną z noexec - uruchomią się wtedy
> cgi z /home/services/httpd/cgi-bin ?

można sobie pogdybać.
Adminowi nie zabronisz nigdy zrobić piramidalnych głupot...

> 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.

Ale tutaj nie mam nic przeciwko... (poza estetyką, ale tu się powtarzam).

> 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.

"Gdzieś", "coś" ...

Musisz dać adminowi standardowe miejsce na jego cgi, które on będzie
wrzucał. I nie może to być /usr/lib/cgi-bin, bo tam naprawdę nie powinien
nic grzebać...

> 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.

To nie ja zacząłem zmieniać.

> A nie mam już czasu na niekończące się dyskusje o niczym.

Jak to o niczym? O konkretnej rewolucji w b. wielu pakietach. Chyba warto
o czym pogadać, zanim się coś zrobi, nie? Żeby potem nie trzeba było 
poprawiać i robić kolejnej rewolucji...

Pytanie jest takie - czy w pozostałych demonach http można ustawić kilka
lokalizacji czegoś co w apache nazywa się ScriptAlias? Jeżeli tak to nie
ma problemu:

/var/lib/http/cgi-bin	/cgi-bin/   (nie wiem czy to dobry katalog)
/usr/lib/cgi-bin	/cgi/

W ten sposób jest wszystko załatwione. Jeżeli adminowi to nie będzie 
pasowało to zmieni na coś w /srv/ , ale ma zapewnione miejsce 
_standardowe_ na swoje cgi. I nie musi grzebać w /usr/lib.

-- 
pozdr.  Paweł Gołaszewski 
---------------------------------
If you think of MS-DOS as mono, and Windows as stereo,
then Linux is Dolby Pro-Logic Surround Sound with Bass Boost
and all the music is free.