Storage can be extended by adding more disks, which are set up in a redundant array (RAID 10), with two redundant servers connected in real-time mirror (Mirror/Cluster Edition). In such a setup, disk failure does not interrupt the storage service. There is no practical storage size limit in the software; it is only limited by hardware specifications, such as the largest disks available on the market (in terms of capacity), and the number of disks that can be connected to servers, RAM memory, etc.
SERVERware storage employs end-to-end checksums to detect and correct silent data corruption. This means that the storage will use this checksum to determine which copy is correct in this redundant disk array. This provides correct data to the VPSs and repairs the damaged copy if it becomes damaged.
SERVERware, except for its Standalone edition, uses a unique approach for managing data storage. It combines disks from two different storage servers into one large storage pool, known as NETSTOR. This integration is achieved through the use of ZFS, a combination of a file system and volume manager, and the iSCSI protocol, which allows storage to be accessed over a network.
The total storage size is only limited by the physical capacity of the servers. To link these disks into a unified storage system, SERVERware requires a dedicated network connection between the two storage servers, termed the Active and Passive servers. This connection, known as the Replication Area Network (RAN), must have a minimum bandwidth of 1Gb/s. It's crucial that this network has extremely low latency, which is why a direct cable connection is necessary, avoiding any intermediate network devices like switches or routers.
In this setup, one server acts as the primary, handling the storage needs of the processing hosts in the Cluster Edition. Each disk on this primary server is mirrored with a disk of similar size on the secondary server. The data on the secondary server's disk is accessed over the RAN using the NVMe protocol. In the event that the primary server fails, the secondary server can seamlessly take over and continue providing storage services.
For each VPS, SERVERware will create a ZFS volume, each volume is formatted to different file system, usually ext4. In case of Cluster Edition these volumes are exported to SAN (Storage Area Network) to corresponding processing host. Processing host will attach volumes assigned and accessible by it and then run the VPSs.
SAN requirements dictate that servers must have 1Gb/s port minimum per server and a switch to connect storage and processing hosts. To have minimum latency between servers it is recommended to keep this configuration as simple as possible. For failover capability, storage requires floating IP address on SAN, which is an IP that will move from primary to secondary storage server in case of primary server failover. For this to work one must make sure that this will be supported by switch, if such security settings exist (depending on model).
To increase the reliability of setup where processing hosts are used, SERVERware supports bonding of network interfaces. It is possible to have redundant SAN with two redundant switches. This requires two ports per server to be bonded in SAN.
Same is possible for RAN and LAN networks, but SAN is the most critical component and it is recommended to make it redundant before others.
Setup of storage configuration is automatic and everything is done via Setup Wizard. In order for this to be automated as such, it requires complete topology in place, servers installed, and networks configured. Of course, one must have correct information about these networks to make this happen. In short, one will have to select ports used for LAN, SAN and RAN and floating IP address will need to be chosen, including location of second storage server.
Scalability of storage is limited by the capacity of RAN and SAN networks and number and size of disks. It is simple enough to scale the storage by adding more disks in pairs, and configuring iSCSI targets depending on the edition.
For more information on how to scale the storage pool, please refer to our documentation manuals:
No resource is unlimited in terms of storage, CPU, network and memory available. With that said, special attention should be paid to management and commitment of these resources.
Following limits must be observerd for storage:
Space, which is determined by number and size of disks available in network storage pool.
Storage speed, which is determined by performance of individual disks and interface they are connected with, like: SAS, SATA, RAID
SAN capacity
RAN capacity
Space limitations should be considered as ratio between actual usage and allocation. Not all VPSs will use the whole allocated storage so there is a space for overcommitment of available storage, but keep in mind that they all have potential to reach full usage and demand storage to extend.
How much can be overcommited depends on specific case and can not be generally predicted. Usage growth should be constantly monitored to be able to react on time. Careful planning of storage that will be required in future, and scalability plan and procedures is what will resolve potential issues with space limitations.
As more VPSes are added, or there is an increase in usage, there will be more demand on storage. To prevent potential problems, SERVERware monitors IO load of the storage and information is displayed on the dashboard. As a general rule, this load should never reach 10%. If this limit is reached, options to alleviate this would be to create new cluster for offloading the VPSs, or update of hardware with improved performance.
Bandwidth and latency limitations apply to SAN and RAN network but there is special case that should be observed when planning and deploying VPSes. Each VPS's IO bandwidth can be limited, and this option should be used appropriately, with same considerations as space overcommitment.
Not all VPSes will use the IO up to the limit all the time, but there is always a possibility for that to happen. For VPSes that have unlimited IO set, there is a potential problem where those VPSes utilize 100% of SAN/RAN resources and that way affect the functionality and performance of all other VPSes, causing a series of issues. In such cases, to alleviate those problems either upgrade the network infrastructure or create more clusters to offload affected VPSes. Of course, this needs careful planning prior to deployment.
Performance of networks and disks can be different, they can outperform each other on multiple occasions, so when troubleshooting, it's crucial to know where the bottleneck is, in order to know how to handle it.
The following guide describes minimal and recommended hardware requirements as well as procedures for a successful deployment of SERVERware 4.2 - Cluster Edition.
HARDWARE | MINIMUM SYSTEM REQUIREMENTS | RECOMMENDED SYSTEM REQUIREMENTS |
---|---|---|
CPU | 2.0 GHz Quad-Core Intel Processor with 8MB Cache | 2.4 GHz Quad-Core Intel Xeon Processor with 12MB Cache |
RAM | 16GB | 32GB |
Ethernet | 8 x 1Gb/s network interfaces | 2 x1Gb/s + 4 x10Gb/s network interfaces |
Disk | 1 x 64GB Solid-State Drive (for system), 2 x 500GB Solid-State Drive (for storage) | 1 x 64GB Solid-State Drive (for system), 4 x 250GB Solid-State Drive (for storage) |
To effectively relieve Storage/Controller, at least 2 Processing Hosts should be added to the cluster. If added, Processing Hosts should have the following:
HARDWARE | MINIMUM SYSTEM REQUIREMENTS | RECOMMENDED SYSTEM REQUIREMENTS |
---|---|---|
CPU | 2.0 GHz Quad-Core Intel Processor with 8MB Cache | 2.4 GHz Quad-Core Intel Xeon Processor with 12MB Cache |
RAM | 16GB | 32GB |
Ethernet | 2 network interfaces | 4 network interfaces |
Disk | 1 x 64GB Solid-State Drive (for system) | 1 x 64GB Solid-State Drive (for system) |
HARDWARE | MINIMUM SYSTEM REQUIREMENTS | RECOMMENDED SYSTEM REQUIREMENTS |
---|---|---|
CPU | 2.0 GHz Quad-Core Intel Processor with 8MB Cache | 2.4 GHz Quad-Core Intel Xeon Processor with 12MB Cache |
RAM | 16GB | 32GB |
Ethernet | 1 network interface | 3 or more, network interfaces |
Disk | 1 x 1TB Hard Disk Drive (for system and backup) | 1 x 64GB Solid-State Drive (for system), 6 x 1TB Hard Disk Drive (for backup) (RAID10) |
'''IMPORTANT NOTE:''' Software RAID (including motherboard) implementations are not supported and could cause potential problems that Bicom Systems would not be able to support.
Letting the controller store (or 'cache') write data in its memory can speed up the writing process. However, this approach has a risk. It might lead the operating system to mistakenly think the data is already safely written to the disk. If a power failure occurs before the controller finishes writing the data, this could lead to data loss.
To prevent such data loss, RAID systems often include a battery backup. This backup keeps the data in the cache safe if the power goes out, until the system is turned on again. That's why it's essential to always have a functioning RAID battery. If the power supply unit (PSU) fails, or even if there's an uninterrupted power supply (UPS), the system could shut down. This might leave uncommitted data in your RAID cache at risk.
A working RAID battery ensures that this data is correctly written to the disk once power is restored. This is also true if there's a failure in the system board. Even if you need to replace the RAID controller, a working battery-backed cache can be transferred to a new card without losing any data.
However, the effectiveness of battery-backed caching depends on the battery's remaining life. To ensure reliability, it's advisable to replace the batteries every three years, unless other specific measures are in place.
To minimize this risk, storage servers should have a reliable power supply. Ideally, they should be powered by two different sources, known as a dual site power supply. This setup ensures that if one power source fails, the other can take over. Alternatively, using an uninterruptible power supply (UPS) can protect against short-term power losses.
It's also important for servers to have dual power supply units (PSUs) inside them. These PSUs should be connected to the power source at all times to provide a continuous and stable supply of electricity. This helps safeguard against potential data loss during unexpected power disruptions.
SERVERware 4.2 Cluster Edition topology is shown on the following image:
How-to instructions regarding network setup are available on the following page:
Because of ZFS, hardware RAID is not required, but if there is RAID controller present and you want to use it, battery and write cache are a must. Any hardware RAID without battery backup and write cache enabled, can't be supported. Fake RAID is not supported, should not be used and must be turned off if supported by motherboard (Fake RAID is essentially software RAID provided by the BIOS on the motherboard).
Lets say we have two disks for storage per server (disks must be identical).
Currently, setup wizard will form the following pool:
The System Installation Wizard has been enhanced to provide users with the ability to create ZFS pools on OS disks during the installation process. This feature streamlines the setup of ZFS pools, optimizing system performance and storage management.
During the installation process, the wizard will identify available disks for the SERVERware operating system. It will then suggest suitable ZFS pool configurations based on the detected number of disks. Users will have the following options to choose from:
Stripe: This option optimizes performance by striping data across multiple disks, enhancing read and write speeds.
Mirror: Selecting this option creates a mirrored ZFS pool, enhancing data redundancy and fault tolerance.
ZRAID: This option allows users to configure a ZFS pool using the ZRAID (ZFS RAID-Z) technology, providing a balance between performance and data protection.
Users will be presented with the number of detected disks and the corresponding available options for creating the system pool. They can then select the desired ZFS pool configuration based on their requirements. The wizard will guide users through the process, making it simple and intuitive.
Once the user has chosen the desired ZFS pool configuration, the wizard will automatically create the specified pool for the OS during the installation. This automation simplifies the setup process and ensures a ZFS pool is ready for use upon completion of the installation.
The System Installation Wizard has been enhanced to provide users with the ability to create ZFS pools on OS disks during the installation process. This feature streamlines the setup of ZFS pools, optimizing system performance and storage management.
Boot target machine from the USB installation media. The following welcome screen appears.
If the live system was able to pickup IP address from DHCP server, it will show so on this screen. You can then access the system remotely via ssh on port 2020 with username 'root' and password 'bicomsystems' and continue installation. There are several options offered on the welcome screen:
Storage/Controller is the network storage for VPSs on the SERVERware network. Processing Host (available in Cluster Edition) is computation resource that will attach and execute VPSs from storage via SAN (Storage Area Network).
Users will have the following options to choose from:
Striped: This option optimizes performance by striping data across multiple disks, enhancing read and write speeds.
Mirrored: Selecting this option creates a mirrored ZFS pool, enhancing data redundancy and fault tolerance.
RAIDZ: This option allows users to configure a ZFS pool using the ZRAID (ZFS RAID-Z) technology, providing a balance between performance and data protection.
User will be presented with the number of detected disks and the corresponding available options for creating the system pool. They can then select the desired ZFS pool configuration based on their requirements. The wizard will guide users through the process, making it simple and intuitive.
Click Next to continue and then chose one of the options to configure network interface.
After finishing network configuration, click Next to start installation.
Redo installation steps for the second (mirrored) machine
SERVERware makes it easy to set up VLAN tagging, a crucial feature for servers that need to connect to the internet or specific networks. In some places like South Africa, Australia, and various South American countries, VLAN tagging is a standard practice in network setups. Without this tagging, servers might not be able to access the internet or certain networks.
VLAN tagging is especially useful when a server has only one physical connection for its LAN (Local Area Network). It allows the server to simultaneously access both local and public networks. To set up a VLAN on SERVERware, simply follow the step-by-step instructions in the 'Installation Wizard Steps' section of the install wizard.
Run '''netsetup''' command in terminal and delete '''br0''' interface. Now we have only one physical interface and next step is to create two or more VLANs.
Open your browser and enter LAN IP you configured upon installation. After confirming the self-signed certificate, the SERVERware setup wizard login screen appears. Enter the administrator password which is by default 'serverware'.
After successful login, SERVERware EULA appears.
Acceptance of the EULA leads to the next step.
Enter your license number, and administrator's email, and set the new administrator's SERVERware GUI password. This password will also apply to the shell root account. Select your time zone and click next to continue.
Depending on the license you acquired, this step will offer you to configure LAN, SAN and mirror RAN networks. LAN is a local network for SERVERware management and service provision. SAN is a network dedicated to connecting SERVERware storage with processing hosts. RAN is a network dedicated to the real-time mirroring of two servers.
The setup wizard will suggest the default configuration for the network interfaces. The machines must be on the same LAN network and the same SAN and RAN network. Modify network configuration if needed and click Next to proceed to the next step.
Choose the name for the cluster if you don't like the one generated by the SERVERware (it must be valid per hostname constraints).
Select from the list or enter the LAN IP address of the second (mirrored) machine. The purpose of the mirrored setup is to provide storage redundancy, so it will need a few more configuration parameters. LAN Virtual IP is a floating IP address for accessing mirrored storage server. SAN Virtual IP is a floating IP address used for access to the storage. Administration UI IP address will be used for CONTROLLER VPS (GUI).
CONTROLLER VPS is set up automatically on the storage server, and its purpose is to provide administrative management web consoles as well as to control and monitor SERVERware hosts and VPSs.
Once you click the Finish button, the wizard will initialize and set up the network storage. When complete, the setup will present the summary info.
Wait a few seconds for CONTROLLER to start and click on the Controller Web Console link to start using SERVERware and creating VPSs.
The components of the SERVERware environment fall into two categories: physical resources, and logical resources. Physical resources are physical objects
such as storage and host servers. Logical resources are nonphysical groupings and processes, such as domains, logical subnets, and virtual server templates.
Log in to the SERVERware Web Control Panel directly from your web browser.
Enter IP Address of SERVERware Web Control Panel into the web browser to access the login screen.
Enter your Username and Password.
Press the "Enter" or click "Login". SERVERware Dashboard appears.
At the title bar of the Web Control Panel, click Logout.
You will be logged out and the Web Control Panel login screen displays.
The API Tokens allows users to generate and manage API tokens for accessing and interacting with the system. API tokens provide a secure way to authenticate and authorize third-party applications or services to use the system's APIs.
By providing a user-friendly interface for creating, managing, and securing API tokens, users can leverage this feature to integrate and interact with the system programmatically while maintaining a high level of security and control.
To access the API Tokens feature, users should follow these steps:
Navigate to the Account Settings section.
Open the API Tokens tab within the Account Settings interface.
To create a new API token, users can follow these steps:
Open the API Tokens tab in the Account Settings.
Locate the Add New Token functionality, typically represented by a small cross mark icon in the right corner of the interface.
Click on the Add New Token icon to initiate the token creation process.
Provide a meaningful name for the token to help identify its purpose.
Click Generate to create the token.
The system will generate a unique API token that can be used for authentication and authorization purposes.
Click Copy API Token. Clicking this button allows users to copy the generated API token to their clipboard for easy usage..
Users can manage their API tokens by:
Viewing: Displaying the details of each generated API token, including its name, permissions, and associated metadata.
Editing: Modifying the tokens is not possible the only way to replace the tokens is to delete existing and create new one.
Permissions: When creating tokens, the system automatically assigns the same permissions as the user who created the token.
Deleting: Removing an API token to revoke its access and render it unusable.
Keep Tokens Secure: Users are advised to keep their API tokens secure and not share them publicly or with unauthorized users.
Rotate Tokens Regularly: For security purposes, it's recommended to periodically recreate tokens to ensure they are always up to date and secure.
If your Authenticator App is not working or unavailable for some reason, you can use '''Backup Codes'''. Click on '''Show Backup Codes''' to view available codes. A new popup will appear with a list of codes and their status (used or not). One code can be used only once, if you don't have available codes you can generate new codes by clicking on the '''Generate new codes''' button.
To start using '''2FA''' please logout from SERVERware panel and login screen will appear. Enter your username and password and click '''Login'''
If entered username and password is correct new screen will appear, if username or password is incorrect you'll get error '''Invalid Credentials!'''. Enter code from your Authenticator app or an unused backup code to complete login procedure.
SERVERware network dashboard is a visual display of the most important performance
indicators of a SERVERware network. Given that a storage server is a crucial component of a
SERVERware network, most of the dashboard performance indicators (widgets) in some way
reflect the status of the storage server itself.
The following is a list of dashboard widgets:
Most Active VPS chart will help an administrator to quickly identify a VPS that generate high I/O load on the system..
Most Active VPS's can be viewed in several time periods:
Also, there is a filter by resources used:
Calls statistics is dashboard widget displaying total number of calls made on all VPSs combined on SERVERware in different periods of time.
Calls statistics are displayed in several time periods:
Meeting statistics is dashboard widget displaying combined information for meetings made on all VPSs combined on SERVERware in different periods of time.
Meeting statistics are displayed in several time periods:
Memory and Storage dashboard displays over-commit on resources:
"LOCAL STORAGE" displays the local storage allocation for all processing hosts storage.
In SERVERware's storage pool display, you'll see two different bars, each representing a different type of space usage:
Logical Used: This shows the actual amount of space currently being used in the storage pool. Think of it as the actual data stored.
Used: This represents a larger number, which includes both the Logical Used space and any additional reserved space in the pool. Essentially, it's the total of the actual used space plus any space set aside for system use or future data."
To access the BSSUP panel, click on the button next to the System Date in the top right SERVERware menu. BSSUP's main panel should appear on the right side of the SERVERware web interface. To close it, simply click again on the BSSUP button.
BSSUP panel has a clean and simple design with several buttons:
Open SSH access button, for opening SSH access to your server
Advanced options button, to modify SSH port or to set Timeout
Show logs button, to access logs.
The status bar is at the bottom of the panel, which is showing whether SSH access is open or closed.
When SSH access is opened, an icon in the status bar changes color into green with the checkmark inside together with the SSH access status, indicating that everything is up and running on port 22. Also, the BSSUP panel button changes color into orange while the SSH access is opened.
Next, to the status information in the status bar, there is also info on when the SSH access will be closed.
During this stage, it's not possible to access Advanced options.
Port section is used to define which port will be used for SSH access. If you enter a text or invalid port value, the text field should be red, and the button for opening SSH access should be disabled.
The timeout dropdown menu is to choose for how long SSH access will be opened.
For example, if you enter 22 for the port, select No timeout and open SSH access, everything should be the same except the status bar. The message will show that the port is permanently open, and there should be no timeout.
Open three separate terminals and in each one execute the command:
ssh root@IP_ADDRESS_OF_CONTROLLER -p22
After that, you should see something like this:
At the end of each connection status, there are buttons for stopping a single SSH session. When you click on one of the buttons, that row should disappear from the table, and on your terminal, you should get the output:
Connection to 10.1.50.10 closed by remote host.
Click on Close SSH access
After clicking on Close SSH access:
Click on Show logs
After clicking on the Show logs button, the BSSUP panel should expand with additional information regarding SSH access history, where you can find the date and time, severity, and detailed explanation of each SSH connection:
At the bottom of the log list, there is a page selector, together with the Previous and the Next buttons.
Above the log, there is a dropdown menu to choose for which period of time the logs should be displayed, All logs or for the Last 7 days.
A SERVERware Partition is a logical group of physical resources, users, and virtual servers. The main purpose of a partition is to define the administrative boundaries for the management of virtual private servers. A partition can represent an individual, department, or company.
The Partitions menu item provides access to a graphical view of all the partitions in the system. The Partitions view consists of a partition list pane and a partition details pane. You can perform a management task on an individual partition by selecting the partition and then clicking the relevant action button.
The following properties of the partition are displayed on the Partitions view as well as on the Create and Edit dialog boxes.
Field | Description |
---|---|
Name | The partition name. Provide a descriptive name. |
Company | Provide a company name to which partition belongs. |
Account URL | An URL to a site or a CRM system containing more details about the company. |
User Quota | A maximum number of partition members. |
VPS Quota | A maximum number of VPSs that can be created within the partition. |
Memory Quota | A maximum amount of RAM memory that can be utilized by the partition VPSs. |
Storage Quota | A maximum amount of Storage space that can be utilized by the partition VPSs. |
The General tab on the Details pane provides information on an individual partition such as partition owner and resource quotas.
Follow this procedure to create a new partition:
On the "Partitions" view click "Create Partition" button.
The "Create Partition" dialog appears.
On the "General" tab enter the details in the following fields:
Name: a descriptive partition name.
Company: the company name to which the partition belongs.
Account URL: enter the company URL or leave empty.
User Quota: select max number of partition members.
VPS Quota: select max number of partition VPSs.
Memory Quota: select max amount of RAM memory for partition VPSs.
Storage Quota: select max amount of Storage space for partition VPSs.
Click the "Next" button to configure partition members on the "Partition Members" tab.
To add a user to the 'Partition Members' in SERVERware:
To remove a user from the 'Partition Members':
After managing your partition members, click the 'Next' button. This will take you to the 'Networking' tab to configure partition networking."
To set up networking for partition VPSs (Virtual Private Servers) in SERVERware:
Selecting a Subnet:
Adding a Partition IP Address:
Releasing a Partition IP Address:
In SERVERware, administrators have the flexibility to choose a different gateway for their network, instead of automatically using the default one. This feature is particularly useful when attaching a subnet to a partition and can be essential for meeting specific Internet Service Provider (ISP) requirements. This allows for the creation of segmented networks in ways that might not be standard, offering more customization to fit unique networking needs.
Click the "Next" button to configure Flavors tab and select resource flavors for partition VPSs.
Enable Resource Flavors:
Complete the Setup:
Confirmation:
You can edit the details of a partition, such as its name, resource quotas, partition members, networking, and flavors.
Follow this procedure to edit partition details:
A SERVERware partition can be removed only if there are no VPSs that belong to it.
Follow this procedure to remove a partition:
A SERVERware host is a physical 64-bit server running a special build of Gentoo Linux, configured with packages required to host virtual servers. Based on a purpose, SERVERware defines the following three types of hosts:
The Hosts menu item provides access to a graphical view of all the hosts in the system. The Hosts view consists of a host list pane and a host details pane. You can perform a management task on an individual host by selecting the host and then clicking the relevant action button. If an action is not possible, the button is disabled.
The General tab on the Details pane provides information on an individual host, including hardware and software versions. The Network Interfaces tab on the Details pane provides information about the logical and physical networks of the host. This allows you to define the attachment of the logical subnets to the physical network interface cards of the host.
Hosts must be correctly installed before you can add them to the SERVERware virtualization platform. Before adding hosts ensure that the IP Address has been assigned correctly. There is no need to additionally configure Network Bridge which is automatically created during the installation. Network Bridge allows Virtual Servers to interact with the network as if they were using physical NICs.
To add a SERVERware host, follow the next steps:
On the Hosts view, click Add Host button.
The Add Host dialog appears.
Enter the details in the following fields:
Purpose: the purpose of the host.
Storage Location: the storage location field appears only when the selected host purpose is the processing. Select the Network Storage as a storage location for VPS volumes.
Service Pool: the service pool such as the storage location makes sense only for the processing hosts. Select the Mixed pool.
Name: a descriptive name for the host. Use a button for generating a random hostname if the name is not so important.
IP Address: the IP address of the host which was provided during installation.
Root Password: the password of the designated host. If not manually changed on the host, the default password is serverware
so you will be asked to provide a new password as soon as you enter the default one into the field.
On the Advanced tab you can edit SW-Connector Port (default is 4433) and you can enable/disable Forward logs to the central syslog server by checking/unchecking box.
Click Add button to submit the form.
The new host appears in the list of hosts with a ''disabled'' state. The host health indicators for the connection and SW-connector should be green circles. Depending on it whether the host SAN network interface was pre-configured or not, the Storage connectivity indicator will be a green or red circle.
After a host has been added, updated or an existing host has been taken down for maintenance, it needs to be enabled before it can be used.
The host state changes to UP. Virtual servers can now run on the host.
The Network Interfaces tab on the Details pane of a host allows you to define the attachment of the logical subnet to the physical network interface cards (or NICs) of the host. This is a simple operation in which you attach one or more of the host's physical network interface cards (NICs) to a predefined logical subnet in the SERVERware environment.
There are three logical subnets defined by SERVERware during installation:
The Network Interfaces tab displays the name, logical subnet name, IP address, subnet mask, MAC address, and link status for each host interface. There is an Edit button next to each interface. The network interface configured during the host installation is automatically assigned to the LAN subnet. Given that the LAN interface is used for the host management, it is not safe to edit the LAN interface from the administration GUI. RAN interface is used by storage servers only and is configured automatically by the setup wizard. The SAN interface is only used in the SERVERware Cluster Edition. It is automatically set up on the storage servers by the setup wizard but needs to be configured upon the new processing host addition.
In the Hosts view, select the appropriate host.
Click Maintenance button to switch host into maintenance mode.
Click Network Interface tab on the Details pane to display the list of NICs on the host, their address and other specifications.
Click the Edit button next to NIC that you want to edit. Edit Host Network Interface dialog appears.
Select a logical subnet from the list to attach NIC to a different logical subnet.
Provide an IP address belonging to the selected logical subnet.
Click Save button to apply the changes.
Click Enable button to enable host.
WARNING: If any virtual servers stay running on the host placed into maintenance mode, be aware that they will not be automatically failed over in the case of a host failure.
Follow the below-mentioned steps to move a host into maintenance mode:
The host status stays unchanged if SERVERware Controller is unable to communicate with and control the host.
You can edit the details of a host, such as its name or network configuration.
Follow this procedure to edit host details:
Hosts that are no longer being used by SERVERware can be permanently removed. A host removing the action is allowed only for the processing hosts. A processing host can be removed only if there is no hosted VPSs on it. So, to remove a processing host for any reason make sure that you have previously moved all VPSs to another processing host.
Follow this procedure to remove a host:
If it's necessary to quickly evacuate all VPSs running on a processing host due to the maintenance tasks so you do not have to repeat multiple steps for each VPS, VPSes can be transferred from one host to another using Evacuate VPSes option in the Hosts menu. The evacuation process is implemented in a way that all VPS will be returned to their initial state as was at the point the evacuation is triggered.
For Evacuate VPSes feature to work the Host which is evacuating must be in Maintenance mode.
Follow this procedure to evacuate VPSes from the host:
In the Host view, select the host to be evacuated.
Click the Maintenance button. A confirmation dialog appears.
Click Yes. Selected Host switch into maintenance mode.
In upper right corner click on Evacuate VPSes
Clicking the “Evacuate VPSs“ button will open a small dialog box that will ask the administrator to select a host to which VPSs will be moved or to let the system to distribute VPSs evenly across all processing hosts in the cluster.
Once the evacuation is initiated, the host state label (MAINTENANCE) will be hidden and in that place, the word “EVACUATING“ will appear and stay so long until the evacuation is completed.
The evacuate action must be run before the undo evacuation. Undo evacuate will ensure that the host goes back to the state before the "Evacuate VPS" action, this is possible only if the evacuated VPSs are not moved further after the Evacuate action.
Example: If we have a processing host with VPSs and we need do some maintenance on the host update system, HDD, RAM, CPU, etc.. we can use Evacuate action the evacuate action will move all VPSs from the host to another host/host's, depending on the user selection, when maintenance work is finished and host back on-line Undo evacuate action can move VPSs back to our host in a state before the evacuate actions. The VPSs that have been moved/deleted between these actions will be ignored in Undo evacuate action.
To start undo evacuate process, select desired host from hosts view and in the upper right corrner dropdown select Undo evacuate action
VPS marked as Unavailable will not be affected by this action (these VPSs must be moved manually)
Confirm dialog is displayed before the action started. The evacuation process will cause some down-time to the VPSs the down-time depends on the hardware, VPSs size, etc.
After the confirmation, the evacuation process will start and can not be stopped until finished.
NOTE: During Undo evacuate process some hosts will show status Evacuating this is normal for Undo evacuate action.
In case there is no Undo evacuate available for the selected host or the Undo evacuation has already been executed on the selected host, a warning message will be displayed.
The sw-connector service agent running on hosts is a crucial component for the proper functioning of the SERVERware environment, so it has to be updated if there are new features or bug fixes. A host should be moved to maintenance mode before updating the sw-connector.
Follow this steps to update sw-connector:
The VPSs menu provides a graphical view of virtual servers that the connected user is permitted to administer. The VPS list pane allows you to perform a management task on an individual VPSs while the VPS details pane provides information such as details about allocated resources, owner name, network interfaces, and storage.
The General tab on the Details pane provides information on an individual VPS such as base template version, the partition it belongs to, owner name as well as details about allocated resources.
The Network Interfaces tab provides information about logical subnets to which VPS is attached.
The Storage tab provides information about VPS storage volume, location, and size. It
allows you to increase the size of the storage assigned to the VPS.
The Archive tab show info (archive URL, health and storage) about Archive service if enabled on VPS
The Terminal allows to open TTY session for selectet VPS in the same tab.
In order to provide a simple and fast way of creating a new virtual server instance, SERVERware provides virtual server templates. A template is a base virtual server that is set with a unique configuration and settings. A virtual server that is based on a particular template acquires the configurations and settings from the template. Thus, templates are used to conveniently and efficiently create a set of identical virtual servers. By default, virtual servers created from templates use thin provisioning. In the context of templates, thin provisioning means that all virtual machines based on a given template share the same base image as the template.
There are three types of templates in SERVERware:
Beside that all VPSs are supported with two engines:
KVM stands for Kernel-based Virtual Machine and is based on Firecracker, an open source virtualization technology that is purposely built for creating and managing secure, multi-tenant container services.
With KVM, each VPS has a fully emulated or virtualized machine to run its copy of the Linux kernel, providing better isolation at the cost of some additional performance. From a security standpoint, this is a much better approach to partitioning resources between multiple services and their users. SERVERware’s implementation of KVM can run unmodified Linux containers as VPSs which can either be PBXware or Docker containers fetched as OCI images from Docker Hub and similar sources. Additionally, one can pack and distribute service software using open standards and tools.
Follow this procedure to create a new virtual server:
On the Virtual Private Servers view click Create VPS button.
The Create VPS dialog appears.
On the General tab enter the details in the following fields:
Type: the type of virtual server to be created.
Service: a service that VPS has to provide. This field appears if a selected VPS type is the service. Select a service name from the list.
Template: the base virtual server version for selected VPS type. Select a template from the list.
Partition: the partition which VPS belongs to.
Host: the host on which VPS will be created
Engine: type of engine on which VPS will be running
Name: a descriptive name of VPS.
Highly Available: enable failover of VPS to storage host.
Exclude From Backup: if selected the VPS will be excluded from backup.
Enable Protected Mode: if selected only administrator can manage VPS ( start, stop, restart).
Include in replication: if selected the dropdown with the list of available enabled replications will appear (select the replication from dropdown to add the created vps to the replication cycle).
Description: Describe VPS if necessary.
Click the Next button to configure Security tab.
Password field: enter password manually (existing password will not be displayed here).
Generate password: serverware will generate the new password.
Check box: select to confirm the password is copied to a safe place
Click the Next button to configure VPS resources on the Resources tab.
On the Resources tab enter the details in the following fields:
Flavor: a resource flavor. Select a flavor from the list that provides a resource ratio which fits the VPS needs.
CPU: limit CPU cores for per VPS. values available :
The default values for CPU limits are inherited from the selected resource flavor.
Bandwith: limit disk read/write bandwith in MB/s
IOPS Limit: Limiting IOPS per VPS. The default value to be 150 With several other options included:
The default values for Read/Write IOPS limits are inherited from the selected resource flavor.
AstDB RAM Disk: a size of RAM disk to keep Asterisk database. This affects PBXware based VPSs only and should be configured only if you detect a performance issue.
Call Recordings RAM Disk: a size of RAM disk to keep call recordings. (PBXware only)
Mount points :
Assign the size of the mounted folder on /tmp for VPS.
• Size of temporary directory:
Temp directory size larger than 50% of RAM given to VPS is not recommended.
Assign the size of the mounted folder on /run for VPS.
• Size of run directory:
Run directory size larger than 25% of RAM given to VPS is not recommended.
Click the Next button to configure VPS networking on the Networking tab.
On the Networking tab select the logical subnet to which you want to connect the VPS.
Click the Next button to configure DNS SRV + NAPTR record if configured.
The DNS lookup routine looks for SRV records first. Proper use of SRV records permits the administrator to distribute a service across multiple hosts within a partition, to move the service from host to host without disruption, and to designate certain hosts as primary and others as alternates.
To set up DNS SRV record on the PBXware VPS
Populate the fields with the data required and press Save.
service
Symbolic name of the service.
The service name is what the client accepts as service (for IP telephony service used is "_sip" or for TLS "_sips").
Protocol
Protocol used to access the service. The SIP clients accept either "_tcp" or "_udp" depending on the client configuration. TLS will only work with "_tcp".
Target
Partition name associated with the resource record.
In the partition name, we will enter the full path to our PBXware VPS including the VPS name "vpsname.cluster1.serverware.xyz")
priority
Service priority. Servers are ordered by priority with the lower priority numbers ordered before the higher priority numbers. Set the priority to 0 if the priority order is not wanted.
weight
Load balancing within the same priority. A higher weight number indicates that the server can handle more requests than a lower weight number. The probability that a server is ordered early in the list increases as the weight increases. Set the weight to 0 if load balancing is not wanted. Otherwise, use nonzero values for all the weights within the same priority. (An SRV record with a weight of 0 has a low probability of being ordered before an SRV record with a nonzero weight).
port
The port number is assigned to the SIP service. This value would be "5060" or "5061" for TLS.
While it is preferable to use a single SRV record for each sip server, some implementations might require multiple SRV records with a single service record for each resource name. As there are some clients on "TCP" and some on the "UDP" on the same service.
Now we can save the configuration and start VPS.
When creating the VPS from the OCI image first we have to download the OCI image from the repository and add it to SERVERware templates, see "OCI image Template" section.
You will notice that we have a new Environment tab appear when OCI is selected as a source
Example for MySQL :
Here we can add some external environment variables needed for the OCI image to function properly, the available environment variables are listed in the docker hub for the image used.
Finish the steps to the end and hit create button, after this, we will have a functional VPS created from the OCI image.
Administrative tasks for virtual servers include:
Follow this procedure to edit VPS details:
Management actions such as VPS starting, stopping, and restart is performed directly on the virtual server by using dedicated buttons for that purpose located on the top of the virtual server list.
Follow this procedure to trigger a VPS management action:
Follow this procedure to change VPS owner:
Follow this procedure to increase VPS storage space:
In the Virtual Private Servers view, select the VPS for which you need to increase storage space.
If the VPS that you want to change is not visible in the list, perform a search.
Select Storage tab and click the Extend Volume button.
Extend Volume dialog appears.
Select an amount you wish to increase storage space for and click the Extend button to increase storage.
Follow this procedure to reclaim VPS storage free space (VPS must be stopped):
In the Virtual Private Servers view, select the VPS for which you need to reclaim free space.
If the VPS that you want to change is not visible in the list, perform a search and stop VPS.
Select Storage tab and click the Trim button.
Trim storage dialog appears, click YES to start trim process.
The trim feature will be available only when there is more than 10% of unused space for trim
TTY is passwordless CLI VPS access from SERVERware GUI. In case of misconfigured ssh, custom templates without an ssh client or for any other reason ssh might be inaccessible.
TTY session will provide easy access for troubleshooting. This is the internal SERVERware service, so it does not depend on the status of services in the VPS.
You can open multiple TTY sessions on a single VPS and TTY session for any VPS from SERVERware GUI.
We strongly advise you to use some kind of screening tool for performing actions that can take longer than 30 min (tmux, screen, etc..)
Steps:
Follow this procedure to move VPS to another host:
Follow this procedure to move VPS to another partition:
In SERVERware, a VPS can be cloned regardless if VPS is stopped or still running. This is especially useful for creating multiple instances of already configured and running VPSs.
Follow this procedure to clone VPS:
VPS can be removed only if it is stopped.
Follow this procedure to remove a VPS:
When removed, VPSs move to the Removed VPSs list, which acts like a recycle bin as it is possible to restore listed VPSs.
If the removed VPS has a backup, it would be possible to restore that VPS from the removed VPSs menu.
To restore the removed VPS, follow these steps:
Go to the VPS menu and click on the Removed VPSs icon
Select the VPS and click Restore
Pop-up menu will appear, then select Restore Point, Partition, Host, and Name of the VPS
Click the Restore button to start the restore VPS process.
The SERVERware statistics module collects data about the resource usage by Hosts as well as VPSs. Data on a wide range of metrics is collected at frequent intervals, processed and archived in the SERVERware database.
The Statistics menu item provides access to a statistic chart view. The Statistics view consists of a chart settings pane and a chart view pane. On the statistic view, you can see both Host and VPS performance charts as well as do a performance comparison between Hosts/VPSs. The following metrics are available in the chart settings:
Follow this procedure to view Host/VPS performance charts:
Select a Host/VPS which performance charts you want to show.
Click the Compare button if you want to compare the performance of different Hosts/VPSs.
The Backup menu item provides access to a backup Schedule and Browse & Restore submenu. The Schedule view consists of a list of scheduled backup jobs below which is a pane showing the backup job history for a selected backup job. The Browse & Restore view consists of a list of backup hosts on which backups are placed and then select a backup host and backup set below there is a pane showing the VPS restore points.
The following properties of a backup job are displayed on the Backup view as well as on the Add and Edit dialog boxes.
Field | Description | |
---|---|---|
Name | The backup job name. Provide a descriptive name. | |
Mode | Available choices for the backup Mode are Backup to ZFS and Backup to File (legacy) | |
Partition | The name of partition from which you want to backup VPSs. It may be an individual partition or all partitions in the network. | |
Destination | The name of a host dedicated to backup. It may be the existing Network Storage host, however, this is not recommended. | |
Pool | The name of the backup dedicated pool. |
It is possible to create any new dataset for backup purposes just by setting srw:dstype property to 'backup'. By default SERVERware set 'backup' property on SYSTEM-xxxx/BACKUP dataset.
But if user want to create a new dataset for backup it is necessary to create a folder for new dataset eg. /newbackup. Then create zfs dataset, mount /newbackup folder to that dataset and set 'backup' property using following command:
~ # mkdir /newbackup
~ # zfs create SYSTEM-XXXX/newbackup -o mountpoint=/newbackup -o overlay=on -o compression=on -o srw:dstype=backup
A newly created dataset for the backup will be available for selection when scheduling a backup job.
Follow this procedure to schedule a backup job:
On the Backup view click Schedule then click on Add Job button.
The Create Backup Job dialog appears.
Enter the details in the following fields:
Job Name: Descriptive backup job name (e.g. Daily Backup).
VPSs From: Select a source partition if you want to create a backup job for VPSs running on that partition only or leave default (''All Partitions'') to backup all VPSs running on all partitions.
Destination: Select a host for backup destination. It is recommended to have a dedicated host for storing backups.
Path/Pool: File system path on which to store backups.
Schedule
Backup Type Select either a full or incremental backup job type.(If backup to zfs option selected only incremental backup type is available) The full backup type means that a full backup will always be performed at a set time and frequency. The incremental backup means that a full backup will be performed only once a week while incremental backup will be performed on other days.
At: select the period of time in wich backup action will be performed
Keep Backup : select from a dropdown of available retention time for backups
When removing a backup job, it is important to note that this action will not remove already created restore points, created by that backup job.
Follow this procedure to remove a backup job:
VPS restoration will revert a VPS to a previously saved restore point. Restore VPS option in Browse & Restore menu will create a new copy of a VPS. Follow this procedure to restore a VPS:
In the Backup menu select Browse & Restore submenu item.
From the Select a Backup Host menu select backup host which contains a backup set.
From Select a Backup set select a backup set which contains restore points fro VPS you want to restore.
Select VPS which you want to restore and click Restore button.
Select a restore point and destination partition to restore VPS and click Restore button.
Restore of VPS will start and progress indicator bar will show progress in percentage and if necessary you can cancel restore by clicking on red Cancel icon on the right. Canceling restore will automatically delete VPS that is created by restore process and clean all data related to that restore process.
After completing restore process, Recent Restores view should look like below, now you can start using restored VPS.
VPS restoration will revert a VPS to a previously saved restore point. Bulk Restore VPSes option in Browse & Restore menu will create a new copys of selected VPSes. Follow this procedure to restore multiple VPSes (bulk restore):
In the Backup menu select Browse & Restore submenu item.
From the Select a Backup Host menu select backup host which contains a backup set.
From Select a Backup set select a backup set which contains restore points fro VPS you want to restore.
In upper right corner next to the Restore button click on Bulk Restore.
Initialize a queue of VPSes for the bulk restore action by configuring the restore options for an individual VPSes and adding them into the queue and click Start' button to start VPS bulk restore process
To see current running bulk restore task, in the Backup menu select Browse & Restore submenu item. Then select backup host on which bulk restore job is created.
From SERVERware 4.4 version, it is possible to permanently remove the backup and exclude the VPS from future backups. This feature is helpful if VPS is removed or backup for that VPS is no longer needed.
To remove VPS from the backup, go to the Backup section, then to Browse & restore. Select the Backup host and the Backup Set on which VPS is backed-up. Select the VPS and then click the Remove button in the upper right corner.
The popup dialogue will appear which can be selected to exclude VPS from future backups if needed.
There are two types of replication,in SERVERware.
Local Replication - By using the replication feature users can connect SERVERware on the same locations to replicate VPSs and be able to recover/takeover/move VPSs between multiple SERVERware instances or clusters with minimum data loss.
Geo-Redundancy - Equivalent to previous except to allow connection between multiple sites. In this case, SERVERware operating at two or more geographical locations as a redundancy in case the primary system fails due to any reason.
This feature will provide the user with the ability to take over services on a remote site with a certain degree of data shift, but that will primarily depend on how frequent data replication is between sites. However, the feature is to give more flexibility in infrastructure requirements, and lower the cost for the customer while still providing a tool on the computer platform level toward achieving a high percentage of availability.
Once GRS (Geo-Redundancy Server) is connected with SERVERware, it can be used for two primary functions. One is to set up replication to this server, and another to browse/list existing replications with the option to select and takeover VPSs from.
Summary of properties
Configure the replication cycle
Browse & Takeover from GRS
Control GRS Resources
For Geo-Redundancy feature to work license must be upgraded (please contact your account manager).
From the left menu, select Geo-Redundancy than from the drop down select Servers.
The Geo-Redundancy overview window will open.
To add the Geo-Redundancy Server press the Add server button in the upper left corner and a popup will open.
Enter new GRS details as required.
General
Advanced
Dropdown values
Populate all the required fields and press "Add".
We have finished adding a new Replication site, now we can manage details for the Replication. Select the site you need to manage and press "Configure Replication" upper right corner.
Replication Config
Replication Enable or disable replication
Replication Cycle Select the desired value in minutes from the predefined drop-down list (Replication Cycle is the time frame between replications)
Recovery points to keep Enter the number of recovery points to keep (Bigger the number of the recovery points the more space on Geo-Redundancy Server will be used)
Geo-Redundancy Server will keep replications until next full circle.
Replicated Partitions
From the dropdown select the partition you want to replicate on another location when selected a list of VPSs from the selected partition will be displayed.
Check the boxes next to the VPSs you wish to replicate or Check the box next to the partition name to select/deselect all.
Alternate Local IP address - Define an alternative IP address for the VPS to use after the takeover. (Address used must be available in the remote SERVERware IP address pool, and if PBXware service is used, it must have secondary IP address defined)
Alternate External IP Address - Define an alternative external IP address for the VPS to use after the takeover. (Address used must be available in the remote SERVERware IP address pool, External IP Addresses enable the VPS to be available from a public network when NAT is used to forward its private IP address to a public IP address)
Press "Save and Apply" to finish setting up the replication.
The first replication will start depending on the time frame defined in configuration and it will be the "Full Replication Cycle" for every VPS selected.
Full replication is done only in the first cycle and can generate a high amount of traffic through the LAN network and cause a slow response while running, full replication should be planned when most VPSs are idle or stopped.
For GR sites that have more intricate networking, with multiple network cards and network interfaces assigned to hosts and VPSs, SW administrators can now assign multiple alternate IPs for each network interface added to a VPS.
Recent replications
Recent replications window display progress and status of replication cycles.
On the right side of every cycle, there is a detail view button, marked with the red square on the screenshot, when opened replication details will be displayed.
Replication Details
Replication tasks
SERVERware GR feature allows us to use multiple sites for replication purposes, the same data can be transferred to several locations to assure data loss prevention.
The replication configuration panel shows the list of remote sites (Geo-Redundancy Servers), and it will allow the configuration of scheduled replication per each. The number of Geo-Redundancy Servers is limited by license, and so implicitly a number of takeover sites. Adding more sites will require a license update.
The procedure of adding the GR site to the takeover location is the same as adding the GR site to the primary site location.
From the left menu, select Geo-Redundancy than from the drop down select **Servers''.
Geo-Redundancy Server overview will open.
To add the Geo-Redundancy Server press the Add server button in the upper left corner and a popup will open.
Enter new Geo-Redundancy Server details as required.
General
Advanced
Dropdown values
Populate all the required fields and press "Add".
We have finished adding a replication site, now we can browse the replications.
Select the "Browse & Takeover" from the menu.
When the "Browse & Takeover" is open, in the upper left corner we can choose the Geo-Redundancy Server and Origin SIte after we choose this the list of the available replications will be displayed below.
Browse the replications, find and select the one you need to take over, and press the Takeover button in the upper right corner for a single VPS takeover or Bulk takeover for multiple VPS takeover.
Also, Bulk takeover action can be saved as Template for quick use in case of a primary site failure (templates can be edited/updated after the creation).
Takeover single VPS
On the right side of the window Metadata of the VPS is displayed for the information purpose.
Metadata
Name: VPS-01
Last Known State: STOPPED
Partition: Default
Company:
Owner: Administrator
Template: PBXware 5.2
Engine: KVM
Volume: 41.00 GB
Memory: 2.00 GB
IP Address: 192.168.200.149
External IP Address: N/A
For virtual interfaces, post takeover the IPs would need to be manually set. Once the VPS has been taken over to the GR site, the alternate IPs will be automatically assigned. This goes for systems behind NAT, post-takeover, both local and external IP addresses will be automatically added to the VPS.
When fields are populated press the Takeover button in the right bottom corner
The takeover process will begin and the duration of the takeover depends on the amount of storage used by the selected VPS.
Bulk Takeover
In the new Bulk takeover window user can add the VPSs to a takeover action with the series of steps:
When all fields are populated press add VPS to queue to add VPS to the list below, this action can be repeated for all VPSs in the Replication database.
When we have finished the list we have two options:
Saved templates window is the list of all saved templates on the server, here we can edit templates and delete templates.
If started the takeover process details can be monitored in the Recent Takeovers window
During the takeover process it is possible to cancel single/multiple VPS takeover or to cancel all takeover with one click.
When the Takeover process is COMPLETED, VPS can be managed from the VPSs section on the main menu.
This concludes take over process.
SERVERware administrators are able to remove old or unnecessary VPS replications from the GR pool by simply selecting the replication they wish to remove and then clicking on the remove button. This will in no way affect the VPS on the production site, or have any impact on the VPSs that are running on the GR site. Once the VPS is removed from the GR pool, it can easily be replicated in full in the next replication cycle.
To remove VPS replication, select the VPS and click on the Remove button. Pop-up dialoge will appear to confirm removal.
For replications older than two weeks, the administrator will see a warning icon indicating that the snapshot in question has data that hasn’t been resynced for the above mentioned time frame.
The main function of the site monitor is to monitor the replication site with a series of different tests and execute actions based on the test results.
To create and start site monitoring select the Site monitoring from the Replication menu.
When Create site monitor button is pressed site monitor edit view will open.
Here we add tests to our new site monitor, first, we have to add a new name for our monitor.
Then we will set the interval of our tests(all tests will execute in a set period for the selected site).
And we will save our monitor, so we can continue adding test cases.
Now we add our new test to the selected site monitor.
Field | Description |
---|---|
Destination: | This will be destination for our ICMP test, set the "IP address" or "Partition name" as destination. |
Packet count: | Specifies the number of echo requests, or pings, to be sent. |
Test Timeout (s): | Designates the maximum amount of time for the test duration. After that time, test will stop. |
Packet delay(ms): | Delay between pings designates the time in milliseconds between each successive PING to the target address. Setting this value very low will send a constant stream of Pings to the destination IP address. |
TTL: | Designates the number of hops allowed along the way to the specified address. With a setting of 10, your PING test could pass through up to 10 different routers on the way to the remote address before being discarded by the network. |
Packet size(B): | Designates the number of data bytes to be sent. The default is 64, combined packet size 56 bytes with the 8 bytes of ICMP header data. |
Maximum loss (%): | Designates the maximum acceptable amount of "packet Loss" in percents(%). |
Max avg. latency (ms): | Designates the maximum acceptable amount of "average latency" in milliseconds. ''If the latency is above entered value test will fail''. |
Timed out: | When ON it will ignore field Test Timeout. |
Invert result: | When ON it will invert test results, ''A failed test will be successful and vice versa''. |
Dry Run button | When pressed will run the "dry test" and display results.(for successful test will be "GREEN" info bar, and fail test will be "RED" info bar). |
Cancel button | Will discard all changes and close the dialogue. |
Update | Will update test configuration and close the dialogue. |
The HTTP test use standard GET, HEAD, POST, PUT, DELETE, requests set and additional success conditions.
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers.
HTTP works as a request-response protocol between a client and server.
Example: A client(our test) sends an HTTP request to the server; then the server returns a response. The response contains status information about the request and may also contain the requested content.
Field | Description |
---|---|
URL: | This will be destination for our HTTP test, "http://", or "https://" are mandatory in destination address. |
Request Type: | * The HTTP GET method requests a representation of the specified resource. Requests using GET should only be used to request data (they shouldn't incude data). * The HTTP HEAD method requests the headers from requested url. * The HTTP POST method sends data to the server. The type of the body of the request is indicated by the Content-Type header. * The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload. * The HTTP DELETE request method deletes the specified resource. |
Test Timeout (s): | Designates the maximum amount of time for the test duration. After that time, test will stop. |
Verify SSL: | You can verify the SSL certificate on your destination to make sure it is correctly installed, valid, trusted and doesn't give any errors to any of your users |
Headers | HTTP headers let the test server pass additional information with an HTTP request or response. An HTTP header consists of its Name and Value * Example: ** Name: Authorization ** Value: Basic U0VSVkVSd2FyZTpleGFtcGxl |
Arguments: | HTTP Arguments let the test server pass specific arguments with an HTTP request or response. An HTTP argument consists of its Name and Value * Example: ** GET from: https://www.google.com/search ** Name: q ** Value: SERVERware |
Body: | Body is used to manually add body for your request, depending of your needs. * Body in JSON example: { "name": SERVERware, "version":4 } |
Response Code: | HTTP response status codes indicate whether a specific HTTP request has been successfully completed. The test will fail if the requested code is not returned from the destination. Responses are grouped in five classes: Informational responses (100–199) Successful responses (200–299) Redirects (300–399) Client errors (400–499) Server errors (500–599) More details on response codes: ''https://developer.mozilla.org/en-US/docs/Web/HTTP/Status'' |
Response RegExp: | Regular expression is used for parsing the response code. Example: In the test above if the test response contains SERVERware the test will pass. More details on how to use regular expressions: https://en.wikipedia.org/wiki/Regular_expression |
Invert result: | When ON it will invert test results, ''A failed test will be successful and vice versa''. |
Dry Run button | When pressed will run the "dry test" and display results.(for successful test will be "GREEN" info bar, and fail test will be "RED" info bar). |
Cancel button | Will discard all changes and close the dialogue. |
Update | Will update test configuration and close the dialogue. |
''The Transmission Control Protocol(TCP) is a transport protocol carried over the Internet Protocol(IP). Together the two protocols are often called the TCP/IP protocol stack. The TCP is a host-to-host protocol it's scope is to provide reliable process-to-process communication in a multinetwork environment. Where IP provides no guarantee that sent packets are actually delivered to the intended recipient in the right order, TCP detects these problems, re-transmits lost data, removes duplicated data, and rearranges out-of-order data. Hereby TCP provides reliable, ordered and error-checked data delivery between applications communicating through an IP network.''
Field | Description |
---|---|
Address: | This will be destination IP address for our TCP test. |
Port: | Specifies the target port. |
Test Timeout (s): | Designates the maximum amount of time for the test duration. After that time, test will stop. |
Invert result: | When ON it will invert test results, A failed test will be successful and vice versa. |
Test payload | The payload of a TCP or UDP packet is the data portion of the packet. |
Response Size(B): | Expected size in Bytes of the response payload. If the response payload returns the correct response size, the test success condition is met. |
Response RegExp: | Regular expression is used for parsing the response code. More details on how to use regular expressions: https://en.wikipedia.org/wiki/Regular_expression |
Reply: | When ON success condition parameters will be used in the test. |
Dry Run button | When pressed will run the "dry test" and display results.(for successful test will be "GREEN" info bar, and fail test will be "RED" info bar). |
Cancel button | Will discard all changes and close the dialogue. |
Add / Update | Will add / update test configuration and close the dialogue. |
''The User Datagram Protocol (UDP) is a connectionless transport-layer protocol (Layer 4) that belongs to the Internet protocol family. UDP is basically an interface between IP and upper-layer processes. UDP protocol ports distinguish multiple applications running on a single device from one another. Unlike the TCP, UDP adds no reliability, flow-control, or error-recovery functions to IP. Because of UDP’s simplicity, UDP headers contain fewer bytes and consume less network overhead than TCP. UDP is useful in situations where the reliability mechanisms of TCP are not necessary, such as in cases where a higher-layer protocol might provide error and flow control. UDP is the transport protocol for several well-known application-layer protocols, including Network File System (NFS), Simple Network Management Protocol (SNMP), Partition Name System (DNS), and Trivial File Transfer Protocol (TFTP).''
Field | Description |
---|---|
Address: | This will be destination IP address for our TCP test. |
Port: | Specifies the target port. |
Test Timeout (s): | Designates the maximum amount of time for the test duration. After that time, test will stop. |
Invert result: | When ON it will invert test results, ''A failed test will be successful and vice versa''. |
Test payload | The payload of a UDP packet is the data portion of the packet. |
Response Size(B): | Expected size in Bytes of the response payload. If the response payload returns the correct response size, the test success condition is met. |
Response RegExp: | Regular expression is used for parsing the response code. More details on how to use regular expressions: ''https://en.wikipedia.org/wiki/Regular_expression'' |
Select Reply Port: | When ON success condition parameters (reply port) will be used in the test. |
Dry Run button | When pressed will run the "dry test" and display results.(for successful test will be "GREEN" info bar, and fail test will be "RED" info bar). |
Cancel button | Will discard all changes and close the dialogue. |
Add / Update | Will add / update test configuration and close the dialogue. |
M/Monit uses Monit as an agent and can manage and monitor all your hosts and services. SERVERware 4.3.x version comes with integrated MMonit which can be used for monitoring systems from SERVERware.
A New MMonit option in the 'Add Site Test' dropdown list is added for easier setup of SERVERware Site monitoring with the third part monitoring tool “MMONIT”.
In the Site Monitoring Name field enter the desired Name for the monitor (In the example we will use the MMONIT ). Set the Schedule time [this represents the time, how often the test will be triggered] and press Save and Apply.
Next, we need to add a New site Test (from the dropdown select MMonit).
A popup window will appear:
Populate the fields:
URL: http:// < MMONIT IP > :8080/api/1/reports/events/list
Request Type: GET (Per MMonit API documentation)
Test Timeout in seconds: 10 [test will wait for the response max 10 seconds after this if no response test will fail]
Per MMonit API documentation we need to add two arguments in our API call to filter only fail events
First, on the Arguments tab, we will add
z_csrf_protection with value off
and
state with the value 1 (this will filter results and display only fail events)
In the Authentication, tab enter the username and the password for the MMonit (this is the user and the pass from the GUI )
For the success conditions, we will use
Response code: 200 [default]
Response RegExp: (we will search for the hostname we have set in the MMonit earlier)
Now we can test our setup by pressing the "Dry Run" button the result should be Test successful (at this point make sure your MMonit is not failing already).
Press the Update button and the test will be saved in the test list.
Test can be edited/removed with the click on the appropriate icon. Actions can be removed only.
Geo-Redundancy Server has its own setup and configuration for its services. Authentication and authorization of access to this service will be determined by API keys and Access Control Lists (ACL). There are two distinct use cases:
Simple plain data redundancy between site
Hosting data redundancy between sites
Case 1, SERVERware on primary and takeover site will be connected to Geo-Redundancy Server with admin API key. The administrator will have access to browse all data on the Geo-Redundancy Server and takeover from any site any replicated VPS to default or partition by choice.
Case 2, SERVERware on the primary site will be connected to the Geo-Redundancy Server with user API key and takeovers will be managed by the hosting provider. (Hosting provider will provide credentials and IP address for the GRS)
To manage the replication service we will be using a tool called "swrepl-adm", this is a CLI managed tool.
Open the SSH client (Putty for example which can be downloaded from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).
Under 'Host Name', type the host system IP address (e.g. 232.123.44.108).
Set 'Port' # '2222'. Click on the 'Open' button to initialize the connection.
Default login for your ssh connection will be “root” and password: “serverware”.
Once you have logged in on your server, you can start using CLI commands.
IMPORTANT If deployed on the mirror/cluster setup of storage servers, we will use “floating IP” from, that way ssh client will connect you to whatever server is in the primary state. Replication storage must be located on the storage host in the NETSTOR pool. Storage for the Geo-Redundancy Server should only be considered as a pool with SSD storage.
After logging, on the screen, you should get simple output information about the server.
Example :
███████╗██╗ ██╗ ██╗ ██╗
██╔════╝██║ ██║ ██║ ██║
███████╗██║ █╗ ██║█████╗███████║
╚════██║██║███╗██║╚════╝╚════██║
███████║╚███╔███╔╝ ██║
╚══════╝ ╚══╝╚══╝ ╚═╝
* SERVERware system IP Address/es:
* 127.0.0.1/x 192.168.x.x/x 10.1.x.x/x 192.168.x.x/x
* Login into the setup by visiting:
* https://127.0.0.1:81/
* https://192.168.x.x:81/
* https://10.1.x.x:81/
* https://192.168.x.x:81/
~ #
Start using the SWREPL application by running the command :
~ # swrepl-adm
The swrepl-adm console will be opened in the terminal and we can start creating a site for replication.
site { COMMAND | help}
COMMAND :#
Add replication site with description, optional set storage quota, throttling in bytes per second,
and allowed IPs (default allows all).
e.g. "192.168.1.10, 10.1.0.0/16, 2001:db8:a0b:12f0::1/32"
default value 0.0.0.0/0 in the list means allow all
Update replication site with description, optional set storage quota, throttling in bytes per second,
and allowed ips (default allows all).
replication { COMMAND | help}
COMMAND :#
- list [id] Show the list of all defined replications for this daemon.
- help Show help.
public_key { help } Output own rsa public key.
admin_key {set newkey} { help } Output or set current admin API key.
task { COMMAND | help}
COMMAND :#
- list [-l, -t backup] [id] List tasks, showing unique id and other settings.
-l - Limit list size (default is 10, 0 for unlimited)
-t - filter tasks of specific type backup,replication or srv_backup,srv_repl
id - id of task for detailed output
- cancel id Cancel task by its id
To be able to create a GRS site we must first create a ZFS dataset for this purpose.
The Geo-Redundancy dataset can be created on the storage host NETSTOR pool.
Minimum storage available for the Geo-Redundancy Server should be double the size of the initial storage occupied by the VPS's combined in the replication circle.
Storage for the Geo-Redundancy Server should only be considered as a pool with SSD storage.
ZFS file systems are created by using the zfs create command. The create subcommand takes a single argument: the name of the file system to be created. The file system name is specified as a pathname starting from the name of the pool as follows:
pool-name/[filesystem-name/]filesystem-name
The pool name and initial file system names in the path identify the location in the hierarchy where the new file system will be created. The last name in the path identifies the name of the file system to be created.
In the following example, a datase named GRS is created in the NETSTOR file system.
~ # zfs create NETSTOR/GRS
ZFS automatically mounts the newly created file system if it is created successfully. By default, file systems are mounted as /dataset, using the path provided for the file system name in the create subcommand. In this example, the newly created Geo-Redundancy Server file system is mounted at /NETSTOR/GRS.
Execute zfs list command to ensure dataset is created:
~ # zfs list
NAME USED AVAIL REFER MOUNTPOINT
NETSTOR 489G 156G 142M /NETSTOR
NETSTOR/CONTROLLER 1.38G 156G 1.38G /NETSTOR/CONTROLLER
NETSTOR/GRS 483G 156G 112K /NETSTOR/GRS
NETSTOR/logs 476K 8.00G 476K /NETSTOR/logs
NETSTOR/templates 3.60G 156G 96K none
SYSTEM-e274 10.1G 205G 96K none
SYSTEM-e274/BACKUP 96K 205G 96K legacy
SYSTEM-e274/rootfs 6.63G 8.37G 4.63G /
SYSTEM-e274/rootfs/log 118M 1.89G 118M legacy
SYSTEM-e274/swap 2.13G 207G 60K -
After this continue with creating the 8145EEE4 site.
On the selected host run swrepl-adm CLI tool.
~ # swrepl-adm
»
Space used for the Geo-Redundancy dataset should be 60% of the storage space available, this way we will secure there is enough space left for replications.
When in the "swrepl-adm" console we can use CLI commands to create a new site to do this we will type :
» site add -storage NETSTOR/GRS -quota 450G -throttle 70M -admin=true -allowedips "192.168.1.10,10.1.0.0/16" "this is my site"
OK 93010f9f4003723d2eec317bf7160e0d
In the list of allowed IPs the remote Controller IP, and the Storage Host IP addresses must be allowed. The best practice is to add the whole subnet of the cluster.
The site with ID: 93010f9f4003723d2eec317bf7160e0d is created, to confirm the site parameters type:
» site list
ID | INFO | ADMIN | STORAGE | QUOTA | THROTTLING
+------------+-----------------+-------+-------------+-----------+------------+
93010f9... | this is my site | false | NETSTOR/GRS | 450.0 GiB | 70.0 MiB/s
+------------+-----------------+-------+-------------+-----------+------------+
All available sites will be displayed, for a more detailed view add site ID after the command
» site list 93010f9f4003723d2eec317bf7160e0d
ID: 93010f9f4003723d2eec317bf7160e0d
Description: this is my site
Admin: true
API Key: 7e0f6463412acc17d3ff163065c1d897
Storage: NETSTOR/GRS
Quota: 450.0 GiB
Throttling: 70.0 MiB/s
Allowed IPs: 192.168.1.10,10.1.0.0/16
to edit the site parameters after the creation site update command can be used:
lets change allowed IPs for example:
» site update 93010f9f4003723d2eec317bf7160e0d -allowedips 0.0.0.0
OK
» site list 93010f9f4003723d2eec317bf7160e0d
ID: 93010f9f4003723d2eec317bf7160e0d
Description: this is my site
Admin: true
API Key: 7e0f6463412acc17d3ff163065c1d897
Storage: NETSTOR/GRS
Quota: 450.0 GiB
Throttling: 70.0 MiB/s
Allowed IPs: 0.0.0.0
If the details on the site are correct we can use API Key: 7e0f6463412acc17d3ff163065c1d897 to connect the SERVERware to our newly created site and start the replication process.
If there is failure on primary site after failover and restore to remote location, to return data to primary site, using the same procedure we will create Geo-Redundancy dataset on storage host (Site - A) and return data to primary location.
To create a new dataset log-on the Processing Host
~ # zpool status | grep pool
pool: SYSTEM-e694
~ # zfs create SYSTEM-e694/GRS
~ # zfs set mountpoint=legacy SYSTEM-e694/GRS
~ # zfs set overlay=on SYSTEM-e694/GRS
~ # mkdir /GRS
~ # mount -t zfs SYSTEM-e694/GRS /GRS
~ # cat /proc/mounts | grep GRS
SYSTEM-e694/GRS /GRS zfs rw,relatime,xattr,noacl 0 0
The output of the last command should be copied into /etc/fstab.
~# nano /etc/fstab
# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't
# needed); notail increases the performance of ReiserFS (at the expense of storage
# efficiency). It's safe to drop the noatime options if you want and to
# switch between notail / tail freely.
#
# The root filesystem should have a pass number of either 0 or 1.
# All other filesystems should have a pass number of 0 or greater than 1.
#
# See the manpage fstab(5) for more information.
#
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
systemd /sys/fs/cgroup/systemd cgroup rw,relatime,name#systemd 0 0
/dev/zvol/SYSTEM-e694/swap none swap defaults 0 0
SYSTEM-e694 /rootfs/log /var/log zfs rw,relatime,xattr 0 0
SYSTEM-e694/GRS /GRS zfs rw,relatime,xattr,noacl 0 0
After the editing saves the file and exit.
Reboot the processing host.
After the host, reboot log on and inspect dataset and mount point we have just created in ZFS
~ # zfs list
NAME USED AVAIL REFER MOUNTPOINT
SYSTEM-e694 117G 225G 19K none
SYSTEM-e694/GRS 24K 225G 24K legacy
SYSTEM-e694/rootfs 7.10G 7.90G 5.10G legacy
SYSTEM-e694/rootfs-prev 4.94G 10.1G 4.94G /
SYSTEM-e694/rootfs/log 24.9M 1.98G 24.9M legacy
SYSTEM-e694/swap 2.13G 227G 12K -
If we can see a new dataset as shown (SYSTEM-e694/GRS 24K 225G 24K legacy) we have successfully created a new dataset and we can continue setting up the Replication users.
On the selected host run swrepl-adm CLI tool.
~ # swrepl-adm
»
Space used for the Replication dataset should be 60% of the storage space, this way we will secure there is enough space left for replications.
When in the SWREPL console we can use CLI commands to create a new site to do this we will type :
» site add -storage SYSTEM-e694/GRS -quota 450G -throttle 70M -admin=false -allowedips "192.168.1.10,10.1.0.0/16" "this is my site"
OK 93010f9f4003723d2eec317bf7160e0d
In the list of allowed IPs the remote Controller IP, and the Storage Host IP addresses must be allowed. The best practice is to add the whole subnet of the cluster.
The site with ID: 93010f9f4003723d2eec317bf7160e0d is created, to confirm the site parameters type:
» site list
ID | INFO | ADMIN | STORAGE | QUOTA | THROTTLING
+------------+-----------------+-------+-------------+-----------+------------+
93010f9... | this is my site | false | SYSTEM-e694 | 450.0 GiB | 70.0 MiB/s
+------------+-----------------+-------+-------------+-----------+------------+
All available sites will be displayed, for a more detailed view add site ID after the command
» site list 93010f9f4003723d2eec317bf7160e0d
ID: 93010f9f4003723d2eec317bf7160e0d
Description: this is my site
Admin: false
API Key: 7e0f6463412acc17d3ff163065c1d897
Storage: SYSTEM-e694/GRS
Quota: 450.0 GiB
Throttling: 70.0 MiB/s
Allowed IPs: 192.168.1.10,10.1.0.0/16
to edit the site parameters after the creation site update command can be used:
lets change allowed IPs for example:
» site update 93010f9f4003723d2eec317bf7160e0d -allowedips 0.0.0.0
OK
» site list 93010f9f4003723d2eec317bf7160e0d
ID: 93010f9f4003723d2eec317bf7160e0d
Description: this is my site
Admin: false
API Key: 7e0f6463412acc17d3ff163065c1d897
Storage: SYSTEM-e694/GRS
Quota: 450.0 GiB
Throttling: 70.0 MiB/s
Allowed IPs: 0.0.0.0
If the details on the site are correct we can use API Key: 7e0f6463412acc17d3ff163065c1d897 to connect the SERVERware to our newly created site and start the replication process.
If there is failure on primary site after fail over and restore to remote location, to return data to primary site, using the same procedure we will create Replication dataset on storage host (Site - A) and return data to primary location.
Depending on the setup you are running sipPROT can be installed in two possible locations:
PBXware - in case you are running standalone PBXware installation on dedicated hardware.
SERVERware host - If you are running PBXware as a VPS in a SERVERware virtual environment, sipPROT should be installed on all SERVERware hosts.
Brute-force break-in attempts are quite frequent, and VOIP PBX systems that are not protected are susceptible to this attack. The most common consequence of this kind of network attack can be:
This kind of attack on unprotected systems can lead straight to financial loss. To avoid this situation, we developed the sipPROT module for PBXware and SERVERware.
sipPROT is protection against brute-force SIP attacks coming from the network.
How does sipPROT work?
After an attack is detected, sipPROT updates firewall rules and blocks the IP addresses from which the attack is detected for a specific amount of time. Unlike other similar solutions, sipPROT works with live SIP traffic and blocks attacks more efficiently than others.
When sipPROT is running, please DO NOT delete any "extension" on PBXware before registered phone on extension is "RESET" to factory settings; otherwise, sipPROT will block IP addresses along with all the phones registering from that IP. Notification about blocked IPs will be sent to the e-mail, set under the Notification Recipients tab, assuming that SMTP settings are correct.
Widget | Description |
---|---|
Health: | This widget displays the health status of the sipPROT service. It indicates whether the service is running smoothly or if there are any issues. If there are problems detected, users are prompted to check the hosts page for more details. A direct link to the hosts page is also provided for quick access. |
System is protected System did not detect any health issues. | |
Issues detected: Please check the hosts page via direct link or from the menue to see details. | |
Attacks Per Endpoint | This widget shows a list of attacks for a specified time period, helping to identify which IP addresses or Virtual Private Servers (VPS) are most targeted on your server. For PBXware users, this will typically show attacks on a consistent IP address. |
Most Blocked Countries | This widget displays information about the origin countries of blocked IP addresses. It groups blocked IPs based on their country of origin, providing insights into geographic patterns in the attack data. |
Blocked Countries Heatmap | A geolocation heatmap that visually represents the density or intensity of attacks based on geographic location. It uses color coding to indicate areas with higher and lower concentrations of attacks. Warmer colors indicate higher concentrations of attacks, while cooler colors indicate lower concentrations. |
All these widgets are affected by the date picker filter and the refresh time selector on the dashboard. This means you can customize the displayed data based on specific time frames and set how frequently the information is updated. | |
Each widget provides valuable insights into different aspects of the security and health of the system managed by sipPROT, making it easier for users to monitor and respond to potential threats or issues. |
General sipPROT configuration can be found under menue Settings > Firewall.
Field | Description |
---|---|
SIP Ports: | Specify one or more ports or ranges to monitor, such as "5060" or "5060:5062". |
SIP Blocking Rule: | Set the maximum number of unauthorized registration attempts per minute before blocking an attacker's IP address for a specified amount of time. |
Dynamic Block Time: | Choose how long blocked IP addresses will remain blocked after preventing an attack. |
Block Threshold: | Define how many times an IP address will be dynamically blocked before it is permanently blocked by being added to the denylist. The acceptable range is (1-20). |
Blocked User Agents: | Specify the SIP user agents to block incoming traffic from. Keep the list as short as possible to avoid affecting system performance. |
Geo Protection: | Enable or disable GEO blocking, and select either the 'Allow' or 'Deny' option. |
Allow: If 'Allow' is selected, only traffic from selected countries will be permitted, and all other traffic will be denied. Ensure that resources the server needs to access outside the selected countries, such as email or external archiving servers, are explicitly allowed. | |
Deny: If 'Deny' is selected, all traffic from the blocked countries will be denied. | |
Blocked Countries: | Select the countries from which to block incoming traffic. sipPROT will block the entire range of IP addresses belonging to the selected countries, or allow them if a different method is selected above. |
Additional Protections: | |
TFTP: Protect your server against TFTP brute force attacks using a rate limit. The default rate limit is 10 requests per minute, with a maximum of 100 burst requests. | |
DNS: Protect older systems from the glibc stack-based buffer overflow in getaddrinfo() security flaw. If DNS zones are actively in use within SERVERware, it is essential to disable sipPROT DNS protection. Failure to do so may result in conflicts or operational issues. This feature is enabled by default and should not be modified unless you know what it is for. | |
If you are unsure what the feature is for, you should not modify this option under no circumstances. | |
Notifications: | |
Enable: Enable or disable notifications from sipPROT. | |
Send Daily Attack Summary: Receive an email with a daily report of attacks if this option is ticked. | |
Send Log For Every Attack Receive a notification for every attack. The default value is once per hour. | |
Mail recipients: | |
Enter the email addresses of all intended recipients for sipprot notifications. | |
The SMTP settings must be correctly configured for email notifications to be sent successfully. |
Regularly monitor the attack logs to stay informed about the types and frequencies of attacks your system is facing.
How to Use the sipPROT Attack Logs Page:
Understanding the Interface: | Attack logs page displays a table of SIP (Session Initiation Protocol) attacks detected by sipPROT. The columns include Attacker IP Address, Victim IP Address, Attack Type, User Agent, and Time of attack. |
Reviewing Attack Logs: | Scan through the list to review the recent attacks detected by sipPROT. Look at the 'Time' column to see when each attack occurred. The 'User Agent' column may give you insights into the type of tools used for the attack. If the user agent in the list is bold it will indicate that user agent is blocked explicitly in the sipPROT settings. |
Filtering Logs: | Use the 'Search' bar to filter logs by specific criteria, like IP address or attack type. You can select different types of attacks from the 'Attack Type' dropdown to narrow down the logs displayed.There are two type of attacks available to filter OPTIONS and REGISTER. |
Inspecting Specific Attacks: | Click on the IP address of either the attacker or victim to possibly see more details about that particular entity (this functionality depends on sipPROT’s features). |
Managing Logs: | Use the date filter at the top to adjust the range of logs you are viewing. You can reset any filters you have applied by clicking the 'Reset' button. |
Using Geo Protection: | If available, the 'Geo Protection' indicator can show if geo-blocking features are active or whether an attack was mitigated based on geographical rules. |
Navigating Pages: | Use the navigation arrows or page numbers at the bottom to scroll through multiple pages of logs. |
Adjusting View Settings: | You can change how many logs you see per page by adjusting the setting in the top right corner where it says '15 Per Page'. |
Taking Action: | Based on the information in the logs, you might decide to update your firewall rules, add certain IP addresses to a blocklist, or take other security measures. |
The Allow/Deny lists offer a variety of management options, such as searching, exporting, importing, and deleting entries. Additionally, users can easily access more detailed information for each entry with a single click, offering valuable insights for more effective list management.
Number of selected/total records.
Page numbers with selector.
Also for the convinience additional information regarding the specific IP can be found with a single click on the arrow on the beggining of the record to expand the additional information for the record, containing:
{
"ip": "217.146.168.190",
"note": "IP address has been added by Damir due to suspicious activity. The IP had made 15 unauthorized registration attempts within a minute, exceeding the blocking rule threshold of 10.",
"time": 1682329066,
"added_by": "Administrator (user@gmail.com)",
"geo_data": {
"country_code": "CH",
"country_name": "Switzerland"
}
}
The allowlist is a list of IP addresses that are allowed uninterrupted access to the system. This list can be manually populated via a form or uploaded using a CSV file. It is important to keep the allowlist up-to-date to ensure that legitimate users are not blocked from accessing the system.
The allowlist provides an additional layer of security to the system and helps prevent unauthorized access.
To add an IP address to the Allowlist, follow these steps:
It's important to ensure that the entered IP address is accurate and valid. Once an IP address is added to the Allowlist, it will be allowed uninterrupted access to the system.
To import multiple IP addresses into the Allowlist, you can use the Import CSV option located in the upper right corner of the Allowlist IP Addresses tab. To use this feature, you will need to have a CSV file that contains the list of IP addresses you wish to add to the Allowlist.
To create the CSV file, you can download the provided template file that contains headers and examples to help you get started. Once you have the file, open it in a spreadsheet program like Microsoft Excel or Google Sheets. Then, add the IP addresses you want to allow access to the system under the "IP_ADDRESS" column. You can also add an optional note for each IP address in the "NOTE" column.
Example CSV file :
IP_ADDRESS,NOTE
192.168.x.x,"example note1"
77.14.x.x,"example note2"
Save the file as a CSV and make sure it is in the correct format. Then, go back to the Allowlist sipPROT tab in the system and click on the "Upload" button. Select the CSV file you just created and click on "Upload" again. The system will import the IP addresses from the file and add them to the Allowlist.
If you need to export the list of IP addresses from the Allowlist, you can also use the "Export CSV" option to download a file that contains all of the IP addresses currently on the Allowlist.
There are two ways to remove a network or IP address from the list. First, you can select one or multiple IP addresses by checking the box next to each one, then clicking on the "Remove" button. A confirmation dialog will appear, and you can click "Yes" to remove the selected network or IP addresses.
Secondly, you can remove all IP addresses from the list by clicking the "Select all" checkbox, then clicking the "Remove" button. A confirmation dialog will appear, and you can click "Yes" to remove all network or IP addresses from the list.
Changes made to the list are applied automatically. If you need to remove a large number of IP addresses, you can also use a CSV file to make bulk changes. A link to a template file with headers and examples is provided to help you get started.
The Allowlist takes precedence over other lists. If an IP address is present in both the Allowlist and a different list (such as the Denylist), the IP address will still be granted access to the system, and the other list will be ignored.
This can be useful when blocking a network or range of IPs (such as "192.168.50.0/24") but needing to allow access for a specific IP address within that range (such as "192.168.50.15"). By adding the allowed IP address to the Allowlist, it will be granted access to the system despite the broader network block in the Denylist.
The Denylist is a collection of IP addresses that have restricted access to the system. This list can be populated manually by entering an IP address and an optional "note" through a GUI or by importing a list of IP addresses via a CSV file. Additionally, the Denylist can be dynamically populated with IP addresses from the Dynamic Denylist if they are identified as being associated with persistent attacks on the system.
IMPORTANT - The Allowlist has precedence over the Denylist. If an IP address is present in both the Allowlist and the Denylist, the IP address will be granted access to the system.
To add an IP address to the denylist, follow these steps:
To import multiple IP addresses into the Denylist, you can use the Import CSV option located in the upper right corner of the Denylist tab. To use this feature, you will need to have a CSV file that contains the list of IP addresses you wish to add to the Denylist.
To create the CSV file, you can download the provided template file that contains headers and examples to help you get started. Once you have the file, open it in a spreadsheet program like Microsoft Excel or Google Sheets. Then, add the IP addresses you want to allow access to the system under the "IP_ADDRESS" column. You can also add an optional note for each IP address in the "NOTE" column.
Example CSV file :
IP_ADDRESS,NOTE
192.168.x.x,"example note1"
77.14.x.x,"example note2"
Save the file as a CSV and make sure it is in the correct format. Then, go back to the Denylist sipPROT tab in the system and click on the "Upload" button. Select the CSV file you just created and click on "Upload" again. The system will import the IP addresses from the file and add them to the Denylist.
If you need to export the list of IP addresses from the Denylist, you can also use the "Export CSV" option to download a file that contains all of the IP addresses currently on the Denylist.
There are two ways to remove a network or IP address from the list. First, you can select one or multiple IP addresses by checking the box next to each one, then clicking on the "Remove" button. A confirmation dialog will appear, and you can click "Yes" to remove the selected network or IP addresses.
Secondly, you can remove all IP addresses from the list by clicking the "Select all" checkbox, then clicking the "Remove" button. A confirmation dialog will appear, and you can click "Yes" to remove all network or IP addresses from the list.
Changes made to the list are applied automatically. If you need to remove a large number of IP addresses, you can also use a CSV file to make bulk changes. A link to a template file with headers and examples is provided to help you get started.
The Dynamic Denylist display automatically blocked IP addresses that are identified as sources of malicious traffic or attacks. These IP addresses are added to the Denylist automatically without any manual intervention. The Dynamic Denylist is constantly updated with the latest information on malicious IP addresses, ensuring that the system remains protected against new threats.
Administrators have the option to manually unblock the IP address or wait for the timeout period to expire, at which point the block will be automatically removed.
One of the advantages of the Dynamic Denylist is that it provides detailed information on the user agent/scanner used in the attack, as well as the country of origin of the attack. This information can be used for inspection and debugging purposes, as well as to better understand the nature of the attack and take appropriate measures to prevent future attacks.
Dynamic deny is a security feature in sipPROT designed to automatically block IP addresses that exhibit malicious behavior against your system. This feature operates based on a set of predefined rules established by the administrator. Here's a more detailed explanation:
Field | Description |
---|---|
Dynamic Blocking: | When an IP address attempts an action that violates the rules set in sipPROT (like repeated failed login attempts, which could indicate a brute force attack), the dynamic deny feature is triggered. This results in the offending IP address being temporarily blocked. |
Dynamic Block Time: | This is a crucial setting within the dynamic deny feature. It specifies the duration for which an IP address will be blocked once it violates the rules. For example, if the Dynamic Block Time is set to one hour, any IP address that breaks the rules will be blocked for an hour. |
Behavior During the Block Period: | If the blocked IP address attempts another attack while it is still in the blocked state, the Dynamic Block Time is reset. This means the block duration starts over, and the IP remains blocked for another full hour from the time of the new attack. |
Unblocking: | If the blocked IP address does not attempt any new attacks during the block period, it will be automatically unblocked once the Dynamic Block Time elapses. |
Permanent blocking: | An IP address is added to the denylist if it persistently attacks and is repeatedly blocked by the dynamic deny feature. This is governed by the "Block Threshold" setting. For example, if an IP address commits more than 3 attacks within a specified time frame (as defined in your settings), it will be permanently blocked, meaning it is moved to the denylist. This ensures that consistently malicious sources are dealt with more stringently. |
In essence, the dynamic deny feature in sipPROT is a proactive security measure that automatically imposes temporary blocks on IP addresses that exhibit potentially harmful behavior, based on the rules configured by the system administrator. This helps in protecting your system from ongoing and repeated attacks while allowing for automatic unblocking in cases where the threat may no longer be present.
To access the hosts page use the top navigation menu Settings > Hosts, or click directly on the dasboard, Health widget.
This includes:
Service Status Per Host: | Displays the current operational status of the sipPROT service on individual hosts. Red shield icon is a sign that service on the host is not running and need to be inspected. |
License Information: | Shows details about the sipPROT license, such as its validity and the number of hosts it covers. |
GEO Protection Status: | Indicates whether geo-protection features are active and functioning correctly on each host. Red earth icon is a sign that GEO service on the host is not available and need to be inspected. |
sipPROT version: | Installed sipPROT version per host. |
Host kernel version: | Version of the kernel installed per host. |
Host IP: | Host IP address |
Additionally, this page provides the functionality to remove hosts. Removing a host from this page will temporarily disable the sipPROT service on that host until it is restarted. This feature is particularly useful in scenarios where there are more hosts than the license permits. For example, backup hosts, which typically do not run SIP services, can be selectively unprotected to stay within the license limits. |
To access the notifications page in sipPROT use the top navigation menu Settings > Notifications.
Configure SSL Encryption: | 'SSL Encryption' option. Select 'Enabled' to ensure that your notification emails are sent using a secure connection. |
Enter SMTP Details: | |
Host: | Enter the SMTP server address for your email provider. For example, smtp.example.com. |
Port: | Input the port number used by your SMTP server. Commonly, this is 465 for SSL or 587 for TLS. |
Enter User Credentials: | |
User: | Input the full email address that will be used to send notifications, such as user@example.com. |
Password: | Enter the password associated with the email account. Make sure to input this accurately. |
Save Your Settings: | After ensuring all the information is correct, click the 'Save Settings' button to apply the changes. |
The new updated version of sipPROT comes with updated CLI commands and outputs. CLI autocomplete is added for sipPROT commands.
# sipprot --help
NAME:
sipPROT - CLI
USAGE:
sipPROT [global options] command [command options] [arguments...]
VERSION:
5.1.0+build.1445.rev.2accad6
COMMANDS:
status, s Prints number of IPs per list
check-update, u Check for updates
version, Print only the version
list, l Manages IP lists
settings To inspect settings
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--config FILE load configuration from FILE (default: "/opt/sipprot/conf/sipprot.conf")
--log value log URI e.g. stdout://, syslog:// or file:///var/log/sipprotd.log (default: "stdout://")
--debug include debug logs (default: false)
--help, -h show help
--version, -v print the version
To get information about sipPROT status use the following command:
- sipprot status
This command will give the following information:
# sipprot status
+---------------------+------------+
| LIST | NUM OF IPS |
+---------------------+------------+
| Allow | 493 |
+---------------------+------------+
| Deny | 482 |
+---------------------+------------+
| Dynamic (temporary) | 100 |
+---------------------+------------+
To list detailed information use flags --all, --allow, --deny, --dynamic
Example:
# sipprot status -allow
Allowlist:
+-----------------+----------------+
| IP ADDRESS | COUNTRY |
+-----------------+----------------+
| 191.85.106.233 | Argentina |
+-----------------+----------------+
| 165.191.222.98 | Australia |
+-----------------+----------------+
| 175.35.61.159 | Australia |
+-----------------+----------------+
| 83.164.34.163 | Austria |
+-----------------+----------------+
| 178.127.91.72 | Belarus |
+-----------------+----------------+
| 178.116.223.166 | Belgium |
+-----------------+----------------+
| 109.140.180.239 | Belgium |
+-----------------+----------------+
Print sipPROT version information:
# sipprot version
sipPROT: 5.1.0+build.777.rev.5ad785a
Additional quick check, if the provided IP is in any of the following: allowlist, denylist, dynamic denylist.
Example:
# sipprot list check 83.221.171.193
IP address '83.221.171.193' found in Allowlist
IP address '83.221.171.193' found in Denylist
If an IP address is in the "List of IPs in the allow list," that IP will not be blocked by sipPROT.
If an IP address is in the "List of IPs blocked by the deny list," IP will be blocked regardless of whether an attack is coming from that IP.
"The information shown in the screenshots on this wiki such as IP addresses, hostnames, email addresses, and service versions are placeholders used for demonstration purposes within the sipPROT interface. They are not indicative of actual threats or real-world configuration and should not be treated as such."
Settings menu expands into Storage, Archive and Networking.
Storage view provides detailed information about storage hosts. Information provided is iSCSI IP Address and Storage Pools.
Advanced section allows you to enable/disable Failover to Storage, Processing on Storage options as well as set the Failover Timeout.
Failover To Storage allow the virtual servers to fall over to the storage in case that there are not enough processing hosts.
Processing on Storage enables VPS creation on storage hosts. Running VPSs on storage hosts is not recommended but if needed, this additional option is available on Cluster Edition.
Syslog on Storage Allow the storage server to run a centralized Syslog service and collect log messages from other hosts in the cluster.
Networking view allows you to add, configure and remove SERVERware network logical subnets.
To add a logical subnet, do the following:
In the Settings menu, select Networking view and click Add.
Add Subnet dialog appears. Select Type, enter Name and relevant network information. Check Use this subnet for VPS networking and provide bridge interface name if you need to use this subnet for VPS networking. Use netsetup to preconfigure bridge interface with the same name on all hosts in SERVERware cluster.
Click Add to add logical subnet.
Follow this procedure to remove a logical subnet:
To configure existing logical subnet, do the following:
In the Settings menu, select Networking view, logical subnet you need to configure and click Configure. Configure Subnet dialog appears.
To extend IP Pool, click on Extend button. Extend IP Address Pool dialog appears.
Enter the IP address range to extend the pool and click Save to extend IP address pool.
When done, click Close to exit Configure Subnet dialog.
In the Settings menu, select Networking view, logical subnet you need to configure and click Configure. Configure Subnet dialog appears.
To remove an IP address from the pool, click on Release button next to IP address in the list. Confirmation dialog appears.
Click Yes to release IP address.
When done, click Close to exit Configure Subnet dialog.
Virtual networking enables communication between multiple machines (VPS). While physical networking connects computers through cabling and other hardware, virtual networking extends these capabilities by using software management to connect computers and servers over the Internet. It uses virtualized versions of traditional network tools, like switches and network adapters, allowing for more efficient routing and easier network configuration changes.
Virtual networking enables devices across many locations to function with the same capabilities as a traditional physical network.
This allows network administrators new and more efficient options to easily create a network connection between VPSs and greater flexibility in provisioning the network to specific needs and applications.
Capacity to move workloads across the network infrastructure without compromising service, security, and availability.
To create a new virtual IPV4 interface we need to first add a new virtual network.
In the main menu go to the Settings > Networking
In the upper right corner select the "+" button, the popup will appear with the parameters for the network interfaces.
Enter the values required as follows:
NOTE: The Bridge option will be added automatically by the server and options in GUI will be grayed out.
When all fields are populated press the "Add" button to finish creating the new virtual network.
Now we need to add some IP addresses to the IP pool in the network we have just created, to do this press the little gear icon next to the network we have just created.
Then select press "initialize | Extend " and enter the range of addresses you want to add to the new virtual network
Optionally you can automatically allocate the range to the selected Partition.
Now we need to Edit/Create VPS and in the "network tab" for the selected VPS add the new virtual interface and select the address from the pool.
To create a new virtual IPV6 interface we need to first add a new virtual network.
In the main menu go to the Settings > Networking
In the upper right corner select the "+" button, the popup will appear with the parameters for the network interfaces.
Enter the values required as follows:
NOTE: The Bridge option will be added automatically by the server and options in GUI will be grayed out.
When all fields are populated press the "Add" button to finish creating the new virtual network.
IPv6 addresses will be generated automatically when adding the interface to the VPS so there is no option to add the IP pool in the IPV6 interface.
Now we need to Edit/Create VPS and in the "network tab" for the selected VPS add the new virtual interface and select the address from the pool.
DNS plugin will allow using SERVERware controller as authoritative partition name server and it will be able to resolve address of each VPS based on SERVERware database.
For example, SERVERware might be assigned with domain zone cluster1.mydomain.com, and it will be able to resolve IP addresses for each host and VPS it is responsible for, based on VPS name given e.g. pbx1.cluster1.mydomain.com.
Depending on the client source address this plugin will resolve IP addresses of the VPS from matching private or public networks.
Immediate benefits:
VPS can change IP or network and still remain accessible via domain name with no additional configuration changes on DNS since SERVERware is authoritative for a given zone.
This can be used as a service discovery mechanism (SRV record) It simplifies DNS management for providers with multiple services since all they need to do is to forward requests to SERVERware
This gives us the opportunity to deploy multiple public DNS instances via the device provisioning feature in PBXware, and connect them in real-time with SERVERware that will eliminate caching issues of third-party resolvers.
To configure the DNS zone go to the Networking > DNS tab
Default DNS on all VPSs will be always set to CONTROLLER IP
To test our newly added DNS zone we can use the dig command from the CLI to resolve the IP address from the VPS.
~$ dig @< IP of SERVERware CONTROLLER > < name of the VPS >.mydomain.xyz
Example:
~$ dig @10.1.35.63 PBXware60.mydomain.xyz
; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @10.1.35.63 PBXware60.mydomain.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16840
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8962e1899e70b4bb (echoed)
;; QUESTION SECTION:
;PBXware60.mydomain.xyz. IN A
;; ANSWER SECTION:
pbxware60.mydomain.xyz. 5 IN A 10.1.35.70
;; Query time: 36 msec
;; SERVER: 10.1.35.63#53(10.1.35.63)
;; WHEN: Mon Apr 19 10:16:42 CEST 2021
;; MSG SIZE rcvd: 101
Example with the host:
~$ dig @<IP of SERVERware CONTROLLER> <Name of the processing/storage Host>.mydomain.xyz
~$ dig @10.1.35.63 PROC1.mydomain.xyz
; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @10.1.35.63 PROC1.mydomain.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32100
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2a583c3da04e3299 (echoed)
;; QUESTION SECTION:
;PROC1.mydomain.xyz. IN A
;; ANSWER SECTION:
proc1.mydomain.xyz. 5 IN A 10.1.35.14 <--- The host LAN IP is resolved
proc1.mydomain.xyz. 5 IN A 192.168.4.14 <---- The host SAN IP is also resolved
;; Query time: 2 msec
;; SERVER: 10.1.35.63#53(10.1.35.63)
;; WHEN: Mon Apr 19 11:11:27 CEST 2021
;; MSG SIZE rcvd: 127
When Use Local DNS is activated (Yes), all VPSs from the host will use local DNS caching when querying DNS.
Go to the Host tab, select one host, and click edit to open the Edit menu. Click on the Advance tab:
The individual host provides the ability to activate/deactivate the use of the DNS cache and to inherit the config value provided at the system level in DNS settings.
Reports menu expands into System Logs, Alarm logs and User Sessions.
All events that occur in SERVERware are recorded in System Logs. Apart from general information and system management, System Logs can also be used for debugging and analysis, also there is available filter for the displaying logs.
All triggered alarms are recorded to alarm log, can also be used for debugging and analysis, also there is available filter for the displaying logs.
User Sessions view provides information on current connections to the SERVERware GUI as well as connection history and activity. The following information is provided: user, start/end time of connection, IP address and user agent.
Audit logs are a record of actions that have been performed within a SERVERware. These logs typically include information about who performed the action, when the action was performed, and what the action was. Audit logs can be used to track changes made to a SERVERware, as well as to detect and investigate potential security incidents. In many cases, audit logs are considered an important tool for maintaining the security and integrity of a system, as they can provide valuable information for auditors and SERVERware administrators.
The filter is implemented so it can help SERVERware administrators to easier search and analyse Audit logs. By clicking on Details popup will appear with additional details about the action.
All sub-actions are previewed on the Subaction tab.
System Settings mode allows you to manage various system settings in SERVERware.
To enter/exit System Settings mode, click on the button System Settings.
Administrators menu allows creation, editing and removal of SERVERware GUI Administrators.
Follow this procedure to add administrator account:
In the Administrators view, click Add.
Add User dialog appears. Select User Role, Status and enter personal user information.
Click Add to add administrator.
Follow this procedure to remove the administrator account:
Follow this procedure to demote an administrator account to a user account:
Partition Users menu allows creation, editing and removal of SERVERware GUI users as well as assignment of various roles and permissions.
Follow this procedure to add a user account:
In the Partition Users view, click Add User.
Add User dialog appears. Select User Role, Status, Partitions and enter personal user information.
Click Add to add user.
Follow this procedure to remove a user account:
Follow this procedure to promote a user account to an administrator account:
Access control is the access management feature for SERVERware Administration.
In this menu, we have options for managing Blocked IP, Allowed IP, and configuration of the automatic lockout after failed login attempts.
Login Lockout
Configure the limit for the allowed failed login attempts. User IP will be blocked after the specified number of failed attempts within the specified retry time period in minutes.
If all of the rules above are met the user account will be blocked after "n" failed attempts in "n" minutes, and will be added to the "Blocked IP Addresses" list.
Blocked IP Addresses
Use Role & Permissions view to add, edit or remove roles and permissions that can be assign to the SERVERware GUI users.
To add a role, do the following:
In the Role & Permissions view and click Add Role.
Add Role dialog appears. Enter name, description and set permissions.
Click Add to add role.
Follow this procedure to remove a role:
Service Pools tab allows you to add and remove service pools.
To add a new service pool, do the following:
In the Service Pools view and click Add Service Pool.
Enter Name, select Service Type and click Save.
Follow this procedure to remove a service pool:
Alarms view is used for setup and configuration of various SERVERware alarms. Alarms can be configured to send notifications when specific conditions are met.
To add an alarm, do the following:
In the Alarms view, click Add Alarm. Configure New Alarm dialog appears.
Select alarm state, monitoring target, enter name, description and click next.
In the Triggers tab, select trigger, operator, enter warning and critical conditions, click Save Trigger and then click next.
In the Notifications tab, configure notifications for individual alarm state changes by selecting Notify and by checking on delivery methods. When all notifications are configured, click next.
In the Recipients tab, select groups that will receive notifications and click Save to add new alarm.
Follow this procedure to remove an alarm:
Under the Flavors menu, it is possible to add, edit and remove Virtual Server Flavors. Flavors represent preconfigured set of hardware resources that can be assigned to a VPS upon creation.
To add a flavor, do the following:
Follow this procedure to remove a flavor:
To properly configure SMTP settings, enter all the relevant SMTP data, and then click Save. Configured settings can be tested by clicking the Send test e-mail button. If there is a need to configure SMTP notification delivery using an SMTP server that does not require user credentials for authentication, change the Authentication to "Open". If the SMTP server does not support SSL from the start, change the Encryption type to "None". When encryption is "None", SERVERware SMTP client will automatically switch to the encrypted mode if STARTTLS mode is supported by the SMTP server, otherwise, the connection will stay unencrypted. In case the sending of a test mail fails, the corresponding error message will be visible through the system logs view.
Templates are software packages used to initialize and deploy new VPSes from. For example, if you want to deploy a PBXware VPS on your SERVERware setup, you will use PBXware template to create a VPS from.
Installed Templates section in System Settings can be used to install and/or remove SERVERware VPS templates. There are 2 template types: Service Templates and System Templates.
Select Available Templates tab to view available templates, this is the list of available templates for installation (do not install templates that will not be used) .
To install a new template from the catalog, select the Available templates tab, click on Install. Template download starts right after the confirmation window.
When downloading templates, if multiple templates are selected for download, SERVERware will start downloading first one, and put others into a queue.
SERVERware allows users to use OCI (Open Container Initiative) images as templates within its infrastructure. This support broadens the range of applications and environments that can be deployed within SERVERware.
Source of OCI Images: Users can download these OCI images from Docker Hub or from local/private repositories. Docker Hub is a popular service for finding and sharing container images. The flexibility to use images from private repositories is crucial for organizations that use custom or proprietary software.
Compliance with Hub Public Rules: It's important that the OCI images conform to the rules set by the Hub Public. These rules likely pertain to how the images are created, structured, and stored, ensuring they are compatible with standard container runtime environments.
OCI Runtime Requirements: An OCI runtime in SERVERware must properly handle the OCI images, which includes creating, starting, terminating, and deleting them as per standard practices. This indicates that SERVERware is capable of managing the complete lifecycle of these containerized applications.
OCI images containing desktop operating systems are not supported. The SERVERware environment is optimized for server-oriented tasks and does not support the rendering or management of graphical interfaces typically found in desktop environments.
To download the OCI image in SERVERware go to the right main menu and select Templates / OCI Image.
In the newly open windows press the blue button in the upper right corner Install New template
In the popup window enter all required fields and press Install.
SERVERware will download the OCI image and install it on the system so it can be used to create VPS in the VPSs menu.
Updates section of System Settings is used to update the various SERVERware components. The list on the right side shows the Name, Current Version, and the Latest Version of the component that can be updated.
The SERVERware controller will check for available package updates on a daily basis. Once the update is available the notification pop-up message will appear on the top of the GUI screen every time the admin user logs in. The pop-up dialogue window disappears after 10 seconds and provides a link to open the package update view if the administrator wants to proceed with updates.
Email notifications for new available updates will be sent to the system administrators as well.
To update a SERVERware component, click the Update button for that component. The update process starts after the confirmation window.
If there is more than one component update, the SERVERware connector should be the first component to be updated.
Updating Host SW-Connector
The sw-connector service agent running on hosts is a crucial component for the proper functioning of the SERVERware environment, so it has to be updated if there are new features or bug fixes. A host should be moved to maintenance mode before updating the sw-connector.
Follow this procedure to update sw-connector:
SSL works by ensuring that any data transferred between users and websites, or between two systems, remains impossible to read. It uses encryption algorithms to scramble data in transit, which prevents hackers from reading it as it is sent over the connection. This data includes potentially sensitive information such as names, addresses, numbers, or other financial details.
The SSL Configuration page show details about the current SSL certificate and option to upload a certificate manually, generate CSR and automatic obtaining of free LE certificate. Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG).
SSL on SERVERware GUI can be installed in two different ways. One way is automatic SSL Let’s Encrypt certificate install, and another is manual install.
The prerequisite for successful SSL certificate installation on a SERVERware instance is a valid domain name which must point to the public IP address of the SERVERware instance (accessible from the internet and port 80 is open).
To automatically install a free Let’s Encrypt SSL certificate on the SERVERware instance, go to the SSL Configuration menu and click on I want a free certificate button. A popup window will appear:
Populate E-mail address and Domain filed and click on the Install button. Wait until the process of installation is complete and GUI will restart to apply changes.
There is also support for ACME servers that require External Account Binding.
We have extended our Automated SSL certificate installation, to support the CA which requires EAB for registering ACME accounts (ZeroSSL, Google Trust Services …)
It is possible to automatically install certificate using DNS challenge when SERVERware instance is not publicly available or to use wildcard domain (*.example.org).
This can be accomplished with manual DNS setup or using SERVERware CoreDNS functionality.
The CSR is a standardized way to send the issuing Certificate Authority (CA) your public key, which is paired with a secret private key on the server, and provides relevant information about the requester.
This can be done from SERVERware GUI, administrator can generate CSR and a private key for the selected domain and use for purchase of a SSL certificate.
There is an option to upload SSL certificate(and private key) to use instead of self-signed one which is the default.
Upload the .cert file you have obtained from the provider and optionally private key, if private key is not selected the existing key will be used and press Upload.
SERWERware will automatically switch to manually added certificate.
Certificate revocation is the act of invalidating a TLS/SSL before its scheduled expiration date. A certificate should be revoked immediately when its private key shows signs of being compromised. It should also be revoked when the domain for which it was issued is no longer operational.
This option is available only if a certificate is generated from Let’s Encrypt, ZeroSSL and similar free providers via automated activation method.
To revoke certificate go to SSL Configuration menu and click on Revoke button.
The popup window will appear, select the reason for revocation and click the Revoke button.
It is also possible to start the certificate renewal process manually.
This option is available only if a certificate is generated from Let’s Encrypt, ZeroSSL and similar free providers via automated activation method.
To renew manually certificate go to SSL Configuration menu and click on Renew button. The popup window will appear, click the Renew button.
Wait until the process of renewal is complete and GUI will restart to apply changes.
License menu shows details about installed SERVERware license and gives you the ability to update or change the license.
If your license has changed, to update the license, click Update License, enter a valid license number in the text box and click Apply. This will refresh the feature list supported on your instance of SERVERware.