I've been thinking about writing a small c program using the API to manage my pools more effectively when my main pool has issues, which has been a LOT lately. The problem when the main pool has issues is it is constantly going up and down multiple times a minute, and that really chokes my hashrate when that happens. As it stands, the failover does not handle this situation well and keeps trying to submit shares to the intermittently failing pool, and keeps switching back to that pool when it briefly comes back online.
What the program would do is try and detect this situation and switch/disable the offending pool for a set amount of time so my hashrate/shares per min don't plummet. As it stands now, reading through the API I would probably have to have the program read the active logfile to detect the situation as there does not seem to be a way to get notifications for the "Pool 0 communication failure, caching submissions" event. If this kind of logic is being added into cgminer sometime soon (perhaps as an optional flag), I'll not waste time developing my hack for it.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 641. (Read 5805546 times)
February 21, 2012, 07:06:50 PM
February 21, 2012, 06:45:59 PM
True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)
Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.
But cgminer already stores passwords in clear text and transmits them as such. Of course they are not important passwords (workers), but the same goes for protecting the API. Only an idiot would set the same password as for his email/facebook whatever. But then that idiot might be using that password for his workers already, so nothing changes there.
February 21, 2012, 06:43:29 PM
True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)
Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)
Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.
I agree for most applications there is no reason for anything less than per password salted SHA-256. Passwords should be transmitted only encrypted and only after host has authenticated itself.
Still this is Bitcoin mining not a financial services database.
February 21, 2012, 06:31:10 PM
Doesn't really matter about being stored in a config file. If the attacker has access to the config file he has access to your machine (and possibly as admin/root) and can do anything he wants including force your GPU to overheat from the command line.
I have a strong dislike for cleat text passwords stored in config files.Access rights need to be very cautiously set on all such files.
True, once the attacker gains shell access, you're in deep trouble.
Your trouble can easily get much deeper, however, when the adversary finds clear-text login credentials in some script or config file (e.g. a password for the corporate database...)
Clear text passwords can really make your day when for whatever reason you're unable to grab the elusive root.
February 21, 2012, 06:21:17 PM
I'm getting this error in the log together with a restart, is it normal?
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 31076 requests (31076 known processed) with 0 events remaining.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 31076 requests (31076 known processed) with 0 events remaining.
February 21, 2012, 05:48:27 PM
FYI, Kano wrote and maintains the API...
Thanks for letting me know.
https://bitcointalksearch.org/topic/completed-request-for-an-rpc-capable-fork-of-cgminer-155-btc-pledged-and-paid-52466
So ... password/encrypted traffic ... some time down the road ...
I was just hoping for something simple in next version rather than some financial services certified end to end encrypted system which may not be in the next 20 versions.
Just something that would prevent casual port sniffing attack like bitcoind uses. simple password = quick & easy.My guess is that getting some encryption scheme wrapped around JSON will take some time and then it will require implementing encryption on the other end which will slow down development of things like android app to control hashing farm because now developers will need to not only for wait for encrypted version of API but implement and test compatible encryption on the remote platform too.
February 21, 2012, 04:55:21 PM
I guess we won't be getting password protected access which is a shame because I am not comfortable leaving it unprotected and setting up VPN and then providing access to all endpoints (which may change) seems like overkill.
FYI, Kano wrote and maintains the API...So ... password/encrypted traffic ... some time down the road ...
OK the pool stuff just became a faster to do change ... sometime ...
February 21, 2012, 04:31:55 PM
Passwords may not the be the best approach when stored in plain-text form in some config file and not encrypted in transit.
Doesn't really matter about being stored in a config file. If the attacker has access to the config file he has access to your machine (and possibly as admin/root) and can do anything he wants including force your GPU to overheat from the command line.
I guess we won't be getting password protected access which is a shame because I am not comfortable leaving it unprotected and setting up VPN and then providing access to all endpoints (which may change) seems like overkill.
I guess I can stop being lazy and fork my own copy.
February 21, 2012, 03:46:34 PM
Yeah, that thought crossed my mind, but I dont think its pointless without encryption; its one thing to do a port scan and find vulnerable cgminer instances, its quite another to intercept IP traffic between the miner and its owner. I agree putting a password on it is of course not 100% secure, but far better than nothing (and in my case, better than an IP lockout, since I would be accessing it via 3G on dynamic IP).
If you have a VPS with a statically-assigned IP somewhere, you could tunnel your dynamic-IP 3G traffic through an easy to configure SSH tunnel.
To the miner it will look like the traffic originates at the whitelisted VPS.
If you don't wish to set up a VPS or if you want to be able to use the API with --api-allow W:127.0.0.1,192.168.1/24" configured (LAN access only) while you're off-site you will need to set up a VPN server.
While configuration-intensive and sometimes tricky to get going, a VPN will massively boost the security of your network - no need to even open the miner's ssh port to the general internet population.
If you're using a mid-to-high end router, it might already have a VPN server built in.
Passwords may not the be the best approach when stored in plain-text form in some config file and not encrypted in transit.
February 21, 2012, 03:44:57 PM
Just have to say, cgminer is working great right now
Previous version were producing a lot of invalids/rejectes/discarded etc. Now the figure are all looking very good.
Well done Con
Previous version were producing a lot of invalids/rejectes/discarded etc. Now the figure are all looking very good.
Well done Con
February 21, 2012, 03:39:56 PM
Adding password access would be more that just a small effort for a few reasons:
1) It's pointless adding password access without data encryption since it defeats the purpose of having a password in the first places
2) If I add data encryption then the protocol used would need to be used by anyone wanting password encryption.
1) It's pointless adding password access without data encryption since it defeats the purpose of having a password in the first places
2) If I add data encryption then the protocol used would need to be used by anyone wanting password encryption.
Yeah, that thought crossed my mind, but I dont think its pointless without encryption; its one thing to do a port scan and find vulnerable cgminer instances, its quite another to intercept IP traffic between the miner and its owner. I agree putting a password on it is of course not 100% secure, but far better than nothing (and in my case, better than an IP lockout, since I would be accessing it via 3G on dynamic IP).
A somewhat clumsy alternative perhaps would be one time passwords, but managing that would likely be a nightmare.
If you are accessing it via 3G then you must mean a laptop? (VPN solves that
Since from a phone you'd normally be accessing a web page that would have some access control that is not related to cgminer?
Or have you written some android/iphone app that talks to cgminer directly?
Quote
Add/delete/disable is not currently available and is also I doubt a very quick addition.
You cannot delete a pool as such anyway - it would only be 'disable'
Adding a pool: I'd have to have a look at what issues that creates when cgminer is already running
(I've no idea at the moment)
...You cannot delete a pool as such anyway - it would only be 'disable'
Adding a pool: I'd have to have a look at what issues that creates when cgminer is already running
(I've no idea at the moment)
Disable is good enough. As for adding a pool, it works just fine in the CLI while its running, which is why I was slightly surprised the functionality didnt seem to exist in the API. Its about the only thing you cant do through the API (and sadly, one I need lol).
(coz I've never used it from the cgminer screen and didn't even realise it existed)
Just checked - yep there it is
Delete is there also ... but I'm wondering how that works ... deleting a pool would mean you'd lose your pool stats which would be a bad thing in my opinion ... that's why I thought only disable, OK I guess I better check that code also.
OK the pool stuff just became a faster to do change ... sometime ...
February 21, 2012, 03:08:35 PM
Adding password access would be more that just a small effort for a few reasons:
1) It's pointless adding password access without data encryption since it defeats the purpose of having a password in the first places
2) If I add data encryption then the protocol used would need to be used by anyone wanting password encryption.
Yeah, that thought crossed my mind, but I dont think its pointless without encryption; its one thing to do a port scan and find vulnerable cgminer instances, its quite another to intercept IP traffic between the miner and its owner. I agree putting a password on it is of course not 100% secure, but far better than nothing (and in my case, better than an IP lockout, since I would be accessing it via 3G on dynamic IP).
A somewhat clumsy alternative perhaps would be one time passwords, but managing that would likely be a nightmare.
Quote
Add/delete/disable is not currently available and is also I doubt a very quick addition.
You cannot delete a pool as such anyway - it would only be 'disable'
Adding a pool: I'd have to have a look at what issues that creates when cgminer is already running
(I've no idea at the moment)
You cannot delete a pool as such anyway - it would only be 'disable'
Adding a pool: I'd have to have a look at what issues that creates when cgminer is already running
(I've no idea at the moment)
Disable is good enough. As for adding a pool, it works just fine in the CLI while its running, which is why I was slightly surprised the functionality didnt seem to exist in the API. Its about the only thing you cant do through the API (and sadly, one I need lol).
February 21, 2012, 02:29:50 PM
Im not entirely sure this belongs here; a feature requests for the API?
I would like to have password on the API. Its kinda dangerous to leave it open, someone could turn off the fans or whatever, and its extremely useful to have access to the API remotely
Yes the RPC API is part of cgminer and requests/discussions about it belong here.I would like to have password on the API. Its kinda dangerous to leave it open, someone could turn off the fans or whatever, and its extremely useful to have access to the API remotely
Your 1st request is related to what I put into cgminer yesterday and will be available with the next release.
If you can't wait for the next release, you can download the latest git, compile it and have it already.
My change yesterday means that by default no-one can change anything, they can only view everything.
You must use the --api-allow to be able to grant access to commands that effect cgminer, and only the ip addresses/subnets that are specified with a "W:" on the front are given this extra write/privileged access.
The privileged commands will be: gpu settings, switchpool, save, quit & privileged.
(the last one is just a way to test if you are privileged)
So in the next version "--api-listen" or "--api-listen --api-network" give access to all of the other display commands only.
Aside: "--api-listen" is the same as "--api-listen --api-allow 127.0.0.1"
and "--api-listen --api-network" is the same as "--api-listen --api-allow 0/0"
In the next version to grant local access to all of the API:
"--api-listen --api-allow W:127.0.0.1"
In the next version to grant only the cgminer computer access to all of the API and read access to your local network:
"--api-listen --api-allow W:127.0.0.1,192.168.1/24"
In the next version to grant cgminer and local network access to all of the API and read access to the rest of the world:
"--api-listen --api-allow W:127.0.0.1,W:192.168.1/24,0/0"
Adding password access would be more that just a small effort for a few reasons:
1) It's pointless adding password access without data encryption since it defeats the purpose of having a password in the first places
2) If I add data encryption then the protocol used would need to be used by anyone wanting password encryption.
Not insurmountable, but also not a quick addition.
Quote
I would also like the possibility to manage pools via the API. Add, delete, enable/disable pools. If that's already possible, then perhaps I misread the documentation.
I someone can make this happen, Ill toss you a coin.
From the API you can only switch pools (switchpool|N) at the moment.I someone can make this happen, Ill toss you a coin.
That is almost the equivalent of enable/disable if you are using the default "Failover" mode since in that mode it only mines on the pool with priority 0 unless there is trouble with it,
So a switchpool|N command makes that the active pool (and enables it) and thus makes the current active pool no long the active pool (but doesn't disable it)
Add/delete/disable is not currently available and is also I doubt a very quick addition.
You cannot delete a pool as such anyway - it would only be 'disable'
Adding a pool: I'd have to have a look at what issues that creates when cgminer is already running
(I've no idea at the moment)
If a few people were interested ... you'd have a better chance of redirecting my current development away from my multi-rig monitoring/notification standalone java tool I'm working slowly on ...
(yes while working on this I realised the recent changes were needed and would also resolve most all but encrypted/password access to the API)
February 21, 2012, 01:41:47 PM
Im not entirely sure this belongs here; a feature requests for the API?
I would like to have password on the API. Its kinda dangerous to leave it open, someone could turn off the fans or whatever, and its extremely useful to have access to the API remotely
I would also like the possibility to manage pools via the API. Add, delete, enabe/disable pools. If thats already possible, then perhaps I misread the documentation.
I someone can make this happen, Ill toss you a coin.
I would like to have password on the API. Its kinda dangerous to leave it open, someone could turn off the fans or whatever, and its extremely useful to have access to the API remotely
I would also like the possibility to manage pools via the API. Add, delete, enabe/disable pools. If thats already possible, then perhaps I misread the documentation.
I someone can make this happen, Ill toss you a coin.
February 21, 2012, 07:14:33 AM
New release: Version 2.2.7 - February 20, 2012
......
reject ratio higher for me, about 3% instead 0,5% at 2.1.2 ......
my conf.
p2pool 462b252 multi merged mining
bitcoind 0.6
atiumdag 8.920.0.0 (Catalyst 11.12) / Win7 64
OpenCL 1.1 AMD-APP-SDK-v2.5 (793.1)
February 21, 2012, 12:16:07 AM
DAT here you go: http://www.fileswap.com/dl/XeABs0KKAQ/cgminer.html
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
bamt sends: quit|\n
when cgminer should exit.
I cannot comment on how that works with 2.2.x. There is no official build of cgminer for BAMT beyond 2.1.2. Gave up trying to keep track of all the bugs in the 2.2.x series, figured better to wait until things settled down before pushing out an update that could potentially break a large number of working installation. We tend to be on the conservative side with things.
(since "quit|anything" just ignores from the "|" onwards since quit takes no notice of the parameter it's supplied)
quit without the | did not work in the version I used in creating the BAMT controller for cgminer. I will retest this the next time we update.
However, yes it's a bug ... seems to have been around for a while now.
(I never use the quit command so I didn't notice the problem when the cgminer shutdown code changed)
But yep ... when you find a bug in something you use ... it's usually a good idea to report it
... now tracking down the cause ...
(I never use the quit command so I didn't notice the problem when the cgminer shutdown code changed)
But yep ... when you find a bug in something you use ... it's usually a good idea to report it
... now tracking down the cause ...
I do not use cgminer myself, therefore am not in a good place to report bugs, unless you want them secondhand. I will encourage the folks testing cgminer and reporting trouble to me to report it via the proper channels.
February 20, 2012, 11:37:27 PM
DAT here you go: http://www.fileswap.com/dl/XeABs0KKAQ/cgminer.html
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
bamt sends: quit|\n
when cgminer should exit.
I cannot comment on how that works with 2.2.x. There is no official build of cgminer for BAMT beyond 2.1.2. Gave up trying to keep track of all the bugs in the 2.2.x series, figured better to wait until things settled down before pushing out an update that could potentially break a large number of working installation. We tend to be on the conservative side with things.
(since "quit|anything" just ignores from the "|" onwards since quit takes no notice of the parameter it's supplied)
However, yes it's a bug ... seems to have been around for a while now.
(I never use the quit command so I didn't notice the problem when the cgminer shutdown code changed)
But yep ... when you find a bug in something you use ... it's usually a good idea to report it
... now tracking down the cause ...
February 20, 2012, 10:34:33 PM
DAT here you go: http://www.fileswap.com/dl/XeABs0KKAQ/cgminer.html
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
bamt sends: quit|\n
when cgminer should exit.
I cannot comment on how that works with 2.2.x. There is no official build of cgminer for BAMT beyond 2.1.2. Gave up trying to keep track of all the bugs in the 2.2.x series, figured better to wait until things settled down before pushing out an update that could potentially break a large number of working installation. We tend to be on the conservative side with things.
February 20, 2012, 10:11:42 PM
DAT here you go: http://www.fileswap.com/dl/XeABs0KKAQ/cgminer.html
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
Kano, I'm sorry I don't know enough about coding. BAMT has a stop mining script that is run from gpumon on stop or restart mining. This doesn't work after 2.1.2 so I just go to the cgminer screen session and hit q before restarting. I'm sure it's an easy fix but the author feels 2.1.2 is the most stable and that is what he currently supports.
EDIT: should mention that's 2.2.7 w/o bitforce or cpu flags.
February 20, 2012, 10:02:37 PM
Just tested, add "copytruncate" in the configuration file, so the old log file will only get truncated and keep growing
Thank You. Trying it out now. Jump to: