Issue with cuisql timing out on FR 3.12
Got a batch of FR server acting as our ORPS servers, two are FR 3.12 and two are 2.2.9. FR 3.12b config based upon 2.2.9 config as that;s been stable and hasn't changed for years. Fr 2.2.9 just works. With 3.12 however, since I brought them on line I've had problems with accessing a mysql CUI table. There's a scheduled backup of our mysql servers at 4:07 every morning. So I'm seeing Tue May 10 04:07:57 2016 : Error: (457308) Ignoring duplicate packet from client roaming1.ja.net port 61546 - ID: 179 due to unfinished request in component post-auth module cuisql and ..... Tue May 10 04:14:14 2016 : Error: rlm_sql (cuisql): No connections available and at max connection limit Tue May 10 04:14:14 2016 : Auth: (457515) Rejected in post-auth: [nagios] (from client systems0 port 0 cli 02-ED-79-28-F8-2A) So the above is happening because of the mysql backups and hence, every morning I get text messages saying both eduroam3 & eduroam4 are down .. which they're not. Guess I could skip the cuisql statements for the healthchecks, but that would be cheating ... Guess you're going to tell me to fix the mysql database access .... or is there something I can do to ignore cui stuff while the database is being backed up? A
Got a batch of FR server acting as our ORPS servers, two are FR 3.12 and two are 2.2.9. FR 3.12b config based upon 2.2.9 config as that;s been stable and hasn't changed for years. Fr 2.2.9 just works. With 3.12 however, since I brought them on line I've had problems with accessing a mysql CUI table.
Alex, Since you're using FreeRADIUS 3.x, look in the raddb/policy.d directory for the cui file. In line 89 (or thereabouts), you will see an entry, cuisql. Add a dash before it, like so: -cuisql This should prevent any errors from stopping the auth request from finishing (i.e. The error will be suppressed). See whether that makes a difference. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Cool! o.k. many thanks, I've made the change. Sadly I do hear my phone when its telling me about inbound messages in the early hours of the morning. Hopefully not tomorrow morning :-)) A
On May 10, 2016, at 5:59 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
So the above is happening because of the mysql backups and hence, every morning I get text messages saying both eduroam3 & eduroam4 are down .. which they're not.
Well, yes they mostly are... because the database is down.
Guess you're going to tell me to fix the mysql database access .... or is there something I can do to ignore cui stuff while the database is being backed up?
You can ignore the CUI checks, but the problem will just show up somewhere else. If you're going to use MySQL, set up master/slave replication, and have FreeRADIUS write to the master. Then, back up the slave. Or, switch to a real SQL database that doesn't break when people use it. Sorry... but MySQL is just not good enough. Alan DeKok.
Well, we're planning a move to postgresql, the two FR servers use that for storing radacct and radpostauth info. Just running on mysql for the cui stuff while I still have the two FR 2.2.9 machines ( need to puppetise my ref 3.12 machine and use that to replace the 2.2.9 machines) Haven't checked yet if the same issue will arise with postgresql A On 10 May 2016 at 12:07, Alan DeKok <aland@deployingradius.com> wrote:
On May 10, 2016, at 5:59 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
So the above is happening because of the mysql backups and hence, every morning I get text messages saying both eduroam3 & eduroam4 are down .. which they're not.
Well, yes they mostly are... because the database is down.
Guess you're going to tell me to fix the mysql database access .... or is there something I can do to ignore cui stuff while the database is being backed up?
You can ignore the CUI checks, but the problem will just show up somewhere else.
If you're going to use MySQL, set up master/slave replication, and have FreeRADIUS write to the master. Then, back up the slave.
Or, switch to a real SQL database that doesn't break when people use it. Sorry... but MySQL is just not good enough.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
p.s. tried master/slave replication for accounting info and gave up, couldn't get it to work reliably On 10 May 2016 at 12:17, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Well, we're planning a move to postgresql, the two FR servers use that for storing radacct and radpostauth info. Just running on mysql for the cui stuff while I still have the two FR 2.2.9 machines ( need to puppetise my ref 3.12 machine and use that to replace the 2.2.9 machines)
Haven't checked yet if the same issue will arise with postgresql A
On 10 May 2016 at 12:07, Alan DeKok <aland@deployingradius.com> wrote:
On May 10, 2016, at 5:59 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
So the above is happening because of the mysql backups and hence, every morning I get text messages saying both eduroam3 & eduroam4 are down .. which they're not.
Well, yes they mostly are... because the database is down.
Guess you're going to tell me to fix the mysql database access .... or is there something I can do to ignore cui stuff while the database is being backed up?
You can ignore the CUI checks, but the problem will just show up somewhere else.
If you're going to use MySQL, set up master/slave replication, and have FreeRADIUS write to the master. Then, back up the slave.
Or, switch to a real SQL database that doesn't break when people use it. Sorry... but MySQL is just not good enough.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks for the offer but our head of infrastructure wants to move to postgresql anyway. The issue we had was with the volume of accounting information that had to be synch'd between two servers. Invariably something went wrong and caused the sync to stop ... which meant that none of the other tables synch'd either. In the end we ran 2 db's in parallel without synching and kept accounting on 1 db I've got postgresql in use for radacct and radpostauth data on FR 3.0.12 A On 10 May 2016 at 13:30, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
p.s. tried master/slave replication for accounting info and gave up, couldn't get it to work reliably
really? had no problem with M/S on MySQL here (5.x) - using TLS/SSL interlink (maybe I can help you out with config etc) but the best fix is PostgresQL anyway :)
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 10, 2016, at 7:17 AM, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Well, we're planning a move to postgresql, the two FR servers use that for storing radacct and radpostauth info. Just running on mysql for the cui stuff while I still have the two FR 2.2.9 machines ( need to puppetise my ref 3.12 machine and use that to replace the 2.2.9 machines)
Haven't checked yet if the same issue will arise with postgresql
You will not have the same issue with postgres. It's a real database. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alex Sharaz -
Stefan Paetow