3 ms·
Read only would require a separate daemon/install package which I'm sure they want to avoid. Tbh, my internal monitoring of Redis uses the same trick but I'm d
by opendais 13y ago
Read only would require a separate daemon/install package which I'm sure they want to avoid.
Tbh, my internal monitoring of Redis uses the same trick but I'm doing it on a racks inside our physical office.
- theonewolf 13y agoI'd be horrified at giving a _third-party_ write access to my production database. Heck, even _virus scanners_ from people like _Symantec_ can kill you with remote code execution---and they often have write access: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4953 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-495...
- theonewolf 13y agoIt could be a simple script with a couple of commands you setup as a cron job. Similar to Loggly setup. Easily verifiable by hand as well if you wanted to. A direct connection which arbitrarily sends commands to my server? Completely unverifiable as to what commands it could potentially send.
- opendais 13y agoYes, like I said they probably wanted to avoid an install process and I would only do this internally. :) That doesn't mean there isn't a cost v. benefit decision to be made that should be left up to the end user at some point. But basic precautions [such as securing the connection properly] need to be made at a minimum. I provided the TBH as part of the disclosure of 'I do this...but I do not use a 3rd party.' so it is viable if done internally.
- theonewolf 13y agoAlso, another random thought. The commands they run are not under my control, nor is even the _timing_ of their commands under my control. Their commands might impact my production workload negatively. At least with a cron job or scheduled monitoring job I could control _when_ it runs.