---
canonical: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/slides-en/4-web-console-en.pptx
---
# PowerPoint Converted to Markdown
Source: https://safekit.evidian.com/wp-content/uploads/downloads_safekit/version-82/slides-en/4-web-console-en.pptx
## Slide 1: SafeKit Web Console
- Configure and monitor
### 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'm going to present the web console of SafeKit, including the configuration of the cluster, the configuration and monitoring of modules, and the securing of the console.
## Slide 2
- Overview
### Speaker notes
> Let’s start with an overview.
## Slide 3: Web console start
- Use a single console to manage all nodes
- node1
- Commands for managing the cluster
from a single console
- Connect to
node1 or node2
- node2
- Start a web browser on a SafeKit node or an external workstation
- Set the URL to http://node1:9010 or
http://node2:9010
- Log in using the 'admin' username and the password set during the installation
### Speaker notes
> You can use a single console to manage all SafeKit nodes, whether it's node 1 or node 2, and thus configure and monitor the cluster globally. Moreover, the console can run on node 1, node 2, or an external workstation.
> To connect to the nodes, follow these steps.
> In step 1, start a web browser on a node or an external workstation.
> In step 2, give the URL of any node. You can choose either node1 or node2, using its DNS name or IP address, and port 9010. The connection node of the console will relay the commands to the other node when necessary.
> In step 3, log in using the 'admin' username and the password set during the SafeKit installation on the nodes.
## Slide 4: Web console layout
- Click to collapse/expand the
navigation sidebar
- Click to monitor and control the modules
- Click to configure the cluster and modules
- Click to open the global menu
- Connection node name
as defined in cluster configuration
### Speaker notes
> The web console layout is designed to provide a seamless and efficient user experience. In the blue window's header, you first have the menu button to collapse or expand the left navigation sidebar, which includes the monitoring and configuration icons. Next, you see node 1, the connection node name of the console. The node name is defined during the cluster configuration. This helps you identify which node you are currently connected to. Finally, in the window's header, you have the three dots button, which gives access to the global menu. Here, you can access the User's Guide, set global parameters such as language or dark mode, and log out.
## Slide 5
- Configuration of the cluster
### Speaker notes
> Let’s now examine the configuration of the cluster.
## Slide 6: Cluster configuration wizard
- http://host:9010/console/en/configuration/cluster/config
- Exit the wizard
- 2-step configuration wizard
- Cluster configuration wizard
- Automatically opened if the cluster is not yet configured
### Speaker notes
> You can access the cluster configuration wizard by clicking on the configuration icon. If the cluster is not yet configured, this wizard will automatically open. The wizard consists of two steps: editing the cluster configuration and checking the result after applying it. Above the steps, you will find an option to exit the wizard.
## Slide 7: Edit cluster configuration
- Step 1/2
- Click to switch to cluster.xml edition
- Add/remove a lan
- Add/remove a node
- Tooltip on hover
- Enter a friendly name for the lan (required for modules configuration)
- Enter the IP address or name and press Tab key to check if it is responding
- Save and apply the configuration to all nodes in the cluster
### Speaker notes
> Let's discuss the cluster configuration editing step.
> In the right figure, 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, but by clicking on the plus icon on the right, you can define a new LAN, like the private one shown in the figure. This option is particularly useful if you want to set up a dedicated replication network on a private network.
> For each LAN, you need to define its logical name and IP addresses of nodes. The LAN name is useful when configuring modules later. Inside a LAN, you can add or remove a node using the plus icon and the trash icon on the right.
> When entering the IP address of a node, press the Tab key to check if it is responding. As shown in the left figure, if the node is responding, a green check icon will appear, and the node name will be automatically filled with the hostname of the node. If it isn’t, a red cross icon will appear, along with a message and a tooltip explaining the issue. You can change the node names if you want, but in this case, make sure to use the same node names across all LANs.
> Once the editing is complete, you can click on the "Save and apply" button at the bottom of the window.
> Note that at the top of the window, there is a toggle switch named 'Advanced configuration'. If you toggle the switch, you will be able to edit the cluster.xml file, which is the file deployed on the nodes and corresponds to the configuration made in the figure.
## Slide 8: Check result
- Step 2/2
- Click to read the output on failure:
- Re-edit the cluster configuration
- Fix the issue then Save and apply again
- Click here if no module has been configured yet
- Click to navigate to the cluster’s configuration home page
### Speaker notes
> After saving and applying the configuration, you need to check the result on both nodes. As shown in the figure, if you see a green check icon for both nodes, everything is fine. If no module has been configured yet, you can continue by clicking on the button named "Configure modules" at the bottom of the window. Alternatively, you can exit the wizard by clicking on the blue arrow over the wizard steps.
> If you encounter a configuration failure with a red cross icon on a node, click on the accordion of the node. You will find the output messages of the configuration command, and then search for an error. After identifying the error, return to step 1 to re-edit the configuration, correct the error, and repeat the operation.
> Be aware that there is an encryption key associated with the cluster configuration. This key must be identical on all nodes of the cluster for proper communication. The key is regenerated each time you save and apply changes on both nodes. If you encounter communication issues within the cluster, you can save and apply the configuration again to regenerate the same key on both nodes.
## Slide 9
- Configuration of a new module
### Speaker notes
> Let’s now examine the configuration of a new module.
## Slide 10: Select a new module
- http://host:9010/console/en/configuration/modules
- Open panels for other modules
- Click on New Module
- Check the box to select the module to configure
- Click to configure this module
- Change the module name if necessary
- Confirm
- Then proceed to the next slide
### Speaker notes
> To deploy a new module like the mirror.safe module shown in the right figure, follow these steps.
> First, select the tab named "New module". The list of available modules will be displayed, which depends on the .safe files in the folder named generic on the node side. In this example, the node is node 1, as indicated in the window's header. If you have pushed a module into the generic folder of node 1 during the installation, it will be displayed in this window.
> Next, select the module you want to deploy, in this case, the mirror.safe module, and click on the configure icon. This action will open the window shown in the left figure, where you can assign a name to the module. Here, it is named mirror, but you can choose any name you prefer.
> As you can see in the right figure, there are other panels that allow the installation of new modules: Backup, Other, and Upload panels.
> Note that next to the configure icon, there is a download icon. This allows you to download the .safe module on your workstation if you prefer, and then edit the internal restart scripts and the userconfig.xml file using your own editors.
## Slide 11: Module configuration wizard
- 5-step configuration wizard
- Configure restart scripts
- (optional if preconfigured in the module)
- Encryption enabled by default
- Exit the wizard
- Save is always possible but applying changes requires a stopped module
- Configure replication, virtual IP…
### Speaker notes
> After setting the module name, the "module configuration wizard" appears with five steps.
> In step 1, you can edit the configuration of the module, such as the virtual IP address and the folders to replicate.
> In step 2, you have the option to edit the start and stop scripts. This is not useful for modules such as Hyper-V or KVM, which come preconfigured and do not require any modifications.
> In step 3, you have the option to enable or disable the encryption of module communications between nodes.
> In step 4, you can either save your configuration, or save and apply it if the module is stopped.
> Finally, in step 5, you can check the results on all nodes to ensure everything is correctly configured.
> If you just want to reapply an existing configuration, you can go directly to the save and apply step by clicking on step 4.
## Slide 12: Edit module configuration
- Step 1/5
- Configure the components
- Open/close each panel
- If there is a Macros panel, configure it first
- Example of the service names of Milestone XProtect, in the startup order, separated by commas:
- SQL Server + Milestone services
- To get service names on Window/Linux
- Get-Service in a PowerShell
- 'systemctl list-unit-files --type=service’ in a shell
- Switch to Advanced configuration
to access the full configuration (userconfig.xml)
### Speaker notes
> Let's begin with editing the module configuration. In the figure, you can see the first configurable components in a mirror module through several panels.
> At the top of the figure, you have the panel to configure the module startup at boot. Preferably, set it to automatic. You also have the option to delay the startup of the module at node boot, which in turn delays the startup of the integrated application at boot.
> Below, you have the macro panel. Open it and configure it first. A macro in SafeKit associates a name with a value for dynamic replacement in the configuration. As an example to help you configure your own application, we have provided the list of services that make up the Milestone XProtect application. Enter the service names of your application, in the startup order, separated by commas. In the example, you can see that the list includes Microsoft SQL Server plus services specific to the Milestone application. The start and stop scripts will use this list to start the services of your application in the specified order and to stop them in the reverse order. With a Hyper-V or KVM module and with the replication and restart of an entire virtual machine, you will not have to specify the services but instead the virtual machine name and its location.
> Next comes the configuration of the heartbeats in the figure. A heartbeat is a monitoring data flow on a network shared by both nodes. It is used to synchronize both nodes and detect node failures. You can see in the figure that two heartbeats, named default and private, are set on two networks. Here, you find the names of LANs defined in the cluster configuration. The replication flow checkbox means that the replication flow will pass through the private network.
> Note that at the top of the window, there is a toggle switch named "Advanced configuration". If you toggle the switch, you will be able to configure the userconfig.xml file, with the possibility to configure all parameters of the module. The quick configuration shown in the figure presents a subset of the configuration options. Changes made in the quick configuration are reflected in the XML file and vice versa.
## Slide 13: Edit module configuration
- Step 1/5
- Discard changes and reload the original configuration files
- Define a virtual IP address in the same subnet as the two physical IP addresses
- Define the path of folders to replicate (here the SQL data and log folders)
- Define checkers if needed
- Once completed, click on Next step
and proceed to the next slide
### Speaker notes
> Let’s continue with editing the module configuration.
> In step 1, you can define a virtual IP address. This virtual IP address is a third IP address that must be set in the same network as the two physical IP addresses of the two nodes. In a mirror module, the virtual IP will be set on the network interface of the primary node as an alias IP address. Clients will connect to the virtual IP and will be routed to the primary node. Note that a virtual IP address must not be configured for Hyper-V or KVM modules. The virtual machine will be rebooted with its physical IP address on the secondary node, and clients will be reconnected to the physical IP address of the VM.
> In step 2, you can see the replicated directories panel. In this panel, you can define the path of application data folders to replicate. In the example, you can see the path of the Microsoft SQL data and log folders. You can add new folders to replicate by clicking on the plus icon.
> In step 3, you will be able to configure checkers if needed, such as process monitoring, custom checkers, TCP, ping, or split-brain checkers.
> For more information on all components that can be configured, refer to the "Examples of module configurations" in the SafeKit User’s Guide.
> In step 4, once the configuration is completed, click on "Next step" at the bottom of the window. You can also reload the original configuration if needed.
## Slide 14: Edit module scripts (Optional)
- Step 2/5
- Skip this step in most cases because scripts are preconfigured. Go directly to next step.
- Click on start_prim/stop_prim to see the scripts of a mirror module
- Click on start_both/stop_both to see the scripts of a farm module
- Switch to Advanced configuration to access all scripts
- Click on Next step and proceed to the next slide
### Speaker notes
> Let's now consider the editing of restart scripts. This step is optional and can be skipped in most cases, as the restart scripts are already pre-configured either to restart services defined in the previous step or to reboot a virtual machine for Hyper-V or KVM modules. So, click directly on “Next step.”
> Nevertheless, if you want to see the content of a script, simply click on it. At the top of the window, there is a toggle switch named "Advanced configuration." If you toggle this switch, you will be able to access all scripts of the module.
## Slide 15: Enable communication encryption (Optional)
- Step 3/5
- Click to enable/disable encryption of communications between nodes
- Once completed, click on Next step
- and proceed to the next slide
### Speaker notes
> Let's move on to the encryption step. It is preferable to keep the encryption of module communications enabled, such as heartbeats and replication, to ensure secure communication between nodes.
> Click on "Next step" at the bottom of the window to continue the configuration.
> Note that if the module's encryption key is not identical on all nodes, internal communication will be impossible. To generate new encryption keys, first disable encryption and apply the configuration to all nodes. Then, re-enable encryption and apply the configuration again, to ensure all nodes have the same encryption key.
## Slide 16: Save and apply
- Step 4/5
- Check/uncheck to select/unselect nodes
(node1, the connection node, is mandatory)
- Save and apply the configuration on selected nodes
- And check result in the next step of the wizard
- node1, the connection node, is mandatory
### Speaker notes
> Now we are going to save and apply the configuration. By default, the configuration is saved and applied on all nodes, which is the best option to ensure a symmetric configuration across all nodes.
> However, you also have the flexibility to save and apply the configuration only on specific nodes. For example, you might choose to apply the configuration only on node1, the connection node shown in the figure. This can be particularly useful if node2 has failed and you need to update the configuration of node1.
## Slide 17: Save and apply
- "Save and apply" is not possible because the module is running
- Click on "Save and check" in this case
- The configuration is saved only on the connection node
- And check result in the next step of the wizard
- Step 4/5
- Case of a running module
- Note: you will have to stop the module before re-executing the configuration wizard and apply the saved configuration
- "Save and check" saves changes on the connection node only
### Speaker notes
> As shown in the figure, the "Save and apply" button may be disabled when the module is currently running. In this case, you should click on "Save and check." This action will save the configuration only on the connection node and check its validity.
> You will then need to stop the module in the monitoring section of the console, before returning to the configuration wizard to apply the saved configuration.
## Slide 18: Check result
- Step 5/5
- Click to navigate to the module's configuration home page
- Click to read the output on failure.
Fix the issue and Save and apply again.
- Click to navigate to module’s monitoring home page
### Speaker notes
> The last step involves checking the result of the configuration saving. As shown in the figure, if you see a green check icon for both nodes, everything is fine. You can continue by clicking on "Monitor modules" at the bottom of the window. Alternatively, you can exit the wizard by clicking on the blue arrow over the wizard steps.
> If you encounter a configuration failure indicated by a red cross icon on a node, click on the accordion of the node. This will display the output messages of the configuration command, allowing you to search for any errors. After identifying the error, return to the previous steps to correct it, and then repeat the save operation.
## Slide 19
- Modules monitoring
### Speaker notes
> Let’s now examine the monitoring of modules.
## Slide 20: Modules monitoring and control
- http://host:9010/console/en/monitoring
- Module name
- Node name
- Module state
- Global module menu
- Start on all nodes
- Stop on all nodes
- Download module snapshots for
all nodes…
- Local menu for a farm
- Start on node 2
- Stop on node 2…
- Local menu for a mirror
- Start on node1
- Stop on node 1
- Force start
- as primary on node1
- as secondary on node 1
### Speaker notes
> The figure shows the monitoring of two modules that have been deployed on the cluster: the farm module and the mirror module. As you can see, the farm module has been started on node 1 and node 2, while the mirror module has not been started.
> On the right side, you can see the different menus that control a module. Let's analyze the three menus presented on the right side, starting with the first menu.
> The first menu is a global menu for the farm module, which acts on all nodes in the cluster. With this menu, you can start or stop the farm module on all nodes. The debug submenu allows you to gather information on both nodes for debugging if you encounter any problems with the farm module.
> Now, let's analyze the second menu. The second menu is the local menu for the farm module on node 2. In this example, you can stop the farm module on node 2. By doing this, node 1 will take over all TCP connections from the clients. You can also restart the module from this menu, which will execute the stop and start scripts defined during the configuration of the farm module. Additionally, you can disable or enable checkers. This is useful if you need to perform maintenance operations that require stopping the application without triggering an automatic restart by a checker.
> Finally, let's analyze the third menu. The third menu is the node-specific menu for the mirror module. Since the mirror module has just been configured, the state is 'not uptodate' on both nodes. SafeKit does not know which node has the most up-to-date data. It is necessary to indicate this by forcing the startup as primary of the node with the most up-to-date data. The other node, upon its own startup, will synchronize the replicated data from the primary node before becoming secondary. SafeKit will then remember which node has the most up-to-date data and will prevent the node with outdated data from becoming primary on a simple start.
## Slide 21: How a mirror module works?
- Real-time replication
- Automatic failover
- Resynchronization
- Real-time replication
- Real-time replication, virtual IP address and failover
### Speaker notes
> Let's examine how a mirror module works and the associated states and colors in the console.
> At step 1 in the figure, the mirror module is running in the PRIM-SECOND state. The application runs only on the PRIM server, and the virtual IP has been set on its network interface. Only modifications inside files are replicated in real-time.
> At step 2, the mirror module has been stopped on node 1, or node 1 has experienced a failure. This triggers an automatic failover to node 2. The module is now in the ALONE state on node 2, the virtual IP has been set on its network interface, and the application has been restarted. There is no more replication from node 2 to node 1.
> At step 3, the mirror module is restarted on node 1, and node1 resynchronizes its local folders from node 2. During this resynchronization, the state is SECOND and the color is orange on node 1. The application continues its execution on node 2 in the ALONE state.
> At step 4, the data has been resynchronized, and we are in the SECOND-PRIM state, ready for a failover. If you prefer the application to run on node 1, you can stop the module on node 2. This will trigger a failover and a restart of the application on node 1. You can do this manually through the console at an appropriate time, or automatically just after the resynchronization, by configuring the defaultprim parameter in userconfig.xml.
## Slide 22: Mirror module state
- SECOND
### Speaker notes
> Let's present the main states of a mirror module in the console.
> When the state is ALONE and the color is green on a node, it means a primary server without a secondary. The failover is not possible in this state.
> When the state is PRIM and the color is green, it indicates a primary server with a secondary. The failover is possible in this state.
> When the state is SECOND and the color is green, it signifies a secondary server with a primary. The failover is possible in this state.
> The STOP state means that the module is not running on the node.
> If the state is SECOND and the color is orange, it means that the node is currently resynchronizing replicated folders. The failover is not possible in this state.
> When the state is WAIT, the color is red, and the message is "not uptodate," it means that the node is waiting for the start of the other node, as it does not have up-to-date data. If the state is WAIT, the color is red, and the message is a failover rule name, it means that the node is waiting for a mandatory resource controlled by a checker before starting.
> Finally, if the state is ERROR, it means that the console cannot connect to the node because, either the node has crashed, or there is a communication issue between the console and the node, such as a firewall issue or the web service not running on the node side.
## Slide 23: How a farm module works?
- Network load balancing
- Automatic Failover
- Failback
- 2 nodes (or more)
- Network load balancing and failover
### Speaker notes
> Let's now examine how a farm module works and the associated states and colors in the console.
> At step 1, the farm module is running in the UP UP state. The application operates on both servers, and the virtual IP is set on the network interface of both nodes as an alias IP. A kernel module named vip handles the load balancing of client TCP sessions between both nodes.
> At step 2, the farm module has either been stopped on node 1 or node 1 has experienced a failure. As a result, all client TCP sessions are now managed by node 2.
> At step 3, the farm module is restarted on node 1, and the load balancing is restored across both nodes.
## Slide 24: Farm module state
_No extractable slide text found._
### Speaker notes
> Let's present the main states of a farm module in the console.
> When the state is UP and the color is green on a node with 100% of the traffic, it means that it is the only node running the farm module. The failover is not possible in this case.
> When the state is UP and the color is green on a node with 50% of the traffic, it indicates that two nodes are running the farm module. The failover is possible in this case.
> The STOP state means that the module is not running on the node.
> When a state is in transition, it is indicated by an orange color.
> If the state is WAIT, the color is red, and the message is a failover rule name, it means that the node is waiting for a mandatory resource controlled by a checker before starting.
> Finally, if the state is ERROR, it means that the console cannot connect to the node because either the node has crashed, or there is a communication issue between the console and the node, such as a firewall issue or the web service not running on the node side.
## Slide 25: Module states timeline
- State on all nodes over time, starting by the newest date (since SafeKit 8.2.2)
- Click to open/close the timeline
- Click to refresh the timeline with the latest state changes
- Click on a state change event to display the module log for the node starting at this date
- Log live display is suspended
### Speaker notes
> Let's explore the module states timeline feature.
> To access this feature, click on the clock icon located in the window's header. The timeline will appear as shown in the figure on the left. This timeline displays the module states on all nodes in reverse chronological order, starting with the most recent date. This visual representation helps administrators quickly understand the current status and historical changes of the module.
> The timeline shown is the one available at the time of loading. To refresh the timeline with the latest state changes, simply click on the refresh icon. Additionally, you can click on an event in the timeline. As shown in the figure on the right, the module log associated with the event will be displayed.
> It's important to note that the clocks of the two nodes must be synchronized for the state changes to be accurately mapped. This ensures that the timeline provides meaningful and precise information about the module states.
## Slide 26: Module details
- Select the module/node
- Click on the node (or button since SafeKit 8.2.2) to display its detailed status
- It is highlighted with a blue color
- The module details are displayed
- Click on the tab to visualize module logs, resources or node information
- Module details for mirror on node1
### Speaker notes
> Let's talk about the process of displaying details for a module on a node.
> In the figure, to access the details of the mirror module on node 1, click on its magnifying glass icon.
> The mirror module on node 1 is then highlighted in blue, and the details of the module on node 1 are displayed on the right.
> To visualize the module logs, click on the "Logs" tab. To see the module resources, click on the "Resources" tab. Finally, to view information on the node, click on the "Information" tab.
## Slide 27: Logs (1/3)
- http://host:9010/console/en/monitoring /modules/AM/nodes/node/logs
- Resume/suspend the view in real time of the log
- Download the log (verbose or not verbose)
- C(ritical) messages (error detection…)
- E(vent) messages (local and remote state…)
- U(ser) messages when the user runs action on the module
(ex.: Action stop called by username)
- S(cript) messages when module scripts are executed
- Select the message type to view
### Speaker notes
> Let's discuss the process of displaying logs for a module on one node.
> As shown in the figure, the panel displays the non-verbose module log in real-time. You have buttons to suspend and resume the real-time view of the log, allowing you to pause and review the information as needed. Additionally, you can download the log to edit it in your favorite editor for further analysis.
> The console also provides an option to filter messages according to their types. Here are the different message types you can filter, represented by the four icons displayed in the View section of the figure.
> The first icon represents critical messages associated with error detection.
> The second icon represents event messages related to changes in local or remote states.
> The third icon represents user messages when the user performs an action on the module.
> The fourth icon represents script messages when module scripts are executed.
## Slide 28: Logs (2/3)
- Verbose messages
- Click on a message other than S(cript)
- verbose messages are displayed
- between this message and the next one
- Verbose messages
### Speaker notes
> Let's explain how to view verbose messages in the module logs.
> As shown in the figure, when you click on a message other than a script message, the console will display verbose messages between this message and the next one on the right side of the panel. This feature allows you to gain a deeper understanding of the events and actions that have occurred within the module, providing valuable insights for troubleshooting and analysis.
## Slide 29: Logs (3/3)
- Script message details
- Click on a S(cript) message
- output of the script execution is displayed
- Output of the script
### Speaker notes
> Let's discuss the process of displaying the script messages.
> As shown in the figure, simply click on a script message. The console will then display the output messages of this script on the right side of the panel. For instance, in the example provided, the output messages of the startprim script are displayed, including the results of the net start command executed on IIS, SQL Server, and Milestone Xprotect services.
## Slide 30: Resources (1/2)
- http://host:9010/console/en/monitoring /modules/AM/nodes/node/resources
- Select a group of resources
- Current value of module resources
### Speaker notes
> Let's discuss the process of displaying module resources.
> To display the resources of a module on one node, click on the "Resources" tab. From there, you can select the group of resources you want to view.
> The module status view displays the main resources. The checkers view shows resources set by checkers. The file replication view displays file replication-specific resources that demonstrate synchronization progress. As the name suggests, the all resources view displays all available resources.
## Slide 31: Resources (2/2)
- Resource values history
- Click on a resource
- to display the history of values
- the history may be empty for some resources
- History of values
### Speaker notes
> Let’s talk about viewing the history of resource values.
> To display the history of values for a specific resource, simply click on the resource. The console will then show the history of values over time in the right panel. Please note that the history may be empty for some resources.
## Slide 32
- Support and maintenance
### Speaker notes
> Let's now explore the support and maintenance features of the SafeKit console.
## Slide 33: Maintenance operations on the application
- How to disable automatic restarts?
- Stop node 2 to avoid a failover on it
- Disable checkers
- Disable process monitoring
- Disable startup at boot
- Note: Re-enable everything once the maintenance is completed
### Speaker notes
> For maintenance operations that require stopping the application monitored by SafeKit, it may be necessary to disable all automatic restarts triggered by SafeKit.
> At step 1, stop the module on the secondary node to avoid a failover on this node.
> At step 2, disable the checkers configured inside the module that monitor the application and trigger restarts.
> At step 3, disable process monitoring, which also triggers restarts.
> At step 4, 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.
## Slide 34: How to take a module snapshot for support?
- Take a snapshot of the module on each node for offline and in-depth analysis
- Take a dump in real-time when a replication problem arises
### Speaker notes
> To support a customer, you need to take a module snapshot on each node. As shown in the figure on point 1, you can download both module snapshots from node 1 and node 2 by clicking on the global menu of the module and opening the debug submenu. This will download two .zip files to your workstation, corresponding to the module snapshots of the two nodes.
> You can also download the module logs of both nodes to your workstation from the debug menu. You have the option to get the non-verbose log if you want to understand the logs with their main messages. For in-depth analysis, the verbose log is required. Note that the module logs are included in the snapshots. The snapshots contain other essential files for support, such as the module configuration. Their contents are explained in the troubleshooting slides.
> There is also a dump command useful for dumping all SafeKit logs in real-time, which is helpful to capture a state in real-time when a replication problem typically occurs. The dump will be included in the snapshot operation.
## Slide 35
- Advanced usage
### Speaker notes
> Let’s now delve into the advanced usage of the SafeKit console.
## Slide 36: Cluster’s configuration home page
- http://host:9010/console/en/configuration/cluster
- Open to display details on the node
- The cluster
### Speaker notes
> Let's examine the cluster configuration home page.
> When the cluster is configured, the cluster configuration home page becomes available. To access it, click on the configuration icon in the left navigation sidebar and then click on the cluster configuration tab at the top of the panel.
> As shown in the figure, node 1 and node 2, which have been configured in the cluster, are listed along with their configuration dates. To display details about a node, click on its accordion on the right. You will see information such as network names and their IP addresses defined in the cluster configuration, SafeKit version, license key, hostname, and operating system.
> At the bottom of the panel, you will find several buttons. The first button allows you to modify the cluster configuration and re-apply it. This opens the cluster configuration wizard and loads the cluster configuration from the connection node. The second button allows you to download the cluster configuration in XML format from the connection node. The third button allows you to unconfigure the cluster on one or more nodes.
## Slide 37: Module’s configuration home page
- http://host:9010/console/en/configuration/modules
- Installed modules
### Speaker notes
> Let's examine the module configuration home page.
> To access it, click on the configuration icon in the left navigation sidebar and then click on the modules configuration tab at the top of the panel.
> As shown in the figure, the farm and mirror modules have been installed and configured and they are listed along with their apply dates.
> To manage a module, you have a series of buttons presented in the figure under the farm module.
> The first icon allows you to modify the module configuration and reapply it. This opens the module configuration wizard and loads its current configuration from the connection node.
> The second icon allows you to download the configuration files to your workstation from the connection node. This means you can locally edit the files on your workstation using your favorite editor.
> The third icon allows you to upload the configuration files from your workstation to the console.
> The fourth icon allows you to restore a previous module configuration. SafeKit keeps a copy of the last three successful configurations on the node side.
> The fifth icon allows you to unconfigure a module, without uninstalling it. The configuration files are kept for later a re-configuration.
> The sixth icon allows you to completely uninstall the module.
> Before reconfiguring, deconfiguring, or uninstalling a module from the console, ensure you close any editors, file explorers, shells, or command prompts open in the module directory on the node's side. Otherwise, the operation will fail due to locked files.
## Slide 38: Edit the module configuration on your workstation
- Example: add the module script checker.ps1
- Download mirror.safe on your workstation
- Edit the mirror.safe (a zip file) and add checker.ps1 into the bin directory
- Click to upload the modified mirror.safe (.zip extension accepted)
- Click to select the file on your workstation then Confirm
- the module configuration wizard is started with the content of the uploaded module
### Speaker notes
> Let's delve deeper into how you can edit a module configuration locally on your workstation.
> In the example of the figure, first, click on the icon to download the mirror.safe file to your workstation. Then, extract on your workstation the contents of mirror.safe, which is essentially a zip file. This allows you to edit the userconfig.xml file in the CONF directory, and to edit restart scripts in the bin directory.
> In the example, a custom checker named checker.ps 1 has been developed on the workstation and added to the bin directory.
> Once your modifications are complete, compress the files into a new mirror.safe (or mirror.zip) file. Both .safe and .zip extensions are acceptable.
> Next, upload the new mirror.safe file to the console. This action will launch the module configuration wizard with the contents of your file. The new contents will be visible in the wizard. Finally, save and apply the new configuration on both nodes in the wizard.
## Slide 39
- Securing the web console
### Speaker notes
> Let's take a closer look at how to secure the web console.
## Slide 40: Securing the web console
- Optional role management
- Protocol and user authentication
- Default: HTTP and user admin with password authentication
- HTTP or HTTPS
- User authentication with
- Apache files (default)
- LDAP/AD authentication
- OpenID Connect authentication
- Default: Admin role
- See "Securing the SafeKit web service" in the SafeKit User’s Guide
### Speaker notes
> Let’s discuss the different possibilities to secure the web console.
> By default, after a simple installation, the system is configured with HTTP and a password authentication for the admin user. However, we also support HTTPS for secure communication. User authentication can be managed through Apache files, LDAP or AD authentication, or OpenID Connect authentication, providing flexibility to meet various security requirements.
> Role management is another essential element of the web console security. By default, the admin role is assigned, granting all rights, including configuration and monitoring. Additionally, we offer optional role management to further enhance security. The control role allows monitoring and control rights without the right to configure. The monitor role is limited to monitoring rights, with actions on modules such as start and stop being prohibited.
> For detailed information, please refer to “Securing the web service” in the SafeKit User’s Guide.
## Slide 41: HTTPS (1/2)
- See "HTTPS setup using an external PKI" in the SafeKit User’s Guide
- S1
- https for global command
- https://10.0.0.10:9453
- https://10.0.0.11:9453
- https://11.0.0.10:9453
- https://11.0.0.11:9453
- S2
- https for the console
- https://s1.x.com:9453
- https://s2.x.com:9453
- SAFEVAR/cluster/cluster.xml
-
-
-
-
-
-
-
-
- Example of a cluster
- Certification Authority of S1 and S2 ca.crt
- Server1 certificate
- s1.crt, s1.key
- Server2 certificate
- s2.crt, s2.key
- Check that ca.crt contains
- the root CA certificate
- all intermediates/subordinates CA certificates
- Enterprise PKI provides three X.509 certificates in PEM format (base 64 encoded).
- .crt
- -----BEGIN CERTICATE-----
- …
- -----END CERTIFICATE-----
- .key
- -----BEGIN PRIVATE KEY-----
- …
- -----END PRIVATE KEY-----
### Speaker notes
> Let's now examine how to switch from the HTTP to the HTTPS protocol.
> As illustrated in the figure, we have a cluster composed of two servers, S1 and S2. We want the cluster to be accessed via HTTPS by the web console on port 9453, using either the s1.x.com or s2.x.com DNS names. Between the S1 and S2 servers, two networks have been configured in the cluster: the 10 network and the 11 network, which will also be switched to the HTTPS protocol for global commands.
> To switch to HTTPS, the enterprise must provide three certificates with its PKI. The first one is the CA certificate, which is the Certification Authority certificate used to issue the server certificates. The second one is the S1 server certificate, which asserts the identity of S1. The third one is the S2 server certificate, which asserts the identity of S2.
> Ensure that the CA certificate contains the root CA and all intermediate and subordinate CAs. Additionally, verify that each server certificate has its Subject Alternative Name, or SAN, correctly configured. For example, the S1 certificate should include in its SAN, s1.x.com and its IP addresses on the 10 network and the 11 network, as defined in the cluster configuration file. Similarly, the S2 certificate should include in its SAN, s2.x.com and its IP addresses on the 10 network and the 11 network, as specified in the cluster configuration file.
## Slide 42: HTTPS (2/2)
- Switch back SafeKit to http on S1 and S2
- Remove SAFE/web/conf/ssl/httpd.webconsolessl.conf
- Run SAFE/safekit webserver restart
### Speaker notes
> Let's now consider the installation of the three certificates on the server side.
> First, take the CA certificate, the S1 certificate, and the S1 key, and place them in the web/CONF directory on the S1 server. Rename these files to CAcert.crt, server.crt, and server.key, respectively. Similarly, take the CA certificate, the S2 certificate, and the S2 key, and place them in the web/CONF directory on the S2 server. Rename these files to CAcert.crt, server.crt, and server.key.
> Next, verify the certificates on both S1 and S2, using the checkCERT command. This step ensures that the certificates are correctly installed and configured.
> Finally, switch the web server on both S1 and S2 to HTTPS. To do this, copy the httpd.webconsoleSSL.CONF file into the ssl directory, restart the web server, and run the firewallCFG command.
> After completing these steps, you should be able to connect to the web console using HTTPS on port 9453.
> If it does not work, you can switch back to http by removing in the ssl directory, the http d.webconsoleSSL.CONF file, and restarting the web server.
## Slide 43: 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.