Central Deployment Tool
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> [MUSIC] Welcome to this lesson
00:00
on the Central Deployment Tool.
00:00
By the end of this lesson,
00:00
you will be able to describe when should CDT be used,
00:00
describe the prerequisites for deploying with CDT,
00:00
describe the process of deploying with CDT,
00:00
use CDT to perform a common use case deployment,
00:00
perform basic troubleshooting in
00:00
the CDT deployment process,
00:00
and you will be able to use CDT's RMA mode.
00:00
When should we use CDT?
00:00
CDT, the Central Deployment Tool
00:00
is a powerful command line utility,
00:00
which runs on management servers and
00:00
multi-domain management servers, running IOS.
00:00
Using a set of configuration files,
00:00
it lets you manage an offline deployment
00:00
>> of software packages from
00:00
>> your management server, or multi-domain server to
00:00
multiple managed gateways, and
00:00
cluster members at the same time.
00:00
This allows you to install software packages,
00:00
perform various actions such as taking snapshots,
00:00
running shell scripts, and pushing, and pulling files.
00:00
It allows you to automate
00:00
the RMA backup, and restore process,
00:00
and it handles cluster upgrades
00:00
automatically, including connectivity upgrade.
00:00
If you need to perform advanced automated actions
00:00
on multiple gateways,
00:00
you should definitely use CDT.
00:00
Otherwise for orchestrating the deployment
00:00
on multiple gateways,
00:00
you should use the central deployment in SmartConsole,
00:00
which is our next lesson's topic.
00:00
In terms of prerequisites,
00:00
make sure to review SK111158,
00:00
for the minimum requirements for management servers,
00:00
>> and multi-domain management servers, and
00:00
>> for gateways, and cluster members.
00:00
In general terms deploying with
00:00
CDT involves the following key steps,
00:00
importing the deployment package to
00:00
the server used for
00:00
package distribution to the gateways,
00:00
editing the Central Deployment Tool,
00:00
which defines logging, and notification settings
00:00
for the deployment process,
00:00
editing the deployment plan,
00:00
which defines a sequence of deployment actions,
00:00
generating the installation candidate list to get
00:00
a full list of deployable gateways and cluster members,
00:00
and finally, running the deployment plan.
00:00
Let's look at the following scenario and
00:00
see how we can accommodate its requirements.
00:00
Bob, a security administrator,
00:00
is in charge of maintaining
00:00
an environment of 100 gateways.
00:00
He would like to upgrade only 50 gateways, and
00:00
clusters form R80.30 to R80.40,
00:00
and deploy the latest Jumbo Hotfix
00:00
to all machines after their upgrade.
00:00
In between those actions,
00:00
Bob would like to perform additional actions,
00:00
including running scripts such as updating
00:00
the DNS address, and taking a snapshot of the system.
00:00
This deployment will be
00:00
conducted offline from a management server.
00:00
Since his deployments targets
00:00
requires an orchestration of the deployment
00:00
on multiple gateways, and includes
00:00
several advanced actions during the process,
00:00
he chooses to use CDT.
00:00
Before we begin to set up the deployment,
00:00
we first need to import
00:00
the deployment packages to
00:00
the server used for package distribution.
00:00
As we previously saw in the CPU's lesson,
00:00
we can download the packages from
00:00
the user center to the local folder on our computer,
00:00
then we transfer them to the designated server.
00:00
This can be done, for example, via SFTP.
00:00
To deploy with CDT in such a use case,
00:00
we connect to the command line on
00:00
the management server used for package distribution.
00:00
We log in using the expert mode, and
00:00
make sure that there is
00:00
no active session on SmartConsole,
00:00
which is locking the management database.
00:00
Now we proceed to edit
00:00
the central deployment tool XML file.
00:00
Bob would like to create
00:00
a comprehensive log file for the process,
00:00
so he keeps it on the default debug mode.
00:00
He would also like to receive
00:00
a summary of the deployment,
00:00
so he defines his email address
00:00
>> under mail notification.
00:00
>> This only applies if a valid mail server is
00:00
configured on the management server,
00:00
or multi-domain server,
00:00
otherwise, delete this element.
00:00
After configuring the Central Deployment Tool XML,
00:00
Bob turns to the second configuration file,
00:00
the deployment plan, which runs
00:00
a number of actions one after the other.
00:00
Bob would like to avoid
00:00
any traffic connectivity loss
00:00
of cluster members within his deployment,
00:00
so he set the connectivity upgrade to two.
00:00
This ensures the target clusters
00:00
maintain a connection failover.
00:00
At this stage of setting up your deployment,
00:00
you can choose to perform
00:00
various actions on your remote machines.
00:00
Supported actions include importing a package,
00:00
executing a command, creating a snapshot,
00:00
and installing a package.
00:00
In Bob's case, he needs to deploy
00:00
the latest Jumbo Hotfixes to
00:00
all machines after their upgrade.
00:00
In-between those actions,
00:00
additional actions need to be performed.
00:00
This includes running a script
00:00
to update the DNS address on
00:00
the gateways, and taking
00:00
a snapshot on each and every target gateway.
00:00
Now that Bob has a deployment plan,
00:00
he can create a candidate list which is
00:00
a common delimited CSV file generated by CDT,
00:00
listing the gateways on which to
00:00
install the CPU's packages.
00:00
Remember, Bob needs to select 50
00:00
out of 100 gateways for deployment.
00:00
Let's step aside for a minute and talk
00:00
about how the candidate list works.
00:00
When you generate the candidate list,
00:00
CDT scans the management servers database for
00:00
potential candidates, and creates a list
00:00
based on the gateways that
00:00
>> are eligible for installation.
00:00
>> CDT assigns a batch number to
00:00
gateways that are eligible for package installation.
00:00
It installs the packages in parallel on
00:00
all batch members that have the same batch number.
00:00
When installations on candidates
00:00
in the same batch complete,
00:00
the next batch is run.
00:00
When all the batches are completed,
00:00
the installation process is completed.
00:00
Note, that when working with clusters,
00:00
all members of the same cluster
00:00
must be in the same batch.
00:00
During candidate list process,
00:00
CDT also assigns a value of NA to
00:00
gateways that are not eligible
00:00
>> for package installation.
00:00
>> You should not change this value.
00:00
>> Additionally, CDT assigns a value of
00:00
installed to gateways on which
00:00
the requested package is already installed.
00:00
This value should not be changed as well.
00:00
Now that we're familiar with the configuration files,
00:00
let's get back to Bob.
00:00
He generates the candidate list by
00:00
executing the generate command using
00:00
a filter handle to filter in
00:00
only the 50 gateways currently installed with R80.30.
00:00
After this filtered list is created,
00:00
Bob reviews it to finalize the list.
00:00
He edits the list, and divides the gateways
00:00
>> into batches.
00:00
>> Finally, he runs
00:00
the deployment plan with the execute command.
00:00
The installation starts.
00:00
You can monitor the installation progress,
00:00
by watching the CDT_status.txt,
00:00
which is updated every five seconds.
00:00
Once the process is complete,
00:00
an email is sent to Bob summarizing the installation.
00:00
Now that we have seen how
00:00
the CDT deployment process looks like,
00:00
let's go over some use cases
00:00
that may occur during the deployment.
00:00
If there's a failure during an upgrade,
00:00
it will revert automatically
00:00
to the previous installed version.
00:00
If any action in the deployment plan that is
00:00
marked as IsCritical fails,
00:00
the execution for that failed gateway stops.
00:00
If you have set up your email address in
00:00
the Central Deployment Tool file, as Bob did,
00:00
any failure during the deployment will trigger
00:00
an email message with the details and relevant logs.
00:00
If the installation failed on some of
00:00
the gateways but continued on the remaining gateways,
00:00
CDT can try and continue the execution on
00:00
the failed gateways and
00:00
cluster members starting from the last failed stage.
00:00
In regards to clusters,
00:00
if an upgrade of
00:00
a cluster member fails during the execution,
00:00
the execution for the cluster will stop, and
00:00
the remaining members will not be upgraded.
00:00
If an upgrade of the first members succeeded,
00:00
but the upgrade of the second member failed,
00:00
the first member will not be
00:00
reverted to the previously installed version.
00:00
Speaking of issues that may arise
00:00
>> during the deployment,
00:00
>> let's briefly touch upon the log files generated
00:00
>> by CDT.
00:00
>> All logs collected from
00:00
the target machines, and logs created by CDT are saved
00:00
in one centralized location on
00:00
the management server
00:00
>> with the following path and format.
00:00
>> For further read on troubleshooting CDT issues,
00:00
please refer to the troubleshooting section of sk1, 1,
00:00
1, 1, 5, 8,
00:00
which you have of course bookmarked by now.
00:00
In this last section of the lesson,
00:00
we are going to cover a different use of
00:00
CDT called RMA mode.
00:00
This functionality is used to backup and
00:00
restore gateway software and configuration information.
00:00
This can be useful when you need to
00:00
reconfigure a replacement to a malfunctioning gateway.
00:00
Let's get back to Bob and examine his use of RMA.
00:00
Being the responsible administrator he is,
00:00
Bob would like to periodically back up
00:00
the configuration information of
00:00
the gateways he manages on a regular basis.
00:00
He first edits the central deployment tool XML file,
00:00
and specify the location of the packages
00:00
and backup files under the repository element.
00:00
Once this is defined,
00:00
Bob can go ahead and perform backups.
00:00
He would like to backup
00:00
all remote machines connected to the management server.
00:00
Therefore, he runs the RMA backup all command.
00:00
A few months later on a rainy day,
00:00
Bob discovers a malfunctioning
00:00
with one of the gateways he manages.
00:00
Luckily, he has an up-to-date RMA backup.
00:00
He would like to restore it onto
00:00
a new machine with a clean install.
00:00
Before restoring, he wants to
00:00
verify the backup info of his gateway.
00:00
He does this by executing the following command.
00:00
Bob must copy the same major version and
00:00
hotfixes found in the info command
00:00
>> to the RMA repository.
00:00
>> The path to this repository has already
00:00
been defined by Bob in the Central Deployment Tool XML.
00:00
Before executing the restore command,
00:00
he makes sure there is no active GUI client that is
00:00
locking the management's database such as SmartConsole.
00:00
Then he executes the restore command,
00:00
making sure to list
00:00
the appropriate package name to
00:00
install and the path to the package's license.
00:00
Note that gateway_name represents
00:00
the backed-up gateway to be
00:00
restored onto the new machine.
00:00
At the end of the process,
00:00
Bob needs to install policy on
00:00
the newly restored gateway. That's it.
00:00
From setting up the RMA definitions to backing up
00:00
gateway configuration information to
00:00
restoring a backup onto a new target.
00:00
For further read on RMA mode prerequisites,
00:00
check out the Central Deployment Tool admin guide.
00:00
With that, our lesson comes to a close.
00:00
You should now be able to,
00:00
describe when should CDT be used,
00:00
describe the prerequisites for deploying with CDT,
00:00
describe the process of deploying with CDT,
00:00
use CDT to perform a common use case deployment,
00:00
perform basic troubleshooting in
00:00
the CDT deployment process,
00:00
and you should be able to use CDT's RMA mode.
00:00
Thank you for taking this lesson.
00:00
I will see you in the next one.
00:00
[MUSIC]
Up Next
Instructed By
Similar Content
