- lms - lists.lms.org.pl

Re: LMS - udane wdrożenie..
by Radosław Antoniuk 24 Paź '03

24 Paź '03

hunter wrote: >> Rozwiązanie na razie jest zrobione banalnie poprzez generowanie >> odpowiedniego dhcpd.conf a na linuxie stoi dhcpd/tftp/routing >> >> CMTS jakiego używam robi za bridge więc wszystkie kompy mam >> wpiętejak w LANie przez switcha :) > > Co było w lmsie miłego a co było przeszkodą którą trzeba było > obchodzić, jakie są z niego pożytki a jakie szkody (a mogą być jaieś?) > Ile trwało wdrożenie i czy można mieć cośkolwiek innego do > zarządzania lanem nawet nei OS i ile by kosztowało? > > Popełniłby ktoś? w dużych sieciach kablowych zastosowanie natywnego LMSa nie jest możliwe. wspomniana wyżej sieć musi być małą siecią skoro cmts działa jako zwykły switch i wszystko było 'takie proste' :-) -- Pozdrawiam, Radosław 'Warden' Antoniuk (http://debian.black.pl)

1 0

OT: Re: Re: LMS - udane wdrożenie..
by hunter 24 Paź '03

24 Paź '03

> Rozwiązanie na razie jest zrobione banalnie poprzez generowanie > odpowiedniego dhcpd.conf a na linuxie stoi dhcpd/tftp/routing > > CMTS jakiego używam robi za bridge więc wszystkie kompy mam wpiętejak w > LANie przez switcha :) A może tak mały artykuli o owdrożeniu, żeby do doc dołożyć? popełniłbyś? Co było w lmsie miłego a co było przeszkodą którą trzeba było obchodzić, jakie są z niego pożytki a jakie szkody (a mogą być jaieś?) Ile trwało wdrożenie i czy można mieć cośkolwiek innego do zarządzania lanem nawet nei OS i ile by kosztowało? Popełniłby ktoś? 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 - udane wdrożenie..
by Przemysław 'Repcio' Gubernat 24 Paź '03

24 Paź '03

On Fri, Oct 24, 2003 at 03:26:01AM +0200, Radosław Antoniuk wrote: > Przemysław 'Repcio' Gubernat wrote: > > TVK Tel-Ka Wrocław (www.tvk.wroc.pl) > > > > [PL] > > Obecnie LMS jest używany do zarządzania siecią modemów w systemie > > DOCSIS 1.1 oraz oczywiście komputerami w tejże sieci. > > Główny powód, łatwość generowania odpowiedniego dhcpd.conf > > Łatkę na 1.0.x/1.1.x podeślę na dniach. > > Jak? CMTS nie współpracuje za dobrze z linuksem. SNMP ? or what? > Rozwiązanie na razie jest zrobione banalnie poprzez generowanie odpowiedniego dhcpd.conf a na linuxie stoi dhcpd/tftp/routing CMTS jakiego używam robi za bridge więc wszystkie kompy mam wpiętejak w LANie przez switcha :) -- Szanuj admina swego, możesz mieć gorszego..... (c) 2000 Przemysław Gubernat IPv4://repcio@3575230515 IPv6://repcio@3ffe:8010:1c:beaf::2 +-=-=- Przemysław Gubernat <repcio(a)repcio.net> -=-=-=-=-=-=-+ | Network Administrator @ Repcio.NET & Trzebnica.NET | | Jestem twoim ostatecznym rozwiązaniem ! | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

1 0

Re: [lms] LMS - udane wdrożenie..
by Radosław Antoniuk 24 Paź '03

24 Paź '03

Przemysław 'Repcio' Gubernat wrote: > TVK Tel-Ka Wrocław (www.tvk.wroc.pl) > > [PL] > Obecnie LMS jest używany do zarządzania siecią modemów w systemie > DOCSIS 1.1 oraz oczywiście komputerami w tejże sieci. > Główny powód, łatwość generowania odpowiedniego dhcpd.conf > Łatkę na 1.0.x/1.1.x podeślę na dniach. Jak? CMTS nie współpracuje za dobrze z linuksem. SNMP ? or what? -- Pozdrawiam, Radosław 'Warden' Antoniuk (http://debian.black.pl)

1 0

LMS - udane wdrożenie..
by Przemysław 'Repcio' Gubernat 23 Paź '03

23 Paź '03

TVK Tel-Ka Wrocław (www.tvk.wroc.pl) [PL] Obecnie LMS jest używany do zarządzania siecią modemów w systemie DOCSIS 1.1 oraz oczywiście komputerami w tejże sieci. Główny powód, łatwość generowania odpowiedniego dhcpd.conf Łatkę na 1.0.x/1.1.x podeślę na dniach. [EN] Curently LMs is used to manage cable modems in DOCSIS 1.1 standard and ofcourse computers it that net. LMS is usend mainly because of easy generation of dhpd.conf Patch for 1.0.x/1.1.x i'll send in few days -- Szanuj admina swego, możesz mieć gorszego..... (c) 2000 Przemysław Gubernat IPv4://repcio@3575230515 IPv6://repcio@3ffe:8010:1c:beaf::2 +-=-=- Przemysław Gubernat <repcio(a)repcio.net> -=-=-=-=-=-=-+ | Network Administrator @ Repcio.NET & Trzebnica.NET | | Jestem twoim ostatecznym rozwiązaniem ! | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

1 0

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

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

Re: budowa modularna.
by Daniellek 22 Paź '03

22 Paź '03

W dniu Wed, Oct 22, 2003 at 12:58:19PM +0200, Łukasz Jarosław Mozer wystukał(a): >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. www.squirrelmail.org Tam jest to chyba w miarę sensownie rozwiązane. -- Daniel Fenert --==> daniel(a)fenert.net <==-- ==-P o w e r e d--b y--S l a c k w a r e-=-ICQ #37739641-== The hardest thing in the world to understand is the income tax. -- Albert Einstein =======- http://daniel.fenert.net/ -=======< +48604628083 >

1 0

Re: [lms] query do zadłużony userów.
by Łukasz Jarosław Mozer 22 Paź '03

22 Paź '03

Witam. > Sprawdzone na: > pg 7.2.4 > mysql 4.0.14 i mysql 3.23.57 -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

query do zadłużony userów.
by Łukasz Jarosław Mozer 22 Paź '03

22 Paź '03

Witam. Ktoś tutaj ostatnio marudził że potrzebuje query do wyciągnięcia listy zadłużonych userów: SELECT users.id AS id, SUM((type * -2 + 7) * cash.value) AS balance FROM users LEFT JOIN cash ON users.id = cash.userid GROUP BY users.id HAVING SUM((type * -2 + 7) * cash.value) < 0; Sprawdzone na: pg 7.2.4 mysql 4.0.14 -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

budowa modularna.
by Łukasz Jarosław Mozer 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. Każdy moduł byłby w modules/nazwamodułu/ w takim katalogu byłoby coś like init.php - skrypt inicjujący moduł, ustawiający jego nazwy, wersję, zależności, jakich klas ten moduł dostarcza, jakich wymaga. classes.php - klasy tego modułu jakie on dostarcza actions/ - katalog z 'akcjami', np. add, delete, edit, etc. Klasa LMS wiązałaby inne klasy i funkcje ogólne LMS'a. I tak np. nie byłoby $LMS->AddUser() tylko $LMS->User->Add(). Klasa User byłaby dostarczana przez jakiś określony moduł. Moduł ten (do zarządzania użytkownikami) wymagałby także klas modułu finansowego (jak np. Finances::GetUserBalance) a inicjacją wymaganych klas zajmowałaby się sama klasa LMS. Ojej. Ale gmatwam. Generalnie cel byłby taki, żeby każdy moduł potrafił określić czego wymaga oraz co on sam może zapewnić. Potrafiłby także sprawdzić czy ma dostępne jakieś moduły i np. w ramach tego sam się odpowiednio zachować. Co za tym idzie, można by było odpalić LMS'a z samym modułem do zarządzania komputerami i urządzeniami sieciowymi i mamy ładną i fajną aplikację do sieci korporacyjnej. 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 :/ -- Łukasz Jarosław Mozer http://www.baseciq.org mailto: lukasz(a)rulez.pl

1 0

Offtopic, ale pewnie się niektórzy zainteresują
by Łukasz Jarosław Mozer 22 Paź '03

22 Paź '03

Hej. Offtopicznie tak, ale pewnie was to zainteresuje: http://www.rzeczpospolita.pl/gazeta/wydanie_031021/prawo/prawo_a_2.html Nowe warunki korzystania ze stałego dostępu do Internetu w TP SA do wyjaśnienia Zmiana reguł w trakcie gry Telekomunikacja Polska zmienia regulamin dla użytkowników Stałego Dostępu do Internetu (SDI). Od 6 listopada nie będą oni mogli dzielić się swoim łączem z nikim spoza lokalu. Protestują przeciw temu użytkownicy sieci osiedlowych, którzy właśnie po to wykupili tę usługę, by wspólnie korzystać z SDI. Osoby posiadające SDI z ostatnim rachunkiem telefonicznym dostały nowy regulamin. W art. 6 pkt. 6 stanowi on, że "w ramach korzystania z Usługi Klient zobowiązany jest nie umożliwiać korzystania z Usługi innym podmiotom poza Lokalem". Jest to zupełna nowość, gdyż dotychczas Telekomunikacji nie interesowało, ilu użytkowników korzysta z jednego łącza. Nowy zakaz dotknie przede wszystkim użytkowników niewielkich sieci osiedlowych czy blokowych. Sąsiedzi, chcąc zaoszczędzić na kosztach, porozumiewali się między sobą i ustalali, że wspólnie będą pokrywać opłatę za SDI. Jeden z nich podpisywał umowę z TP SA. Łącze z jego mieszkania było dzielone na inne w bloku. Dostęp do Internetu był dużo wolniejszy, ale korzystać z niego mogła jednocześnie większa liczba osób, a opłatę dzielili między sobą. Teraz, bez ostrzeżenia, klienci TP zostali postawieni pod ścianą. Dalsze korzystanie z usługi SDI traci dla nich sens, gdyż podpisali umowę w celu korzystania z łącza przez wielu użytkowników. A tego właśnie im zakazano. - Zupełnie niezrozumiałe jest dla mnie, czym kieruje się TP SA, wprowadzając taki zakaz. Teoretycznie nie powinno ich obchodzić, ile osób korzysta z tego samego łącza. Poza tym jest to zmiana reguł w trakcie gry. To tak, jakbym kupował butelkę wody, ale nie mógłbym się nią podzielić z nikim innym - mówi Marek Warczewski, jeden z użytkowników osiedlowej sieci. - Naszym celem nie jest utrudnianie życia innym, tylko dostosowanie usługi do potrzeb użytkowników i nowych możliwości technicznych - zapewnia Barbara Górska, rzecznik TP SA. - Usługę SDI zaczęliśmy świadczyć w listopadzie 1999 r. Od tego czasu pojawiły się nowe możliwości i chcemy skłonić naszych klientów do skorzystania z Neostrady czy DSL. Usługa SDI jest przeznaczona dla indywidualnych użytkowników - dodaje. Przyznaje jednak, że ze względów technicznych nie wszyscy klienci, do których dociera SDI, mogą skorzystać z nowych rozwiązań. Zmiana warunków świadczenia usługi SDI dotknie też małe firmy mieszczące się w więcej niż jednym lokalu. Dotychczas wystarczyło jedno łącze dzielone na wiele komputerów w różnych pomieszczeniach. Teraz, aby nie złamać regulaminu, właściciel firmy powinien wykupić łącze SDI osobno dla każdego lokalu. W związku z licznymi skargami klientów TP SA Urząd Ochrony Konkurencji i Konsumentów zdecydował się wczoraj wszcząć postępowanie wyjaśniające w tej sprawie. Pracownicy UOKiK zbadają, czy zmiany w regulaminie nie naruszają przepisów ustawy antymonopolowej. TP SA podkreśla natomiast, że daje klientom możliwość wyboru, nie obarczając ich konsekwencjami zmiany decyzji. - Jeśli uznają oni, że nowe warunki świadczenia usługi SDI im nie odpowiadają, mogą wypowiedzieć nam umowę, nie płacąc za to nawet złotówki. Dotyczy to wszystkich naszych klientów, nawet tych, którzy podpisali z nami umowę na czas określony, np. na 24 miesiące - zapewnia Górska. Jeśli jednak TP SA przyłapie kogoś na udostępnianiu łącza SDI poza swoim lokalem, będzie musiał on zapłacić karę: trzykrotność opłaty miesięcznej. Pozostaje jeszcze problem możliwości sprawdzenia, czy klient łamie regulamin. Klienci TP SA nie mają przecież obowiązku wpuszczania kontrolerów do swoich mieszkań. Telekomunikacja zapewnia jednak, że ma sposoby na skontrolowanie użytkowników SDI. Sławomir Wikariak -- Pozdrowienia, Łukasz Jarosław Mozer

1 0

Re: Pomocy...
by Marek Malinowski (Malina) 21 Paź '03

21 Paź '03

Dzieki ludzie....qde wszystko juz dziala...hehe...mozecie siec ASK Blok4wIEs dopisac do zadowolonych z Waszego skryptu (programu..czy jakos tak). Aha a pomogla instalacja nowego php...Jeszcze raz dzieki!!!!!! --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search

1 0