xmrigCC
xmrigCC copied to clipboard
[2.1.0] Ignore read-only config attribute
CC server must ignore read only attribute. I just bricked most of my miners by pushing old style config to 2.0.0 clients, that messed their configs up, they have algo set to null so they don't mine. Worst part is that this somehow put read-only attribute on config file, maybe it's default behaviour when autosave set to true (which should be false by default i think). So i have no other way to change these configs but with physical access since CC server does nothing, not even a notice that it failed to write config or smth.
Clarification, i pushed old config on new clients on 2.0.0 CC Server version, 2.1.0 doesn't even let me save old-style config but old one for some reason pushed it just fine.
There are a few things i don't understand.
What do you mean by read-only properties? They doesn't exist.
And the server doesn't do a validation of the content of you push. If its valid json then its fine for him and he will forward it to the miner. Regardless if its 1.* or any 2.* version of the server. They all do the same.
When the miners are conneted to the dashboard you can ALWAYS heal them by pushing a new config and using the restart feature.
When they aren't connected to the server anymore, yeah then you're lost.
What do you mean by read-only properties? They doesn't exist. config.json file read-only attribute. It's reproducible, if i set read-only flag on my config there's this error message on the client side when i try to push changes in it : [2019-10-25 22:38:25.455] [CC-Client] Not able to store client config to file C:\xmrig\config.json. So no, not always. I still don't know how the hell that read-only attribute was set but it's obviously smth to do with at least previous CC server version since new one can't write read-protected config too and if it were set before invalid config was pushed it wouldn't work either.
Sorry but that sounds very strange and hard to believe.
The server is not writing a file on the miner. The miner itself does.
And if its not able to store the file because of insufficient rights the config won't change. That code didn't changed since a long time. And the miner is not changing any file permissions, that has to be done manually.
If you can provide steps to reproduce that will be helpful.
Ok then it's the miner that can't write a file with read-only attribute, i don't see this to be a problem since it's already running with administrative rights so it can use huge-pages, just clear the attribute and put it back if it really should be there for some reason. Steps are simple : Put read-only attribute on config.json, on windows like that : attrib +R config.json Try to push a new config to client CC server doesn't report any errors but there's error in client's log Client's config doesn't change obviously
Also, while we at it. Dashboard rework is pretty good but :
- Why you've moved pull and push buttons around ? I've tried to push config several times clicking pull button by muscle memory until i noticed that lol.
- That algo grouping is very good idea but in current implementation it's worthless as it doesn't group anything really, you need to sort the list by algo anyway, it should split the list for algo groups.
Also it would be pretty useful if clicking on the group label would select all miners in it.
- Hahaha. That wasn't on purpose. I was all the time thinking something is different. I'll flip it back.
- It's the first iteration.. the idea was to have group sums, select all miners of a group etc..
- is fixed in master for two im currently changing the group behavior. Once its done i'll let you know