Październik 2003 - lms - lists.lms.org.pl

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

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

22 Paź '03

Witam. /cut/ 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. 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). Do tego każdy moduł w demonie mógł mieć ustawialne triggery na konkretne tabele 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. 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. A czy podczas odpalania miałby być uruchamiany reload - to chyba proste do implementacji jako opcja podczas odpalania/opcja configa. -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

LMSd - moduły, reload
by A.L.E.C 22 Paź '03

22 Paź '03

Ponieważ próbuję sił z nowym daemonem, napotkałem na problemy projektowe i chciałbym je tutaj przedstawić licząc na podpowiedzi. <1> RELOAD 1. Tego że powinien być reload dostępny w UI nie da się chyba przeskoczyć. Pomysł żeby wykrywać zmiany w tabelach jest niedoskonały i trudny w implementacji. Bo nie każde zmiany muszą pociągać za sobą konieczność reloadu. 2. Padły propozycje, aby zamiast czytać tabelę reload co jakiś czas, użyć socketów. Pomysł w implementacji okazuje się być prosty. Możnaby nawet przesyłać daemonowi komendy w stylu 'stop' 'start' 'reload', ale mam wątpliwości czy byłoby to rozwiązanie bezpieczniejsze od korzystania z bazy. <2> MODUŁY 1. Czy moduły powinny być inicjalizowane podczas startu daemona, czy podczas reloadu. Drugie rozwiązanie pozwala na zmiane konfiguracji modułów lub dodanie nowych modułów bez restartu daemona. Choć z drugiej strony jak już grzebię w konfiguracji, to co za problem go zrestartować. Co wy na to? p.s. w cvs'ie mój kod się znajdzie chyba dopiero jak zrobię obsługę modułów i choć jeden moduł działający. Na razie udało mi się zrobić obsługę mysql i pgsql oraz lms.ini. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://k27.prv.pl/alec GG-2275252

1 0

Re: budowa modularna.
by A.L.E.C 22 Paź '03

22 Paź '03

> Witam. > > Hm. Tak sobie myślę jak to rozwiązać. I takie pomysły mi przychodzą. > Nie wiem czy dobrze myślę, oczekuję waszych sugestii. > [...] > Ha, brzmi fajnie, co nie? :) Ale chyba to nie przejdzie narazie. Za > dużo roboty. Tak naprawdę trzeba by było napisać LMS'a od nowa. Ech :/ 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 :) -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://k27.prv.pl/alec GG-2275252

1 0

templejty...
by Łukasz Jarosław Mozer 22 Paź '03

22 Paź '03

Hi. Powiedzcie mi, jak to wygląda wg. was - da się zrozumieć?: # Przykładowy template do generowania pliku dhcpd.conf # $Id:$ ddns-update-style none; shared-network LMS { <? foreach from=$networks item=network ?> subnet <? $network.address ?> netmask <? $network.mask ?> { default-lease-time 86400; max-lease-time 86400; option subnet-mask <? $network.mask ?>; <? if $network.gateway ?> option routers <? $network.gateway ?>; <? /if ?> <? if $network.dns ?> option domain-name-servers <? $network.dns ?>; <? /if ?> <? if $network.domain ?> option domain-name "<? $network.domain ?>"; <? /if ?> <? if $network.wins ?> option netbios-name-servers <? $network.wins ?>; <? /if ?> <? if $network.dhcpstart && $network.dhcpend ?> range <? $network.dhcpstart ?> <? $network.dhcpend ?>; <? /if ?> <? if $network.nodes ?> <? foreach from=$network.nodes item=node ?> host <? $node.name ?> { hardware ethernet <? $node.mac ?>; fixed-address <? $node.ipaddr ?>; } <? /foreach ?> <? /if ?> } <? /foreach ?> } -- Pozdrowienia, Łukasz Jarosław Mozer

1 0