A.L.E.C pisze:
Michał Gacek wrote:
boże, to że lms nie korzysta z tej tabeli nie znaczy, że inne narzędzie nie korzysta, to że lms jest za głupi żeby z niej korzystać no to już trudno, można zrobić zawsze opcje, dla ludzi którzy nie lubia nadmiarowości, zresztą accounting można wyłączyć z poziomu radiusa czy też samego nasa, wiec jedyne co zostanie to struktura dodatkowej bazy...
Dopóki LMS nie będzie umiał z tej tabeli skorzystać, jej struktura się w bazie nie znajdzie. Jeśli będzie komuś potrzebna, to sobie sam ją utworzy.
Nie widzi mi się też pomysł rezygnowania z dotychczasowych statystyk i przechodzenie na strukturę radiusową, ona po prostu jest mniej optymalna od naszej jeśli chodzi o bardzo dużą ilość danych. Kluczem jest nazwa komputera (UserName) - porażka. Dla postgresa można zrobić kilka triggerów, żeby przerzucić dane z tej tabeli do LMSowej, ale dla mysql musielibyśmy podnieść wymagania, bo triggery są od 5.0.2. Wtedy statystyki transferów byłyby w stats, a cała radiusowa reszta w radacct.
W takim razie warto rozszerzyć tabelę 'stats' o pola: type, ipaddr, sessionid. Wtedy będzie można za pomocą 'type' oznaczyć czy jest to SessionStart, InterimUpdate itd. 'ipaddr' przyda się do celów retencji połączeń, np. w sytuacji, gdy adresy IP komputerów są przydzielane dynamicznie. Za pomocą 'sessionid' będzie można łatwo wybierać dane dot. konkretnych sesji.
W takim rozwiązaniu nie trzeba modyfikować LMS, a jedynie zmienić format danych dot. statystyk w jakim radius będzie przesyłał dane do LMS.
Przykład: Początek sesji: type=1, dt=<aktualna_data>, upload,download=0, ipaddr=<adres_ip>, sessionid=asdf
Aktualizacja danych: type=2, dt=<aktualna_data>, upload,download=xxx, ipaddr=<adres_ip>, sessionid=asdf
Koniec sesji: type=3, dt=<aktualna_data>, upload,download=xxx, ipaddr=<adres_ip>, sessionid=asdf