Did this app ever become available? If so, is there a specific repository I need to enable as I don;t see it at this time. I'm close to purchasing some Unifi APs but will only do so if I can host the management utility on my ClearOS server, and having something like your app appears likely to save me a lot of hassle on the command line!
Hello adrianr, I do not know if Brian completed is app?
F.Y.I. I was able to move my unifi controller to ClearOS 7.3, though I only upgraded the controller to version 4.8.20. My latest upgrades to my ap's firmware i.e. [FIRMWARE] 22.214.171.12437 for UAP/USW has been released to fix: Key Reinstallation Attacks the weaknesses in WPA2 have been successful and does not seem to affect to much the older controller. Another solution is you can also make use of: UniFi Cloud Key if you do not wish to install the controller.
In regards to the version of Squiq, I was under the impression that you where running: 'Squid 2.3.4-1', so that is not the issue.
I hate to say this but I now have squid running, snort, fail2ban and not having your problem though I am running my vm's on a ESXI platform if that makes any differences?
I have checked for the NETWORKING environment variable that you mention and I do not have it. Similar configuration to yours:
My suggestion would be to attempt to find the conflicting services, I would disable snort from starting and see if that helps? I do not see fail2ban in your logs but I would also disable it if you have it installed?
Nick would be better at this then I am but sounds like multiple process are attempting to alter your iptables rules at the same time, could be Squid?
The squid starting information is going to be in the message... log, though I do not know if that will tell us much. Maybe the start time of Squid will be that same as your error?
I noticed that the current version of squid in the repos is:
[root@cognoquest ~]# yum list squid
You could take a look at your startup script for Squid? See if it similar to this:
Also can you duplicate your vm's with another vlan? and test with a more recent version of squid?
Sorry, I may have misunderstood your problem. I was under the impression that your second VM was attempting to access your Gateway VM prior to it being operational.
You may be running into hardware contention issues which in you case creating a racing situation? I have read that it is not recommended to run a Gateway as VM's, mostly because of clock issues but who knows what else? I am as culprit as you are, I also run my home gateway from a VM though I do not use Dropbox and Squid.
You may have to experiment and delay the start of Squid? or maybe you can try this fix: Title This solution is for another problem and a bit of a shot in the dark but I recently discovered that I was having a conflict with the start of the firewall and fail2ban.
content of: clearos-sshd.conf
content of: clearos-sshd-ddos.conf
Straight after boot up, result of "lsmod | grep ip_set":
Straight after /usr/bin/fail2ban-client reload, result of "lsmod | grep ip_set":
I think the bug you are referring to was that both the above jails actions where identified by the same name in the configuration. This would mess up the iptables: [name=sshd] but also note that they where using a different action at the time: iptables-allports[name=sshd] this was replaced by: iptables-ipset-proto6-allports[...]
Wanted to check if any one else is having this issue, I am working on enhancing my mail gateway fail2ban jail scripts and encountered an issue with a rule missing. I do not think it is related to my changes but you never know.
I boot my server, I have 6 jail configuration.
Output of iptables: (notice: --match-set f2b-sshd missing)
I reload: fail2ban-client
Output of iptables: (notice: --match-set f2b-sshd can now be found)
It appears to me that this occurs when we use the fail2ban action: iptables-ipset-proto6-allports in multiple jail activities such as: clearos-sshd.conf & clearos-sshd-ddos.conf
Anyone else noticed this problem?