RADRELAY(8)

✨ RADRELAY — the FreeRADIUS Daemon girlies' guide 💅

okay so bestie, we're in section 8 of the manual (that's the admin/daemon section, iykyk) and the vibe here is... complicated. let me hold your hand through it 🫶

🌸 NAME 🌸

radrelay — Deprecated command. yeah. she's retired. gone but not forgotten. 💀

🎀 DESCRIPTION 🎀

so here's the tea: everything radrelay used to do? it got folded into radiusd itself. the glow-up was real. ✨

and one major perk of the merge — one single instance of radiusd can read multiple detail files, among other things. not me being obsessed with consolidation. 👑

also, the rlm_sql_log module does something similar, but for SQL queries instead. go check its man page for the deets, bestie. 📖

💖 REPLICATION FOR BACKUPS 💖

okay so picture this: lots of sites run multiple radius servers — at minimum one primary and one backup. and when the primary goes down, most NASes notice and switch over to the backup. main character energy from the backup, honestly. 💅

but here's where it gets messy 😭 — that switch means your accounting packets are now heading to the backup server. and some NASes don't even switch back to the primary when it comes back up. they just stay there. rude.

the fallout:

• accounting records get missed, and/or
• the administrator has to jump through hoops to combine the different detail files from multiple servers 🎪
• and the session database (radutmp, which is what radwho and simultaneous use detection rely on) gets out of sync 🫠

so how do we fix it? we "relay" packets from one server to another, so they both end up with the same set of accounting data. matching outfits. iconic. 🌈

see raddb/sites-available/buffered-sql for more information. ✨

🦋 BUFFERING FOR HIGH-LOAD SERVERS 🦋

imagine the RADIUS server suddenly gets a ton of accounting packets all at once. there may not be enough CPU power to process them all in a timely manner 😭. this problem hits especially hard when those accounting packets are headed to a back-end database. she's stressed. she's trying her best.

similarly — and this is the fun part — you might have one database tracking "live" sessions and another tracking historical accounting data. in that case, accessing the first database is fast, because it's small. accessing the second one may be slower, because it can contain multiple gigabytes of data. 😳

and the priorities are different too: writing to the first database in a timely manner is important, while data can be written to the second database with a few minutes delay without any harm being done. no rush, babe. 🍓

see raddb/sites-available/copy-to-home-server for more information. 🫶

👀 SEE ALSO 👀

• radiusd(8)
• rlm_sql_log(5)

💜 AUTHOR 💜

The FreeRADIUS Server Project — the legends themselves. 👑

okay that's the whole page, bestie, you ate that. this one's dated 23 October 2007 and it's from the FreeRADIUS Daemon manual set. slay, go read radiusd(8) next 💖✨🎀