classic.ISPforum.cz

Dovolím si otevřít tohle vlákno, které bych věnoval tipům na co nejvychytanější chod FreeRADIUS serveru. Samotný FR není žádný moloch a jedno ATOM jádro dokáže obsloužit řádově tisíce klientů s vytížením CPU v řádově procentech. Samozřejmě záleží na tom, zda-li logujeme interim updaty a v jakých frekvencích. Mimořádnou událost typu run na radius nepočítám, ale to se stává jednou za uherský blackout. Protože se občas setkávám s předsudky, týkající se strachu z nedostatečného výkonu FR serveru, dovolím si začít asi tou nejzákladnější věcí, která má na výkon FR vliv. Tím je zapisování do souborů, které je třeba okamžitě potlačit. Většina adminů jako první konfiguraci provede napojení na SQL. Pokud však zapomene potlačit vytváření souborové accouting struktury a tmp souborů, má na průser zaděláno.

Následuje pár postřehů z Evernotu ...

Jak zakázat vytváření logů do souboru (s)radutmp, radwtmp a raddact adresář, které zahlcují a zpomalují činnost FreeRADIUSu
* Pokud je nastaveno používání SQL, pak není důvod jakékoliv tmp a accouting soubory vytvářet.
* Jedná se o zakomentování direktiv v accouting sekci příslušné virtuální instance.


... a nyní proč FR vůbec vytváří tmp:

radwho
* Výpis aktuálních sessions, které se zaznamenávají na základě jakékoliv interakce s accoutingem.
* Čte pouze soubor /var/log/freeradius/sradutmp, nelze přesměrovat na /var/log/freeradius/radutmp (bug?), a samozřejmě nefunguje se sessions ukládaných do SQL.
* tmp soubory vychází z rlm_radutmp, viz http://wiki.freeradius.org/Rlm_radutmp#Configuration
* Ukládání do sessions do /var/log/freeradius/sradutmp, viz sekce accouting v konfiguraci příslušného virtuálního serveru FR2.
* Příklad výstupu:


radlast
* Historický výpis všech úspěšných autorizací.
* Čte soubor /var/log/radwtmp
* Příklad výstupu:


Díky za vaše tipy!