you need straight double quotes like the ones encapsulating rest of the parameters
The forum makes them curly which will throw an error
Not sure Debian will be the smoothest process as most are on Ubuntu 20
1 Like
gotcha appreciate your feedback
I ended up deleting everything and starting over from scratch. I compiled 1.18.0 instead of 1.15.1 and I was able to run a passive node.
Next step is to generate keys. I see everywhere on here that I should not generate keys on my internet connected node computer. (I am running ubuntu natively on its own computer) How do I generate keys on a different computer and then how do I use those keys for my node if my node is required by design to be connected to the internet?
Bottom line: What is the standard for key generation and usage?
In the meantime, I did generate a payment skey and vkey to give it a try. (Typing this from memory because I am AFK at the moment) If I cat the payment.skey it shows a few numbers followed by a long string of Fs. Eg. ffffffffffffffffffffffff. Is this normal? I ask because in Carlos’ SPC video it shows a normal looking key.
So I have everything setup, but now I am stuck at trying to get my core to talk to my relay and vice versa.
What is the standard way people have their topology configured? I am a small time operation so no AWS or google cloud here. I am running everything at home. So I need help that has that in mind please.
FROG, how long did it take you and others in general to say, “OK, I’m ready for mainnet.”? Let’s say people not as gifted or experienced as you - say, someone who learned from scratch during ITN period.
Or SPOs like me who are building and learning now?
Hi JT,
It takes a good amount of engagement - I recommend hanging out in the Telegram groups - both official and unofficial, as the operator community is cultured to both learn from and share with each other. This has been the most valuable for me personally - good search history too helps you look back at things you glanced at months ago - forward anything of interest to your “Saved Messages”
Mainnet is a different ballgame as we are now all targets. Proper key management - protecting your funds and your pool via cold storage and cold signing methods is critical. Make sure you are comfortable with these along with basic security measures (ed25519 or rsa 4096 password-protected SSH keys, disabling password SSH login, disabling root login, firewall config, etc).
I hope this helps.
1 Like
Yes, it does, thx.
I’m familiar with cold signing for xrp - one of the most user-unfriendliest cryptos around, ethereum too, also using encryption 4096 for my pgp key to make sure downloaded text files containing hashes of downloaded apps are legit, and then sha256sum usually to verify those downloaded apps. For ssh key I only give 400 permissions (user-read only), and never log in as root.
Got to work on ‘disabling root login’ I suppose from the server side?, and firewall config skills. I feel like I could do mainnet, but I know my server uptime and latency would suffer big time as a consequence because I’m still learning and I have no plan for redundancy or ‘plan B’ if BP fails. I need to do a lot of research on this still. Do like a VM cloud instance in which I can clone the VM and getting running on another instance while fixing my downed primary BP. I don’t know…I’ll figure out something. BP on the cloud sounds risky though, especially with a high pledge.
BP on the cloud is fine, just don’t add your signing keys to the cloud (or any hot) node.
You can follow snippets from this guide on how to lock down your SSH:
And can find how to disable root login here:
You could run a cloud node as passive under one systemd service to keep the node on tip, and in emergeny stop that service, reconfig firewall, and restart a separate service configured to run the node as as a block producer - you would need similar setups/topologies prepared for your relays so they could adapt to operate with your new block producer
1 Like
Thanks, FROG! Your help is invaluable.
1 Like