Compatibility with xmr-stak

[Keksov]

I'm porting some of my monitoring scripts from xmr-stak to xmrig. Former miner reports GPU's statistics at each "print-time" interval. Without this information it's not possible to tell hashrate of individual card (I need it for statistic) and monitor its availability. Probably, it should be made configurable by some parameter in config.json

[xmrig]

Why not just use HTTP API in both cases? Parsing miner output not best idea, it's for humans and can be changed without notice. JSON data in API for machines and stable across versions. Thank you.

[Keksov]

I prefer not to compile http built-in server at all. It's a potential security risk which just wait to be exploited one day or another. Yes, I know, I'm paranoid.. and I know how to configure firewall too )) As I suggested in my PR - let's do it configurable by some parameter in config.json (OFF by default) Please...

[Keksov]

I would agree to have a json report-file on my disk which is updated by miner every 60 sec. or something like that (also configurable)

[Spudz76]

Writing files to disk is a good way to burn out SSD total write cycles. Better to dump it into a ramdisk, easily done on Linux with /dev/shm/ but probably tougher on Windows (does it even have builtin ramdisk support?) So some problems with that idea.

HTTP is really the right supported way, you'd be more likely to get your existing pool connection intercepted or such (especially when non-SSL) before anyone is going to bother trying to get into your private and firewalled HTTP ports that are as secure as libmicrohttpd and the JSON library, which is pretty secure since it's super simple (not Apache, not nginx, not complex, less crevices for bugs or exploits). All layers (two) are well tested for buffer overflow abuses, I don't think there are any holes regardless how it is beaten up. And if it is set to read-only then nobody can do anything but snoop, guaranteed.

The idea that an open port is a vulnerable port, is like building your house with no doors or windows. Sure it's secure, but what if you actually want to DO anything or GO anywhere, or know what's happening? Surely the 0.01% risk is worth being able to monitor things (you have windows even though a 0.01% risk of peeping toms? and a front door even though solicitors might knock twice a year?), and parsing console output must get real old when it changes format, while the JSON is pretty much never changed and easier to adjust for renamed/relocated information if it ever did.

If you really want a secure way to report metrics the proper protocol is probably SNMP and send traps to a remote collection agent, make up some custom OIDs for mining. That is then pushed from the miner to the collector, leaving no open ports on the miner, and could be on its own reporting rate timer (similar to the old console output report-rate). That is the only thing that might be better than polling via HTTP-JSON.

You could also put the HTTP listener on 127.0.0.1 and then only obtain its data from some other undocumented proxy applet running locally, and push to any format you like (email? sms? snmp? zabbix-sender? mysql?) from there. There is literally no way to get into 127.0.0.1 unless they already owned your machine some other way.