Jump to content

Cobalt

Member
  • Content count

    185
  • Joined

  • Last visited

  1. The new self-tests in version 1.2.5 take some time to complete and there are retry mechanisms built-in so you might want to give them some time to run. One of the recommended ways to find out what could be wrong would be to run "systemctl restart codiusd && journalctl -f -u codiusd". This lets you see in the real-time what is happening in the codiusd service as it runs the various self-tests.
  2. Once your old host has been inactive for a while (around a week or so based on my own experience - this "time-out" is set by the owners of CodiusHosts.com), it will be automatically removed from the list.
  3. "wsSuccess: false" means that the web-socket testing failed. You might want to check that the following lines have been added to your "/etc/nginx/conf.d/codius.conf" file (or /etc/nginx/nginx.conf if that is where you have your Codius-related block placed): map $http_upgrade $connection_upgrade { default upgrade; '' $http_connection; } Check out Nathan's tutorial for upgrading the codiusd service for detailed instructions: https://medium.com/codius/codiusd-1-2-0-upgrading-and-websocket-support-42f712a0cee9
  4. You might want to set an A-Record with the "*" wildcard instead of setting it in a CNAME record. Do note that if you intend to use a sub-domain instead, you will need to specify "*.<subdomain>" instead of just "*". Hope this helps.
  5. They will have to pry my XRPs from my cold dead fingers.
  6. You might want to take a look at the Codius Client Command Line Interface (CLI) at: https://github.com/codius/codius, specifically the upload options that are available. The options will let you have a better idea of what are currently available to an uploader of a job e.g. number of hosts to upload to. At present there does not seem to be any option to restrict by server/service uptime.
  7. If there is no random name, it means you are using an older version of moneyd, probably version 4.0.1. It would be good to update your moneyd to the latest version before repeating the steps: "npm update -g moneyd moneyd-uplink-xrp --unsafe-perm" After that, you will need to run "systemctl restart moneyd-xrp".
  8. For the BTP host of parent connector, there are a few to use but the one I am using and seems to be rather stable is "client.scyl.la". For name, you can use the default randomly generated string in parantheses (just press enter). For rippled server, you can use "wss://s1.ripple.com".
  9. On your host@home, you will need to delete or move to a backup folder the existing .moneyd.json file before running "moneyd xrp:configure --advanced".
  10. You might want to run "moneyd xrp:info" just to make sure that the new payment channel for your host@home has been created. If it hasn't been, perhaps you can retry the payment channel creation by running "moneyd xrp:configure --advanced" and specify "client.scyl.la" as the btp connector.
  11. The port redirection needed would be 443 (https). You can also configure your host to be in the DMZ but that means it will be completely exposed to the internet directly: https://www.tp-link.com/us/FAQ-28.html Regarding your hyperd going offline and other troubleshooting situations, take a look at this helpful resource by Wilson: https://ilp-ix.link/connect-to-ilp-exchange/troubleshooting
  12. It should suffice but it wouldn't hurt to have just a tad more, say around 40 XRPs in there just to avoid insufficient fund issues with moneyd. Yes, just need to enter the same secret key when prompted.
  13. You can use the same XRP Ledger account for multiple hosts. However do note that each host will require its own payment channel (to connect to the ILP connectors) and the 10 XRP reserve applies for new channel created. Just need to ensure that your account contains sufficient XRPs to begin with.
  14. It would be good to take a read of Nathan's tutorial regarding the upgrading to version 1.2.0: https://medium.com/codius/codiusd-1-2-0-upgrading-and-websocket-support-42f712a0cee9 It seems that adding Environment="CODIUS_DISABLE_SELF_TEST=true" will allow codiusd to start but in this state it won’t broadcast itself to the rest of the network, nor receive any network broadcasts. (italicised text quoted verbatim from the tutorial). and the rationale for this self-test implementation: The Codius network is growing fast, with an astounding number of hosts being launched since the announcement in June. But without consistency among hosts, it invalidates a portion of that achievement. To ensure that growth in the network is meaningful, we must enforce proper configuration for all members of the Codius network.
  15. If you refer to https://host2.soulardcodiushost.site/info, it responds with: {"fullMem":false,"acceptingUploads":true,"serverFreeMemory":18041588736,"serverUptime":143594,"serviceUptime":142705.487,"avgLoad":0.00146484375,"numPeers":6,"currency":"XRP","costPerMonth":5,"uri":"https://host2.soulardcodiushost.site","selfTestSuccess":false,"runningContracts":0} Specifically, the selfTestSuccess:false means that the new self-test (implemented in version 1.2.0/1.2.1) is failing in your host. This also results in your host not getting peered with the rest of the Codius hosts. It will be necessary to check your codiusd logs to find out why the self-test is failing and make the necessary rectifications before host2 can get peered with the rest.
×