The CLI command (solana program deploy) doesn't seem to permit offline signing.
Is there any other way to deploy a solana program without putting the contract authority on an internet-connected computer?
It's almost possible. You'll need to follow the instructions for deploying to a buffer before performing the upgrade in one transaction.
Essentially, you have a hot key write the program buffer with solana program write-buffer, and then the upgrade authority only authorizes the upgrade transaction with solana program deploy --program-id <> --buffer <>.
It wouldn't be a lot of work to add the sign_only flag to the deploy command to have the last bit done offline. Feel free to submit an issue for that! https://github.com/solana-labs/solana/issues
More information at: https://docs.solana.com/cli/deploy-a-program#using-an-intermediary-buffer-account
Related
I'm starting to build a dapp on Aptos and I notice that there are two development networks, devnet and testnet. What are the differences between these two?
Update - 2022-01-26: Previously the testnet faucet required the user to complete a captcha. This is no longer true, the faucets of both networks work similarly, so that section has been removed from the answer.
Release cadence
Devnet is generally released every week. Testnet is generally released every two weeks, after devnet.
This means devnet gets new features sooner and more frequently.
Persistence
With devnet, the chain is reset every release. All data is wiped, including any deployed modules, accounts, etc. and the chain restarts from genesis with a new chain ID. If you're building on devnet this means you must redeploy your Move modules and accounts every week.
Testnet is never wiped, similar to mainnet.
Faucet access
On both devnet and testnet you can create new accounts and get new APT easily by either:
Using the "Faucet" button in your wallet (e.g. in Petra).
Using the FaucetClient in the SDK.
Using the aptos CLI:
aptos account fund-with-faucet --account 0xd0f523c9e73e6f3d68c16ae883a9febc616e484c4998a72d8899a1009e5a89d6
Hitting the faucet directly:
curl -X POST 'https://faucet.devnet.aptoslabs.com/mint?amount=100&address=0xd0f523c9e73e6f3d68c16ae883a9febc616e484c4998a72d8899a1009e5a89d6'
Which should you use?
Generally speaking testnet is a friendlier developer experience because you don't need to keep redeploying your code / recreating accounts. For standard development the amount of APT the testnet faucets give you should be more than sufficient.
Devnet is good for rapid experimentation where you don't care about data persistence or if you're running tests that require programmatic access to APT.
I tried posting this on ask.openstack but it has been stuck in the moderator for 5 days now. I thought I'd try here.
I was trying to debug a Nova issue and wanted to decode the SSL / TLS packets being exchanged using Wireshark. Part of the changes I was making was setting Nova up to use SSL / TLS and I wanted to be sure that part of it I had set correctly. I eventually figure out my issues from the various log files but I'm somewhat assuming that being able to watch the network traffic may help in some very difficult cases.
The exchange uses TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at one point. According to this security stackexchannge question, there is a "pre-master secret" or various other terms. I've wrestled with this before in a previous life doing IPSec. Usually you can set debug in the application and it will spew out the secret into the log file. I tried "debug = true" under Default in nova.conf and got lots of debug but no secret. There was two items that looked interesting that were reported as **** in the log: keystone_authtoken.memcache_secret_key and neutron.metadata_proxy_shared_secret. I wasn't sure if those were the secrets I was looking for or not. In this case, I'm looking at the nova-api traffic going to port 8774.
Also, since all of openstack is Python and uses the same "request" and "certifi" packages, it may be possible to generalize this to all of the openstack components.
nova --version report 9.1.1
I'm having a problem with a Solaris server I inherited that has been happening for years. (The release is Solaris 10 5/09 s10x_u7wos_08 X86)
Every few seconds in my /var/adm/messages file I get the following line:
httpd[2910]: [ID 218067 user.debug] pkcs11_softtoken: Keystore access failed
I'm pretty sure this is what is causing my core dumps that are filling up my hard drive causing my database to stop functioning, so I'd love to figure this out.
My apologies if I did not provide enough information, I really have no clue what the error means so I don't know what would be relevant to post. Thanks!
Disclaimer: I am a programmer by profession, not a server administrator... so please be gentle.
If you do not store certificates in Solaris PKCS11 token, then simply disable/comment SSLCryptoDevice pkcs11 in Apache config. Note that Solaris PKCS11 token do correctly work just with Solaris bundled OpenSSL. On X86 it doesn't bring much performance improvement too, to use this token. On SPARC since T1 it has its meaning, cause there are hardware accelerators on CPU. Refer to man cryptoadm for Solaris token details.
I'm experimenting with the Distributed Shell example in YARN 2.2 and am hoping that someone can clarify what the difference between a managed and and an un-managed application manager is?
For example the following lines appear in the client code
// unmanaged AM
appContext.setUnmanagedAM(true);
but I am unable to find documentation explaining the difference this line makes to the execution behaviour.
Many thanks.
The setUnmanagedAM(true) is used for debugging purposes i.e. it runs an application manager in local mode and does not submit it to a cluster so it is easier to step into code and debug.
You can see it in use in the hadoop-yarn-applications-unmanaged-am-launcher.jar that ships with yarn
Check the respective JIRA tickets: JIRA-420 and JIRA-419 (client side)
Currently, the RM itself manages the AM by allocating a container for it and negotiating the launch on the NodeManager and manages the AM lifecycle. Thereafter, the AM negotiates resources with the RM and launches tasks to do the real work.
It would be a useful improvement to enhance this model by allowing the AM to be launched independently by the client without requiring the RM. These AM's would be launched on a gateway machine that can talk to the cluster. This would open up new use cases such as the following
1) Easy debugging of AM, specially during initial development. Having the AM launched on an arbitrary cluster node makes it hard to looks at logs or attach a debugger to the AM. If it can be launched locally then these tasks would be easier.
2) Running AM's that need special privileges that may not be available on machines managed by the NodeManager
Blog post with more implementation details on unmanaged AM: click-me
Example of how Impala manages its resources with the help of unmanaged applications: Llama
Our code-signing certificate recently expired. It's been renewed, but now whenever I try to package the app with the renewed cert (whether I attempt a migration of the expired cert or not), after installation, I get the following message any time I try to run the app:
"This installation of this application is damaged. Try re-installing or contacting the publisher for assistance."
Opening up the package contents, the publisherid file inside Resources/META-INF/AIR is blank. This is apparently the problem, because if I manually edit it to contain our previous publisherID, the app will run.
But of course, it's not like we can tell all our users "oh install it then manually edit this file inside the package."
Has anyone encountered this or know how to fix it?
Ah, after a bit more banging my head against my desk I got it.
For anyone who comes after me:
I had to change a couple things in my app descriptor file.
First I had to change the namespace to point at AIR 1.5.3 instead of 1.5
<application xmlns="http://ns.adobe.com/air/application/1.5.3">
And then I had to manually specify our old publisherID in the descriptor as well
<id>OurAppID</id>
<publisherID>OurOldPublisherID</publisherID>
Now it works just as it's supposed to, installs as an update to our old version instead of a new app, and actually runs instead of just throwing that error.