That custom templeate did not quite understand it, putting that in the terminal should be reconfigured alone those parameters or I have to manually modify the squid.conf file
Bear in mind that technically as I have been able to read that crash, it is because the Squid is not able to process all the requests and this computing capacity as I have been able to understand is determined by those parameters.
vi /etc/e-smith/templates-custom/etc/squid/squid.conf/20acl_10_auth_custom
{
use esmith::NetworksDB;
use NethServer::SSSD;
my $ndb = esmith::NetworksDB->open_ro();
my $green_mode = $squid{'GreenMode'} || "manual";
my $blue_mode = $squid{'BlueMode'} || "manual";
my $sssd = new NethServer::SSSD();
if ($green_mode eq 'authenticated' || (defined($ndb->blue()) && $blue_mode eq 'authenticated')) {
$OUT .= "# Custom Authentication Parameters\n";
if ($sssd->isAD()) {
$OUT .= "auth_param negotiate children 20\n";
}
}
}
signal-event nethserver-squid-update
This will create a duplicate entry for auth_param negotiate children xx. If squid takes the last one then it will be effectively overwriting the default with the custom one.
For the number of children helpers there was some recommendation on squid manual. Let me check.
The parameter auth_param basic credentialsttl 1 hours by default is technically 2 hours
I understand that Nethserver uses templates for the subject of future updates, right? If I modify the file /etc/squid/squid.conf it would work now but would the changes be lost with the updates?
I do not quite understand you, sorry but it is a server in production and I do not want to mess it up
I edit:
vi /etc/e-smith/templates-custom/etc/squid/squid.conf/21acl_10_auth_custom
and I execute:
signal-event nethserver-squid-update
It is not necessary to restart the Squid service or anything else? Does that automatically modify the parameters and apply them in the /etc/squid/squid.conf?
Sorry to be so heavy dnutan and thank you so much for the help!
With the filename change? No, it’s the same. You can keep it as is (no change), or just rename 21_acl_10_auth_custom to 20_acl_10_auth_custom and execute expand-template /etc/squid/squid.conf
Final result will be practically the same.
In the custom template we created config overrides (duplicate entries but the latter with different/desired value). You can add other config parameters you want to tweak. Note order matters for some squid parameteres.
It seems that it works for now, I will keep you updated, what I have been able to verify is that it eats more cpu, within the expected if we expand the processes to manage the requests
Hola Fernando. How is it working so far?
I ask because there’s another user with the same problem and was wondering if you could give any additional advice:
Since I have modified the configuration file we have gone from 460 concurrent users without problems of cuts (before it did not exceed 250) at the moment quite well, when I have the whole company passed through the new proxy I confirm the total number of users and more data of interest if you are interested.