Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(corda-connector): scp jars to nodes #621

Closed
petermetz opened this issue Mar 2, 2021 · 0 comments · Fixed by #666
Closed

feat(corda-connector): scp jars to nodes #621

petermetz opened this issue Mar 2, 2021 · 0 comments · Fixed by #666
Assignees
Labels
Corda enhancement New feature or request

Comments

@petermetz
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Right now the deploy contract endpoint only adds the jar to the class path of the connector back end, but not to the cordapp dir of the corda node itself (which must be done via SSH unfortunately, same way as with Fabric).

So this task is about adding support for that SSH/SCP mechanism that will make sure that the jars that are being sent up will also be present on the cordapp dir of the node when the request returns with a successful status code of 2xx.

Describe the solution you'd like

  • Good old SSH/SCP to the rescue. The deploy request should have a targetNodeHosts array where each item of the array is an object with keychain references in it (and possibly other necessary metdata such as the cordapp dir file path).
    This way the deploy endpoint can loop through the target node hosts, SSH into all of them and dump the jars in the right location for the corda nodes to pick it up.
  • The jars, when uploaded to the Corda node should be named after their own base64 content's hash so that it's trivial to detect duplication.
  • Need to look into how class conflicts are handled by corda, e.g. what if different versions of the same jar get uploaded and they both have certain classes? Do we need to take care to override those or does corda have some mechanism for taking care of this and we can just dump whatever we have in the cordapp dir?

Describe alternatives you've considered

A bunch! This has been going on for months in terms of design/research...
Looked into braid, looked into corda attachments, etc. Nothing seems to provide the necessary flexibility that we want so it's just SSH for now, gets the job done and with the keychain mechanism in place we don't have to sacrifice security either.

Additional context

Right now the deploy contract endpoint only works if the jar is already present in the cordapp dir of the node so this is why we need this enhancement.

cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo

@petermetz petermetz added the enhancement New feature or request label Mar 2, 2021
@petermetz petermetz self-assigned this Mar 2, 2021
petermetz added a commit to petermetz/cacti that referenced this issue Mar 17, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 19, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 19, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 23, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 24, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 24, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 25, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 25, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 26, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit that referenced this issue Mar 26, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes #621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
jordigiam pushed a commit to kikoncuo/cactus that referenced this issue Apr 8, 2021
Implements transferring the cordapp jar files onto
Corda nodes via SSH+SCP.
It supports deploying to multiple nodes in a single request
via an array of deployment configuration parameters that
the caller can specify.
Credentials are travelling on the wire in plain text right
now which is of course unacceptable and a follow-up
issue has been created to rectify this by adding keychain
support or some other type of solution that does not
make it necessary for the caller to send up SSH and RPC
credentials with their deployment request.

Another thing that we'll have to fix prior to GA is that
right now there is no SSH host key verification.

For development mode Corda nodes:
There's possibility to declare which cordapp jar contains
database migrations for H2 and the deployment endpoint
can run these as well.

The graceful shutdown method is implemented on our
RPC connection class because this is not yet supported
on the version of Corda that we are targeting with the
connector (v4.5).

The new test that verifies that all is working well is
called deploy-cordapp-jars-to-nodes.test.ts and
what it does is very similar to the older test
called jvm-kotlin-spring-server.test.ts but this one
does its invocations with a contract that has been
built and deployed from scratch not like the old
test which relied on the jars already being present in the
AIO Corda container by default.

The current commit is also tagged in the container registry as:
hyperledger/cactus-connector-corda-server:2021-03-16-feat-621

Fixes hyperledger-cacti#621

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Corda enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant