Bitcoin Forum
December 03, 2016, 07:57:17 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 [208] 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4815421 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
jake262144
Full Member
***
Offline Offline

Activity: 210


View Profile
February 21, 2012, 07:46:34 PM
 #4141

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.
1480795037
Hero Member
*
Offline Offline

Posts: 1480795037

View Profile Personal Message (Offline)

Ignore
1480795037
Reply with quote  #2

1480795037
Report to moderator
1480795037
Hero Member
*
Offline Offline

Posts: 1480795037

View Profile Personal Message (Offline)

Ignore
1480795037
Reply with quote  #2

1480795037
Report to moderator
1480795037
Hero Member
*
Offline Offline

Posts: 1480795037

View Profile Personal Message (Offline)

Ignore
1480795037
Reply with quote  #2

1480795037
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480795037
Hero Member
*
Offline Offline

Posts: 1480795037

View Profile Personal Message (Offline)

Ignore
1480795037
Reply with quote  #2

1480795037
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 21, 2012, 08:31:55 PM
 #4142

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. Smiley
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
February 21, 2012, 08:55:21 PM
 #4143

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 ...
<snip>...
OK the pool stuff just became a faster to do change ... sometime ...
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 21, 2012, 09:48:27 PM
 #4144

FYI, Kano wrote and maintains the API...

Thanks for letting me know.  Smiley
https://bitcointalk.org/index.php?topic=52466.0

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.  Smiley 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.
johnyj
Legendary
*
Offline Offline

Activity: 1806


Beyond Imagination


View Profile
February 21, 2012, 10:21:17 PM
 #4145

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.


jake262144
Full Member
***
Offline Offline

Activity: 210


View Profile
February 21, 2012, 10:31:10 PM
 #4146

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.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 21, 2012, 10:43:29 PM
 #4147

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.

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.
P4man
Hero Member
*****
Offline Offline

Activity: 504



View Profile
February 21, 2012, 10:45:59 PM
 #4148


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.

QuantumFoam
Full Member
***
Offline Offline

Activity: 130


View Profile
February 21, 2012, 11:06:50 PM
 #4149

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.
P4man
Hero Member
*****
Offline Offline

Activity: 504



View Profile
February 21, 2012, 11:17:35 PM
 #4150

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 21, 2012, 11:20:17 PM
 #4151

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.
It's actually a longstanding bug I've been fighting for some time. The driver really shouldn't be reporting back speeds of the lower profile but it screws everything up when it does.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jake262144
Full Member
***
Offline Offline

Activity: 210


View Profile
February 21, 2012, 11:23:57 PM
 #4152

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.
Ah, the old 1d10t error code Cheesy

Did you per chance hear about protests against the ACTA treaty being signed in Europe?
Many government websites were brought down as an act of defiance.
Apparently, Polish Prime Minister needed admin-rights access to his official site... the password was revealed to have been admin1 Grin
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
February 22, 2012, 07:42:50 AM
 #4153

Current git fails to build kernels. According to a bisect, the following commit is the problem:

Code:
commit 26c59fbf0f399950d843faba5a9a0fb5dc345df6
Author: Con Kolivas <kernel@kolivas.org>
Date:   Wed Feb 22 16:59:28 2012 +1100

    Allow the worksize to be set per-device.

The resulting failure:

<snip>

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 22, 2012, 07:45:39 AM
 #4154

Current git fails to build kernels. According to a bisect, the following commit is the problem:

Code:
commit 26c59fbf0f399950d843faba5a9a0fb5dc345df6
Author: Con Kolivas <kernel@kolivas.org>
Date:   Wed Feb 22 16:59:28 2012 +1100

    Allow the worksize to be set per-device.
Heh you couldn't wait till I finished it Cheesy Yeah I'm still working on the code, thanks.

edit: Yes I know I shouldn't leave the master branch in an unworkable state but I had to rush off and didn't want to lose my work to date.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
johnyj
Legendary
*
Offline Offline

Activity: 1806


Beyond Imagination


View Profile
February 22, 2012, 07:52:28 AM
 #4155

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

Same here, I use AMDOverdriveCtrl to handle each graphic card, and when there is no load due to lag of pool, the card automatically drop clocks to 157Mhz, I think it is a feature of ATI powerplay on card, has nothing to do with cgminer/AMDoverdriveCtrl. But when load is re-applied to the card, AMDOverdriveCtrl immediately shows the clock returned to 900Mhz, but cgminer's hash rate will only slowly climb back to original hashrate in about 10 minutes

But I take it as a feature Cheesy Smoothly increase the load on card will improve the stability when there is a sudden change in the clock frequency

ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
February 22, 2012, 07:55:12 AM
 #4156

Heh you couldn't wait till I finished it Cheesy Yeah I'm still working on the code, thanks.

edit: Yes I know I shouldn't leave the master branch in an unworkable state but I had to rush off and didn't want to lose my work to date.

Tongue I figured as much, just wanted to make sure you knew about it. And you'd just left IRC when I was about to ask...

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 22, 2012, 07:58:54 AM
 #4157

The plummeting hashrate is partially caused by what I consider a bug I noticed recently. When a pool lags, cgminer sets the clocks back to 157 Mhz. When the pool comes back or cgminer switches to a backup pool, it slowly ramps up the speed from the minimum configured. I see no need for that behavior.  It takes a few minutes before its mining back at full speed for no real reason.

Same here, I use AMDOverdriveCtrl to handle each graphic card, and when there is no load due to lag of pool, the card automatically drop clocks to 157Mhz, I think it is a feature of ATI powerplay on card, has nothing to do with cgminer/AMDoverdriveCtrl. But when load is re-applied to the card, AMDOverdriveCtrl immediately shows the clock returned to 900Mhz, but cgminer's hash rate will only slowly climb back to original hashrate in about 10 minutes

But I take it as a feature Cheesy Smoothly increase the load on card will improve the stability when there is a sudden change in the clock frequency
A number of niggling issues cause drop in hashrate over longpolls and network outages in 2.2.7. Fixed in next version.  Hold on to your hats...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
P4man
Hero Member
*****
Offline Offline

Activity: 504



View Profile
February 22, 2012, 08:13:12 AM
 #4158

. But when load is re-applied to the card, AMDOverdriveCtrl immediately shows the clock returned to 900Mhz, but cgminer's hash rate will only slowly climb back to original hashrate in about 10 minutes

I take it you arent using auto-gpu with a clockspeed range then. If you are, it doesnt start at 900, it will start at whatever you configured as lowest in the range (say 700-1000 in my case) and then slowly increase back to 1GHz. Same behavior as when it overheats. So its not the average hashrate Im talking about, its the clock.

leveer
Jr. Member
*
Offline Offline

Activity: 42


View Profile
February 22, 2012, 11:44:29 AM
 #4159

Any chance the pool settings could be stored in a separate configuration file? It would sure make changing those in bulk/on multiple rigs a lot easier, when my pool preference order changes... distribute one pools.conf to each rig.

It also would be nice to have an ability to re-order pools from within cgminer.

I've got 3 BTC in bounty for each.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
February 22, 2012, 12:47:11 PM
 #4160

Any chance the pool settings could be stored in a separate configuration file? It would sure make changing those in bulk/on multiple rigs a lot easier, when my pool preference order changes... distribute one pools.conf to each rig.

It also would be nice to have an ability to re-order pools from within cgminer.

I've got 3 BTC in bounty for each.
Can I have the 2nd one Smiley
With the API, you simply move any pool of choice to position 0 (highest priority).
The number of moves to get the required order is at maximum, the number of pools.
How many pools do you have anyway?

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 ... 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 [208] 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!