By default, the ClearOS syswatch daemon pings upstream servers to determine if it is on line. According to /etc/syswatch they are your WAN next hop - but mine does not seem to be - and another server (GoogleDNS 8.8.8.8). Have a look at /var/log/syswatch when your interface goes down to see which servers are being pinged. For me it seems to ping 54.152.208.245 and 8.8.8.8, but you can override these in /etc/syswatch at the bottom. Choose a couple of different destinations if you want and don't block them. Either that or disable syswatch (perhaps not such a good idea).

Can I suggest you take a copy of the system backups from /var/clearos/configuration_backup (also available through the webconfig)? This is not the be all and end all because it does not quite back up all your settings and not all bits get restored on a restore (e.g. flexshare and webserver folders don't get created). I also back up the whole of /etc using rsync, just in case. With these you should get most things restored including your whole user database.

There is no "if I can't..." message. If I block all of the IPs that seem related to you, it decides that none of my interfaces are working, and thus I have no access to the internet.

I'm a bit calmed today after resolving yesterday's failure (another thread), but I'm still flying in opposition of the "cloud" movement, and likely always will.

ClearOS is the only network-related thing I'm running right now that isn't either application-specific hardware, or virtualized. It is the one thing I fear being broken/corrupted by an update. Anything else that gets mangled gets restored from a snapshot and little to nothing is lost. If ClearOS gets mangled, however, *everything* is dead in the water until either I figure it out, somebody posts a solution on here, or I wipe the entire system and start over.

I'm totally okay with a model that says "here's an update, we think it might work, it might break stuff, why don't you find out for us?" as long as I get to choose when to do that and on which systems. I have periods where work is slow and do certainly enjoy tinkering, and I also have sacrificial sandbox systems. If one system goes down on a Friday it's a slight annoyance ("well, there went my weekend"), the disaster is when it's Sunday evening and I'm getting ready for (literally everybody I work for) to open on Monday morning, and every system is fighting with me in some unexpected way. That's when I'm in a panic, that's when things are critical, and, frankly, that's when I'm furious.

I have learned from the past, that when leaving Automatic Updates enabled, changes can get pushed that rewrite config files to default and/or push new kernel versions and drivers that have negative effects to my server, so I leave Automatic Updates disabled in the Webconfig. Then I check for updates from the command line, so that I can see what packages are going to be updated. If I know it might have negative effects on my server, I won't do the update or I'll exclude certain packages when I do the update, if I'm certain they aren't part of the dependencies of the other packages being updated.

I think it would be awesome if the devs would allow for an echo feature in the Webconfig, so we could see what yum is telling us as we're doing the updates. Then also provide a yes or no response to the current updates. Then at the least, we could go to the command prompt and exclude packages in the update. Better yet, allow check boxes to pick what updates we want to allow.

You can stop automatic updates in the Webconfig > Cloud > Updates > Software Updates. It calls out (but not home) with the syswatch daemon which is what checks you are on line. It also calls out if you use the Dynamic DNS updates. There are separate calls home if you subscribe to any of the ClearSDN updates (antispam, antimalware, antivirus and intrusion-protection). Also the Dynamic VPN calls home to function. I have a feeling the suva daemon calls home but I'm not sure of this one. I think this is to do with the registration system used for the checking the validity of your registration and, therefore access to the marketplace. The only things which make changes to your system are the Software Updates, ClearSDN updates and Dynamic VPN.

If you have incoming tcp:1875 (ClearSDN in the Incoming firewall), then ClearCenter dials in to do a remote security audit daily.

Please can you give the exact message it gives when say it says "if I can't phone home then you can't have the internet."?

I am not aware of any updates in the past week which may have caused you problems. There were two released on Tuesday night, one which allowed uppercase names in the content filter if you used the AD Connector. It also started clearing stale content filter cache files. The other update stopped "mailfilter" messages appearing in /var/log/system and moved them to /var/log/maillog. App-antivirus was expected on Wednesday night but did not make it. It will probably now come out tomorrow night. What updates have you received in the last couple of weeks?

Please also note that if you have a Community version of ClearOS, you get tested updates, but are more likely the hit issues in edge cases which have not been picked up in the internal testing. This is the joy of running a free version. (Just about) all apps get released to the Community a week or two before they get released to the Home and Business versions for just that reason - so final, unnoticed bugs can be ironed out. One typical case in point was the update to ClearOS 7.6 where two critical issues were missed. One was in grub which stopped UEFI systems from booting. A patch was pushed within a day and a manual workaround was release for anyone who rebooted their systems in the one-day window. The other was excessive logging of events which took a little longer to find and patch, but, again, I think this was done within a week, and certainly before the Home/Business versions were released. This one caused problems for a few systems especially if you sat in the IP settings screen of the Webconfig. I know of one user who powered their systems down but a couple of others helped troubleshooting so we could release a patch. I am not aware of the bug killing any system but it is conceivable if the system was very low on disk spaces or was a very low power device.