--- canonical: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/slides-en/5-command-line-en.pptx --- # PowerPoint Converted to Markdown Source: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/slides-en/5-command-line-en.pptx ## Slide 1: SafeKit CLI - Command Line Interface ### Speaker notes > These slides are timed and automatically move from one to the next after a delay. To remove this automation: Go to 'Slide Show' and uncheck 'Use Timings’. > The slides have a soundtrack represented by an audio icon on the right side of each slide. To remove the soundtrack, click on each audio icon and lower the volume to the minimum. > I am going to present the command line interface of SafeKit, which includes the configuration of the cluster, the configuration of modules, and the monitoring and control of these modules. ## Slide 2 - Overview ### Speaker notes > Let’s start with an overview. ## Slide 3: Command line interface - Multiple uses - Command line administration - Automation via scripts - Rich interface - Configure the cluster - Deploy modules, start/stop/monitor them - 1 - 2 - 3 ### Speaker notes > As shown in the table on the right, all commands are prefixed by safekit followed by arguments. The safekit command is available on Windows in the C drive and the /safekit directory. On Linux, the safekit command is found in the /OPT/safekit directory. > On Windows, the SYSTEM account, administrators, and safewebserver can execute SafeKit commands. On Linux, the root user and the safekit user (the user under which the safewebserver runs) can execute SafeKit commands. > SafeKit provides powerful command line administration, enabling an administrator to manage the cluster efficiently through a command prompt or a shell. Additionally, the command line can be useful for automating configuration and startup processes via scripts. > The interface is rich and simplifies the process of configuring the cluster globally on all nodes, as well as deploying various modules, and manage their starting, stopping, and monitoring. ## Slide 4 - Configure the SafeKit Cluster ### Speaker notes > Let’s now examine how to configure the cluster. ## Slide 5: Scenario of the following slides - Edit the cluster configuration on node1 - Apply it on node1 and node2 - Check the result - 1 - 2 - 3 ### Speaker notes > In the next slides, we will explain the three steps of the cluster configuration process. First, edit the configuration on node 1. Second, apply the configuration on node 1 and node 2. Third, verify the results. ## Slide 6: Cluster configuration - Step 1/3 on node1 - Edit the cluster configuration - Log in as administrator/root on node 1 - Open a system console (PowerShell, shell,…) - Edit SAFEVAR/cluster/cluster.xml - - - - - - - - - - - - - ### Speaker notes > Let’s start with the editing of the cluster configuration. > Begin by logging in as an administrator or root user on node 1. This will give you the necessary permissions to edit the cluster.xml file. > Open a PowerShell, a shell, or any preferred command-line interface. > Navigate to the var/cluster directory of SafeKit and edit the cluster.xml file on node 1. > In the cluster.xml example, you can see the definition of two LANs or Local Area Networks between two nodes. The first LAN is named "default," and the second one is named "private". The IP addresses of both nodes on each LAN are provided. > By default, there is a single LAN. However, a second LAN can be useful if you wish to set up a dedicated replication network on a private network. ## Slide 7: SAFEVAR/cluster/cluster.xml - - - - - - - - - - - Logical name of the lan - name referenced in the modules configuration - Logical name of the node - IP address or DNS name of the node. - prefer IP address to be resilient to DNS failure ### Speaker notes > Let's take a closer look at the essential configuration of the cluster.xml file. This configuration defines two key elements: the logical name of the LAN and the logical name of the nodes, along with their IP addresses or DNS names. > The logical name of the LANs will be referenced when configuring modules, for example, to define where to pass heartbeats and the replication flow. The logical names of the nodes will be displayed in the console, used in the distributed commands and in the SafeKit framework to identify the nodes. > For the address field, it is advisable to use IP addresses to ensure resilience against DNS failures. ## Slide 8: Cluster configuration - Step 2/3 on node1 - Apply the cluster configuration on all nodes - Change directory to SAFE on node 1 - Check the configuration without applying it - safekit cluster confcheck SAFEVAR/cluster/cluster.xml - Apply the configuration on node1 - safekit cluster config - => Configure and create new cryptographic key, for communication between cluster nodes - Export the configuration on all nodes - safekit –H "*" -G - (–H "*" for running the command on all nodes defined in cluster.xml) - => Apply and export the cluster configuration and cryptographic key ### Speaker notes > Now let’s go to the second step, which consists of applying the cluster configuration on all nodes. > Let's begin by changing the directory to the root directory of SafeKit on node 1, where the safekit command is located. > Then, check the configuration without applying it. This can be done using the safekit cluster confcheck command. This command ensures that the local cluster.xml file is correct and ready to be applied. > Next, we can apply the configuration on node 1. Use the safekit cluster config command. This step will configure the cluster on node 1 and create a new cryptographic key for secure communication between cluster nodes. > Once the configuration is applied on node1, we need to export it to all nodes. This can be achieved with the command: safekit dash H star dash G. > The dash H star option runs the command on all nodes defined in the cluster.xml file. > This last step will apply and export the cluster configuration and the cryptographic key to all nodes. ## Slide 9: Cluster configuration - Step 3/3 on node1 - Check the result - Check the configuration on all nodes - safekit –H "*" cluster confinfo - Node Signature Date Lock - node1 417453d0caf10e9dc5122dd8335c0e4d2d700991 09-08T15:25:24 0 - node2 417453d0caf10e9dc5122dd8335c0e4d2d700991 09-08T15:25:24 0 - => Signatures must be identical. If not, the cluster does not work properly - Check license on all nodes - safekit –H "*" level - Host : node1 - OS : Microsoft Windows Server Standard [64-bit] (10.0.17763 ) Server - SafeKit : 7.5.0.13 - License : NO license : Demo 3 days - Host : node2 - … ### Speaker notes > Let’s finish with the third step, which consists of checking the result. > To do this, use the safekit cluster confinfo command, applied to all nodes with the the dash H star. > It is important that the signatures are the same on all nodes; otherwise, the cluster will not work properly. > You can also check the license keys on all nodes with the safekit level command, applied to all nodes with the the dash H star option. ## Slide 10 - Configure a SafeKit Module ### Speaker notes > Let’s now consider the configuration of a module. ## Slide 11: Scenario of the following slides - Install a module on node1 - Configure the module on node1 - Start and stop the module on node1 - 1 - 2 - 3 - Install and configure the module on node2 from node1 - Start the module on node1 and node2 - Stop the module on node1 and node2 - 4 - 5 - 6 ### Speaker notes > In the next slides, we will explain a scenario with six steps. > In step 1, we will install a module on node1. > In step 2, we will configure the module on node1. > In step 3, we will start and stop the module on node1. > In step 4, we will install and configure the module on node2 from node1. > In step 5, we will start the module on node 1 and node 2. > In step 6, we will stop the module on node 1 and node 2. ## Slide 12: Module configuration - Step 1/6 on node1 - Install a module on node1 - Log in as administrator/root - Open a system console (PowerShell, shell,…) - Change directory to SAFE - Install a module, named AM, from the generic mirror module template - safekit module install –m AM SAFE/Application_Modules/generic/mirror.safe - Install a module, named AM, from the generic farm module template - safekit module install –m AM SAFE/Application_Modules/generic/farm.safe - The module is installed in SAFE/modules/AM/ ### Speaker notes > Let's start with the first step of our scenario, which involves installing the module on node 1. > Firstly, log in as an administrator or root user on node 1. This will give you the necessary permissions to execute the safekit command. > Secondly, open a PowerShell, a shell, or any other command-line interface that you are comfortable with. > Thirdly, navigate to the root directory of SafeKit where the safekit command is located. > Fourthly, with the safekit module install command, install a mirror module named AM, from the generic mirror.safe template. Instead of AM, you can choose the name that best suits you to identify your module. > Fifthly, alternatively, install a farm module named AM, from the generic farm.safe template. > Sixthly, the module is installed on node 1 in the modules directory under a subdirectory named AM, the parameter given during the installation command. ## Slide 13: Module configuration - Step 2/6 on node1 - Configure the module on node1 - Edit module XML configuration file to set hearbeats, virtual IP… - SAFE/modules/AM/conf/userconfig.xml - Edit module scripts to insert the start/stop of the application - SAFE/modules/AM/bin/start_prim and stop_prim (mirror module) - SAFE/modules/AM/bin/start_both and stop_both (farm module) - Manage encryption of the module internal communications (optional) - Enable encryption with a new cryptographic key - safekit module genkey –m AM - Disable encryption - safekit module delkey –m AM - Apply the configuration locally - safekit config –m AM - Apply it every time userconfig.xml, scripts or key are changed - Stop the module before configuring ### Speaker notes > Let's move on to step 2 of our scenario, which involves configuring the module on node1. > Firstly, edit the module XML configuration file to set parameters such as heartbeats and virtual IP address. This can be done by editing the userconfig.xml file located in the modules directory. > Secondly, you will find the module scripts, also located in the modules directory, which contain the start and stop commands for the application. These scripts should not be changed in most cases, as they are already pre-configured either to restart services defined in userconfig.xml, or to reboot the virtual machine, also defined in the userconfig.xml file for the Hyper-V or KVM modules. > For a mirror module, the scripts are named startprim and stopprim. The startprim script will be executed only on the primary node in the mirror module. For a farm module, the scripts are named startboth and stopboth. The startboth script will be executed on all nodes of the farm module. > Thirdly, manage encryption of the module's internal communications. This is optional, but encrypting communications of a module like heartbeats or replication is better. To enable encryption with a new cryptographic key, use the safekit module genkey command. To disable encryption, use the safekit module delkey command. You need to generate the key only once and not at each configuration. You can also use the genkey command to regenerate new keys. > Fourthly, apply the configuration locally using the safekit config command. This step should be repeated every time the userconfig.xml, scripts, or keys are changed. Remember to stop the module before configuring. ## Slide 14: Module configuration - Step 3/6 on node1 - Start and stop the module on node1 - Start on node1 with - Optional. Wait for the startup with safekit waitstart –m AM - Stop with safekit stop –m AM - Optional. Wait for the stop with safekit waitstop –m AM ### Speaker notes > Let's proceed to step 3 of our scenario, which involves starting and stopping the module on node1. > Firstly, start the module using the appropriate command. > For a mirror module, use the safekit prim command on the first startup to force the start as primary of the node with the up-to-date replicated directories. The other node, upon its own startup, will resynchronize its data from the primary node before becoming secondary. For subsequent startups, use the safekit start command because SafeKit remembers the node with the up-to-date data. > For a farm module, use the safekit start command. > Secondly, optionally, you can wait for the startup to complete by using the safekit waitstart command. > Thirdly, stop the module with the safekit stop command. > Fourthly, optionally, you can wait for the stop to complete by using the safekit waitstop command. ## Slide 15: Module configuration - Step 4/6 on node1 - Install and configure the module on node2 from node1 - If not already done, change firewall rules on both nodes - See "Installation" slides - List of ports used safekit module getports –m AM - Export AM on node2 - safekit –H "node2" -E AM - (–H "node2" for running the command node2 as defined in cluster.xml) - => Install and configure AM on node2 (including cryptographic key) - List the cluster state for installed modules - safekit –H "*" cluster state - (–H "*" for running the command on all nodes defined in cluster.xml) - Node Module Mode Id Date Signature - node1 AM mirror 1 09-14T16:29:18 689a4f1bdbe8c8ef84f8e537a87cfd08d19b26af - node2 AM mirror 1 09-14T16:29:21 689a4f1bdbe8c8ef84f8e537a87cfd08d19b26af - => Signatures and module id must be identical. If not, the module does not work properly ### Speaker notes > Let's move on to step 4 of our scenario, which involves installing and configuring the module on node2 from node1. > Firstly, if not already done, change the firewall rules on both nodes. Refer to the Installation slides for detailed instructions. You can also list the ports used by the module by running the safekit module getports command. > Secondly, export the module named AM to node2, using the command: safekit "dash H node2" "dash E AM" . The "dash H node2" option specifies that the command should be run on node2 as defined in the cluster.xml file. This step will install and configure the module on node2, including the cryptographic key. > Thirdly, list the cluster state with its installed modules by running the safekit cluster state command. The "dash H star" option specifies that the command should be run on all nodes defined in the cluster.xml file. The output will show the state of modules in the cluster, including node name, module name, mode, ID, date, and signature. It is crucial that the signatures and module IDs are identical on all nodes; otherwise, the module will not work properly. ## Slide 16: Module configuration - Step 5/6 on node1 - Start the module on node1 and node2 - Individual start - Optional. Wait for the end of the start with safekit –H "node1" waitstart -m AM - Global start - safekit –H "node1,node2" start -m AM - (–H "node1,node2" for running the command on node1 and node2 as defined in cluster.xml) - => For a mirror module, node1 becomes PRIM (if last up-to-date); node2 becomes SECOND - => For a farm module, node1 and node2 become UP ### Speaker notes > Let's proceed to step 5 of our scenario, which involves starting the module on both node1 and node2. Thanks to the dash H option, you can start the module on both nodes from a single node, node1 in our scenario. > You have two options for starting the module. > Option 1 is an individual start where you can start the module on each node individually. For a mirror module, start first the node with the most up-to-date data with the safekit prim command. In this example, node1 is supposed to be this node. For subsequent startups, use the safekit start command since SafeKit retains the most up-to-date node. Then start the module on node2 with the safekit start command. Node2 will synchronize data from node1 and become secondary. For a farm module, start the nodes in any order with the safekit start command and by specifying the node name in the dash H option. Optionally, you can wait for the startup to complete by using the safekit waitstart command. > Option 2 is a global start where you can start the module on both nodes simultaneously. Use the safekit start command. The option, "dash H node1 node2", specifies that the command should be run on both node1 and node2 as defined in the cluster.xml file. For a mirror module, node1 will become the primary with the PRIM state, if it has the most up-to-date data, and node2 will become the secondary with the SECOND state. For a farm module, both node1 and node2 will become active with the UP state. ## Slide 17: Module configuration - Step 6/6 on node1 - Stop the module on node1 and node2 - Individual stop - Optional. Wait for the end of the stop with safekit –H "node2" waitstop -m AM - Global stop - safekit –H "node1,node2" stop -m AM - => For a mirror module, you may have an unnecessary failover if node1 (PRIM) is stopped before node2 (SECOND) ### Speaker notes > Let's move on to step 6 of our scenario, which involves stopping the module on both node1 and node2. Once again, thanks to the dash H option, you can stop the module on both nodes from a single node, node1 in our scenario. > You have two options for stopping the module. > Option 1 is an individual stop where you can stop the module on each node individually. For a mirror module, stop first the secondary node to avoid an unnecessary failover. In this example, run safekit stop on node2 first. Then, run safekit stop on node1. For a farm module, stop the nodes in any order with the safekit stop command and by specifying the node name in the dash H option. Optionally, you can wait for the stop to complete by using the safekit waitstop command. > Option 2 is a global stop where you can stop the module on both nodes simultaneously. Use the safekit stop command. The option,  dash H "node1,node2", specifies that the command should be run on both node1 and node2 as defined in the cluster.xml file. With a global stop and for a mirror module, you may have an unnecessary failover, if node1 in the PRIM state is stopped before node2 in the SECOND state. ## Slide 18 - Control and Monitor ### Speaker notes > Let’s now consider the main commands to control and monitor a module. ## Slide 19: Control modules - safekit help for a list of all commands ### Speaker notes > Here are some essential commands you need to know to control your modules effectively. > Note that to get a list of all commands, use safekit help. > As already discussed in the previous scenario, the safekit start and safekit stop commands start and stop a module. > To stop all running modules and wait for their stops, you can use the safekit shutdown. > Some special commands are available for a mirror module and they must be used in special cases only. > To force the module to start as primary even if it does not have the most up-to-date data, the safekit prim command can be used. > To force the module to start as secondary, the safekit second command can be used. > To force the module to start as secondary with a full resynchronization of replicated directories, the safekit second fullsync command can be used. ## Slide 20: Monitor _No extractable slide text found._ ### Speaker notes > Here are some essential commands you need to know to monitor your modules effectively. > To check the SafeKit version and license, use the safekit level command. > To get the state of a module, use the safekit state command. The dash v option returns the resource states in addition to the module state. > To reduce the output to the synthetic state of a module with an exit code, use the dash lq option. This can be useful for scripting SafeKit commands. > For the logs, you can view the last messages of the module log in real-time with the safekit logview command. The dash A option displays all messages. > To save the module log to a file, use the safekit logsave command. > Additionally, the outputs of the module script executions are saved in the var/modules directory. A file is created for each script execution with the date of its execution and the script name. ## Slide 21: Other useful commands _No extractable slide text found._ ### Speaker notes > Here are other useful commands. > For maintenance operations that require stopping the application monitored by SafeKit, it may be necessary to disable all automatic restarts triggered by SafeKit. > First, for a mirror module, stop the module on the secondary node to avoid a failover on this node. > Then, as shown in the first table, disable the checkers configured inside the module that monitor the application and trigger restarts. > Next, disable process monitoring, which also triggers restarts. > Finally, disable the automatic startup of the module at boot to ensure that the application integrated into the module will not start at boot with the module startup. > Please note that disabling monitoring is permanent, even after a node's reboot. Therefore, you must re-enable everything once the maintenance is completed. > As shown in the first table, you have a resource for each case indicating whether it is enabled or disabled. > In the system logs, as shown in the second table, you can retrieve SafeKit events in the Windows event log with the Get-EventLog command, and with the journalctl command on Linux. ## Slide 22: Thank you ! _No extractable slide text found._ ### Speaker notes > Thank you for your attention. If you have any questions or need further clarification, please feel free to ask.