- lms - lists.lms.org.pl

Re: [lms] Re: Re: [lms] Re: [lms] LMSd - moduły, reload
by A.L.E.C 23 Paź '03

23 Paź '03

> ja bym proponowal: > standart to reload poprzez menu `Przeladuj" > a jezeli ktos chce co 15minut.. to dodaje do crona. Cały czas dążę do tego aby można było zdecydować, które moduły (usługi) przeładować, a metoda z cronem nie daje takiej możliwości. Na razie więc mam zamiar zrobić tak. W menu 'Przeładowanie' wybieramy moduły do przeładowania i zapisujemy ich nazwy do tabeli reload. Daemon sprawdza ilość rekordów w tej tabeli, jeśli count>0 wykonuje po kolei te moduły. Jeśli będzie to działać, to wrzucę do cvs, a potem zobaczymy. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://k27.prv.pl/alec GG-2275252

1 0

Re: Re: [lms] Re: [lms] LMSd - moduły, reload
by pbern＠pbern.biz 23 Paź '03

23 Paź '03

> Ostatecznie można zaimplementować obie metody i dać użytkownikowi do wyboru, > ale to dodatkowa robota. Najłatwiej zaprogramować reload ręczny, ale nie > chciałbym, żeby potem narzekano na to. Jeszcze decyzja nie podjęta, więc > przekonujcie mnie proszę. A może chce ktoś się za to wziąć, to wystawię to > co mam do cvs'u. ja bym proponowal: standart to reload poprzez menu `Przeladuj" a jezeli ktos chce co 15minut.. to dodaje do crona. Pozdrawiam Pawel Bernadowski

1 0

Re: [lms] Re: [lms] LMSd - moduły, reload
by A.L.E.C 23 Paź '03

23 Paź '03

> Wyobraź sobie maszynę która obsługuje 1000 użyszkodników i lmsa > generujacego > dla niej regułki do iptables, siada sobie nasz księgowy i stuka, user > iksiński > wpłacił, user kowalski wpłacił, zmiana w finansach powoduje ze trzeba > wygenerowac nowe konfigi odcinajace/zmieniajace przepustowosc > (prawda?). > Czemu robić to co 60s skoro wystarczy co imo m*60s gdzie m możnaby > zmieniać > przy kompilacji/w konfigu demona (m=5..15) tak będzie mniej > zarznynania maszyny Oczywiście czas między reloadami można zmieniać i w starym daemonie też chyba tak było. Chodzi mi o to, że motoda oparta na timestampach jest niedoskonała, bo np. zmiana mac'a albo urządzenia sieciowego w danych komputera spowoduje zmianę timestampu, ale nie spowoduje konieczności zmiany konfiguracji firewalla. Reload wykona się niepotrzebnie. Ktoś powie, skoro nic się nie zmieniło to konfiguracja firewalla się też nie zmieni więc reload nie zaszkodzi, ale ... Inny aspekt sprawy: osoba wprowadzająca jakieś zmiany może nie chcieć aby w trakcie tej czynności wykonał się reload i tutaj najlepiej by było skorzystać z menu 'Przeładowanie'. Znowu ktoś powie, ale muszę pamiętać o przeładowaniu... Ostatecznie można zaimplementować obie metody i dać użytkownikowi do wyboru, ale to dodatkowa robota. Najłatwiej zaprogramować reload ręczny, ale nie chciałbym, żeby potem narzekano na to. Jeszcze decyzja nie podjęta, więc przekonujcie mnie proszę. A może chce ktoś się za to wziąć, to wystawię to co mam do cvs'u. Zobaczę jeszcze te templejty Baseciqa. > BTW: skoro juz demoun będzie czytał z sqla to czy mógłby pisać i > umieszczać timestamp 'ostatnio zmieniono wtedy a ftedy' a w php-ui można dać > zakładkę konfigi i co będzie i kiedy zmienione. Taka historia zmian. Nie ma problemu dodatkowa tabela i już. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://k27.prv.pl/alec GG-2275252

1 0

Re: [lms] LMSd - moduły, reload
by hunter 23 Paź '03

23 Paź '03

On Thu, Oct 23, 2003 at 09:17:29AM +0200, =?iso-8859-2?Q?A. L. E. C?= wrote: > >Jak ja to myślałem jak chciałem to napisać w perlu. > > > Podczas reloadu byłby > > >zapisywany czas ostatniego reloadu i np. reload nie byłby wykonywany > > >jeżeli reloadowaliśmy coś w ciągu ostatnich n sekund (np 600). > > Nie dokońca rozumiem sens. Chyba nie ma takiej potrzeby. Zamiast ustawiać n można wyłączyć daemona. Czasem też może się zdażyć, że będzie potrzeba reloadu częściej niż to n. > > Wyobraź sobie maszynę która obsługuje 1000 użyszkodników i lmsa generujacego dla niej regułki do iptables, siada sobie nasz księgowy i stuka, user iksiński wpłacił, user kowalski wpłacił, zmiana w finansach powoduje ze trzeba wygenerowac nowe konfigi odcinajace/zmieniajace przepustowosc (prawda?). Czemu robić to co 60s skoro wystarczy co imo m*60s gdzie m możnaby zmieniać przy kompilacji/w konfigu demona (m=5..15) tak będzie mniej zarznynania maszyny zmiany uaktualnią się średnio po m*30 + 30 sekund, jakby ktoś pytał to rozkład będzie jednostajny czyli równie dobrze to może być m*60 + 59 sekund jak i 1, ale zmiany będą najpóźniej po 10-11 minutach więc da to się zauważyć. BTW: skoro juz demoun będzie czytał z sqla to czy mógłby pisać i umieszczać timestamp 'ostatnio zmieniono wtedy a ftedy' a w php-ui można dać zakładkę konfigi i co będzie i kiedy zmienione. kd. -- Krzysztof Drewicz Podsłuchane na pogrzebie: "Wiem, że to niezręcznie pytać o takie rzeczy w tej chwili, ale przypominasz sobie, żeby on kiedykolwiek wspomniał coś o kodzie źródłowym?" --- Charles Addams

1 0

Re: [lms] Re: [lms] LMSd - moduły, reload
by A.L.E.C 23 Paź '03

23 Paź '03

>Jak ja to myślałem jak chciałem to napisać w perlu. > >1) Reload na podstawie timestamps > >Reload ten miał polegać na tym, iż co jakiś interwał czasu (60 sek) >sprawdzane by były timestampy tabel i porównywane z tymi które znamy. >Jeżeli jakaś tabela się zmieniła to jedziemy. Ale nie każda zmiana w tabeli pociąga za sobą konieczność reloadu. No chyba że przyjmiemy inaczej. > Podczas reloadu byłby >zapisywany czas ostatniego reloadu i np. reload nie byłby wykonywany >jeżeli reloadowaliśmy coś w ciągu ostatnich n sekund (np 600). Nie dokońca rozumiem sens. Chyba nie ma takiej potrzeby. Zamiast ustawiać n można wyłączyć daemona. Czasem też może się zdażyć, że będzie potrzeba reloadu częściej niż to n. > Do tego >każdy moduł w demonie mógł mieć ustawialne triggery na konkretne tabele Możesz rozwinąć? > >2) Reload przez wpisy w tabeli reload. > >Tutaj należy uwzględnić kilka demonów odpalonych i to że np. chcemy >reloadnąć tylko jednego a nie każdego, etc. PO co uruchamiać kilka? Chyba że chodzi ci o zadbanie o to, żeby nie było możliwości uruchamiania kilku daemonów. >A tak btw. zerknij na moje templejty w php... Przemyśl to. Może >faktycznie będzie łatwiej przerzucić generowanie configów na barki ui. Na pewno zobaczę. >A czy podczas odpalania miałby być uruchamiany reload - to chyba proste >do implementacji jako opcja podczas odpalania/opcja configa. Z tym akurat nie ma problemu. Chodziło mi o inicjację modułów (bo tak to jest zrobione w starym daemonie), a nie o reload. -- Pozdrawiam Aleksander Machniak ( A.L.E.C )

1 0

Re: [lms] LMSd - moduły, reload
by Przemek SAKO Galczewski 23 Paź '03

23 Paź '03

Hello Łukasz, Wednesday, October 22, 2003, 11:47:29 PM, you wrote: ŁJM> Witam. >> znowu calkowicie niepotrzebne grzebanie w bazie ... ŁJM> I kolejny wymóg do PHP - obsługa socketów. No niestety, nie ma nic za darmo. Ale co tam, zmusimy uzytkownikow na przejscie na PHP w wersji 3.x lub nowszej, bo 2.x nie mialo socketow ... -- Best regards, Przemek mailto:sako@infinity.waw.pl

1 0

Re: [lms] Re: [lms] Re: [lms] LMSd - moduły, reload
by Łukasz Jarosław Mozer 22 Paź '03

22 Paź '03

Witam. > znowu calkowicie niepotrzebne grzebanie w bazie ... I kolejny wymóg do PHP - obsługa socketów. -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

Re: [lms] Re: [lms] LMSd - moduły, reload
by Przemek SAKO Galczewski 22 Paź '03

22 Paź '03

Hello Łukasz, Wednesday, October 22, 2003, 10:59:06 PM, you wrote: ŁJM> Witam. ŁJM> /cut/ ŁJM> Jak ja to myślałem jak chciałem to napisać w perlu. w c jest szybszy, zajmuje mniej zasobow i nie ma problemu z dodatkowymi wymaganymi modulami perla :) ŁJM> 1) Reload na podstawie timestamps ŁJM> Reload ten miał polegać na tym, iż co jakiś interwał czasu (60 sek) nie podoba mi sie pomysl ciaglego grzebania w sql. zwlaszcza ze jesli ktos uzywa sql'a na slabej maszynie i tylko do lms'a to nie moze skorzystac z dobrodziejstwa swapowania nieuzywanych procesow lub ich czesci. ŁJM> 2) Reload przez wpisy w tabeli reload. znowu calkowicie niepotrzebne grzebanie w bazie ... -- Best regards, Przemek mailto:sako@infinity.waw.pl

1 0

Re: [lms] LMSd - moduły, reload
by Przemek SAKO Galczewski 22 Paź '03

22 Paź '03

Hello A.L.E.C, Wednesday, October 22, 2003, 9:22:48 PM, you wrote: ALEC> Ponieważ próbuję sił z nowym daemonem, napotkałem na problemy projektowe i ALEC> chciałbym je tutaj przedstawić licząc na podpowiedzi. :)) ALEC> 1. Tego że powinien być reload dostępny w UI nie da się chyba przeskoczyć. ALEC> Pomysł żeby wykrywać zmiany w tabelach jest niedoskonały i trudny w ALEC> implementacji. Bo nie każde zmiany muszą pociągać za sobą konieczność ALEC> reloadu. i nie zawsze administrator chce reloadowac .... ALEC> 2. Padły propozycje, aby zamiast czytać tabelę reload co jakiś czas, użyć ALEC> socketów. Pomysł w implementacji okazuje się być prosty. Możnaby nawet ALEC> przesyłać daemonowi komendy w stylu 'stop' 'start' 'reload', ale mam ALEC> wątpliwości czy byłoby to rozwiązanie bezpieczniejsze od korzystania z bazy. samo sluchanie na porcie nie jest niebezpieczne. jesli uzywamy tylko lokalnie, sluchamy na 127.0.0.1 i w komunikacie moze byc przesylane jakies haslo lub mozna wymyslic inne zabezpieczenia. jesli dostep zdalny, to firewall. mozna by wbudowac w daemona sprawdzanie ip autoryzowanych do wykonywania operacji - masz tak zrobionego sql'a i jakos nikt nie narzeka. ALEC> 1. Czy moduły powinny być inicjalizowane podczas startu daemona, czy podczas ALEC> reloadu. Drugie rozwiązanie pozwala na zmiane konfiguracji modułów lub ALEC> dodanie nowych modułów ALEC> bez restartu daemona. Choć z drugiej strony jak już grzebię w konfiguracji, ALEC> to co za problem go zrestartować. a nie mozna mu ladowac konfiguracji w locie po przekazaniu sygnalu, lub -k z przykladu ktory dostales ? -- Best regards, Przemek mailto:sako@infinity.waw.pl

1 0

Re: budowa modularna.
by Łukasz Jarosław Mozer 22 Paź '03

22 Paź '03

Witam. > sam sobie odpowiedziałeś. Wydaje mi się, że moduły są ze sobą za bardzo > powiązane, aby je podzielić, choć może w wersji 2.0 :) Musiałby być bardziej dynamiczne ;-> $_MODULE[name] = 'customers'; $_MODULE[version] = '1.9-cvs'; $_MODULE[description] = 'Customer managment'; $_MODULE[requires] = array('core', 'common'); $_MODULE[opt_requires] = array('nodes', 'finances'); $_MODULE[provides] = array('customers'); No to kawałki kodu już leżą sobie u mnie głęboko w $HOME i czekają na lepsze czasy ;-) -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0