W dniu 25 lutego 2009 11:54 użytkownik Szymon Kajewski lysysoft@o2.pl napisał:

Właśnie zabrałem się za pisanie podobnej poprawki. Z tym że przyjąłem minimalnie inne podejście. Przy urządzeniu czy to >komputerze wybór z listy typu urządzenia (komputer,laptop,switch,mikrotik,itp) - to jedno dodatkowe pole w tablicy urządzeń, i >osobna tabela zawierająca typy urządzeń, oraz ich ewentualne atrybuty i opisy. W ten sposób jest szybki wybór typu >urządzenia, i duża elastycznośc konfiguracji.

Liczę że w miare gotowe poprawki będę miał w ciągu 2-3 dni. jak zaczna "po ludzku" wyglądać podeślę diff-a.

Widzisz bardzo fajnie, ja porponuje ustalic kilka rzeczy tak aby twoje poprawki nie były poźniej do poprawki ;) Uważam że wszyscy zainteresowani powinni sie wypowiedziec, szczegolnie ALEC, pozostaje problem gdzie typy urzadzen umieszczac czy w tabeli nodes czy netdevices, komputery to nody, urzadzenia sieciowe to netdevices powiazane z nodami ktore maja ownerid=0.

Glupia troche sprawa wyglada z netdevices, gdzie typ urzadzenia trzeba by ustalac w adresie ip (node), z kolei komputery to same nody ich parentem jest klient.

Nie wiem wydaje mi sie ze najprostrszym wyjsciem tam gdzie node jest wlasnoscia netdevice'a ustalać 0 w typie urzadzenia, i po prostu pole w tabeli netdevices by przejelo okreslanie typu tego urzadzenia. chodzi o to zeby umozliwic później ludziom ktorzy beda pisac skrypty itp. w miare latwe korzystanie z tych udogodnień.

Pozdrawiam

!DSPAM:49a5285a87232889253296!

Dnia 25 lutego 2009 12:15 Michał Gacek michal.gacek@gmail.com napisał(a):

Widzisz bardzo fajnie, ja porponuje ustalic kilka rzeczy tak aby twoje poprawki nie były poźniej do poprawki ;)

Napewno będą.. Pisze tak jak umiem czyli brzydko ;>

Uważam że wszyscy zainteresowani powinni sie wypowiedziec, szczegolnie ALEC, pozostaje problem gdzie typy urzadzen umieszczac czy w tabeli nodes czy netdevices, komputery to nody, urzadzenia sieciowe to netdevices powiazane z nodami ktore maja ownerid=0.

Glupia troche sprawa wyglada z netdevices, gdzie typ urzadzenia trzeba by ustalac w adresie ip (node), z kolei komputery to same nody ich parentem jest klient.

Takie podejście jest chyba jedynym sensownym, ponieważ nodes określa IP LAN i WAN oraz MAC, i urządzenia które ich nie posiadają nie trafiają do tej tabeli. Więc urządzenia typu switche,itp nie znalazły by sie w nodes. Z drugiej strony w netdevices nie ma urządzeń klienckich, i to wiąże sie z kilkoma poprawkami w prawie wszystkich elementach wyświetlających/edytujących dane komputerów. Uważam że wrzucenie urządzeń klientów jest dość istotne, gdyż niektórzy klienci posiadają sprzęt własny, a inni firmowy, który dobrze jest mieć wprowadzony do systemu, a część z takich urządzeń może aktywnie współpracować z serwerem (przesyłać np dane o poziomie sygnału) poprzez SNMP lub www. Dla komputerów nie posiadających odpowiadającego im pola w netdevices zwracana była by wartość "typ nieznany", a reszta ładnie by się wyświetlała. Większym problemem wg mnie jest ustalenie zawartości tabeli z typami urządzeń - jakie atrybuty sa potrzebne. Bo znając życie tu będzie dużo modyfikacji. Może zagłębic to w kolejną tablice - artybuty? Wtedy tablica typów miała by format : "ID","ID Typu","ID atrybutu dotyczacego tego typu". I rodzi się kolejne pytanie - czy te atrybuty maja miec możliwość ustawiania odrębnych wartości w poszczególnych urządzeniach? Powiedzmy mam 5 mikrotików - 4 robią jako PPPoE a jeden serwer VPN. Wszystkie maja typ urządzenia mikrotik, 4 mają włączoną właściwość PPPoE a jeden VPN_PPTP. Na kilku tablicach z małą ilościa danych fajnie się cos takiego obsłuży (dodając np widoki), ale nie możemy przesadzić z ilościa tablic bo poginiemy w ich gąszczu. Juz teraz jest ich ponad pięćdziesiąt...

!DSPAM:49a538e9115171336712104!

Przydałyby się grupy dla urządeń. Nie wszyskie w końcu urządzenia to bedą NAS-y.

...

to tez nie jest zly pomysł bo tak jak powiedziałem moze byc urzadzenie ktore

bedzie nasem, routerem i czyms jeszcze naraz... :/

Rozwiń myśl o grupach:> Jedno jest pewne, nie widze rozwiazania, w stylu dodawania urzadzen do grup, powinno sie to robic z karty urzadzenia i na jego karcie powinna widniec lista grup do ktorych nalezy dane urzadzenie z mozliwoscia latwego wywalenia tego...

Nie wiem juz sam ;)

---

Nie ważne czy przypisywanie do grup bedzie tradycyjne czyli identyczne jak w przypadku komputerów czy jakoś inaczej na zasadzie checkboxa ktorego zaznaczenie przypisze urządzenie do wbudowanej (predefiniowanej) w LMS grupy NAS ważne żeby potem łatwo mozna było wyciągnac inforamcje o wszystkich urzadzeniach ktore funkcje nas spełniaja czy to w skyptach czy lmsd itd jakoś trzeba w końcu te urzadzeniapracujace jako NAS odfiltrować od innych urządzeń

Dariusz Kowalczyk

!DSPAM:49a54589126995315134984!

Michał Gacek wrote:

wydawalao mi sie ze bylo tego wiecej ;) no ale dobra, trzeba bedzie cos ustalic na temat właśnie clients.conf, radius moze czytac te ustawienia z tabeli i nawet jest to wskazane, problem polega na tym ze przy kazdej zmianie czy to w clients.conf czy w tabeli nas trzeba zrestartowac freeradiusa, proponuje zapisywac gdzies hasha tabeli nas, i porownywac go przy przeładowaniu, jeżeli jest rózny od poprzedniego, restart radiusa...

no może być i tak, można po prostu gdzieś timestampa ostatniej zmiany zapisywać i porównywać, albo po prostu przeładowywać wraz z Przeładowaniem, ale podejrzewam że chodzi o zminimalizowanie problemu rozłączania sesji?

druga sprawa to format db to na bank bylo poruszane proponuje aby zrobic to na widokach mysql, pytanie co z polami których lms jeszcze nie posiada... czy można zrobić półwidok-półtabele...?? chyba nie ;), trzeba bedzie dolozyc pare tabel i dopiero znich zrobic widok w standardzie radiusa...

mogą być widoki, ale najpierw trzeba zrobić resztę

Co do urzadzeń w ogóle jestem za tym aby zrobić przy okazji rewolucję, i dac mozliwosc wyboru z listy rozwijalnej typów urządzenia, np router border gateway nas pppoe koncentrator, itp itd. tego brakuje od dawna, a skoro LMS ma być frontendem, no to akurat tego mu dobitnie brakuje... to samo bym proponowal zrobić z komputerami, zmienic wogóle nazewnictwo na Urządzenia klienckie i rozgraniczac na: Komputer stacjonarny, laptop, palmtop, bramka voip, ap client,....

No jeśli miałaby być rewolucja, to wszystkie urządzenia w tym komputery powinny być w tabeli devices z określonym typem, a nodes to powinny być same adresy. Ale to chyba byłaby zbyt wielka zmiana jak na możliwości obecnych deweloperów. Trzeba uważać, żeby nie utracić prostoty obecnych rozwiązań w pogoni za nowymi funkcjami.

Proponuje rowniez zrobic tabele attributes, i tam np umieszczac rozne atrybuty, np w formacie typ urzadzenia:nas, router....| typ atrybutu:checkbox, lista rozwijalna | values: wartosc(i). dzieki temu jak wybierzemy np nas pojawią nam się dodatkowe opcje typu wlasnie pola ports itp itd...

można tak do tego podejść.

Michał Gacek wrote:

załózmy że mamy te grupy i dla netdevices i dla nodes osobne zestawy grup trzeba je zrobic na zasadzie customerassignments. czyli mamy dodatkowe 4 tabele netdevicesgroups nodesgroup i nodesassignments i netdevices assignments o ile dobrze pamietam wiazemy je relacjami z nodes i netdevices. Problem naprawde jest z atrybutami, opcjami dla tych grup, druga sprawa ze np 2 urzadzenia nasy moga miec np 2 rozne secrety czy community, i to jest problem przy ktorym niestety grupy odpadaja bo gdzie wtedy zapisac te wartosci??

ALEC moze ty masz jakis pomysl?

Ja słabo znam radiusa, a tym bardziej jego zaawansowane zastosowania, dlatego nie potrafię odpowiedzieć wprost. Nie myśl jak to będzie wyglądało w bazie danych, przedstaw wymagania co do interfejsu, a bazę się wymyśli, choćby to miało być i 15 dodatkowych tabel.

malpi wrote:

ja proponuje rozwinąć rozwiązanie które kiedyś zrobiłeś dla mnie :)

Jest o tyle fajne, że radius czyta sobie "na żywo" z bazy LMS loginy/hasła i sprawdza czy klient jest podłączony do prawidłowego koncentratora (urządzenia sieciowego w lms). Dodatkowo na MT (oczywiście może to być dowolny koncentrator) sprawdzane jest czy dany mac może się podłączyć do tego ssid (ssid=nazwa urządzenia sieciowego w LMS) oraz zakładana jest kolejka SQ (2,5x download 1,5x upload - to akurat wynika ze specyfiki taryf które sprzedaje; ostateczne cięcie pasma+NAT mam na głównym routerze) Działa to rewelacyjnie od +-2 lat na kilkuset userach.

No właśnie tak, problem jest z bardziej zaawansowanymi sprawami oraz z clients i nas.

Dariusz Kowalczyk - Webvisor wrote:

Dlatego od razu skupiłbym się na lmsd a nie na skryptach

najpierw skupmy się na frontendzie ;)

On Wed, 25 Feb 2009 20:31:41 +0100, Dariusz Kowalczyk - Webvisor dariusz.kowalczyk@webvisor.pl wrote:

dany mac może się podłączyć do tego ssid (ssid=nazwa urządzenia sieciowego w LMS) oraz

a co jak masz rb 433 i 3 anteny sektorowe bo ja tak mam i tutaj sie zaczynaja schody ogolnie brak w lms rozszezonego wsparcia dla mt

On Wed, 25 Feb 2009 21:31:08 +0100, Dariusz Kowalczyk - Webvisor dariusz.kowalczyk@webvisor.pl wrote:

A co jak masz vlany i np 16 SSID ? Wsparcie powinno moim daniem być do standardu wifi jako takiego. A większość komercyjnych AP ma wsparcie dla 2 serwerów radius i 16 ssid (ssid/ per vlan)

racja ze nalezy trzymac sie standardow ale w lms brak ogolnie wlasnie wsparcia dla urzadzen wifi a najbardziej by sie przydala obsluga anten w urzadzeniu gdyby to bylo juz dawno wymyslil bym skrypt do tworzenia acceslistyna mt wlasnie z lmsa

On Wed, 25 Feb 2009 21:56:13 +0100, adminnistrator admin@toszek.com.pl wrote:

Pobaw się Generatorem plików konfiguracyjnych (lms-mgc)

pisz pod postami wygodniej sie czyta na marginesie samo mgc nic mi tutaj nie da potrzeba odpowiednich pol w bazie i w gui lmsa

W dniu 25 lutego 2009 21:31 użytkownik Dariusz Kowalczyk - Webvisor dariusz.kowalczyk@webvisor.pl napisał:

Dlatego apeluje skupmy się na standardach bo nic z tego nie będzie.

zdecydowanie sie zgadzam powiedziałem ze zrobie radiusa, ale nie kazde widzimisie chce cos zrobić od a do z i zeby nie musiało to byc 20 razy poprawiane, aby było według standardów i ogolnych naszych oczekiwan

P.S wyłaczam sei z konwersacji na jakies 4 dni bo jade na MUMa do pragi ;)

Pozdrawiam

!DSPAM:49a6406061795750622685!

Dariusz Kowalczyk - Webvisor wrote:

czy ktoś ma argumenty przeciwko temu aby zrobić wreszcie pierwszy mały kroczek co by ALEC wiedział co robić:

1. Zrobić grupy dla urządzeń, w tym jedna predefiniowana na stałe o nazwie NAS

Tak się zastanawiam, czy to nie powinny być grupy adresów urządzeń. Urządzenie może mieć wiele adresów (interfejsów) i każdy pełnić inną funkcję, ale może bredzę?

do wsparcia NAS moim skromnym zdaniem wystarczy dodanie kilku pol o ktorych dzis rozmawialismy tj.: przydal by sie checkbox przy urzadzeniach (adresach ip ?) nas=0/1 oraz pola shortname, secret i nastype.

A gdzie wpiszesz adresy serwerów radius ? Będziesz je wpisywał recznie do kazdego urządzenia czy jako zmienna do ui i kot ja tam bedzie szukał?

Moim zdaniem lepszym rozwiązaniem jest wprowadzeni grup do urządzeń, predefiniowanie grupy NAS w której bedzie miejsce na zdefiniowanie 2 serwerów nas dla całej grupy. Grupy w urządzeniach i tak się przydadzą także do innych celów. To czy przynależność do grupy robić tradycyjnie jak w przypadku komputerów zrobione czy na zasadzie checkboxa to już sprawa ergonomii.

Dariusz Kowalczyk

!DSPAM:49a68d83134381804284693!

On Thu, 26 Feb 2009 15:30:37 +0100, Robert wrote

...

A gdzie wpiszesz adresy serwerów radius ? Będziesz je wpisywał recznie do kazdego urządzenia czy jako zmienna do ui i kot ja tam bedzie szukał?

zeby cokolwiek odpytalo radiusa musisz mu podac jego adres wiec do czego maja sluzyc adresy serwerow radius skoro bez wpisania tych adresow z palca w poszczegolnych urzadzeniach i tak sie do tego nie odwolaja ? no chyba ze zupelnie nie rozumie o co Ci chodzi, czego nie wykluczam ;) -- Robert CyberM

Gdzieś administrator musi przechowywać dane o serwerach radius, skoro w konfiguracji dhcp wpisuje się serwery dns to dosyć logiczne wydaje się aby w konfiguracji grupy NAS były wpisane adresy serwerów radius. Choćby po to żeby np wygenerowac sobie łatwo konfiguracje do AP i wrzucić ja przez snmp do niego czy ręcznie przez telnet. Ja tak mam zrobione że wszystkie radiomodemy maja aktualizowana konfiguracje przez snmp, upgrade firmwareu przez snmp i to wszystko lmsd+skrypty. Więc jak bedą te radiusy jawnie zdefiniowane i przypisane do grupy to i zostana wysłane konfoguracje do konkretnych urządzeń.

Oczywiście można sobie napisać na kartce serwery radius i recznie je konfigurowac ... ale mamy sobie życie ułatwiać.

Dariusz Kowalczyk

teraz to do mnie przemawia w pelnej rozciaglosci :) podziel sie tutaj swoimi rozwiazaniami (po co robic cos na nowo skoro juz to masz). wykorzystanie snmp jest faktycznie trafnym kierunkiem. --

Tyle że mało komu się to przyda pewnie bo my jako radiomodemów dla klientów wyłącznie używamy Tsunami Mp11a firmy Proxim Wireless. Tu na liście 99% to użytkownicy Mikrotika który możliwości ma 100 razy większe, nikt tego nie kwestionuje, ale przez to zarządzenia nim przez snmp będzie zapewne 100 razy bardziej skomplikowane ale pewnymi potrzebnymi funkcjami na pewno się da.

Poniżej przykładowy fragment konfiguracji instancji z modułem hostfile który tworzy plik konfiguracyjny do wrzucenia przez snmpset dla Tsunami MP11a 5012-SUR/5012-SUI.

Ten fragment konfiguruje radiomodem jako router, wybierając region PL, ustawia adresy publiczne na wanie i na lanie, konfiguruje wbudowany w urządzenie serwer dhcp i go włącza, ustawia limity prędkości, konfiguruje wbudowanego klienta tftp, itd, itp. I to wszytko w kilka sekund :-).

Wykorzystane są widać tutaj dosyć solidnie dostępne zmienne z modułu hostfile ktory jako najpotężniej wyposażony moduł lmsd potrafi wygenerować konfiguracje do prawie wszystkiego. Jedyny problem to nie da się na dzień dzisiejszy trywialnie wyciągnąć z lms przypisanej klientowi prędkości inaczej jak karkołomnymi kwerendami.

p.s. U W A G A !!!! Żadna kobieta nie ucierpiała przy tworzeniu tej konfiguracji.

:-)

Dariusz Kowalczyk

Dnia czwartek, 26 lutego 2009 21:28, Michał Gacek napisał:

Panie Robercie mi osobiście wydaje się, że skoro chcesz zrobić tego

jestesmy tu na Ty wiec daruj sobie tego Pana :)

radiusa, to prosze stosuj sie do tego co uzytkownicy oczekuja, bo to dla nich glownie to jest, wlasnie po to powstał ten wątek, i wiele wczesniejszych aby ustalic co komu jest potrzebne, sklecić to w całość. A Pan jak do tej pory tylko neguje potrzeby innych, zupelnie jakby chiał Pan wprowadzić na siłe swoje rozwiązanie, przy jak najmniejszych przeróbkach... Nie tędy droga...

jestem jednym z uzytkownikow wlasnie, uzywam na codzien lmsa i mt (i troche innych gratow) jak wiekszosc zainteresowanych. nie neguje niczego tylko pisze co juz mozna wykozystac nie trawiac sil na robienie czegos na sile. to nie maja byc moje rozwiazania tylko nasze. ostatnio byla tu debata o dzieleniu sie kodem itd. korzystam z dobrodziejstw lmsa i postanowilem sie czyms podzielic z reszta (moze ktos postapi podobnie).

ALEC sam przyznal ze nie ma pojecia o radiusie wiec to raczej nie znim ustalaj ficzery, ALEC ma decydowac o tym jak rozwiazanie bedzie zintegrowane i o ewentualnych nazewnictwach

i wlasnie dlatego radiusem zajalem sie ja,nie twierdze przy tym ze robie to najlepiej. robie to tak zeby bylo skuteczne, proste we wdrozeniu i niezawodne z naciskiem na to ostatnie. za czesc rzeczy zdecydowalem sie Alecowi zaplacic, czesc mialem gotowe wczesniej, czesc trzeba dorobic.

P.S. nie będe sie juz z panem kłocił na temat co ma radius czego nie ma, czy cos slyszalem, widziałem, czy wprowadziłem, o tym czy checkrad trzeba przerabiac czy nie, ja musiałem, nie jest to w tej chwili miejsce na taka polemike.

a klucisz sie ze mna ? mialem wrazenie ze wymieniamy poglady z korzyscia dla wszystkich.

Najważniejsze jest teraz ustalenie potrzeb, i omówienie integracji, jeżeli nie chcesz realizować naszych potrzeb to się po prostu nie udzielaj.

urazona duma czy jak ? przeciez omawiamy potrzeby, jesli uwazasz ze wypisanie ze czesc z tego co chcesz robic juz jest zrobione jest zle to pis lmsa od zera bo poco korzystac z istniejacej funkcjonalnosci. zasoby ludzkie nalezy szanowac miedzy innymi przez madre wyznaczanie celow i drog ich realizacji.

Skoro projekt freeradius uznal ze preferowana metoda na konfigurowanie nasow radiusa jest tabela nas, TO TAK POWINNO BYC

wcale tak nie uznal, jest to mozliwe rozwiazanie ale nie zmienia funkcjonalnosci. RADIUSA i tak trzeba "przeladowac" po kazdej zmianie w tej tabeli.

LMS ma być kombatybilny z radiusem, a nie protezą!!!

a tak chcesz to robic ?

Zaraz po wprowadzeniu podstaw statystyki powinny być kompatybilne z radiusem, chociaz dalece im do funkcjonalnosci i przejrzystości jaką oferuje np ara

statystyki to moim zdaniem odrebna kwestia. radius zapisuje sobie dane do bazy kiedy i jak to bedzie obrobione nie jest kluczowa sprawa w kontekscie wykorzystania radiusa do obslugi sieci. zwyczajnie te statystyki nie maja zadnego wplywu na to co ma byc robione choc oczywiscie jestem za ich wykorzystaniem... tyle ze nie wszystko na raz

LMS powinien miec opcje decydujace o lastonline time dla interim-update uzywanych w nasach, po to aby po zadanym czasie gdy baza nie jest aktualizowana, informował o odłączeniu kompa, myśle że nawet lepsze byłoby aby oprzec to na tabeli radacct całkiem, niz protezowac to dodatkowym insertem przy post-auth czy tam accounting, a jezeli juz nawet to powinien byc kreator to skonfigurowania sql.conf

a co tam chcesz konfigurowac, wychodzi na to ze beda dwa gotowe pliki dla mysql i postgresql (zapytania do bazy roznia sie skladnia). radacct... accounting.. wiesz o czym piszesz ? bo to co napisales brzmi jakos "bulki sa pyszne ale bulki sa beee wiec zjedzmy bulke"

To wszystko co przyszło mi dogłowy na tą chwile

teraz podeslij rozwiazanie problemu: koniec limitu danych=mniejsza predkosc bo pisales nie tak dawno temu ze to proste i masz rozwiazanie

Pozdrawiam

ja rowniez, bierz troche luzniej wymiane opinii czy pomyslow bo szybko sie zestarzejesz. pisze serio robie w tej branzy ~15lat i wiem ze trzeba miec troche dystansu do roboty zeby nie nabawic sie wylewu ;)

...

Jedyny problem to nie da się na dzień dzisiejszy trywialnie wyciągnąć z lms przypisanej klientowi prędkości inaczej jak karkołomnymi kwerendami.

ktore sa juz zrobione i jak skoncze zalozony plan stana sie jak sadze czescia lmsa publicznie dostepna. dziala to u mnie produkcyjnie i wydaje sie ze jest ok. przetestowalismy chyba wszystkie dostepne mozliwosci konfiguracji taryfy/wielu taryf dla jednego, wielu, powiazanych i nie z taryfami komputerow. -- Robert CyberM

Byle dało się to zrobić przez lmsd bo tylko on ma przyszłość moim zdaniem :-)

Dariusz Kowalczyk

On Thu, 26 Feb 2009 22:32:17 +0100, Robert wrote

...

Poniżej przykładowy fragment konfiguracji instancji z modułem hostfile który tworzy plik konfiguracyjny do wrzucenia przez snmpset dla Tsunami MP11a 5012-SUR/5012-SUI.

jako inspiracja jest ok :)

zdecydowanie tylko jako inspiracja, komendy snmpset/snmpget nie należą do specjalnie czytelnych :-) a po jakimś czasie bez opisu stają się całkowicie niezrozumiałe

Ale dosyć o tym bo zbaczamy z tematu.

Nie zauważyłem żeby ktoś zgłaszał sprzeciw przeciwko wprowadzeniu grup do urządzeń i predefiniowanej na stałe grupy NAS (w której powinny się znaleźć miejsce na wpisanie 2 adresów ip serwerów radius), co Ty na to ALEC? Mógłbyś się za te grupy na razie zabrać.

Ciebie jak zawsze interesują tylko konkrety a to malutki konkret i do końca daleko ale konkret inaczej nie ruszymy.

Dariusz Kowalczyk

Co do grup to należy się zastanowić nad dwoma aspektami:

• czy w przypadku urządzeń nie byłoby wygodniej zastosować jakiegoś

innego interfejsu ich grupowania (definiowania typu/funkcji jaką ma spełniać)?

• czy grupowanie (typowanie) nie powinno być robione na poziomie adresów

urządzeń?

Nie kombinowałbym tuz grupowaniem adresów, wiele miałem sytuacji że grupy w urządzeniach były by jak złoto ale nigdy żeby potrzeba było grupować ich po adresach ip zwłaszcza że do grupowania po adresach można skorzystać np z przynależnośći tych adresów do konrektnych sieci i po tym filtrować

dlatego wprowadzamy po prostu analogiczne grupy jak w komputerach żeby zachować jednolita ergonomię projektu, tak to wyjdzie taka nieintuicyjna pokraka ergonomiczna

Dariusz Kowalczyk

W dniu 27 lutego 2009 10:56 użytkownik Robert cyberm@sarocom.net napisał:

tak wyglada tabela do obslugi NAS:

/*

• Table structure for table 'nas'

*/ CREATE TABLE nas ( id SERIAL PRIMARY KEY, nasname VARCHAR(128) NOT NULL, shortname VARCHAR(32) NOT NULL, type VARCHAR(30) NOT NULL DEFAULT 'other', ports int4, secret VARCHAR(60) NOT NULL, community VARCHAR(50), description VARCHAR(200) );

proponuje gdzies na poziomie lmsa, umiescic zmienna najlepiej w phpui np default_community i default_secret ttd, aby np w razie gdy nie wpiszesz community przy nasie wpisze ta standardowa wartosc, moze sie przydac w momencie zmieniania tych parametrow w calej sieci...

!DSPAM:49a7c07357734062814199!

Robert wrote:

...

...

tak wyglada tabela do obslugi NAS:

koledzy tak nad tym mysle i prosze Was o opinie. moze w weekend udalo by mi sie znalesc wiecej czasu i moglbym dorobic to w gui. zastanawiam sie tylko czy przypisac opis NAS'a to urzadzenia jako takiego czy do jego adresu IP (wiele IP wiele mozliwych NAS ?) jak to widzicie ?

problem zwiazany jest w pewnym sensie z grupami urzadzen, tzn czy grupowac cale urzadzenia czy ich IP. sadzilem ze wystarczy grupowac urzadzenia w zaleznosci od ich przeznaczenia ale z drugiej strony w specyficznych sytuacjach poszczegolne adresy (interface) IP urzadzenia moga pelnic rozna role. np. jeden interface moze byc NAS'em ale inny juz tylko odbierac sygnal w szkielecie (upraszczajac) wiec ich przeznaczenie bedzie rozne mimo ze fizycznie to to samo urzadzenie.

No właśnie mam te same wątpliwości, bo zobacz do pierwszego postu w wątku tam jest podsumowanie starych ustaleń i pisze, że shortname, secret oraz flaga NAS mają być przypisane do adresu urządzenia.

moze nei wielu osobom sie to przyda ale po co robic kompromisy grupowanie wg adresow nie jest według mnie eleganckim rozwiazaniem. bo skoro robimy grupy dla urzadzen to moze warto spojrzec w przyszlosc moze byc grupowanie urzadzen, dla ktorych akurat ip wazne nie jest...

jest jeszcze jedna kwestia. mianowicie interface w urzadzeniu nie dosc ze moze miec rozny adres IP to moze tego adresu nie posiadac wcale a posiadac np. nazwe co bedzie przydatne w przypadku checi przypisania czego do konkretnego portu. oczywiscie port mozna przypisac juz teraz ale trzeba wszystkie na wszystkich urzadzeniach zwyczajnie pamietac i wpisywac z glowy a nie pobierac z bazy.

przy okazji teraz port to numer kto jest za zmiana tego na nazwe ? w czym rzecz w switchu nie ma problemu z numerem (numery portow to niejako naturalne rozwiazanie) ale w przypadku np bazy z wieloma ssidami (a wiec niejako portami) trudno je nazywac numerycznie. reasumujac jestem za tym zeby w polu port zrodlowy/docelowy mozna bylo wpisac zarowno "1" jak i "ether1" co moim zdaniem zdecydowanie zwiekszy czytelnosc

tak tylko co w sytuacji gdy na jednym interfejsie ma się powiedzmy 4 adresy :D:D ciężko jest trafić w złoty środek...

!DSPAM:49a80556125111804284693!

No jak by tak popatrzec na firmowe gotowe rozwiązania dostępnę na rynku to AP czy kontrolery wifi czy switche zarządzalne nie maja po kilka adresów ip tylko jeden. Nawet switche się stackuje i wszystkie połączone razem

troche w tym prawdy jest

Dlatego sądzę że tam gdzie można zrobic ukłon w stronę rozwiązan niestandardowych nie robiąc galimatiasu w interfejsie tam należy go zrobić w innych przypadkach zwyczajnie zalecałbym "olewanie" niestandardowych rozwiązań bo nigdy nie dojdziemy do niczego.

czyli opcje typu "przeznaczenie" oraz pola potrzebne dla obslugi NAS przypisujemy do urzadzenia calkowicie wykluczajac interface'y no moze poza boxem NAS=0/1 ? trzeba by to ustalic/doprecyzowac zeby zaczac cos robic na gotowo.

W dniu 2 marca 2009 00:58 użytkownik Robert cyberm@sarocom.net napisał:

jako ze dzis troche zaczalem klecic gui do tego mam pytanie. typ NAS'a zostawic jako pole do wpisania wartosci czy select'a z opcjami dostepnymi domyslnie we freeradiusie ? pierwsze napewno elastyczniejsze (tak zrobilem na ta chwile niejako z rozpedu) drugie wygodniejsze bez mozliwosci pomylki przy wprowadzaniu (liste mozna by aktualizowac w razie potrzeby przy okazji upgrade samego lmsa).

mysle ze pole narazie wystarczy, dorobienie listy to pikuś... moze poczekać

druga kwestia. w wersji 1.x.x baza NAS pobierana jest tylko przy starcie czy to z pliku czy sql. zeby ja zaktualizowac trzeba ubic proces i z tego co widze nie ma mozliwosci zrobienia tego inaczej. w wersji 2.x.x jesli dobrze rozumie Alana DeKok'a da sie autoryzowac nowo dodane NAS'y w locie bez ubijania freeradiusa. jako ze ma byc uniwersalnie bedzie tak zeby dzialalo z kazda wersja freeradiusa czyli wariant 1. --

zawsze mozna zrobic zmienna gui, bo nie widze czemu ktos mialby rezygnowac z tego dobrodziejstwa, baa skrypt moze wykrywac jaka wersje sie ma i adoptowac sie do niej?

!DSPAM:49ab24f0187389813612796!

Dnia 26 lutego 2009 10:32 "A.L.E.C" alec@alec.pl napisał(a):

Dariusz Kowalczyk - Webvisor wrote:

...

czy ktoś ma argumenty przeciwko temu aby zrobić wreszcie pierwszy mały kroczek co by ALEC wiedział co robić:

1. Zrobić grupy dla urządzeń, w tym jedna predefiniowana na stałe o nazwie NAS

Tak się zastanawiam, czy to nie powinny być grupy adresów urządzeń. Urządzenie może mieć wiele adresów (interfejsów) i każdy pełnić inną funkcję, ale może bredzę?

U mnie to wyglada to tak, że urządzenie ma 1 adres IP (czasem 2) ale za to jest na nim kilka interfejsów(=NAS/koncentrator pppoe)

!DSPAM:49a68d50133191711816961!

w duzym skrocie

1. login/hasło

nie wymaga zmian w lmsie

2. mac-address (różne urządzenia wymagają separacji odmiennych separacji

znaków ":" :-" "" - co wtedy?) 3) taryfa down/up (mogą być potrzebne różne jednostki)

nie wymaga zmian w lmsie

4. nazwa koncentratora do którego może się podłączyć autoryzowane

urządzenie (co w przypadku, kiedy wybrany klient ma mieć możliwość podłączania się do wielu NAS - jak w sieci komórkowej)

nie wymaga zmian w lmsie moze poza sytuacja kiedy klient ma sie moc autoryzowac do wielu sprecyzowanych wezlow

5. accounting

nie wymaga zmian w lmsie poza wizualizacja tego co radius zapisuje w bazie sql

6. "ptaszek" przy komputerze: Simultaneous-Use = X

calkowicie zbedne, powinno byc na sztywno = 1

7. limit ilości danych, które można ściągnąć w danym okresie

rozliczeniowym; w przypadku wykorzystania limitu ograniczenie prędkości do 1/20 pasma albo 30/30kbps :)

limit da sie to zrobic w zasadzie mam gotowe rozwiazanie od strony radiusa, trzeba by wymeczyc ograniczanie pasma po przekroczeniu limitu. po zerwaniu sesji w wyniku przekroczenia limitu zamiast deny przydzielany bylby jakis minimalny transfer. musialbym to przemyslec a potem Alecowi zadac zrobienie stosownego zapytania sql

8. możliwość tworzenia dostępu czasowego w

godzinach/minutach - np. dla obsługi HOT-SPOT

da sie to chyba zrobic dosc latwo po dorobieniu odpowiednich pol w bazie i gui lmsa. jak znajde troche czasu to sprawdze to

Tyle ja już wiem, że potrzebuję/będę potrzebował, ale inni mogą mieć większe/mniejsze/odmienne potrzeby. Generalnie chodzi mi o to, żeby rozwiązanie było ELASTYCZNE.

zdecydowana wiekszosc tego co opisales nie wymaga zmian w lmsie badz wymaga zmien niewielkich. troche zaczelismy z Aleciem klecic w powyzszym temacie. mysle ze tych pare spraw ktore zostaly wymienione a ktore nie sa jeszcze zrobione dam rade z Aleciem popchnac do przodu. w relacji radius<>koncentrator 98% tego o czym pisales mam zrobione i przetestowane produkcyjnie (wraz z platnosciami smsem za dostep do hotspota). brakujace powiazania radius<>lms mysle da sie zrobic

P.S. Może ktoś ma pomysł jak dodawać "w locie" regułki firewall na routerze linuxowym z freeradiusem: kiedy klient dostaje od radiusa "accept" automatycznie dodają się regułki iptables dla jego IP (przy założeniu, że nie mamy na tym routerze koncentratora ppp) ;-)

tak to chyba tylko w erze ;)

W dniu 25 lutego 2009 23:15 użytkownik Robert cyberm@sarocom.net napisał:

nie wymaga zmian w lmsie moze poza sytuacja kiedy klient ma sie moc autoryzowac do wielu sprecyzowanych wezlow

na sztywno to wiesz co mozna zrobic,sa sytuacje w ktorych simultaneous-use nie powinien byc na sztywno, ba dla swieżych osob moze być nie lada problemem, poczytaj o stalled-sessions, jedzeli podlacza sie ludkow do wyspecyfikowanego koncentratora, bez mozliwosci migracji po bazach nie powinno sie uzywac tego w ogole, koncentratory z reguly maja opcje do sprawdzania zduplikowanych logowan.

Simultaneous-use to bardzo ciezki temat chyba nawet poruszalem go wczesniej trzeba zadpac o to aby w razie stalled-sessions radius zalogowal sie na koncentrator sprawdzil czy faktycznie, sesja jest zajeta, jak nie to wywalil stalled-session z bazy i dopuszcza usera jezeli jest to wtedy robi mu deny.

Pozdrawiam

!DSPAM:49a5e494303146258220944!

W dniu 26 lutego 2009 04:06 użytkownik Robert cyberm@sarocom.net napisał:

mam tak od paru juz lat i nie wiem w czym widzisz problem, logowanie sie po 100x na jeden login bo klient czegos nie ogarnia nie jest rozwiazaniem, to tez nie bedzie poprawnie dzialalo choc by z uwagi na routing na jeden adres do wielu sesji

simultanous-use ma byc wyborem nie przymusem tak jak mowilem jezeli kontrole robisz wzgledem jednej bazy to nie ma problemu, problem robi sie jak na 2 raznych bazach zaloguje sie ten sam user, wtedy niezbedny jest dobrze skonfigurowany checkrad, ktory nie dziala ze wszystkimi urzadzeniami itp itd...dlatego uwazam ze powinnismy unikac problemow niz je stwarzac ludziom

do tego sa stosowne mechanizmy bez rzezby

tak checkrad, ktory jest wlasnie rzezba jezeli w ogole czytales jego kod... pozatym np zeby dzialal z mikrotikami trzeba go mocno zmodyfikowac.

!DSPAM:49a6401a60402042218820!

nie tak dokonca kolego wystarczy ze radius bedzie wrzucal odpowiednie dane do bazy tak jak np zmuszenie go do aktualizacji lastonline, a pozniej tylko skrypcik ktoiry bedzie sprawdzal te pole i wykonywal zadane operacje, nie ma rzeczy nie mozliwych kwestia inwencji..

jaki to ma miec zwiazek z radiusem i sql ? gdzie tu upraszczanie dzialania ? musialbys miec ten swoj skrypcik dzialajacy nonstop wiecznie sprawdzajacy baze i dopisujacy/kasujacy jakies wpisy w iptables. moze dla 10 klientow to nawet zadziala ale dla 100 juz mam watpliwosci co do wydajnosci (a wielu tutaj przekroczyla dawno 1000 klientow). inna rzecz, tak ja widze idee wdrozenia radius pozenionego z lms juz na etapie bazy danych, calosc ma zminimalizowac przeladowania czy inna rzezbe na rzecz mozliwie bezawaryjnego mechanizmu bez zbednych udziwnien. koncentrator<>radius<>baza lms niczego nie nalezy tu udziwniac no ale moze Cie po prostu nie rozumie...

p.s. oczywiscie jak ktos bedzie chcial miec przy tym 200 skryptow i skrypcikow to zaden problem moze sobie naklepac takich wynalazkow ile dusza zapragnie ;-)

p.s.2 wykorzystanie pola "limit danych" w taryfie w miedzy czasie opanowalem mimo skromnej raczej znajomosci sql. nie mam pomyslu jak przydzielac po wykorzystaniu limitu np. 64kbps zamiast odmowy przy logowaniu jak jest normalnie. zeby windows wyswietlal komunikat z koncentratora to mozna by wyswietlac np "nie mozesz sie zalogowac bo wyczerpales limit" ale zadziala to z tego co wiem na wszystkim poza windowsem, moze ktos wymysli jakies sensowne rozwiazanie :-)

przeciez nie mowie o tym zeby je napisac mowie o tym ze to mozliwe, ale napewno nie jest to zadanie dla lmsa, lms ma spelniac wymagania porzadnego frontendu sprosta modyfikacja tabeli nas, powtarzam konfiguracja clients.conf powinna zostac porzuconana na rzecz tabeli nas

w wolnej chwili sie nad tym pochyle, rozmawialem dzis na ten temat z Aleciem i zmian w samym lmsie wiele nie trzeba

jest na to rozwiazanie, ponoc mozna zmienic te komunikaty w windowsie ;), co do limitu radius natywnie to wspiera, do tego miedzy innymi jest tabela accounting, po wybraniu odpowiednich atrybutow radiusa, on sam zbiera dane, i przy nastepnym logowaniu jak jest limit to ustawia nowa predkosc, pod warunkiem ze sie korzysta z podziału juz na samym koncentratorze, polecam manuala do radiusa....

windows nie obsluguje tych komunikatow a szkoda jesli znasz rozwiazanie ktore je wyswietla w windowsie to podziel sie wiedza. jesli wiesz jak zmienic predkosc po wyczerpaniu np. limitu przesylanych danych to podziel sie wiedza. ja takiego rozwiazania nie znam nie wydaje mi sie to mozliwe (bez jakiejs specyficznej rzezby) mam radiusa od paru lat, obecnie produkcyjnie podzial pasma na koncentatorach (dane z radiusa) i jesli przypisze limit danych w taryfie (tez mam produkcyjnie) to po wyczerpaniu limitu dostaje login incorrect i jakos nie widze zeby moglo byc inaczej. jesli wiesz jak to zrobic to napisz jak a nie ze widziales/slyszalesz

co do blokowania neta po wyczerpaniu limitu jest to zabronione przez uke, w ogole zeby zablokowac klientowi neta, musisz mu wysłać 2 ponaglenia do zapłaty, inaczej nie masz prawa, tak samo jest z tel komorkowymi

jesli sprzedajesz pakiet limitowany iloscia danych to klient placi za mozliwosc przetransmitowania okreslonej ilosci bajtow i koniec. wykorzystuje limit czym kontrakt wygasa (jesli to jednorazowa paczka danych)/czeka na reset limitu (jesli jest np. miesieczny przydzial). zanim napiszesz ze czegos nie wolno najpierw przeczytaj kiedy ma to miejsce i w jakich okolicznosciach... w skrocie jak kupisz 100x wody to po jej wypiciu nadal ma woda plynac tylko wolniej ??

Gaco , for fak sejk :) ale nie rzucaj nam w gębę za każdym razem tym "zgodnym w 100% bla bla bla". Póki co niech będzie jakikolwiek. Nie od razu Kraków zbudowano...

!DSPAM:49a5e81e322206491211187!

Michal ma racje, wiec niech bedzie cokolwiek ale zmierzajace do pelnej zgodnosci i juz teraz nalezy obrac dobry kierunek.

zrozumcie ze bardzo wiele juz mozna miec nie psujac lmsa na sile. i wiekszosc z nas bedzie z tego bardzo zadowolona. piszesz o pelnej zgodnosci z radiusem ale czy wiesz ile opcji on oferuje i do jak wielu dosc specyficznych rozwiazan z ktorymi 99% uzytkownikow lmsa nigdy nie zobaczy nie mowiac juz o wykorzystaniu do czegokolwiek. sadze ze prace powinny zmierzac do osiagniecia tego z czego bedziemy realnie korzystac a nie tego co da sie uzyskac potencjalnie. po co mamy sie meczyc nad zrobieniem czego z czego z byc moze (a moze napewno) nigdy nikt nie skorzysta ? jak juz pisalem szanujmy zasoby ludzkie :) i nie starajmy sie robic obok czegos co juz jest gotowe.

Robert pisze:

...

Michal ma racje, wiec niech bedzie cokolwiek ale zmierzajace do pelnej zgodnosci i juz teraz nalezy obrac dobry kierunek.

zrozumcie ze bardzo wiele juz mozna miec nie psujac lmsa na sile. i wiekszosc z nas bedzie z tego bardzo zadowolona. piszesz o pelnej zgodnosci z radiusem ale czy wiesz ile opcji on oferuje i do jak wielu dosc specyficznych rozwiazan z ktorymi 99% uzytkownikow lmsa nigdy nie zobaczy nie mowiac juz o wykorzystaniu do czegokolwiek. sadze ze prace powinny zmierzac do osiagniecia tego z czego bedziemy realnie korzystac a nie tego co da sie uzyskac potencjalnie. po co mamy sie meczyc nad zrobieniem czego z czego z byc moze (a moze napewno) nigdy nikt nie skorzysta ? jak juz pisalem szanujmy zasoby ludzkie :) i nie starajmy sie robic obok czegos co juz jest gotowe.

Mialem na mysli to ze jesli LMS ma wspierac radiusa to nie-po-swojemu tylko powinien zmierzac do pelnej zgodnosci z RADIUSEM. Oczywiscie pelnej 100 procentowej jego (radiusa) funkcjonalnosci byc moze niewielu bedzie uzywalo/wykorzystywalo w LMSie ale w takim kierunku nalezaloby isc. Oczywiscie nie uwazam wcale, ze Twoje rozwiazanie jest zle lub niekompletne bo napewno wiele wnosi do tematu i bedzie bardzo przydatne ale nie starajmy sie na sile zawezac mozliwosci takiej funkcjonalnosci w LMSie. Dlatego pronuje na poczatek podstawowe rzeczy i w miare postepu prac kolejne rzeczy.

A tak ma sam koniec prosze Was o zaprzestanie polemiki a o skupieniu sie na potrzebnych ustaleniach bo o tym tutaj jest watek. Przypomne takze ze zobowiazalem sie sfinansowac ten projekt i jesli ktos czuje sie na silach takze dolozyc swoje "3 grosze" a jeszcze lepiej podzielic sie swoimi rozwiazaniami lepszymi lub gorszymi, to bedzie to mile widziane, ale o tym pozniej :)

Tak wiec prosze o ustalenia majac na uwadze pelna zgodnosc z radiusem, co bardzo sugeruje Michal, poniewaz jesli beda one w koncu poczynione to wtedy bedzie mozna rozmawiac o kosztach i rozpocznie sie prace.

Przemysław Kudyba pisze:

Dobra. Niech ktoś w końcu napisze treściwie i bez owijania, co dla niego znaczy "pełna zgodność z radiusem".

no to pierwszy z brzegu przyklad: simultaneous-use nie na sztywno...

przepraszam za lakoniczny skrot nt ale nie moge zacytowac wszystkiego co sie odnosnie simultaneous-use tutaj wczesniej napisalo.

Przemysław Kudyba pisze:

tdabek@go2.pl pisze:

...

no to pierwszy z brzegu przyklad: simultaneous-use nie na sztywno...

No ale nie poprzestawajmy na pierwszym z brzegu, resztę proszę.

Chodzi tutaj o to ze skoro radius daje pewne mozliwosci to LMS nie powinien ich ograniczac i tyle. Zalezy mi na tym zeby LMS potrafil zarzadzac radiusem w pelni wykorzystujac jego mozliwosci oczywiscie nie odrazu ale moze za pol roku, rok albo dwa i nie bedzie sie to wiazanlo z rewolucja kiedy za rok sie okaze ze ktos bedzie chcial wykorzystac jakas funkcjonalnosc radiusa a niestety aby to zrobic to bedzie trzeba LMSa wywrocic do gory nogami bo inaczej nie pojdzie tego zrobic.

Twoje wytyczne w sasiednim temacie sa takze cenne wiec napewno duzo wnosza do tego co chcemy widziec i traktowac je mozemy jako podstawe wyjsciowa a jak to zrobic to pomysla madrzejsze glowy ode mnie :)

Przemysław Kudyba pisze:

No i dochodzimy do sedna. Czy chcemy zrobić z LMS-a "fully featured" kontroler RADIUS-a (coś jak ara, dialupadmin, whatever),

Tak to chcialbym widziec docelowo na przestrzeni moze roku, a na poczatek podstawowe sprawy i mozliwosc etapowego dobudowywania funkcji/mozliwosci.

...

...

no to pierwszy z brzegu przyklad: simultaneous-use nie na sztywno...

ale to jedno pole w bazie radiusa i mozna to zrobic w 15 minut, nie widze problemu

...

No ale nie poprzestawajmy na pierwszym z brzegu, resztę proszę.

slusznie... w miare precyzyjne bo do radiusa mozna przesylac setki parametrow do ktorych wsparcie nikomu z nas sie nigdy nie przyda

Chodzi tutaj o to ze skoro radius daje pewne mozliwosci to LMS nie powinien ich ograniczac i tyle.

ale lms niczego nie ogranicza

Zalezy mi na tym zeby LMS potrafil zarzadzac radiusem w pelni wykorzystujac jego mozliwosci oczywiscie nie odrazu ale moze za pol roku, rok albo dwa i nie bedzie sie to wiazanlo z rewolucja kiedy za rok sie okaze ze ktos bedzie chcial wykorzystac jakas funkcjonalnosc radiusa a niestety aby to zrobic to bedzie trzeba LMSa wywrocic do gory nogami bo inaczej nie pojdzie tego zrobic.

rzecz w tym ze chyba nie rozumiesz jak dziala radius. lms nim nie zarzadza i nigdy tego nie bedzie robil. radius przelknie wszystko co mu podasz i niczego do tego nie trzeba przewracac do gory nogami.

Twoje wytyczne w sasiednim temacie sa takze cenne wiec napewno duzo wnosza do tego co chcemy widziec i traktowac je mozemy jako podstawe wyjsciowa a jak to zrobic to pomysla madrzejsze glowy ode mnie :)

zrobiona jest juz wiekszosc tego co wiekszosci jest/moze byc przydatne, kiedy to do Ciebie dotrze. jak bedzie calkiem skonczone to to opublikuje. Alec napisal bardziej zawile zapytania sql z ktorymi ja sobie nie poradzilem co uczciwie przyznaje co juz z nim rozliczylem. pozostalo dopisac obsluge paru niezbednych pol zeby mialo to rece i nogi i nadawalo sie do zamieszczenia w glownej galezi, o czym zreszta nie ja decyduje.

Przemysław Kudyba pisze:

Michał wspominał kiedyś, że chciałby żeby klikał u niego skrypt checkrad(.pl) , bo korzysta.

Jesli da sie to zrobic demonem to bedzie cudnie.

Robert pisze: [...]

numer konta podesle Ci na priv :)

Zgoda ;)