Authenticating External Configuration Files
Prior to Cisco ESC Release 4.0, ESC supports several external configuration files and scripts as part of day 0 configuration, monitoring, deployment and LCS actions. ESC supports getting these files from a remote server with or without authentication as part of the deployment.
Starting from ESC Release 4.0, the file locator attribute is defined at the deployment level, that is, directly under the deployment container. This allows multiple VM groups and their day 0 configuration and LCS actions to reference the same file locator wherever needed within the deployment.
Sample deployment data model is as follows:
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant>
<name>sample-tenant</name>
<deployments>
<deployment>
<name>sample-deployment</name>
<file_locators>
<file_locator>
<name>post_deploy_alive_script</name>
<remote_file>
<file_server_id>http-my-server</file_server_id>
<remote_path>/share/qatest/vnfupgrade/lcspostdeployalive.sh</remote_path>
<local_target>vnfupgrade/lcspostdepalive.sh</local_target>
<persistence>FETCH_ALWAYS</persistence>
<properties/>
</remote_file>
</file_locator>
<file_locator>
<name>asa-day0-config</name>
<remote_file>
<file_server_id>http-my-server</file_server_id>
<remote_path>/share/qatest/day0/asa_config.sh</remote_path>
<local_target>day0.1/asa_config.sh</local_target>
<persistence>FETCH_ALWAYS</persistence>
</remote_file>
</file_locator>
<file_locator>
<name>scriptlocator</name>
<remote_file>
<file_server_id>dev_test_server</file_server_id>
<remote_path>/share/users/gomoore/actionScript.sh</remote_path>
<local_target>action/actionScript.sh</local_target>
<persistence>FETCH_MISSING</persistence>
<properties/>
</remote_file>
</file_locator>
</file_locators>
<policies>
<policy>
<name>VNFUPGRADE_POST_DEPLOY_ALIVE</name>
<conditions>
<condition>
<name>LCS::POST_DEPLOY_ALIVE</name>
</condition>
</conditions>
<actions>
<action>
<name>post_deploy_alive_action</name>
<type>SCRIPT</type>
<properties>
<property>
<name>file_locator_name</name>
<value>post_deploy_alive_script</value>
</property>
</properties>
</action>
</actions>
</policy>
</policies>
<vm_group>
<name>ASA-group</name>
<image>ASAImage</image>
<flavor>m1.large</flavor>
<recovery_policy>
<max_retries>1</max_retries>
</recovery_policy>
<scaling>
<min_active>1</min_active>
<max_active>1</max_active>
<elastic>true</elastic>
</scaling>
<placement>
<type>affinity</type>
<enforcement>strict</enforcement>
</placement>
<bootup_time>120</bootup_time>
<recovery_wait_time>60</recovery_wait_time>
<interfaces>
<interface>
<nicid>0</nicid>
<network>my-net</network>
</interface>
</interfaces>
<kpi_data>
<kpi>
<event_name>VM_ALIVE</event_name>
<metric_value>1</metric_value>
<metric_cond>GT</metric_cond>
<metric_type>UINT32</metric_type>
<metric_occurrences_true>1</metric_occurrences_true>
<metric_occurrences_false>5</metric_occurrences_false>
<metric_collector>
<nicid>0</nicid>
<type>ICMPPing</type>
<poll_frequency>5</poll_frequency>
<polling_unit>seconds</polling_unit>
<continuous_alarm>false</continuous_alarm>
</metric_collector>
</kpi>
</kpi_data>
<rules>
<admin_rules>
<rule>
<event_name>VM_ALIVE</event_name>
<action>ALWAYS log</action>
<action>TRUE servicebooted.sh</action>
<action>FALSE recover autohealing</action>
</rule>
</admin_rules>
</rules>
<config_data>
<configuration>
<dst>ASA.static.txt</dst>
<file_locator_name>asa-day0-config</file_locator_name>
</configuration>
</config_data>
<policies>
<policy>
<name>SVU1</name>
<conditions>
<condition><name>LCS::DEPLOY_UPDATE::PRE_VM_VOLUME_DETACH</name></condition>
</conditions>
<actions>
<action>
<name>LOG</name><type>pre_defined</type>
</action>
<action>
<name>pre_vol_detach</name>
<type>SCRIPT</type>
<properties>
<property>
<name>file_locator_name</name>
<value>scriptlocator</value>
</property>
<property>
<name>exit_val</name>
<value>0</value>
</property>
</properties>
</action>
</actions>
</policy>
</policies>
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>
</esc_datamodel>You must configure a remote server (file server) separately using the APIs before performing any deployment. Both REST and NETCONF APIs are supported
-
A remote server with URL, authentication details including username, and password. You can either use REST or NETCONF to configure.
Note
The username and password are optional. The password is encrypted within ESC.
You must configure the remote file server before deployment. You can update the credentials anytime during the deployment.
-
File locator is added to the deployment data model. It contains a reference to the file server, and the relative path to the file to be downloaded.
To get files remotely with authentication, you must
-
Add a remote server.
-
Refer the remote server in the file locator. The file locator is part of config data in day 0 and LCS action blocks.
-
The day 0 and lifecycle stage (LCS) scripts will then be retrieved based on the file locator as part of the deployment.
The file server parameters include:
-
id—used as the key and identifier for a file server.
-
base_url—the address of the server. (e.g. http://www.cisco.com or https://192.168.10.23)
-
file_server_user—the username to use when authenticating to the server.
-
file_server_password—string containing the password for authenticating to the server. Initially the user provides a cleartext string, which is encrypted internally.
-
properties—name-value pair for extensibility in the future.
The file locator parameters include:
-
name—used as the key and identifier for a file locator.
-
local_file or remote_file—choice of file location. Local file is used to specify a file existing on the ESC VM file system already. The remote_file is used to specify a file to fetch from a remote server.
-
file_server_id—id of the File Server object to fetch the file from.
-
remote_path—path of the file from the base_url defined in the file server object.
-
local_target—optional local relative directory to save the file.
-
properties—name-value pairs of of information that may be required.
-
persistence—options for file storage. Values include CACHE, FETCH_ALWAYS and FETCH_MISSING (default).
-
-
checksum—optional BSD style checksum value to use to validate the transferred file's validity.
The file server values such as server connectivity, file existence, checksum and so on will be verified for validity.
The encrypted_data values in the file_server_password and properties encrypted_data fields are encrypted using AES/128bits in CFB mode for transmission.The data remains encrypted until it is required for accessing the server. For more information on encrypted values, see Encrypting Configuration Data.
Example of file servers,
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<file_servers>
<file_server>
<id>server-1</id> <!-- unique name for server -->
<base_url>https://www.some.server.com</base_url>
<file_server_user>user1</file_server_user>
<file_server_password>sample_password</file_server_password> <!-- encrypted value -->
<!-- properties list containing additional items in the future -->
<properties>
<property>
<name>server_timeout</name>
<value>60</value> <!-- timeout value in seconds, can be over-ridden in a file_locator -->
</property>
</properties>
</file_server>
<file_server>
<id>server-2</id>
<base_url>https://www.some.other.server.com</base_url>
<properties>
<property>
<name>option1</name>
<encrypted_value>$8$EADFAQE</encrypted_value>
</property>
</file_server>
</file_servers>
</esc_datamodel>Example for day 0 configuration
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants><tenant>
<name>sample-tenant</name>
<deployments><deployment>
<name>sample-deployment</name>
<vm_group>
<name>sample-vm-group</name>
<config_data>
<!-- exisiting configuration example - remains valid -->
<configuration>
<file>file:///cisco/config.sh</file>
<dst>config.sh</dst>
</configuration>
<!-- new configuration including use of file locators -->
<configuration>
<dst>something</dst>
<file_locators>
<file_locator>
<name>configlocator-1</name> <!-- unique name -->
<remote_file>
<file_server_id>server-1</file_server_id>
<remote_path>/share/users/configureScript.sh</remote_path>
<!-- optional user specified local silo directory -->
<local_target>day0/configureScript.sh</local_target>
<!-- persistence is an optional parameter -->
<persistence>FETCH_ALWAYS</persistence>
<!-- properties in the file_locator are only used for
fetching the file not for running scripts -->
<properties>
<property>
<!-- the property name "configuration_file" with value "true" indictates this is the
script to be used just as using the <file> member case of the configuration -->
<name>configuration_file</name>
<value>true</value>
</property>
<property>
<name>server_timeout</name>
<value>120</value> <!-- timeout value in seconds, overrides the file_server property -->
</property>
</properties>
</remote_file>
<!-- checksum is an optional parameter.
The following algorithms are supported: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 -->
<checksum>SHA256 (configureScript.sh) = dd526bb2c0711238ec2649c4b91598fb9a6cf1d2cb8559c337c5f3dd5ea1769e</checksum>
</file_locator>
<file_locator>
<name>configlocator-2</name>
<remote_file>
<file_server_id>server-2</file_server_id>
<remote_path>/secure/requiredData.txt</remote_path>
<local_target>day0/requiredData.txt</local_target>
<persistence>FETCH_ALWAYS</persistence>
<properties/>
</remote_file>
</file_locator>
</file_locators>
</configuration>
</config_data>
</vm_group>
</deployment></deployments>
</tenant></tenants>
</esc_datamodel>For more details on day 0 configuration and LCS actions, see day 0 configuration, and Redeployment Policy sections.
Feedback