Re: Firefox - jak ustawic proxy przy pomocy AD?

Autor: Konrad Kosmowski <k.kosmowski_at_gmail.com>
Data: Fri 12 Aug 2005 - 02:02:54 MET DST
Message-ID: <ei5ts2-0p3.ln1@kosmosik.ath.cx>
Content-Type: text/plain; charset=ISO-8859-2

*** Tomasz Onyszko <T.Onyszko_nospam_@w2k.pl>:

>> Większość rozsądnych - tak, ma.

> To chociaz tu sie zgadzamy :).

>> Wyimaginowaną sytuacją jest 5000 stacji upgradeujących się bez
>> żadnego rozsądnego rozwiązania.

> Zgadzam sie

No więc dlatego napisałem wyimaginowana sytuacja - sytuacja że w sieci
5000 maszyn nie istnieje rozwiązanie do rozsądnego (w co wliczne jest
np. cacheowanie plików do rozprowadzania wewnątrz sieci) rozprowadzania
poprawek. Naprawdę uważam, że jeżeli takie rozwiązanie istnieje, to
różnica 5MB/1MB nie ma różnicy. Tylko należy przyjąć założenia:

1. Działa mechanizm (jakikolwiek skuteczny) cacheowania plików.
2. Dla sieci lokalnej nie ma różnicy czy przepycha 1MB czy 5MB - z
   reguły nie ma, jedna stacja pewnie dziennie generuje ok.
   (optymistycznie) 50MB ruchu - a my mówimy o 5MB w skali np.
   miesiąca... No proszę...

>> OK i mieliście problem z rozprowadzaniem poprawek zajmujących 5MB, a
>> z

> mielismy problem z rozprowadzaniem paczek majacych 5MB i wiecej
> niestetyt - chodzi o to zeby rozprowadzic je na czas i nie powodowac
> niedogodnosci w pracy uzytkownikow przy takich laczach jakie sa
> dostepne (czyli na przyklad kilku klientow ma lacze 128 kbps , musza
> pracowac i jeszcze pobrac oprogramowanie - stawiac im tam serwer tylko
> do dystrybucji oprogramowania sie nie oplaca a do innych celow nie
> ptorzebuja)

I ta sieć miała 5000 takich końcówek (na łączach 128kbps)? Coś mi się
wierzyć nie chce. To jest właśnie taka wyimaginowana sytuacja:

1. To w jaki sposób im pchaliście te poprawki?
2. Skoro ściąganie poprawki z Internetu przeszkadzało im w pracy to
   rozumiem, że praca wiązała się z pracą poprzez Internet - no więc
   128kbps jakby nie patrzyć to jest za mało do wygodnej pracy przez
   Internet (dla kilku maszyn).

W każdym razie sytuacja 5000 maszyn po kilka w sieci połączonych łączami
128kbps to jest dla mnie nierealne, 5000 maszyn w kilkunastu sieciach po
kilkaset maszyn to już bardziej do mnie trafia i tam stawia się serwery
w każdej z sieci, a 5MB/1MB w skali powiedzmy dwóch tygodni przy sieci
nawet 10mbps to nie jest nic znaczącego...

(...)

>> Wiesz na stronie MS jest też np. oprogramowanie w wersjach beta,
>> firmowane przez MS - jak dokładnie brzmi Twój zarzut?

> Widzisz, podstawowa roznica miedzy nami polega w tym momencie chyba na
> tym ze ja nie stawiam zadnych zarzutow :), po prostu dyskutuje i
> jestem daleki od zarzucania czegokolwiek jakiemukolwiek softowi.

No więc w czym problem? Że rozwojowe (moje zdanie jest takie - że jak
dany dodatek jest odpowiednio dojrzały to jest odporny na zmiany wersji)
wersje dodatków mają prawo się psuć - pytanie czy Mozilla powinna je
rozprowadzać jako rozwojowe - kwestia rachunku korzyści i strat.

Korzyści:
User dostaje to czego chce, jakieś rozszerzenie, które mu ułatwia życie.
Developerzy rozszerzenia mają testerów - mogą je zrobić lepszymi.

Strata:
Czasami się posypie - trzeba zainstalować (albo poczekać na) nowszą
wersję.

IMHO korzyści są większe. :)

> A co do softu typu Beta to nie jest dobre porownanie bo istalujesz
> bete wiedzac ze to beta, ze moze sie sypac i jestes o tym ostrzegany.
> Extension na stronie wskazanej przez FF nie maja oznaczenia ze sa
> beta/niestabilne czy cos takiego.

Ale to nie są krytyczne rzeczy. W obu przypadkach, jak Ci się posypie
dodatek to nic się nie stanie, zainstalujesz nową wersję i jest OK, nie
dramatyzujmy. A w przypadku gdy dodatek jest istotny - np. można mieć
własne dodatki obsługujące konkretne funkcjonalności i potrzebne -
zawsze masz czas na przetestowanie i przygotowanie się na nową wersję.
Podobnie jak z SP2 - ludzie mieli własne rozwiązania popisane
niechlujnie np. w VBS - zainstalowali SP2, przestało działać - musieli
poprawić albo zrezygnować z SP2 - identyczna sytuacja, albo poprawisz
albo nie instaluj nowej wersji FF i przygotuj się na konsekwencje. ;)

Z FF jest *na* *razie* o tyle przyjemniej, że ZTCW nie jest atakowany,
każdy poważniejszy patch na Windows po kilku dniach dorabia się
exploitów wykorzystujących luki, które poprawia. To wymusza
zainstalowanie go. Z FF tak *jeszcze* nie jest.

(...)

>> Czyli troszkę dramatyzujesz. Więc właściwie w czym jest pies
>> pogrzebany? W czym tkwi problem?

> To ze bym sobie poradzil nie oznacza ze jakbym projektowal taka siec
> to bym przyjal takie rozwiazanie. Hund jest begraben w tym ze jezeli
> juz mowimy o FF i jego zastosowaniu w wiekszych sieciach to dla mnie
> powinien dorobic sie dwoch mechanizmow: - zarzadzania konfiguracja w
> sposob zcentralizowany - uaktualnien w postaci patchy a nie pelnych
> instalacji

Co do konfiguracji jestem w stanie się zgodzić, już teraz można w pewien
sposób na to wpływać, wygląda to tak że przygotowujesz samemu
skonfigurowany pakiet i pchasz na końcówki, niestety rozsądnej metody na
ustawienia użytkownika (FIXME) nie ma.

Co do patchy to się nie zgodzę, jak już napisałem - wdrażanie innego
rozwiązania (lepszego jedynie z uwagi na ilość transferu, która jak
napisałem dla mnie nie gra roli w tej skali) niż jest obecnie wiąże się
z poświęceniem cennych zasobów w innym kierunku niż mi by odpowiadał.

>> Potrafisz rozsądnie wyliczyć jakie koszty są związane z tym, że
>> poprawka zajmuje 5MB, a nie 5KB? W punktach np.?

> Zaczalbym od kosztu pasma ktore jest przeznaczone na przesylanie
> poprawki

Koszty pasma w tej skali (5MB co dwa tyg. - pesymistycznie) są
pomijalne. Inne koszty są o rząd wielkości większe.

> a nie na wymiane danych zwiazanych z dzialanosci, to raz. Dwa to
> miejsce na skladowanie tego, trzy to czas potrzebny na instalacje i
> dlugosc przerwy w pracy dla usera.

Przecież nikt nie zmusza do instalowania w momencie kiedy user pracuje.
Można w nocy np. można na starcie systemu. Można wraz z okresowym
wymienieniem całego obrazu systemu etc. etc. w żadnym wypadku nie trzeba
userowi przeszkadzać. A poza tym transfer jakby nie przeszkadza userowi
w niczym, ściąga się w tle - wolniej/szybciej bez różnicy.

> To takie tam .. zgodze sie ze takie argumenty na pierwszy rzut oka
> wygladaja na wyimaginowane a i ja specjalista od kosztow itp nie
> jestem ale w skali wiekszych firm z rozbudowanymi sieciami i tysiacami
> userow to juz zaczyna sie liczyc. Bo jak przekonasz do przejscia na FF
> lub inne tego typu oprogramowanie firme ktora ma 100k userow (a nie
> dalej jak wczoraj z czlowiekiem ktory pracuje dla takiej firmy przy AD
> rozmawialem). Teraz policz ile potrwa przeslanie do 100k stacji 5MB a
> ile 50KB i tak dalej ...

W przypadku przechodzenia firmy mającej 100 tys. userów na inną
przeglądarkę to różnica w rozmiarze tej paczki nie ma *żadnego*
policzalnego znaczenia, koszty pochłonie support/przeszkolenie
pracowników, poprawienie (ewentualne) aplikacji aby działały i pod tym,
ale nie jakieś tępe przesyłanie 5MB - to nie kosztuje, tzn. kosztuje ale
śmieszne grosze. Obecnie łącza *użytkowe* to są ADSL o przepustowości
min. 256kbit - to jest standard *domowy*, w firmach są z reguły lepsze
(nie ze względu na transfer ale raczej jakość/gwarancje obsługi) -
rozsądne łącze to są koszta rzędu 200zł miesięcznie, to jest śmieszna
kwota w skali nawet niewielkiej firmy. To co jest najdroższe to praca
ludzi, porównaj sobie pensję wykfalifikowanego pracownika z kosztami
łącz, wtedy różnica 5MB/500KB nie jest istotna. :)

Ergo: FF ma wady ale w/g mnie napewno nie jest to rozmiar poprawki. Nikt
nie powinien się tym zajmować - prędzej (jeżeli zależy im na
spenetrowaniu rynku korporacyjnego) powinni zająć się nad rozwinięciem
np. integrowania FF z rozwiązaniami uwierzytelnianias na różne sposoby,
z tym o czym wspomniałeś (ułatwienie centralnej konfiguracji), ale na
Miłość Boską sama waga pliku jest totalnie nieistotna.

>> Akurat w tych bez proxy się z niczym nie połączysz (chyba, że
>> wewnętrznie). :) Czyli musisz się na proxy uwierzytelnić tak czy siak
>> - w MSIE to jest rozwiązane przez NTLM, w FF i innych nie - używają
>> domyślnych ustawień (muszą przyłazić razem z paczką) czyli
>> automagicznej

> ano wlasnie .. a jak nagle trzeba bedzie zmienic ustawienia czegos w
> takiej przegladarce to co .. paczka i lecimy z dystrybucja.

To nie jest problemem - codziennie z rana maszyny się bootują i łapią
nowe pakiety. :) Z resztą co chciałbyś zmieniać PO STRONIE PRZEGLĄDARKI
co znacząco wpływa na cokolwiek? Proxy? Jest automagicznie
konfigurowane. Co jeszcze? Logo? :>

> A przy mechanizmie centralnego zarzadzania chociazby takim jak GPO to
> po prostu zmienam w odpowiednim obiekcie jedno ustawienie i dalej sie
> to dystrubuuje po klientach samodzilenie.

Ale co ustawiasz przez GPO na ten przykład? Co *konkretnie*, jakiś
realny przykład.

> W FF konifguracja oparta jest o pliki i ciezko cos takiego w tej
> chwili zrobic.

No puścić pliki po klientach. :) Tak to wygląda, GPO to też pliki
puszczane na klienta w gruncie rzeczy, tylko może mają ładniejszy
interfejs. ;)

> Ale jak zauwazyl Pawel Golen warstwa wirtualizacji dostepu do
> konfiguracji rozwiazalaby problem

Oczywiście, że tak - ale jak już napisałem, dorobienie czegoś takiego
nie jest trywialne ani nie jest to w gestii firm rozwijających FF. BTW
tego typu rozwiązania (abstrakcja nad - wirtualizacja to zupełnie co
innego) są w FF - np. interfejs użytkownika, na Windows kompiluje się z
toolkitem win32, na innych systemach z toolkitem GTK - można dodać (jak
ktoś będzie miał taką potrzebę) inny toolkit - dorobi się opcje
kompilacji. ;)

Ergo: FF idzie w tym kierunku w którym jego użytkownikom (w kontekście
większych podmiotów) zależy - jeżeli komuś dostatecznie zależy na tym
aby zrobił abstrakcję od przechowywania swojej konfiguracji i
dostarczał różne backendy do tego to droga wolna. Po prostu zrozum w
jaki sposób rozwija się FF. :)

> - FF zawsze czytalby konfiguracje tak samo ale na konkretnych
> platformach znajdowalaby sie ona gdzie indziej - tak jak to realizuje
> HAL w systemach Windows.

Sorry to bzdura. Rozumiem, że jesteś niewyspany. W sensie HAL w Windows
jest charakterystyczny... dla Windows - nie ma tu mowy o innych
systemach.

> Wtedy i FF bylby caly i konfiugracje moglby w Win czytac z rejestru a
> w Linux z pliku

W Linuksie też są rozwiązania typu rejestr windows - jeżeli ktoś
zażyczyłby sobie aby z nich korzystać to droga wolna.

>> konfiguracji proxy i wyskakuje za pierwszym połączeniem monit o
>> autoryzację do proxy, jak user sobie zażyczy to zostanie to zapisane
>> w profilu - a że wszędzie logują się tym samym zestawem
>> użytkownik:hasło więc problemu raczej nie ma, nazwałbym to
>> niedogodnością... Z resztą nie pamiętam czy FF czasem nie obsługuje
>> NTLM - jak ostatnio tam byłem to wyglądało tak jak opisałem. Ja wiem,
>> że zaraz zadramatyzujesz jakie to ma ogromne koszty itd. w każdym
>> razie tak to tam działa.

> To nie chodzi o niedogodnosc - powiedzmy z dnia na dzien musisz
> wlaczyc obsluge SSL 3.0 na tych 1.5 tys stacji bo w domyslnej paczce
> byla wylaczona,

Wyimaginowana sytuacja. W takiej skali - czego byś nie chciał włączyć -
tego sie nie robi z dnia na dzień. Testuje się długo, wdraża się przez
jakiś czas, daje się jakiś okres toleranci w którym oba rozwiązania
(starsze i nowsze) działają, sprawdza się czy wszystko poszło OK,
poprawia się to co nie poszło OK i dopiero jest koniec... To *nigdy* nie
jest z dnia na dzień - nie opowiadaj bajek. :) To jest nierealne co
mówisz. ;)

> albo chcesz sie zabezpieczyc zeby userzy nie mogli wylaczyc tego co ty
> im wlaczysz ...

Również się nie zgodzę - zabezpieczenia to ja wprowadzam po tej stronie
po której jestem - na serwerze, na kliencie to niech tam się dzieje co
chce, to nie jest zabezpieczenie.

> to nie jest niedogodnosc. W pewnej skali to jest niestety juz brak
> funkcjonalnosci IMO - ale to jest moja osobista opinia i moge sie
> mylic, miec calkiem bledne pojecie o zarzadzadniu siecia itp.

Wiesz ten przykład z przejściem na nowy protokół (SSL wersja++) to
chybiony IMHO - OK w totalnie zamkniętych sieciach może tak się zdarzyć,
ale np. masz serwer pocztowy - dla N tys. ludzi - oni muszą po prostu tą
pocztę czytać, nie możesz z dnia na dzień zmienić protokół i kazać im
się przekonfigurować, to wymaga sporego przygotowania, okresu
przejściowego, informowania użytkowników itd. - a i tak jak już
zamkniesz stary protokół to zgłoszą się do Ciebie ludzie, że nie działa.
;) Tak to wygląda.

(...)

>> No tak, ale to to w ogóle chyba najwięcej transferu jak się da. ;) W

> No tak ale to mowisz juz o make world - ale przy konkretnej aplikacji
> i portach to wcale tak duzo nie musialobyc.

W skali więcej niż jedna maszyna.

> A jezeli juz mowa o transferach to my genrujemy strasznie duzo
> transferu tymi postami i moze przeniesmy to na priv bo moze to nie
> interesuje nikogo poza nami :)

IMHO nie - to jest grupa dyskusyjna o Windows NT - sobie dyskutujemy,
ostatnio grupy dyskusyjne działają głównie na zasadzie pytanie ->
odpowiedź, a to nie o to chodzi. :)

-- 
                                      +                       .-.     .
  Pozdrawiam,                .                            *    ) )
  Konrad Kosmowski                          .           .     '-'  . kK
Received on Fri Aug 12 02:06:22 2005

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Fri 12 Aug 2005 - 02:42:02 MET DST