- lms - lists.lms.org.pl

Re: Taryfy bardziej elastyczne.
by A.L.E.C 21 Lis '03

21 Lis '03

Podłączę się do wątku, bo mój problem dotyczy także taryf i uprate/downrate. Mianowicie pisząc moduł do HTB, napotkałem na taki problem (w moim przypadku tylko teoretyczny, ale realny). Na przykład, gdy user ma 2 kompy i płaci abonament z dwóch taryf (do tego różnych) to jest problem z ustaleniem uprate i downrate dla tych komputerów z osobna, bo taryfy są przypisane do usera a nie do kompów. Jedyne rozwiązanie jakie mi się nasuwa, to dodanie pól downrate i uprate do tabeli nodes, albo (może nawet lepiej) zmiany w assignments, tak aby można było przypisywać taryfy do kompów. Proszę o uwagi. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://k27.prv.pl/alec GG-2275252

1 0

Re: Re: [lms] Re: [lms] Re: [lms] RE: [lms] Kilka wyjaśnień.
by pbern＠pbern.biz 21 Lis '03

21 Lis '03

On Thu, 20 Nov 2003, A.L.E.C wrote: > nie ma sprzeciwów, to panowie do roboty! Ja oczywiście staram się jak mogę > dawać dobry przykład. tutaj prosba do Ciebie... gdybys mogl dodac do payments 'kary', ja bym to widzial tak: dodajemy do kazdego usera pole 'kary' o domyslej wartosci null. do pliku konfiguracyjnego zmienna kara = [1-31] - dzien naliczania kary. potrzebna by byla jeszcze opcja w ktorej mozna by ustawic wysokosc kary. czy jest takie cos do zrealizowania??? a co najwazniejsze czy bys TY to zrobil ;) Pozdrawiam Pawel Bernadowski GG 3377, email kontakt(a)pbern.biz

1 0

Re: Taryfy bardziej elastyczne.
by hunter 21 Lis '03

21 Lis '03

On Fri, Nov 21, 2003 at 01:38:46PM +0100, Rafal Ramocki wrote: > Witam > > Co do taryf to proponuje zrobic tak: > Z tablicy tarrifs wywalic koluymny uprate i downrate. a dodac kolumne > credits. Nastepjnie dodac tablice "tariffs_zones". W tej tabeli pola > odpowiednio Ech, rzeźbienie w niepowiem czym. 3/4 ludzi nawet nie zauważy takich ficzerów jako konieczne/przydatne. pozatym np od 8 do 17 możesz łatwo up/down wszystkich o danym id zmienić kożystając z crona. > Co myslicie? Ja moglbym nawet posiedziec i sie tym zajac. Oczywiscie o ile to > nie przerosnie moich mozliwosci :P Jak zrobisz to się chyba nikt nie obrazi. A może nawet podziękuje :) 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

Taryfy bardziej elastyczne.
by Rafal Ramocki 21 Lis '03

21 Lis '03

Witam Co do taryf to proponuje zrobic tak: Z tablicy tarrifs wywalic koluymny uprate i downrate. a dodac kolumne credits. Nastepjnie dodac tablice "tariffs_zones". W tej tabeli pola odpowiednio ruleid - numerek identyufikacyjny regoly tarrifid - identyfikator taryfy do ktorej nalezy wpis download_cir\ download_eir \ > wiadomo, do czego upload_cir / upload_eir / time_zone - godzian od ktorej ma obowiazywac dana regola. Takie rozwiazanie da mozliwosc elastycznej konfiguracji dla kadzego. Stworza sie mozliwosci konfiguracji: - Inna predkosc w dzien i w nocym, czy w roznych strefach czasowych - Inna predkosc dla download i upload - Inna predkosc gwarantowana a inna maxymalna (zeby lacze providera sie nie nudzilo) - Mozliwosc ograniczenia ilosci przesylnaych danych do XXXX na miesiac (taka praktyke stosuje na przyklad moj obeny provider mam 10GB po p[rzekroczneiu ktorych mam 2gr za kazdy kolejny megabajt. Co myslicie? Ja moglbym nawet posiedziec i sie tym zajac. Oczywiscie o ile to nie przerosnie moich mozliwosci :P z powazaniem Rafal Ramocki

1 0

Problem ze skryptami lms-*
by Krzysztof Zagorski 20 Lis '03

20 Lis '03

Przy probie odpalenia skryptow (przykladowo niech bedzie to lms-notify) Dostaje tylko taki okmunikat o bledzie: lms-notify, version 1.1.4 Tanith (C) 2001-2003 LMS Developers Using file /etc/lms/lms.ini as config. DBD::Pg initialisation failed: Can't locate object method "driver" via package "DBD::Pg" at /usr/lib/perl5/DBI.pm line 723. Perhaps the capitalisation of DBD 'Pg' isn't right. at /usr/sbin/lms-notify line 145 Pewnie albo jeszcze czegos mi brakuje, albo np. jest zle zainstalowane. Czy ktos mogl by mnie naprowadzic co mam probowac naprawic? Wersja Perla 5.8.2 Postgres'a 7.3.4-9 Module id = DBD::Pg CPAN_USERID DWHEELER (David Wheeler <david(a)wheeler.net>) CPAN_VERSION 1.31 CPAN_FILE R/RU/RUDY/DBD-Pg-1.31.tar.gz MANPAGE Pg - Perl5 extension for PostgreSQL INST_FILE /usr/share/perl5/DBD/Pg.pm INST_VERSION 2.0.2 -- [ Krzysztof Zagórski GG:147848 ICQ: 236331820 GSM: +48 1E 0B 20 BC ] [ ircname: Maverick rlu:215007 PGP Key: http://3281429070/pgp ] [ http://znirevpx.wrfg.gjbvz.theh.cy mailto: maverick(a)irc.pl ]

1 0

Re: [lms] Re: [lms] Re: [lms] RE: [lms] Kilka wyjaśnień.
by A.L.E.C 20 Lis '03

20 Lis '03

> To nie mam wyjścia? Hmm, to na początek was trochę pogonię, Baseciq > zrobi invoices (tego w sumie nie widać), Lexx - netdevip (a to > wygląda nieładnie), ja trochę jestem zajęty demonem, ale skrobnę w > dokumentacji o formacie pliku konfiguracyjnego (z uwagi na nowe > funkcje parsujące) - to tyle jeśli chodzi o 1.1.5, trzeba to zamknąć > w tym miesiącu. Natomiast do końca roku pasuje wszystko dopracować i > napisać dokumentację do demona (to ja) i może 1.2.0 ? Być może > jeszcze przed 1.2 zrobię INET_NTOA i INET_ATON, ale rewolucja > Basecikowa, jeszcze chyba poczeka. nie ma sprzeciwów, to panowie do roboty! Ja oczywiście staram się jak mogę dawać dobry przykład. -- Pozdrawiam Aleksander Machniak ( A.L.E.C ) http://k27.prv.pl/alec GG-2275252

1 0

Re: stabilna wersja
by Radosław Antoniuk 20 Lis '03

20 Lis '03

>> Kiedy można się spodziewać nowej stabilnej wersji lms'a? z linii 1.2 ? >proponuje archiwum... mowa byla o koncu 2003. > Jak się uda to na gwiazdkę :P -- Warden

1 0

Re: stabilna wersja
by pbern＠pbern.biz 20 Lis '03

20 Lis '03

On Thu, 20 Nov 2003, Paweł Rohde wrote: > Witajcie > > Kiedy można się spodziewać nowej stabilnej wersji lms'a? z linii 1.2 ? proponuje archiwum... mowa byla o koncu 2003. Pozdrawiam Pawel Bernadowski GG 3377, email kontakt(a)pbern.biz

1 0

stabilna wersja
by Paweł Rohde 20 Lis '03

20 Lis '03

Witajcie Kiedy można się spodziewać nowej stabilnej wersji lms'a? z linii 1.2 ? pozdrawiam Paweł

1 0

Re: Moje 3 grosze do LMS'a
by Zarzad Interblock 19 Lis '03

19 Lis '03

On Wed, 19 Nov 2003 17:53:22 +0100, Administrator (warsztat) wrote > Witaj Przemysław, > > W Twoim liście datowanym 18 listopada 2003 (22:59:13) można przeczytać: > > >> Dobrym rozwiazeniem bylo by tez dodanie w taryfac pola CIR... > >> > PRG> Hmm.... IMHO zbędne.. > PRG> jeżeli chcesz generować pliki do HTB możesz określić CIR jako: > PRG> * stałą wartość > PRG> * procent przepustowości > > PRG> Osobićie generuję rozwiazanie 2 częściowe: LMS generuje mi plik > w formacie PRG> %ID %IP %UPRATE %DOWNRATE i na jego podstawie > dopiero generuję plik dla PRG> htb.init (ot takie lenistwo) gdzie > określam RATE (CIR) CEIL (EIR) > > Tzn ja generuje EIR (narazie) dla upload i downrate wiec juz nie mam > pola na CIR, ale to nie bedzie chyba trudne do zrobienia wiec pomysle > nad tym (bo uwazam ze jest to dobra mysl). Narazie jednak mam dwa > kola :( Ja myslalem sporo nad tymi taryfami i tym co moze byc potrzebne zeby system taryf byl mozliwie bardzo elastyczny i zeby dal sie dopasowac do kazdej sieci. Tak amatorskiej jak i komercyjnej. W moim chorym umysle zrodzil sie taki oto szatanski plan: 0. Wywalic z tabeli tariffs pola downrate i uprate i dolozyc pole "credits" ktore bedzie limitem ilosci danych jaki bedzie mogl uzytkownik przeslac w ciagu miesiaca. (Teraz kozystam z uslug firmy ktora rozlicza klientow z ilosci danych jakie przesylaja, mam miesiecznie 10GB, a potem kazdy megabajt kosztuje mnie 2gr) 1. Dolozyc jeszcze jedna tabele ktora w mysql'u bedzie defiuniowana na przyklad tak: CREATE TABLE tariffs_timezones ( id int(11) NOT NULL auto_increment, tariffid int(11) NOT NULL default '0', timezone time NOT NULL default '00:00:00', dl_cir int(11) default '0', dl_mir int(11) default '0', ul_cir int(11) default '0', ul_mir int(11) default '0', PRIMARY KEY (id), UNIQUE KEY id (id), KEY id_2 (id) ) TYPE=MyISAM; 2. Kazdy rekord w tabeli tarrifs bedzie sie tyczyl ogolnej definicji taryfy, tylko ogolnej bez predkosci czy sterf czasowych. 3. Kazdy reokrd w nowej tabeli bedzie definicja tego jak ma dzialac dana taryfa w okreslonej porze dnia lub nocy iu jaka predkosc ma miec user w danej porze dnia. 4. Pola w nowej tabeli: - id - identyfikator danej regoly (na dobra sprawe mozna yb to chyba pominac) - tariffid - identyfoikator taryfy do ktorej nalezy regola - timezone - czas od ktorego ma obowiazywac dana regola (na przykalad od 01:00) Do momentuy nie wlaczoenia kolejnej regoly beidze obowiazywala ta - dl_cir - predkosc jaka chcemy uzytkownikowki zagwarantowac w tym czasie - dl_mir - w przypadku niedociazonego lacza prezdkosc jaka uzytkownik bedzie mogl osiagnac maxymalnie - ul_mir - analogicznie - ul_mir - analogicznie Co myslicie o takim rozwiaznaiu?? Bo mnie sie wydaje ze moze to kompleksowo rozwiazac wszelkie mozliwosci taryfowe. Jezeli cos jest nie jasne to pytajcie :) BO pise ot po 5 godzinach zabwy w noigagame i mi mozg sie jeszcze po tym nie przestawil na normalne myslenie :P z powazaniem Rafal Ramocki

1 0