- lms - lists.lms.org.pl

Re: lastonline, nowe ToDo
by marcin 25 Sie '04

25 Sie '04

> w demo juz sa jakies wpisy - czyzby tez zewnetrzny program juz ujzal swiatlo > dzienne? Tak mi chodzi po glowie, coby lastonline pokazywało jeszcze last_squid_user_activity, bo czasem pakiety przychodza na router, a userek dalej skarzy sie ze mu sie stronki nie otwieraja Marcin

1 0

Re: Potwierdzenie przeladowania ALMSD
by lukas 24 Sie '04

24 Sie '04

MO> Wystarczy, ze zamiast slowka _force umowimy sie na jakis prefix i MO> dalej bedziemy dodawac identyfikator instancji almsd, np. _rld_siec1. MO> Identyfikator bylby wpisany do jego konfiga. Swietny pomysl Jak pomysl nie przejdzie do oficjalnej wersji to ja to napewno zaaplikuje w swoim "branchu" ;-) -------------------- Łukasz Wojciechowski

1 0

Re: Potwierdzenie przeladowania ALMSD
by Maciej Ochalek 24 Sie '04

24 Sie '04

11:20:14 PM, lukas był(a) łaskaw(a) nastukać list o treści: MO>> Witam, MO>> Wlasnie wpadlem na pewien problem i chcialbym go zaproponowac MO>> szanownym developerom. MO>> Otoz uzytkownik (tutaj: admin) czuje sie znacznie bardziej komfortowo MO>> gdy widzi, ze system reaguje na jego polecenia, nawet jesli skutki tej MO>> reakcji wystepuja znacznie pozniej. MO>> W starej wersji demona przeladowanie demona powodowalo po prostu MO>> skasowanie flagi _force, co mozna bylo latwo sprawdzic, np. wydajac MO>> jeszcze raz polecenie przeladowania w UI. MO>> A gdyby tak kazda instancja demona po udanym reloadzie wystawiala MO>> odpowiedniego timestampa o nazwie ustalonej w pliku konfiguracyjnym MO>> (np. jako parametr dodatkowego moduliku)? MO>> W ten sposob UI w sekcji Przeladowanie mogloby wyswietlac informacje o MO>> czasie przeladowania wszystkich instancji demona, przez co latwiej by MO>> mozna bylo kontrolowac jego prace, a admini tracili by mniej wlosow MO>> rwanych z glowy :) MO>> O. l> Mi się ten pomysł podoba a do tego dorzuciłbym jeszcze jeden. l> Na stronie "Przeładowanie" dorzuciłbym możliwość wyboru co ma być l> przeładowane. Mogła to by być np jedna ze zdefiniowanych sieci lub l> grup lub np jakikolwiek string - ta informacja byłaby zapisywana w l> bazie obok polecenia "_force" (potrzebna byłaby oczywiście zmiana l> struktury tabeli timestamps). Wystarczy, ze zamiast slowka _force umowimy sie na jakis prefix i dalej bedziemy dodawac identyfikator instancji almsd, np. _rld_siec1. Identyfikator bylby wpisany do jego konfiga. BTW: czy ktos bawil sie moze m0n0wall'em? Strasznie mi sie zabawka spodobala i zastanawiam sie, jak by toto wspolgralo z LMSem. O. -- Maciej O'Klap Ochałek ASK RudyNET http://www.rudynet.pl

1 0

Re: Potwierdzenie przeladowania ALMSD
by lukas 24 Sie '04

24 Sie '04

MO> Witam, MO> Wlasnie wpadlem na pewien problem i chcialbym go zaproponowac MO> szanownym developerom. MO> Otoz uzytkownik (tutaj: admin) czuje sie znacznie bardziej komfortowo MO> gdy widzi, ze system reaguje na jego polecenia, nawet jesli skutki tej MO> reakcji wystepuja znacznie pozniej. MO> W starej wersji demona przeladowanie demona powodowalo po prostu MO> skasowanie flagi _force, co mozna bylo latwo sprawdzic, np. wydajac MO> jeszcze raz polecenie przeladowania w UI. MO> A gdyby tak kazda instancja demona po udanym reloadzie wystawiala MO> odpowiedniego timestampa o nazwie ustalonej w pliku konfiguracyjnym MO> (np. jako parametr dodatkowego moduliku)? MO> W ten sposob UI w sekcji Przeladowanie mogloby wyswietlac informacje o MO> czasie przeladowania wszystkich instancji demona, przez co latwiej by MO> mozna bylo kontrolowac jego prace, a admini tracili by mniej wlosow MO> rwanych z glowy :) MO> O. Mi się ten pomysł podoba a do tego dorzuciłbym jeszcze jeden. Na stronie "Przeładowanie" dorzuciłbym możliwość wyboru co ma być przeładowane. Mogła to by być np jedna ze zdefiniowanych sieci lub grup lub np jakikolwiek string - ta informacja byłaby zapisywana w bazie obok polecenia "_force" (potrzebna byłaby oczywiście zmiana struktury tabeli timestamps). Założmy, że mam 10 lokalizacji, 10 routerów a na każdym z nich odpalony demon lub skrypt, który ma podane jako parametr nazwę sieci lub kilku. Po dokonaniu zmiany odnośnie klienta z sieci X wykonuje polecenie przeładowania tylko sieci X. Demony z każdego z routerów sprawdzają co 10min polecenie przeładowania i dodatkowo sieć dla której zostało wydane polecenie i rekonstruują pliki konfigruacyjne, tylko jeśli polecenie przeładowania dotyczyło sieci, która zajmuje się dany router. -------------------- Łukasz Wojciechowski http://webdesign.peenzet.net

1 0

Re: Odp: Re: LMS 1.4
by lukas 24 Sie '04

24 Sie '04

MK> Sami niewiemy ;) :) MK> Pytasz czy będzie programowany obiektowo? MK> Będzie na tyle obiektowy, na ile pozwoli php4. A nie myśleliście nad tym, żeby pójść w stronę OOP przy pomocy PHP5? Pozwoliłoby to stworzyć o wiele "lepszy" kod no i można by oprzeć pewne elementy o już gotowe rozwiązania - np framework mojavi (mojavi.org) ? -------------------- Łukasz Wojciechowski

1 0

Potwierdzenie przeladowania ALMSD
by Maciej Ochalek 24 Sie '04

24 Sie '04

Witam, Wlasnie wpadlem na pewien problem i chcialbym go zaproponowac szanownym developerom. Otoz uzytkownik (tutaj: admin) czuje sie znacznie bardziej komfortowo gdy widzi, ze system reaguje na jego polecenia, nawet jesli skutki tej reakcji wystepuja znacznie pozniej. W starej wersji demona przeladowanie demona powodowalo po prostu skasowanie flagi _force, co mozna bylo latwo sprawdzic, np. wydajac jeszcze raz polecenie przeladowania w UI. A gdyby tak kazda instancja demona po udanym reloadzie wystawiala odpowiedniego timestampa o nazwie ustalonej w pliku konfiguracyjnym (np. jako parametr dodatkowego moduliku)? W ten sposob UI w sekcji Przeladowanie mogloby wyswietlac informacje o czasie przeladowania wszystkich instancji demona, przez co latwiej by mozna bylo kontrolowac jego prace, a admini tracili by mniej wlosow rwanych z glowy :) O. -- Maciej O'Klap Ochałek ASK RudyNET http://www.rudynet.pl

1 0

Re: lastonline, nowe ToDo
by A.L.E.C 24 Sie '04

24 Sie '04

greg wrote: > ps: alec ma zwalona poczte :( hmm.. amavis+spamassassin od niedawna, jeszcze nie wiem dlaczego, ale odrzucał twoje maile z komunikatem BAD_HEADER, dojdę do tego dlaczego, a tymczasem możesz słać do mnie pocztę na konto alec1(a)poczta.onet_usun-to_.pl -- Aleksander 'A.L.E.C' Machniak http://alec.pl gg-2275252 Lan Management System Developer http://lms.alec.pl

1 0

Odp: Re: LMS 1.4
by Marcin Król 24 Sie '04

24 Sie '04

> Jakie macie założenia odnonie kodu LMS2? Sami niewiemy ;) > W czym będzie pisany - PHP5? Coś około PHP 4.3. Przynajmniej na tej wersji php ja pracuję ;) > Czy będzie to OOP? Pytasz czy będzie programowany obiektowo? Będzie na tyle obiektowy, na ile pozwoli php4. > Czy jest możliwoć dołšczenia się do prac nad LMS2? Być może puźniej, Baseciq chciał aby nad samym core pracowało niewielu ludzi. LMS 2.0 jest już pisany od około 8 miesięcy. Przynajmniej jakoś tak w styczniu czy lutym widziałem pierwsze fragmenty kodu ;) Początkowo to LMS 1.2 miał być ostatnim z serii 1.x, ale wszystko potoczyło się troszkę inaczej.

1 0

Odp: Re: lastonline, nowe ToDo
by Marcin Król 24 Sie '04

24 Sie '04

> w demo juz sa jakies wpisy - czyzby tez zewnetrzny program juz ujzal swiatlo > dzienne? Nie. Wpisy generuje genfake.

1 0

Re: lastonline, nowe ToDo
by greg 24 Sie '04

24 Sie '04

w demo juz sa jakies wpisy - czyzby tez zewnetrzny program juz ujzal swiatlo dzienne? byq ps: alec ma zwalona poczte :( ps2: sox za html :(( -------Original Message------- From: lms(a)lists.rulez.pl Date: 08/16/04 11:55:33 To: lms(a)lists.rulez.pl Subject: [lms] Re: lastonline, nowe ToDo Użytkownik Krzysiek napisał: > No właśnie a u mnie nie pokazuje. Proszę o info co jest wymagane w systemie > i co odpowiada za zapis do bazy. Zewnetrzny program którego jeszcze nie ma. -- _ _ _ ___ | |_ | \/ |( __| http://www.|___)|_||_||___).rulez.pl Marcin 'Lexx' Król LMS Developer lexx(a)polarnet.gliwice.pl GG: 652506 Nie odpisuje na listy pisane w HTML.

1 0