* An up-to-date version of the ``network-parameters`` file ([see docs:](https://docs.corda.net/network-map.html#network-parameters)) generated by the bootstrapper tool
The configuration values available in ``deployNodes`` task are as follows:
Required configuration
^^^^^^^^^^^^^^^^^^^^^^
*``name`` <string>
* The legal identity name of the Corda node. (see :ref:`myLegalName <corda_configuration_file_myLegalName>`)
* e.g.
::
name "O=PartyA,L=London,C=GB"
*``p2pAddress`` <string> <**required if p2pPort not specified**>
* The address/port the node uses for inbound communication from other nodes. (see :ref:`p2pAddress <corda_configuration_file_p2pAddress>`)
* e.g.
::
p2pAddress "example.com:10002"
*``p2pPort`` <integer>
* The port the node uses for inbound communication from other nodes. Assumes the address is ``localhost``. (see :ref:`p2pAddress <corda_configuration_file_p2pAddress>`)
* e.g.
::
p2pPort 10006 // "localhost:10006"
*``rpcSettings`` <config>
* Specifies RPC settings for the node. (see :ref:`rpcSettings <corda_configuration_file_rpc_settings>`)
* e.g.
::
rpcSettings {
port 10006
adminPort 10026
}
Optional configuration
^^^^^^^^^^^^^^^^^^^^^^
*``notary`` <config> (see :ref:`notary <corda_configuration_file_notary>`)
* Optional configuration which specifies the node is a notary.
* .. note:: <**required**> for notary nodes
*``devMode`` <boolean>
* When true enables development mode. (see :ref:`devMode <corda_configuration_file_dev_mode>`)
* e.g.
::
devMode true
*``webAddress`` <string>
* Configure a webserver to connect to the node via RPC. This will specify the address and port it will listen on. The node must have an RPC address configured. (see :ref:`Specifying a custom webserver<specify-custom-webserver>`)
* e.g.
::
webAddress "example.com:10011"
*``webPort`` <integer>
* Configure a webserver to connect to the node via RPC. Defaults the address to `localhost`. The node must have an RPC address configured. (see :ref:`Specifying a custom webserver<specify-custom-webserver>`)
* e.g.
::
webPort 10011 // "localhost:10011"
*``rpcUsers`` <list>
* Set the RPC users for this node. (see :ref:`rpcUsers <corda_configuration_file_rpc_users>`)
To extend node configuration beyond the properties defined in the ``deployNodes`` task use the ``configFile`` property with the path (relative or absolute) set to an additional configuration file.
This file should follow the standard :doc:`corda-configuration-file` format, as per node.conf. The properties from this file will be appended to the generated node configuration. Note, if you add a property already created by the 'deployNodes' task, both properties will be present in the file.
The path to the file can also be added while running the Gradle task via the ``-PconfigFile`` command line option. However, the same file will be applied to all nodes.
Following the previous example ``PartyB`` node will have additional configuration options added from a file ``none-b.conf``:
Additional properties can be also specified directly by the ``extraConfig`` property which defines a map of keys and values. The example config above uses ``extraConfig`` to set value of the ``jvmArgs`` property.
See the extended example of :ref:`adding database configuration <testing_cordform_ref>`.
To specify :doc:`design/data-model-upgrades/package-namespace-ownership` configuration, the optional ``networkParameterOverrides`` and ``packageOwnership`` blocks can be used, similar to the configuration file used in :doc:`network-bootstrapper`:
Signing the CorDapp enables its contract classes to use signature constraints instead of other types of the constraints :doc:`api-contract-constraints`.
*``all`` if set to ``true`` (by default) all CorDapps inside *cordapp* subdirectory will be signed, otherwise if ``false`` then only the generated Cordapp will be signed
*``options`` any relevant parameters of `SignJar ANT task <https://ant.apache.org/manual/Tasks/signjar.html>`_ and `GenKey ANT task <https://ant.apache.org/manual/Tasks/genkey.html>`_,
by default the JAR file is signed by Corda development key, the external keystore can be specified,
the minimal list of required options is shown below, for other options referer to `SignJar task <https://ant.apache.org/manual/Tasks/signjar.html>`_:
*``keystore`` the path to the keystore file, by default *cordadevcakeys.jks* keystore is shipped with the plugin
*``alias`` the alias to sign under, the default value is *cordaintermediateca*
*``storepass`` the keystore password, the default value is *cordacadevpass*
*``keypass`` the private key password if it's different than the password for the keystore, the default value is *cordacadevkeypass*
*``storetype`` the keystore type, the default value is *JKS*
*``dname`` the distinguished name for entity, the option is used when ``generateKeystore true`` only
*``keyalg`` the method to use when generating name-value pair, the value defaults to *RSA* as Corda doesn't support *DSA*, the option is used when ``generateKeystore true`` only
*``generateKeystore`` the flag to generate a keystore, it is set to ``false`` by default. If set to ``true`` then ad hock keystore is created and its key isused
instead of the default Corda development key or any external key.
The same ``options`` to specify an external keystore are used to define the newly created keystore. Additionally
``dname`` and ``keyalg`` are required. Other options are described in `GenKey task <https://ant.apache.org/manual/Tasks/genkey.html>`_.
If the existing keystore is already present the task will reuse it, however if the file is inside the *build* directory,
then it will be deleted when Gradle *clean* task is run.
The example below shows the minimal set of ``options`` needed to create a dummy keystore:
Contracts classes from signed CorDapp JARs will be checked by signature constraints by default.
You can force them to be checked by zone constraints by adding contract class names to ``includeWhitelist`` entry,
the list will generate *include_whitelist.txt* file used internally by :doc:`network-bootstrapper` tool.
Refer to :doc:`api-contract-constraints` to understand implication of different constraint types before adding ``includeWhitelist`` to ``deployNodes`` task.
The snippet below configures contracts classes from Finance CorDapp to be verified using zone constraints instead of signature constraints:
The ``Dockerform`` is a sister task of ``Cordform`` that provides an extra file allowing you to easily spin up nodes using ``docker-compose``. It supports the following configuration options for each node: