2017-01-23 - Re: [GRASE-Hotspot] guidance for medium large installation

Header Data

From: Gianluca Filippini <gi***4@gmail.com>
Message Hash: 67b7f493ee1d14032681eab119d55e4fdf5fdccbb8bf106f9b6f2bf555c4fd0c
Message ID: <293ba468-bf8b-48b1-b5f3-9c0a23657a53@grasehotspot.org>
Reply To: <CAESLx0JpWB_JJjE0qi9RKJ4=e0rC=GBQ=qzTTxGrYeocjsiR4A@mail.gmail.com>
UTC Datetime: 2017-01-23 07:23:07 UTC
Raw Date: Mon, 23 Jan 2017 06:23:07 -0800

Raw message 

one more note on this topic.

I think for GRASE we still use dnsmaq on the latest releases, correct?

for a slightly different prj I was seeing dnsmaq performing quite badly on 
a 4 cores xeon machine when the load of users from the network was high 
(100+ users in a single office).
I was seeing an incremental delay for name resolution, basically slowing 
down the user surfing experience on the web

so after struggling with dnsmasq logs and custom configs I decided to 
switch to UNBOUD and the performance has jumped immediately to a different 
level.

I followed this howto:
https://blog.josefsson.org/2015/10/26/combining-dnsmasq-and-unbound/

now my question is: on my next install I would like to use unbound as dns 
resolver because for me it works much much better.

do we have specific needs or specific code that would prevent me to do this 
change on a GRASE machine?

thanks

On Sunday, January 22, 2017 at 9:58:02 PM UTC+1, timwhite88 wrote:
>
> Hi Gianluca
>
> Firstly, 16.04 isn't yet supported. I'm in the process of building new 
> packages that support it (actually, they are built), and now need to test. 
> Due to some package changes in 16.04, I'm having to change how the 
> repositories work, so we can target specific distributions. This is great, 
> as it'll be clearer what is supported and (somewhat) tested. It also allows 
> us to get rid of some packaging oddities we've had to work with.
> The supported list of distributions will be Ubuntu Xenial (16.04), Trusty 
> (14.04), and Debian Jessie. I'm in the testing phase of the new 
> repositories, and once I can confirm that they work, will release 
> instructions to get others testing the newly built packages. With 3 
> distributions, and up to 4 architectures (32bit, 64bit, ARMHF and ARMEL on 
> Debian), there are lots of combinations to test, and not much time or 
> hardware.
>
>
> 1) is there some parameter for freeradius that I should tweak from the 
>> default install? I reading about the num_threads but I did not test it 
>> before, yet it seems likely something that I should increase...
>>
>
> None that I'm aware of. As you get more connections going through, you may 
> want to decrease the accounting interval (definteriminterval) for Coova 
> Chilli. The default is 5 minutes, but with more connections, an easy way to 
> reduce the freeradius load is to increase that interval. 
>
>>
>> 2) mysql num of connections : seems another param to be increased with 
>> 200 users to track ..
>>
>
> I'm guessing you'd want this to match the number of threads of Freeradius. 
> Current default is 5 I believe. 
>
>>
>> 3) for 3.8 I don;t want to keep more than 2 weeks of history in my 
>> session database, is there a way I can automatically prune the database? 
>> I've seen few few emails with some scripts from Tim, are those ready to be 
>> used in production?
>>
>
> I'm not sure. The ones floating around I've not looked at in depth. It'll 
> depend on if the users are "expired" or used up their quota. If so, some of 
> the built in scripts will help. Although 2 weeks is very short. The 
> sessions table is used to manage limits, so if you are emptying it 
> regularly, you need scripts that take into account how much data a user has 
> used, before removing them from the table.
>  
>
>>
>> 4) firewall: is there a way to disable the internal firewall on GRASE? I 
>> just need access control, all port filtering is done from the fw/router in 
>> front of the grase machine itself.
>>
>
> Not easily. We currently NAT connections, so a firewall is required. 
> However, it's a minimal firewall, mostly there for the NAT and transparent 
> squid proxying. Linux firewalls are very efficient, so I doubt turning it 
> off would give you much performance improvement. You'll find that 
> CoovaChilli is a bigger drain of resources, as it needs to track all the 
> active connections, rate limit them, report traffic flows, etc. CoovaChilli 
> has a kernel module now, to help with this, but I've done 0 testing with 
> it, and I doubt I'll get to testing it for a long time as it's not as easy 
> to build and setup.
>
> From the sounds of it, you really need to ensure you have adequate 
> hardware to handle your setup.
>
> Looking forward to seeing progress.
>
> Tim
>

Thread