On Mar 1, 2018, at 11:45 AM, Dom Latter <freeradius-users@latter.org> wrote:
Hi, I have looked into our current script and ascertained that the vast majority of auth requests can be handled by a single SELECT query and some logic in perl.
That's good.
It is (essentially) only when we see a device for the first time that we need to update database tables and send emails.
I imagine that it will be easy enough to create a non-blocking mechanism for sending email, but out of interest, if we use perl, would it be such a big problem to send mail from the perl script given that the perl interpreter is threaded?
Yes. As soon as anything goes wrong with the email subsystem, the threads will lock one by one, and then the RADIUS server will go down. If you can write the Perl script so that it *always* runs within (say ) 1/10s, then it's probably OK. i.e. try to send the email, and if it doesn't successfully send immediately, bail out with an error. The alternative is to write the email details to a queue, and then have the mailer pick up messages. If the mail subsystem can poll a directory for queued messages, you can just place messages there, and rely on the mailer to eventually pick them up. The key thing to realize is that if mail is delayed, no one cares that much. If the RADIUS server goes down, then everyone complains.
As for the database updates I think we can take the performance hit of running them from within the script as they are infrequent - I don't have a metric immediately to hand but one every few minutes sounds about right. Or would you still strongly recommend making these DB updates "native" as well?
If it's one every few minutes, it's probably OK. Alan DeKok.