Activate and deactivate blades
Platform blades can be active or inactive. Here’s how to change the active/inactive state of a blade, and a note about managing the states of mutually exclusive blades.
In the following steps you’ll be using the For a list of |
Activating a blade
-
To make inactive blades active on the server machines where they are deployed, on each server enter the command
./dfw activate <blade-name-1> <blade-name-2> <blade-name-3> ...
For example, to activate the Deployment Framework’s built-in Config blades HTTPS and LiberatorWebsite, enter
./dfw activate HTTPS LiberatorWebsite
Any resulting configuration changes don’t take effect until you restart the Deployment Framework on each of the server-machines where the blades are deployed. |
Deactivating a blade
-
To make active blades inactive on the server machines where they are deployed, on each server enter the command
./dfw deactivate <blade-name-1> <blade-name-2> <blade-name-3> ...
For example, to deactivate the Deployment Framework’s built-in Config blades HTTPS and MinimalLiberatorWebsite, enter
./dfw deactivate HTTPS MinimalLiberatorWebsite
Any resulting configuration changes don’t take effect until you restart the Deployment Framework on each of the server-machines where the blades are deployed. |
Managing mutually exclusive blades
Some blades are mutually exclusive because they provide different versions of the same feature, so you should only make one of them active at a time.
For example, these pairs of Config blades that are built into the Deployment Framework are mutually exclusive:
-
OpenPermissioning and Permissioning
-
LiberatorWebsite and MinimalLiberatorWebsite
If you do activate two mutually exclusive built-in blades, the activate command reports the clash, and you won’t be able to start the Framework.
|
You can can manage the compatibility of Platform blades that you write by adding entries to the blade control file. |
See also: