-
The main problem in regards to the VPS storage until SERVERware 3 was the VPS duplication feature which would see data loss happening in between duplication cycles. Unlike SERVERware 1.x, version 3 does not rely on VPS duplication to provide VPS failover functionality. By using a shared storage, SERVERware 3 ensures that all VPS data is present in the event of a processing host failure. Another processing host will connect to the appropriate VPS volume exported by the storage server, after which the VPS will start running with the most recent data.
-
¶ Standalone Edition: Uses a single server for both processing and storage needs. Disks are paired to make redundant array(s) for data protection.
-
¶ Mirror Edition: Uses two real-time mirrored redundant servers in Active/Passive configuration, where disks are paired across RAN (Replication Area Network).
-
¶ Cluster Edition: Uses redundant shared storage built with two servers in real-time mirror, and processing hosts connected to shared 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
- Bandwidth
- Latency
-
RAN capacity
- Bandwidth
- Latency
- Importance of working RAID battery
- Importance of UPS and dual power
- Remote power management support (remote reset/power off/on)
- Remote access to BIOS
- Remote SSH console access
- A public IP assigned to KVMoIP
- If KVMoIP is behind firewall/NAT, the following ports must be opened: TCP (80, 443, 5100, 5900-5999)
- DVD image burned on to a DVD and inserted into DVD drive
- USB image burned onto 4GB USB drive and inserted into operational USB port
-
NETSTOR pool without HW RAID
-
NETSTOR pool with HW RAID
-
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.
- Exit - Choose this option to exit installation wizard. This option will open live system command line shell.
- Verify Media - This option will go trough the installation media files, match them against previous stored checksum and check for corruption.
- Next - Proceed to the next step.
- Network - Configure IP address for the remote access to the installation wizard.
-
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.
- A redundant storage server which holds virtual resources like virtual server volumes and templates.
- Virtual private server's hosts that use Linux Containers (LXC) is virtualization technology.
- Agents and tools running on hosts. These tools provide local management for virtual private servers.
- Controller, a centralized management platform for the SERVERware environment. It provides a graphical user interface which can be used to view, provision, and manage resources. It runs on the storage server within a dedicated Linux container.
- A database that tracks the states and changes of the environment.
- Networking links the environment together. This includes physical network links as well as logical subnets.
- Network - A SERVERware network is the highest level container for all physical and logical resources within a managed virtual environment. It is a collection of hosts, domains, virtual servers, storage, and networks.
- Storage - SERVERware uses a centralized shared storage system for virtual server volumes and templates. SERVERware storage is implemented using ZFS as a storage engine and Internet Small Computer System Interface (iSCSI) protocol for exporting VPS volumes to the processing hosts.
- Hosts - A SERVERware host is a physical server that hosts virtual servers.
- Logical Subnets - SERVERware defines a couple of logical subnets to the physical network interface cards. Logical subnets are used for traffic management, storage mirroring, and storage, traffic between storage and processing hosts.
- Domains - A SERVERware Domain is a logical group of physical, virtual resources and users.
- Virtual Private Servers - A VPS (Virtual Private Server) is equivalent to a dedicated physical server. Since it is software-defined, it is much more easily configured and managed.
- Virtual Networks - Create virtual networks inside the SERVERware using either IPV4 or IPV6 protocols.
- Templates - A Template is a pre-configured VPS that is loaded with all the necessary software for its specific role. A couple of Templates can be used together to form an even more specific VPS.
- Backups - Backup is a feature that is used for data protection and recovery.
- Archiveing - Archive PBX calls and CDRs in a safe place and free up space on the storage.
- GRS - Ability to replicate the VPS from SERVERware to another (geo remote location) SERVERware.
- Users - SERVERware allows a couple of different user accounts to be created. Accounts can have different roles and various permission levels.
- System Logs - A SERVERware System Log is a logging system that records events that occur in SERVERware. It can be used for system management, analysis, and debugging.
- Alarms - Alarm is an alert that can be triggered under certain abnormal operating conditions. Alarms can be received by a group of recipients via various notifications.
- Statistics - SERVERware statistics collects resource usage data. Data is stored and presented for Hosts and VPSs.
-
Navigate to the Account Settings section.
-
Open the API Tokens tab within the Account Settings interface.
-
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..
- Close Clicking this button saves the API token, associating it with the user's account for future reference and usage.
-
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.
- At the title bar of the Web Control Panel, click on the username (Administrator, YourName, etc..), then click on Account settings to enter the Account settings menu.
- Account settings page will open. On the "Two Factor Authentication" section of the page click on Enable Two Factor Authentication
- Follow the instructions from '''Set up Authenticator''' window and click '''Save'''
- On this step you can disable '''2FA''' or view '''Backup Codes''', this window is also a confirmation that '''2FA''' is enabled for specific user. It is possible to '''Change Password''' on this step for specific user. Click '''Close'''.
- 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.
- Running VPSs Indicator - Display the total number of VPSs as well as the number of running VPSs.
- Active Calls Indicator - Display a total number of concurrent calls on all running VPSs within the SERVERware network.
- CPU Usage Indicator - Display CPU usage on primary storage host.
- MEMORY usage indicator - Display memory usage on primary storage host.
- STORAGE Usage Indicator - Display storage usage of a NETSTOR pool.
- Resource Monitor - Display resources usage over time CPU/MEMORY/CALLS, the period of HOUR/DAY/WEEK can be selected.
- Recent Activity List - Display recent activity on SERVERware.
- Triggered Alarm List - Display the list of alarms being activated.
- Most Active VPS - Display the pie chart of resource usage per VPS.
- Local storage - Display status of local storage for all hosts in cluster.
- HOUR
- DAY
- WEEK
- CPU
- DISK I/O
- CALLS
- Current Hour
- Today
- Yesterday
- Current Week
- Current Month
- Active Meetings
- Active Participants
- Sent
- Received
- Active Producers
- Active Consumers
- Processing hosts with local storage are excluded from the calculation.
- MEMORY - Resources represent total available memory on all hosts. The memory allocated to all VPSs is shown under Committed, as a percentage of Resources.
- STORAGE - Resources represent total available storage on all hosts. The storage allocated to all VPSs is shown under Committed, as a percentage of Resources.
-
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."
-
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.
- In the column '''IP Address''' you should see all IP addresses of computers from which you made an SSH connection request
- The column '''Port''' shows all used ports of your connections
- The column '''Start Time''' indicates when each connection has started
- All sessions should terminate. Check-in your terminal if all connections are closed
- BSSUP panel button at the top should be gray
- Advanced options button should be enabled again
- Port and Timeout fields should be enabled again
- Message in the status bar should show that the SSH access is closed
- Date/Time column shows the exact date and time when something happened
- Severity column shows the status of the messages. Severity marked as “WARN” should have a yellow background
- Message column shows detailed explanation regarding each log
- Go to the 'Partition Members' tab.
- In the dropdown list, either select an existing user or search for one.
- Once you select a user, they will appear in the list of partition members with their pre-assigned role. The next time this user logs into the web interface, they will have access to the assigned partition and can manage the Virtual Private Servers (VPSs) within it.
- Find the user you want to remove in the list.
- Click the 'Remove Member' button next to their name.
- A confirmation dialog will pop up. Click 'Remove' to confirm.
The user will then be removed from the list of partition members. - Go to the 'Networking' tab.
- Choose the logical subnet you want to connect your partition VPSs to.
- Click on 'Reserve Address Icon'
to open the 'IP Address Reservation' dialog. - In the dialog, select or search for an IP address from the list.
- Click 'Reserve' to add it.
- The reserved IP address will now appear in your list.
- If there are no IP addresses available for reservation, go to the 'Settings/Networking' menu to increase the size of your IP address pool.
- To remove an IP address, click the 'Release Address' button next to the IP address you wish to remove.
- A confirmation dialog will pop up. Click 'Release icon'.
- The IP address will be removed from your partition's IP pool."
- Select the resource flavors that you want to be available for the partition. Resource flavors define the sizes and capacities of the virtual instances that will be used.
- Remember, these flavors must have been previously configured in the 'System Settings/Instance Flavors' section.
- Once you've chosen the desired resource flavors, click the 'Finish' button. This will start the process of creating your new partition.
- After clicking 'Finish', you will see a new entry in the list that represents the newly created partition."
- In the Partition view, select the partition that you want to edit.
- Click the Edit button. The Edit Partition dialog appears (see Create Partition dialog).
- Edit the details as required.
- Click Save to save the changes.
- In the Partition view, select the partition to be removed.
- Click the Remove button. A confirmation dialog appears.
- Click Yes. Partition disappears from the list.
- Storage host is a crucial component of SERVERware environment and is usually implemented as a mirrored pair of physical servers to provide a fault-tolerant and redundant storage infrastructure for virtual servers running on processing hosts.
- Processing hosts are the physical servers that run virtual private servers. The server virtualization technology used is LXC (Linux Containers). LXC runs stateless and without disk writes unless explicitly requested.
- Backup hosts have dedicated servers for storing backups of virtual server volumes.
- In the Hosts view, select the host to be enabled.
- Click the Enable button. A confirmation dialog appears.
- Click Yes.
- LAN - Local Area Network used for SERVERware management traffic as well as for VPSs services.
- RAN - Replication Area Network is used for the storage mirroring. It is implemented as a direct connection between two storage hosts that constitute a fault-tolerant storage solution.
- SAN - Storage Area Network is used for storing traffic between storage and processing hosts.
- In the Hosts view, select the host to be placed in maintenance.
- Click the Maintenance button. A confirmation dialog appears.
- Click Yes.
- The State field of the host changes to MAINT (maintenance). The icon changes to indicate that the host is in maintenance.
- Perform any required task. When the host is ready to be re-enabled, click the Enable button to enable the host. The State field of the host changes to UP.
- In the Hosts view, select the host that you want to edit.
- Click the Edit button. The Edit Host dialog appears (see Add Host dialog).
- Edit the details as required.
- Click Save to save the changes.
- In the Host view, select the host to be removed.
- Click the Remove button. A confirmation dialog appears.
- Click Yes. The host disappears from the list.
-
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
- If undo evacuate action is available for the selected host the popup will appear with the list of the available VPSs for the undo 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.
- Multiple evacuation actions can not start at the same time.
- A smal question mark near the host on the right side in a HOST wiev is an indication of new sw-conn update available.
- In the Host view, select the host which sw-connector has to be updated.
- Move the host into maintenance mode.
- Click the Update SW-Connector button.
- Open the System Logs view to track the progress of updating.
- When the update is complete, click the Enable button to enable the host.
- OFFICIAL
- COMMUNITY
- OCI
- LXC
- KVM (supported from SERVERware version 4.5.0 and above)
- • 1
- • 2
- • 4
- • 6
- • 8
- • 10
- • 12
- • 14
- • 16
- • 18
- • 20
- • 24
- • 28
- • 32
- • 64
- • Unlimited
- • 100
- • 200
- • 500
- • 1000
- • Unlimited
- Default value for all VPSs will be 256MB
- Minimum value is 64MB
- Default value for all VPSs will be 128MB
- Minimum value is 64MB
- Address: Enter an IP Address belonging to the selected logical subnet.
- External Address: Enter public IP address (optional)
- MAC: Enter MAC address manually or leave blank (will be auto generated)
- Go to the VPS menu and select create new VPS from the top menu
- Create a new VPS, a popup will appear, in the general tab select the OCI radio button to use OCi templates for VPS
- Select the "oci-runner template" from the dropdown
- Select Partition
- Select the Host
- Select the Registry
- Enter image name for example "library/mysql" and tag: "latest"
- Starting, Stopping and Restarting virtual servers,
- Changing virtual server ownership,
- Increasing virtual server storage, changing VPS engine (LXC or KVM)
- Cloning and migrating virtual servers,
- Restoring virtual servers.
- Reclaim free space - TRIM
- Shrink VPS
- VPS snapshots
- In the Virtual Private Servers view, select the VPS that you want to edit.
- If the VPS that you want to edit is not visible in the list, perform a search.
- Click the Edit button. The Edit VPS dialog appears with the disabled fields that cannot be changed.
- Edit the required details of enabled fields under the desired tab.
- Click the Save button. The details of the VPS are updated in the view.
- In the Virtual Private Servers view, select the VPS that you want to edit.
- If the VPS that you want to manage is not visible in the list, perform a search.
- Depending on action that you want to perform click either Start, Stop or Restart button.
- Monitor VPS state change in the VPS view.
- In the Virtual Private Servers view, select the VPS for which you need to change owner.
- If the VPS that you want to change is not visible in the list, perform a search.
- Click the Change Owner button.
- Change Owner dialog appears.
- Select a new owner from the list and click the Change button to change ownership of the VPS.
- Closing the browser tab will not terminate a session.
- This feature is enabled only for SERVERware administrators, not for Partition admins or VPS owners.
- Links (URLs) for the sessions are not sharable.
- TTY session will work even if the VPS doesn’t have the network interface defined.
- Stopping the VPS will close all the TTY sessions for the VPS.
- The TTY session timeout is 30 minutes of inactivity.
- Create the new VPS from the template ( SERVERware or OCi)
- Start the VPS
- On the bottom info panel select terminal TAB
- Press the “Open TTY” button to open the Console access to the VPS
- Perform various actions in the VPS over the TTY - Console
- In the Virtual Private Servers view, select the VPS that you want to move.
- If the VPS that you want to move is not visible in the list, perform a search.
- Click the Move VPS button.
- The Move VPS dialog appears.
- Select Host Change as Move Type.
- Select a destination host from the list and click the Move button to initiate move operation.
- Monitor task progress in the VPS view. The host column should show a new hostname for the moved VPS.
- In the Virtual Private Servers view, select the VPS that you want to move.
- If the VPS that you want to move is not visible in the list, perform a search.
- Click the Move VPS button.
- The Move VPS dialog appears.
- Select Partition Change as Move Type.
- Select a new Partition from the list and click the Move button to initiate move operation.
- Monitor task progress in the VPS view. The partition should show a new name for the moved VPS.
- In the Virtual Private Servers view, select the VPS that you want to clone.
- If the VPS that you want to clone is not visible in the list, perform a search.
- Click the Clone VPS button.
- The Clone VPS dialog appears.
- Enter a description and a new name for a VPS and click the Clone button.
- Monitor task progress in the VPS view. The name column should show a new name for the cloned VPS.
- To finish configuration of VPS click Edit and then select Networking tab.
- On the Networking tab select the logical subnet to which you want to connect the VPS.
- Enter an IP Address belonging to the selected logical subnet.
- Click the check box “Include in Geo-Redundancy” and select the site if needed.
- Then click the Clone button to start the clone VPS process.
- In the VPSs view, select VPS that needs to be removed.
- Click the Remove button. A confirmation dialog appears.
- Click Yes. VPS disappears from the list.
-
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.
- CPU Usage (Utilization/IO Wait)
- CPU Load
- Memory Usage
- Concurrent Calls
- Pool Usage
- Network Bandwidth Utilization
- In the Statistics view select a view category. Select either Host Charts or VPS Charts depending on which statistics charts you want to show.
- Select which data series you want to show Average or Maximum.
- Select metrics that you want to show on the chart view pane.
- Select a period for which you want to show the performance charts.
- In the Schedule view, select the backup job to be removed.
- Click the Remove button. A confirmation dialog appears.
- Click Yes. The backup job disappears from the list.
- Incremental replications
- Keep multiple replication cycles in time at GRS
- Takeover from multiple points in time
- Data synchronization separated from active services on takeover site and not affecting active services
- Add one or multiple GRS
- Monitor each GRS status
- Monitor recent replications
- Flexibility in combinations for replicating between sites
- The site can replicate to one or more destination sites
- One or more sites can replicate to one destination
- Different VPSs can be replicated to different remote sites
- Connect to remote GRS specifying its IP address and secret API key
- Control bandwidth and storage IO utilized by GRS
- Select SERVERware partitions and VPSs to be replicated
- Select the replication cycle, the minimum is one minute
- Specify how many recovery points to keep
- Control bandwidth and storage IO utilized by GRS
- Specify Alternate IP of VPS, (IP to be used after takeover on remote site if different)
- Monitor progress and completion status of each cycle and VPS replicated in that cycle
- Multiple sites can be replicated
- Select origin site and VPS to takeover
- Choose latest or older recovery point, in case most recent, contains unwanted data
- Choose destination partition
- Choose destination host
- Save Template for fast takeover in case of disaster
- Using the CLI administration interface, the administrator can allocate and control multiple sites on single GRS
- Limit storage
- Limit bandwidth
- Manage access control list
- Name The name of the Geo-Redundancy Server.
- IP Address Enter the IP Address of the Geo-Redundancy Server (If the Geo-Redundancy Server data-set is created on NETSTOR in mirror or cluster edition of SERVERware, floating IP should be used).
- API key Enter the API key for the Geo-Redundancy Server site.
- Send an email notification Select which notifications you want to be sent on administrator email.
- When Geo-Redundancy Server goes offline - This notification will be triggered when Geo-Redundancy Server is offline (network issue, hardware issue, etc..).
- If Replication fails - This notification will be triggered if the replication process is interrupted.
- If Replication completes with errors - Replication process is completed with errors for example when Geo-Redundancy Server site quota is reached or missing IP address.
- API Port Enter the API port for the remote site if needed (8282 default).
- Data Port Enter the port for data transfer if needed (7788 default).
- Max Bandwith Limit the Geo-Redundancy transfer rate to suit your network preferences and infrastructure.
- 1MB/s
- 5MB/s
- 10MB/s
- 20MB/s
- 30MB/s
- 40MB/s
- 50MB/s
- 75MB/s
- Unlimited
- Name Name of Replication site
- Replication Details
- Status Enabled or disabled replication
- Frequency How often Replication Cycle occurs (this is defined in Replication Config)
- Next run Time when next run of replication cycle is scheduled
- Server Details
- Status Status of Repication server can be Online or Offline
- IP address Ip addres of Geo-Redundancy Server
- API port API port used to connect on Geo-Redundancy Server
- Bandwidth Bandwidth usage by Geo-Redundancy Server
- Storage usage Storage usage and quota of Geo-Redundancy Server
-
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)
- fill out the timepicker values with start time of your will (the time specified is used only for initial start of replication)
- Depending on the Replication Cycle, SERVERware will calculate and display the time and date of the next replication
-
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)
-
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.
- Start Time Time when the replication cycle is started.
- Duration Duration of the replication cycle.
- Data Transferred Amount of the data transferred in the cycle.
- Transfer rate Max transfer rate in cycle.
- Cycle ID Unique ID for the cycle.
- Details per VPS transferred in the selected cycle.
- Name The name of the Geo-Redundancy Server
- IP Address Enter the IP Address of the Geo-Redundancy Server (If Geo-Redundancy storage is located on NETSTOR in mirror or cluster edition of SERVERware, floating IP should be used)
- API key Enter the API key for the Geo-Redundancy Server site
- API Port Enter the API port for the remote site if needed (8282 default).
- Data Port Enter the port for data transfer if needed (7788 default).
- Max Bandwith Limit the Replication transfer rate to suit your network preferences and infrastructure (Other server-side limits may apply).
- 1MB/s
- 5MB/s
- 10MB/s
- 20MB/s
- 30MB/s
- 40MB/s
- 50MB/s
- 75MB/s
- Unlimited
- Recovery Point From the dropdown list select the desired recovery point
- Partition Select the partition for the restored VPS
- Host Select the processing host where the restored VPS will be placed
- Name Enter the name for the restored VPS
- To start a Bulk takeover action we need to make the list of VPSs for takeover first.
- First select Geo-Redundancy Server and replication site upper left corner, afterward select the upper-right drop-down menu and select Bulk takeover.
- New window will open with the possibility to create a bulk action list, start bulk operations, and save an operation as a template.
- Template Name: The name for the takeover template.
- Source Partition(s): Select the source partition of the VPS to recover.
- VPS: Select the VPS from the drop-down list.
- Recovery Point: select the recovery point for the VPS (NOTE: If the operation is saved as a template this will be automatically populated with the latest available point).
- Partition: select the destination partition for the VPS
- Host: Select the destination host for the VPS
- Name: select name for the VPS (This is automatically populated from metadata, and can be changed, duplicated names will not be allowed).
- Save this list as a template and run later Save Template (Templates can be modified later if needed in the saved templates window).
- Start bulk takeover action instantly Start.
- Create site monitor - This will open a new frame for creating a new site monitor (create an empty set of test to be executed and actions to trigger)
- Edit - Edit existing site monitor (site monitor has to be stopped prior to editing)
- Remove - Remove existing site monitor (site monitor has to be stopped prior to removing)
- Start - Start site monitor actions
- Stop - Stop the site monitor actions
-
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.
- Site Monitoring Name: enter the name for the new site monitor, make sure to set the name in a few words explaining what site you are monitoring or similar for a better overview.
-
Then we will set the interval of our tests(all tests will execute in a set period for the selected site).
- Schedule every: Select the period from the predefined dropdown. this is the period in which all tests in this monitor will be repeated.
- Example: if the Schedule timer is set to 1 minute all tests added to this site monitor will be executed every minute(if the test can't finish in the selected period this period will be delayed until all tests are finished).
-
And we will save our monitor, so we can continue adding test cases.
- Save & apply: When we enter the site name and select schedule time we have to save this monitor to be able to add test and triggers.
-
Now we add our new test to the selected site monitor.
- Add Site Test: This will open a popup with the test design parameters.
- Add Site Test: This will open a popup with the test design parameters.
- ICMP test parameters
The ICMP test is the standard ICMP command set and additional success conditions. - Test successful example:
- Test failed example:
- HTTP test parameters
- TCP test parameters
- TCP Test example:
- UDP test parameters
- UDP Test example:
- MMonit integration
- Create actions to be triggered if conditions are met
- Add Action button : This will add action to the action list with a preselected option
- Trigers if: Two conditions available ALL and ANY and one action ALARM.
- ALL: Trigger alarm only when all tests fail for this site.
- ANY: Trigger alarm when any of the tests fail for this site.
- Alarm: Select action to trigger when conditions are met.''The Alarm will be displayed on the dashboard, an email notification will be sent to the administrator''
-
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)
- - add -storage -quota [KMGT] -throttle [KMGT] -admin=true/false -allowedips ... "quoted description text"
- -allowed IPs specify quoted the comma ',' separated list of IPs or subnets in CIDR format
- - update -storage -quota [KMGT] -throttle [KMGT] -admin=true/false -allowedips ... "quoted description text"
- - list [id] List sites, showing unique id and other settings.
- - remove [-force] id Remove site by its unique id
-
- 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}
-
- 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
- Find out the name of the pool by typing:
- When we know the name of the zfs pool we can create a dataset for Replication storage we will use the name of the pool from the previous command "SYSTEM-e694" add trailing slash / and dataset name, in our case "GRS" so the command will look like this:
- Next, we need to create the mount point and boot parameters for the new dataset
- Create a directory and mount our newly created ZFS dataset.
- We should add this mount point to the "/etc/fstab" so the SERVERware mounts this dataset after reboot.
-
Reboot the processing host.
-
After the host, reboot log on and inspect dataset and mount point we have just created in ZFS
-
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.
- VOIP service downtime and unreachability
- The possibility of password stealing (SIP registration)
- Add (Mannualy add single IP record to the list)
- Export (export the whole list to a CSV file)
- Import (import the list from a CSV file)
- Delete (delete selected IP record)
- Search (Search the list by IP record or note)
- Country (Search IP records by country)
- Reset (Clear the country and reset the search)
- Show per page (dropdown to select number of records displayed per parge)
- Refresh (The "Refresh" option in the allow list is a dropdown that allows users to set the refresh interval for the list. When a refresh interval is set, the list will automatically refresh at the specified interval. However, it's important to keep in mind that this action may clear any current selections in the list. )
-
Number of selected/total records.
-
Page numbers with selector.
- Note: the note for the record if available.
- Added By: the user who added the record.
- Copy button: copy the record data in the clipboard in json format.
- Edi: edit the record button.
- Delete: delete the record button.
- Open the Allowlist sipPROT tab in your system.
- Click on the "ADD" button.
- Enter the Network or IP address in the designated field.
- Enter any optional notes to help you remember why this address was added.
- Click the "Add" button to add the IP address to the Allowlist.
- Open the Denylist sipPROT tab in your system.
- Click on the "ADD" button.
- Enter the Network or IP address in the designated field.
- Enter any optional notes to help you remember why this address was added.
- Click the "Add" button to add the IP address to the Denylist.
-
Locate the Configuration File:
A new file,/opt/sipprot/conf/sipprot_custom.conf, is provided with the sipPROT package. This file allows you to customize the sipPROT configuration, ensuring that your settings are preserved between updates. -
Modify the Configuration File:
Open/opt/sipprot/conf/sipprot_custom.confand update the settings as follows:[GENERAL] # Set controller service discovery mode to manual ctrl_sd_mode = manual [CTRL_SERVICE] # Provide the controller's IP address and port ip = <MAN_IP> port = 8183 - Set ctrl_sd_mode to manual.
- Replace <MAN_IP> with the MAN IP address of the controller.
- The default port for the controller service is 8183. Leave it unchanged unless specified otherwise.
- Obtain the MAN IP Address: To find the MAN IP address of the controller, run the following command on the controller:
- Restart sipPROT: After updating the configuration, restart the sipPROT service on the remote host:
-
Check sipPROT Logs:
Ensure that the remote host successfully connects to the controller by checking the sipPROT logs. Look for log entries confirming that the host has registered and joined the cluster.
- In the Settings menu, select Networking view.
- Click Remove next to the logical subnet you want to remove. A confirmation dialog appears.
- Click Yes. Logical subnet disappears from the list.
- Name: Enter the new network name (limited to 15 characters).
- Type: From the dropdown select the type VIRTNETIPv4 for the network (there are two options for virtual networks "VIRTNETIPv4" for IPV4 and "VIRTNETIPV6" for IPV6)
- IP address: Enter the network address range
** Example for IPv4: 192.155.0.0 - Subnet Mask: Enter the subnet range for the selected network
** Example for IPv4: 255.255.0.0 - Gateway: 192.155.0.1 (The gateway address will be added to the CONTROLLER of the SERVERware and the CONTROLLER behave as a Gateway/router for the virtual networks)
- Name: Enter the new network name (limited to 15 characters).
- Type: From the dropdown select the VIRTNETIPv6 for the network (there are two options for virtual networks "VIRTNETIPv4" for IPV4 and "VIRTNETIPV6" for IPV6)
- Routing prefix: Enter the network routing prefix for your IPv6 network (SERVERware will auto-populate this field)
- Example for IPv6: fd:ce8c:54b5
- Subnet ID: Enter the subnet ID for the selected network
- Example for IPv6: 1
- Gateway: Enter default gateway (The gateway address will be added to the CONTROLLER of the SERVERware and the CONTROLLER behave as a Gateway/router for the virtual networks)
- Example for IPv6: fd:ce8c:54b5:1::1
-
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.
- Press the add new zone button
-
Type: From the dropdown select the role of server primary or secondary
-
Add the name of your domain server1.mydomain.xzy in the field Name (this will be the resolve name for your DNS zone)
-
In the Domain field from the dropdown select the Domain to limit the DNS record to the selected SERVERware domain (default selection will use all domains available on the SERVERware).
-
The default port is 53 this is the default port for DNS (domain name server) lookup and should not be changed if otherwise not required from your network administrator.
-
TTL (time to live) is a setting that tells the DNS resolver how long to cache a query before requesting a new one. The information gathered is then stored in the cache of the local resolver for the TTL before it reaches back out to collect new, updated details.
-
Transfer From: This field should be populated with the IP address of the primary server in the DNS zone and will be enabled only if the type is set to secondary.
-
Transfer to (ACL): Enter the IP addresses of the servers you wish to specify, the application allows servers to send DNS zone data to the secondary server specified.
-
Press SAVE button, we have added our DNS zone successfully
- Open the terminal and issue the next command:
- Select Administrators menu.
- Select Remove from the dropdown menu next to the administrator account you want to remove. A confirmation dialog appears.
- Click Yes. Administrator account disappears from the list.
- In the Administrators view, select Downgrade from the dropdown menu next to the administrator you want to demote. A confirmation dialog appears.
- Click Yes. Administrator disappears from the list and appears in the list of Partition Users.
- In the Partition Users view, select Remove User from the dropdown menu next to the user you want to remove. A confirmation dialog appears.
- Click Yes. The user disappears from the list.
- In the Partition Users view, select Upgrade from the dropdown menu next to the user you want to promote. A confirmation dialog appears.
- Click Yes. User disappears from the list and appears in the list of Administrators.
- Login Lockout enable/disable the feature
- Max. Failed Attempt maximum number of fail attempts in a given period before the SERVERware will block user account.
- Retry Time Period period in which the fail attempt happened before is blocked. The available selection is 1min, 5min, 10min, 30 min, and 60min.
- Block Time Period period in which the restriced user will have denied access
- IP Address or Subnet To block access for the specific IP address, in the input field type the address you need to block and press the + Add button.
- To remove the specific address from the blocked list of addresses press the X mark button next to the blocked IP address in the list.
- IP Address or Subnet To grant access for the specific IP address, in the input field type the address you need to grant access for and press the + Add button.
- To remove the specific address from the granted list of addresses press the X mark button next to the granted IP address in the list.
- Configure the number of maximum concurrent sessions. When enabled, attempts to connect beyond the maximum will be rejected. For example, if the session limit is 3, only 3 users can be connected simultaneously. Every next user login attempt will be rejected.
- Select Role & Permissions view.
- Select Remove Role from the dropdown menu next to the role you want to remove. A confirmation dialog appears.
- Click Yes. Role disappears from the list.
- Select Service Pools view.
- Click Remove Service Pool next to the service pool you want to remove. A confirmation dialog appears.
- Click Yes. Service pool disappears from the list.
- In the Alarms view, select Remove Alarm from the dropdown menu next to the alarm configuration you want to remove. A confirmation dialog appears.
- Click Yes. Alarm disappears from the list.
- In the Flavors view, click Add Flavor. Add Flavor dialog appears.
- Enter Name, select CPU Priority, CPU limit, amount of Memory, Storage, Bandwith, and IOPS limit than click Create to create a new flavor.
- In the Flavors view, select Remove Flavor from the dropdown menu next to the flavor you want to remove. A confirmation dialog appears.
- Click Yes. Flavor disappears from the list.
- In the Host view, select the host which sw-connector has to be updated.
- Move the host into maintenance mode.
- Click the Update SW-Connector button.
- Open the System Logs view to track the progress of updating.
- When the update is complete, click the Enable button to enable the host.
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 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 largest disks available on the market (in terms of capacity), and number of disks that can be connected to servers, RAM memory, etc…
SERVERware storage employs the end-to-end checksum to detect and correct silent data corruption which means that storage will use this checksum to determine which copy is correct in this redundant disk array. This provides correct data to the VPSes, and repairs the damaged copy if it becomes damaged.
Press to expand (It is important to discern different editions of the SERVERware)
¶ Structure and requirements
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.
¶ VPSes
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 and Repair/Maintenance
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:
¶ TO LINK MANUALS FOR EXPANDING POOLS
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 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.
¶ Deployment Guide for Mirror Edition
The following guide describes minimal and recommended hardware requirements as well as procedures for a successful deployment of SERVERware 4.2 - Mirror Edition.
¶ Hardware Requirements
¶ Server requirements for Storage/Controller
Press to expand (2 x server with 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 | 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) |
¶ Server requirements for Backup Hosts
Press to expand (If added, Backup 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 | 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) |
To add Processing Hosts, SERVERware 4.2 license must be upgraded to Cluster Edition and at least 2 Processing Hosts added to effectively relieve Storage/Controller.
Upgrade to Cluster Edition increases the number of required network interfaces to 3 on every server in the cluster.
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.
¶ KVMoIP (Keyboard, Video, Mouse over IP) remote access to each server
¶ SERVERware installation media is required in one of the following forms
¶ Deployment Guide
SERVERware 4.2 Mirror Edition topology is shown on the following image:
¶ Network setup
How-to instructions regarding network setup are available on the following page:
¶ Disk setup
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:
¶ Creating USB installation media
USB images and instructions are available on the following how-to page:
¶ System Installation Wizard: Enhanced ZFS Pool Creation
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.
¶ ZFS Pool Configuration Options
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:
¶ User Interaction
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.
¶ ZFS Pool Creation
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.
¶ Installation wizard steps
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:
¶ Step 1: Select the type of installation you want to install, Storage/Controller or Host (Backup).
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).
¶ Step 2: Installation wizard will proceed to check for available disks, 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:
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.
¶ Step 3: Select physical disk for "SYSTEM" installation. Volume for storage "NETSTOR" will be automatically created from disk's that are not selected in this step
¶ Step 4: Confirmation dialog appears
¶ Step 5: Configure network dialog appears
Click Next to continue and then chose one of the options to configure network interface.
After finishing network configuration, click Next to start installation.
¶ Step 6: Installation wizard will now proceed with installation of SERVERware operating system.
After finishing finishing installation. Wizard will initiate reboot.
¶ Step 7:
Redo installation steps for the second (mirrored) machine.
¶ VLAN Tagging on host and VPS interfaces
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.
¶ Step 1: Run "netsetup" command and select ''Create virtual local area network (VLAN)'' and press ''Next''
¶ Step 2: Select network interface and click ''Next''
¶ Step 3: Follow three next steps to configure IP address of new VLAN interface. One of last steps will be to enter VLAN interface name. For name to be valid you should use min 3 and up to 20 alphanumeric characters without spaces. Also it is not possible to create VLANs with same ID.
¶ Step 4: Enter VLAN ID. For VLAN ID use numbers in range between 2 and 4096. Numbers 0, 1, 1002-1005 and 4096 are reserved and therefore also can't be used
¶ Step 5: Complete NIC Wizard and run ''ifconfig'' to confirm VLAN interface is present with assigned IP address. If necessary you can use virtual interface to create bridge interface or another virtual interface. Al this can be done using ''netsetup'' NIC Wizard
¶ Setup wizard steps
Open your browser and enter LAN IP you configured upon installation. After confirming self signed certificate, SERVERware setup wizard login screen appears. Enter administration password which is by default serverware.
¶ Step 1: After successful login, SERVERware EULA appears.
Acceptance of the EULA leads to the next step.
¶ Step 2: Enter your license number, administrator's email, set new administrator's SERVERware GUI password. This password will also apply to shell root account. Select your time zone and click ''next'' to continue
¶ Step 3: This step will offer you to configure LAN and mirror RAN network. LAN is a local network for SERVERware management and service provision. RAN is a network dedicated to real-time mirroring of two servers.
The setup wizard will suggest default configuration for the network interfaces. The machines must be on the same LAN network and the same RAN network. Modify network configuration if needed and click Next to proceed to the next step.
¶ Step 4: Choose the name for the server 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. Purpose of 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. 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 managing web console as well as to control and monitor SERVERware hosts and VPSs.
Once you click Finish button, the wizard will initialize and setup the network storage. When complete, 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.
¶ SERVERware Architecture
A SERVERware environment consists of:
SERVERware network topology is shown on the following image:
¶ SERVERware resources
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.
¶ Accessing the Web Control Panel
¶ Logging in to the Web Control Panel (Administration UI)
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.
¶ Logging out of the Web Control Panel
At the title bar of the Web Control Panel, click Logout.
You will be logged out and the Web Control Panel login screen displays.
¶ API Tokens
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.
¶ Accessing API Tokens
To access the API Tokens feature, users should follow these steps:
¶ Creating a New API Token
To create a new API token, users can follow these steps:
¶ Managing API Tokens
Users can manage their API tokens by:
¶ API Token Best Practices
¶ Enable 2FA for SERVERware
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.
¶ Network
¶ Dashboard
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:
¶ BSSUP
¶ BSSUP panel
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:
The status bar is at the bottom of the panel, which is showing whether SSH access is open or closed.
¶ SSH access
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.
¶ 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.
¶ SSH access list
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:
¶ Logs
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.
¶ Partitions
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.
¶ Managing Partitions
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.
¶ Creating Partition
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:
¶ Editing Partition
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:
¶ Removing Partition
A SERVERware partition can be removed only if there are no VPSs that belong to it.
Follow this procedure to remove a partition:
¶ Hosts
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:
¶ Managing Host
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.
¶ Adding 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.
¶ Adding Remote Host
A remote processing host in SERVERware refers to a server added to an existing cluster but located outside the local network subnet of the primary servers. This host uses its own local storage for virtual private server (VPS) volumes. The feature is particularly useful when scaling horizontally becomes necessary due to system load, but physical limitations like insufficient rack space or supply chain issues prevent adding a server in the same data center. SERVERware’s ability to integrate remote processing hosts offers a flexible solution for expanding clusters under such constraints.
In order to be able to add a remote processing host to an existing SERVERware cluster one should register an additional subnet to which the new processing host belongs. The newly registered subnet should be of MIXED type and should provide a pool of IP addresses to be used by VPSs that will be running on this new host. Once it is ensured, one could add the remote processing host by following the standard procedure for the host adding.
A remote processing host uses its local storage so SERVERware cannot ensure high availability of VPSs running on it.
In the picture above one can see that the remote processing host has an IP address that belongs to a completely different subnet than the IP addresses of the remaining hosts in the cluster. Moreover, the remote processing host does not have access to the SAN network and shared storage (NETSTOR) so it relies on its own storage only.
Once the new host is added, depending on the needs one can simply start adding new VPSs on the new processing host and assign them IP addresses from the new subnet.
VPSs on a remote processing host can communicate with each other and public endpoints, but not with other VPSs in the cluster unless connected to a public subnet. SERVERware's virtual networks feature enables private communication between VPSs within the same cluster, even without subnet attachment. The CONTROLLER, functioning as a virtual router, must be accessible from all hosts to allow VPSs to join a virtual network.
VPSs running on a remote processing host cannot join a virtual network if the CONTROLLER IP address is behind NAT.
To enable sipPROT on the remote Host and join to the sipPROT cluster, plese reffer to the sipPROT section.
¶ Enabling Host
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.
¶ Managing Host Network Interfaces
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.
¶ Maintaining Hosts
¶ Moving host into Maintenance Mode
Hosts must occasionally be brought down for maintenance. You have to manually migrate or stop all virtual servers, before shutting them down. Placing a Host into maintenance mode is a way to notify SERVERware Controller that the host is no longer a stable resource for VPS hosting and cannot be used as a target host for new VPSs as well as a target for VPSs migration or failover.
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.
¶ Editing Host Details
You can edit the details of a host, such as its name or network configuration.
Follow this procedure to edit host details:
¶ Removing Host
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:
¶ Evacuate VPSs
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.
¶ Undo Evacuate VPSs
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.
¶ 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 steps to update sw-connector:
¶ Virtual Private Servers (VPSs)
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.
¶ Creating New Virtual Private Server
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:
Besides that, VPSs created from OFFICIAL templates are supported by two engines:
While VPSs created from COMMUNITY and OCI templates are created as KVM for security reasons.
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 you wish to create.
Template: The base virtual server version for the selected VPS type. Choose a template from the provided list.
Partition: The partition to which the VPS belongs.
Host: The host on which the VPS will be created.
Engine: The type of engine on which the VPS will run.
Name: A descriptive name for the VPS.
Highly Available: Enables failover of the VPS to a storage host for high availability.
Exclude From Backup: If selected, the VPS will be excluded from backup processes.
Enable Protected Mode: If selected, only administrators can manage the VPS (start, stop, restart).
Include in replication: If selected, a dropdown with a list of available enabled replications will appear. Select the replication from the dropdown to add the created VPS to the replication cycle.
Description: Provide any necessary description for the VPS.
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.
¶ Create VPS from OCI
When creating the VPS from the OCI image first we have to download the OCI runner template from the Bicomsystems repository and add it to SERVERware templates, see "OCI image Template" section.
When (OCI) is selected as a source, a new 'Environment' tab appears, providing users with additional configuration and management options specific to OCI environments.
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.
SERVERware 4.7 now supports volume mapping for OCI images from the GUI. Volume mapping is a feature that allows mapping directories or files on the host machine to directories within a container. SERVERware’s implementation pertains solely to the VPS and docker container that’s running inside the VPS, enabling data to be shared and persisted between them.
Shared data between the docker container and the VPS can also be bi-directional, writable, and in read-only mode.
Finish the steps to the end and hit create button, after this, we will have a functional VPS created from the OCI image.
¶ Managing Virtual Private Servers
Administrative tasks for virtual servers include:
¶ Editing VPSs
You can edit details of a virtual server such as its name or memory size. However, you cannot change the template or the partition to which the virtual server belong. Also VPS engine change is possible only when VPS is stopped The VPS network configuration changes take effects after the virtual server is stopped and restarted.
Follow this procedure to edit VPS details:
¶ Starting, Stopping and Restarting VPSs
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:
¶ Changing VPS Ownership
Follow this procedure to change VPS owner:
¶ Increasing VPS storage
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.
¶ Reclaim free space - TRIM
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
¶ VPS Shrink
In SERVERware 4.7, shrinking VPSs can be done with a single click through the SERVERware GUI.
SERVERware will automatically calculate the required volume size based on the Data Used values within the volume.
Before shrinking the volume, the VPS needs to be stopped.
The shrink button is located next to the extend button and as with the extend functionality, this is a process that might take a while, so it’s recommended not to immediately start the VPS once the dialog is closed. The shrinking process can be tracked through the system logs and audit logs.
¶ VPS Snapshots
Snapshot is a read-only copy of a dataset or volume. Upon creation, which is almost instantaneous, snapshots do not take up any extra storage space.
In SERVERware 4.7 you can take snapshots of individual VPSs and manage them from the snapshots tab. The supported actions in SERVERware are creating a snapshot, removing individual snapshots, or removing all snapshots created for a single VPS, as well as performing a rollback to the point in time when the snapshot was created.
To create a snapshot, simply click on the Create Snapshot button and fill in the name of your snapshot, as well a short description if necessary, that will help distinguish between multiple snapshots.
All snapshots created for a particular VPS will appear in a list under the snapshots tab, where SERVERware administrators can manage them.
Snapshots can be removed either individually or have all snapshots deleted by clicking on the Delete All button. Creating a new snapshot and removing individual or all snapshots does not require stopping the VPS in SERVERware.
One of the main advantages of snapshots is that they allow for the entire dataset to be rolled back to the point in time when the snapshot was created, which can be useful in many scenarios, for example, upgrades, various maintenance tasks, to pull out certain files and more.
To perform a rollback of a SERVERware snapshot, simply click on the Rollback button. In order to complete the rollback function, the VPS needs to be stopped. When performing a rollback to a specific snapshot, all snapshots created after the rollback point will be automatically removed.
Snapshots initially do not take up any storage space, however once more data is added to the original dataset, so will the snapshot increase in size which is why it’s recommended practice not to store snapshots for longer periods of time.
Snapshots in SERVERware will be automatically removed after 15 days.
All snapshot-related activities are recorded in the Recent Activity Log on the Dashboard, in System Logs and, in Audit Logs.
¶ Open TTY session on VPS
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:
¶ Moving VPSs
A stopped VPS can be moved to any processing host within the SERVERware network. This is especially useful if the load on a particular host is too high, and is essential before bringing a server down for maintenance. A live VPS migration is not yet supported. Also, while VPS is stopped, it is possible to move a VPS to another partition.
Follow this procedure to move VPS to another host:
Follow this procedure to move VPS to another partition:
¶ Cloning VPSs
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:
¶ Removing VPSs
VPS can be removed only if it is stopped.
Follow this procedure to remove a VPS:
¶ Removing VPSs from the Removed VPSs list
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:
Removed VPS will be automatically removed from SERVERware inventory once their latest backup expires
¶ Statistics
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.
¶ View Host/VPS Performance Charts
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.
¶ Backup
In order to provide fault-tolerant storage, SERVERware relies on a mirrored pair of storage servers. Given that the storage mirror by definition and purpose is not a backup, SERVERware provides a built-in backup feature to protect data of hosted VPSs in the event of a disaster.
¶ Manage Backup Jobs
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. | |
¶ Schedule Backup Job
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
¶ Removing Backup Job
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 Restore from Browse & Restore menu
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 Bulk Restore from Browse & Restore menu
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.
¶ Remove backup for VPS
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.
¶ Geo-Redundancy
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
¶ Configure the replication cycle
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
Geo-Redundancy Server will keep replications until next full circle.
Replicated Partitions
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
¶ Browse & Takeover from Geo-Redundancy
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.
¶ Remove replicated VPSs
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.
¶ Geo-Redundancy / Site Monitoring
Site monitoring enables the SERVERware administrator to setup monitoring of remote sites by creating a set of tests that will report whether the monitored site is available or not. The administrator can add actions that will be executed in case tests fail. Actions can be configured to trigger only if all tests fail **(ALL action type)** and if any of the tests fail **(ANY action type)**.
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.
| 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.
¶ Control Geo-Redundancy Server Resources
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:
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.
¶ The list of commands supported
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 :#
COMMAND :#
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.
¶ Geo-Redundancy dataset on the Processing/Backup host
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.
~ # 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.
¶ sipPROT
¶ Introduction to sipPROT
Depending on the setup you are running sipPROT can be installed in two possible locations:
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.
¶ sipPROT Dashboard
The sipPROT dashboard is designed to provide critical information regarding the health and status of the protection system. Here's a brief overview of what each widget on the dashboard likely represents:
| 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. |
¶ sipPROT Settings
General sipPROT configuration can be found under menue Settings > Firewall.
¶ The description for the options available:
| 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. | |
¶ Attack Logs
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. |
¶ Allow/Deny lists
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.
¶ Buttons
¶ Search
¶ Display and refresh options
¶ At the bottom of the list, users can find:
¶ Note
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"
}
}
¶ Allowlist
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.
¶ ADD IP records to Allowlist
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.
¶ IMPORT / EXPORT Multiple IP records to Allowlist
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.
¶ Remove IP address from the list
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.
¶ 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.
¶ ADD IP records to Denylist
To add an IP address to the denylist, follow these steps:
¶ IMPORT / EXPORT Multiple IP records to Denylist
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.
¶ Remove IP address from the list
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.
¶ Dynamic denylist
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.
¶ sipPROT Hosts
To access the hosts page use the top navigation menu Settings > Hosts, or click directly on the dasboard, Health widget.
The sipPROT hosts page offers a comprehensive overview of various hosts. On this page, users can access detailed information about the status of the sipPROT service for each host.
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. |
¶ sipPROT on the remote Host
In cases where the sipPROT service needs to run on a remote host located on a different network than the controller, you can manually configure the sipPROT instance to register and communicate with the controller service by following these steps.
¶ Steps:
ifconfig MAN | grep 'inet6' | awk '{print $2}'
This command will provide the MAN IP address required for configuration.
/etc/init.d/sipprotd restart
REMOTE sipprotd[31063]: [ info ] Starting sipPROT ...
REMOTE sipprotd[31063]: [ info ] Max Active Instances: 2
REMOTE sipprotd[31063]: [ info ] Licence Expiry Date: 2030-08-20 23:59:59 +0100 BST
REMOTE sipprotd[31063]: [ info ] Terminating licence watcher
REMOTE sipprotd[31063]: [ info ] Using static config to access sipPROT admin service: [IP: fe88:54f5:8784:9b0c:f9cd:794d:38cb:820d, Port: 8183, BaseURL: /api/, RegisterEndpoint: register]
REMOTE sipprotd[31063]: [ info ] Start watching security group (ID: 1)
REMOTE sipprotd[31063]: [ info ] Activating firewall
REMOTE sipprotd[31063]: [ info ] Loading firewall rules ...
REMOTE sipprotd[31063]: [ info ] - setting up TRUSTED DOMAINS protection
REMOTE sipprotd[31063]: [ info ] Waiting for redis client to sync with master...
REMOTE sipprotd[31063]: [ info ] - setting up ALLOWLIST protection
REMOTE sipprotd[31063]: [ info ] - setting up DENYLIST protection
REMOTE sipprotd[31063]: [ info ] - setting up DYNAMIC DENYLIST protection
REMOTE sipprotd[31063]: [ info ] - setting up GEOIP protection
REMOTE sipprotd[31063]: [ info ] - setting up SIP protection
REMOTE sipprotd[31063]: [ info ] - setting up TFTP protection
REMOTE sipprotd[31063]: [ info ] Sync completed!
Navigate to the sipPROT hosts in GUI to verify that host is added:
¶ sipPROT Notifications
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. |
¶ Working with sipPROT CLI
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
¶ sipPROT status
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
Settings menu expands into Storage, Archive and Networking.
¶ Storage
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
Networking view allows you to add, configure and remove SERVERware network logical subnets.
¶ Adding logical subnet
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.
¶ Removing logical subnet
Follow this procedure to remove a logical subnet:
¶ Extending IP address pool
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.
¶ Removing IP address from the pool
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.
¶ Create virtual network interface IPV4
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.
¶ Create virtual network interface IPV6
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 Zones
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:
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
¶ Reports
Reports menu expands into System Logs, Alarm logs and User Sessions.
¶ System Logs
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.
¶ Alarm 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
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
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
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
Administrators menu allows creation, editing and removal of SERVERware GUI Administrators.
¶ Adding administrator account
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.
¶ Removing administrator account
Follow this procedure to remove the administrator account:
¶ Demoting administrator account to user account
Follow this procedure to demote an administrator account to a user account:
¶ Partition Users
Partition Users menu allows creation, editing and removal of SERVERware GUI users as well as assignment of various roles and permissions.
¶ Adding user account
Follow this procedure to add a user account:
In the Partition Users view, click Add User.
Add User dialog appears. Select User Role, Status and enter personal user information.
Click Add to add user.
¶ Removing user account
Follow this procedure to remove a user account:
¶ Promoting user account to administrator account
Follow this procedure to promote a user account to an administrator account:
¶ Access Control
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
¶ Trusted IP Addresses
¶ Limit Session Number
¶ Role & Permissions
Use Role & Permissions view to add, edit or remove roles and permissions that can be assign to the SERVERware GUI users.
¶ Adding role
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.
¶ Removing role
Follow this procedure to remove a role:
¶ Service Pools
Service Pools tab allows you to add and remove service pools.
¶ Adding service pool
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.
¶ Removing service pool
Follow this procedure to remove a service pool:
¶ Alarms
Alarms view is used for setup and configuration of various SERVERware alarms. Alarms can be configured to send notifications when specific conditions are met.
¶ Adding alarm
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.
¶ Removing alarm
Follow this procedure to remove an alarm:
¶ Flavors
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.
¶ Adding flavor
To add a flavor, do the following:
¶ Removing flavor
Follow this procedure to remove a flavor:
¶ Notifications
SMTP/XMPP notification delivery settings can be configured in the **Notifications** section of System Settings.
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
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.
SERVERware Templates are software packages that run in VPSs on SERVERware. Previously organized as built-in templates and OCI images, version 4.7 introduced major changes in their structure and organization.
To enhance security and ease of management, all SERVERware templates now conform to the OCI standard. The Open Container Initiative is an open governance structure dedicated to creating open industry standards around container formats and runtimes.
Templates are now grouped into three categories: official, community, and third-party (OCI).
¶ Official Templates
Official templates are software packages created, maintained, and supported by Bicom Inc. Under this category, SERVERware administrators can download, install, and delete PBXware templates, along with other software packages published by Bicom.
¶ Community Templates
Community templates are reserved for third-party software that will be available for easy install and use. Downloading a new template can be completed by clicking on the Add New Template button, which will provide a list of available templates. The list contains information about the version number, creation date, and a download button. If a new version of the template is uploaded to the repository, an update button will appear next to the download icon.
Official and community templates are hosted in our official repository, registry.bicomsystem.com.
Community Templates: Homer and Ubuntu 24.04
Our aim with the template restructure was to offer more versatility to our users regarding applications that they can run on SERVERware. As part of the SERVERware 4.7 release, we added two brand new templates to the Community section: Homer and Ubuntu 24.04.
Homer is an open-source VoIP and RTC Capture Framework for Analysis and Monitoring based on the HEP/EEP protocol. Homer supports advanced IP, RTP/RTCP Reports, RTC events, and Custom protocols, and provides various methods of processing logs, metrics, and traces, including Packets and PCAP. For more information on Homer, visit sipcapture.org.
To use Hommer with the PBXware you will need to edit PBXware manually:
Asterisk 12 and above has a native HEP module that would be able to send SIP/RTCP/TLS data to Homer directly.
Editing /opt/pbxware/pw/etc/asterisk/hep.conf to point to your homer server would be all thats needed, for example:
;
; res_hep Module configuration for Asterisk
;
; All settings are currently set in the general section.
[general]
enabled = yes ; Enable/disable forwarding of packets to a
; HEP server. Default is "yes".
capture_address = 10.1.100.60:9061 ; The address of the HEP capture server.
capture_password = foo ; If specified, the authorization passsword
; for the HEP server. If not specified, no
; authorization password will be sent.
capture_id = 1234 ; A unique integer identifier for this
; server. This ID will be embedded sent
; with each packet from this server.
Once done, restart asterisk and confirm the module is sending the HEP traffic by doing a tcpdump towards the homer server. Please keep in mind that HEP will send the unencrypted traffic, so this should be sent over a dedicated/private network if possible.
Under SERVERware Community templates, both Homer 7 and Homer 10 will be available to download and install.
Please note that software installed from the Community templates, as well any other third-party software installed from the OCI registries tab, is not supported by Bicom Inc.
¶ OCI Templates
In the OCI Registries tab, administrators can add other repositories to download and install OCI images that are not Official or Community.
To add a new repository, click on the Add new registry button, add the URL to the registry, provide a name, and optionally a username and password if you’re adding a private registry that requires authentication. The OCI registry tab includes a test connectivity feature to verify the network connection between SERVERware and the configured registry.
"For security reasons, please ensure that you create a read-only access token when using a private repository."
Once the templates are downloaded, they can be used to create a new VPS.
To run an OCI image in SERVERware, we added a template that will automatically provide a docker container engine. The OCI runner template will automatically pull and start an app using the specified OCI image. Once a new version of the template is available, the Update button will appear next to the template.
Deploying third-party OCI images has been reorganized so everything can be completed from a single point, the Create VPS dialog, once the OCI registry has been added.
Selecting the OCI option in crete vps dialog, changes the view to include the required information, including the registry, the image name, and tag.
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.
¶ Updates
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 Configuration
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 …)
¶ Obtain a certificate using domain verification process
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.
¶ Generating CSR (Certificate Signing Request) from GUI
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.
¶ Manual certificate upload and installation
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.
¶ Revoke a 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.
¶ Manual renewal of active ssl certificate
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
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.