Operating a node on a 32bit system

[Alexey]

@ste

error: ping satellite: check-in ratelimit: node rate limited by id

Ping satellite: check-in ratelimit: node rate limited by id, errorVerbose": "ping satellite: check-in ratelimit: node rate limited

The satellites will apply the rate limit to nodes by Id, if they are trying to check-in too often. The storagenode would try to check-in if the satellite said that the node was not reachable after the last check-in. So, yes, it’s related to your configuration - something partially blocking access from the satellite in question. Please, check your firewall and make sure that you have not blocking the traffic from said satellite (you should not block any traffic to the port of the node), please …

@ste

and I can reach the console through http://storj.fornari.net:14002

Please, do not expose your private information without protection. Remove the port forwarding rule for the dashboard port and use either How to remote access the web dashboard - Storj Docs or [Tech Preview] Multinode Dashboard Binaries

[ste]

Thanks Alexey.
I have done some tests from the outside network and I can not see any issues on a arbitrarily picked port. It consistently transfers a file of about 100MB in 3.3sec. Do satellites or nodes cache anything that may result in such that message when switching the forwarding from the 64bit node to the 32bit one? (of course shutting down the 64 node)

Later I’ll do some more tests on storj node port, but I doubt I will see different results.

BTW I did not know the trick to reach the console via ssh, that was cool!

UPDATE: tried from another network, on the DSC port and no issues at all. I can exclude is a pure network issue. Next step I am setting up a node from scratch.

[ste]

ok, I am happy to let you know I successfully completed the migration to a 32bit system. Another caveat I had not realized at the beginning is that the default configuration layout is as follows:

├── identity
│   └── storagenode
└── storagenode
    ├── orders
    │   ├── archive
    │   └── unsent
    └── **storage**

If you change the storage.path to point to an external disk, you have to take that into account and copy in your new node the content of storagenode (orders, revocations.db, trust-cache.json).

As a final note/suggestion, I have the feeling that there are many different root causes for a satellite check-in failure. It would be great the error message could give better hints where to look at.

Thanks a lot Alexey and all have helped.

[Alexey]

@ste

If you change the storage.path to point to an external disk, you have to take that into account and copy in your new node the content of storagenode (orders, revocations.db, trust-cache.json).

It’s described in the docs in migration guides. There are described all cases, include orders and that actual node’s data (blobs, etc.) must be in storage subfolder for docker version.
The trust-cache.json is expendable and will be created on start in the --config-dir location, if you did not specify the path for it explicitly.
The orders will be placed to the --config-dir location too, if you did not specify the path for orders explicitly.

[Alexey]

The docs provider has had issues today: https://www.gitbookstatus.com/
Now it seems returned back

[heunland]

You should be still able to manually navigate to the subsections of interest. We are still waiting for gitbook to finish fixing these issues. However, though we have already reported the issue ourselves, it may be helpful if you filed an issue on their gitbook support to alert them about this problem existing for docs.storj.io links redirecting to the main page, the more people report the better I think.

[ste]

Hello,
I am now trying to build an ansible script to programmatically create or update my DCS node. To develop it, I am using a VM as target. When building the storagenode as per the above instructions, I am running into this error:

npm WARN addRemoteGit Error: Command failed: git config --get remote.origin.url
npm WARN addRemoteGit 
npm WARN addRemoteGit     at ChildProcess.exithandler (child_process.js:275:12)
npm WARN addRemoteGit     at emitTwo (events.js:126:13)
npm WARN addRemoteGit     at ChildProcess.emit (events.js:214:7)
npm WARN addRemoteGit     at maybeClose (internal/child_process.js:925:16)
npm WARN addRemoteGit     at Socket.stream.socket.on (internal/child_process.js:346:11)
npm WARN addRemoteGit     at emitOne (events.js:116:13)
npm WARN addRemoteGit     at Socket.emit (events.js:211:7)
npm WARN addRemoteGit     at Pipe._handle.close [as _onclose] (net.js:567:12)
npm WARN addRemoteGit  storj/eslint-storj resetting remote /home/frodo/.npm/_git-remotes/git-github-com-storj-eslint-storj-git-76f98687 because of error: { Error: Command failed: git config --get remote.origin.url
npm WARN addRemoteGit 
npm WARN addRemoteGit     at ChildProcess.exithandler (child_process.js:275:12)
npm WARN addRemoteGit     at emitTwo (events.js:126:13)
npm WARN addRemoteGit     at ChildProcess.emit (events.js:214:7)
npm WARN addRemoteGit     at maybeClose (internal/child_process.js:925:16)
npm WARN addRemoteGit     at Socket.stream.socket.on (internal/child_process.js:346:11)
npm WARN addRemoteGit     at emitOne (events.js:116:13)
npm WARN addRemoteGit     at Socket.emit (events.js:211:7)
npm WARN addRemoteGit     at Pipe._handle.close [as _onclose] (net.js:567:12)
npm WARN addRemoteGit   killed: false,
npm WARN addRemoteGit   code: 1,
npm WARN addRemoteGit   signal: null,
npm WARN addRemoteGit   cmd: 'git config --get remote.origin.url' }

sequence of commands:
git clone https://github.com/storj/storj.git
cd storj
git checkout v1.45.3
cd web/storagenode
npm install

I’ve never seen this error and strangely, I do not have the same error on my node.

Any ideas?
Ste

[ste]

found the answer: just the standard repository has a very old version of nodejs…