DCImanager Overview

DCImanager is a centralized platform for managing, monitoring, and diagnosing server and network equipment. It supports physical and virtual networks efficiently.

Use Cases

Customers recommend Account Management, Onboarding, Collaboration, as the business use cases that they have been most satisfied with while using DCImanager.

Other use cases:

  • Products & Pricelist Management
  • Performance Management
  • Generation Of New Leads
  • Proposal & Quote Management
See all use cases See less use cases

Business Priorities

Enhance Customer Relationships and Acquire Customers are the most popular business priorities that customers and associates have achieved using DCImanager.

DCImanager Use-Cases and Business Priorities: Customer Satisfaction Data

DCImanager works with different mediums / channels such as Offline. Events. Trade Shows etc.

DCImanager's features include Templates, and Alerts: Popups & Notifications. and DCImanager support capabilities include 24/7 Support, AI Powered, Email Support, etc. also DCImanager analytics capabilities include Custom Reports, and Analytics.

Reviews

"...Developer team with totally wrong logic, which does not listen the needs of their clients, the users of DCIm software...." Peer review by Perica D., ceo, Computer & Network Security

DCImanager, belong to a category of solutions that help Data Security. Each of them excels in different abilities. Therefore, determining the best platform for your business will depend on your specific needs and requirements.

Popular Business Setting

for DCImanager

Top Industries

  • Computer Software
  • Information Technology and Services
  • Computer & Network Security

Popular in

  • Mid Market
  • Small Business

DCImanager is popular in Computer Software, Information Technology And Services, and Computer & Network Security and is widely used by Mid Market, and Small Business,

Comprehensive Insights on DCImanager Use Cases

What makes DCImanager ideal for Onboarding?

4+ more Business Use Cases

11 buyers and buying teams have used Cuspera to assess how well DCImanager solved their Data Security needs. Cuspera uses 350 insights from these buyers along with peer reviews, customer case studies, testimonials, expert blogs and vendor provided installation data to help you assess the fit for your specific Data Security needs.

Video

DCImanager: больше чем платформа для выдачи серверов | ISPsystem Meetup 2022

Video Thumbnail
lightning

Peers used DCImanager for account management and onboarding

DCImanager Features

  • Low
  • Medium
  • High
FEATURE RATINGS AND REVIEWS
Custom Reports

3.96/5

Read Reviews (36)
Analytics

3.73/5

Read Reviews (11)
CAPABILITIES RATINGS AND REVIEWS
Custom Reports

3.96/5

Read Reviews (36)
Analytics

3.73/5

Read Reviews (11)

Software Failure Risk Guidance

?

for DCImanager

Overall Risk Meter

Low Medium High

Top Failure Risks for DCImanager

ISPsystem Feeds

Simpler and faster: PowerDNS usage is now available directly from DNSmanager

ISPsystem adds PowerDNS integration to DNSmanager, enhancing server management capabilities and automation for diverse industries.

23/10/2024 - source

Migration from CentOS Linux 7 for DCImanager, VMmanager and BILLmanager

Migration from CentOS Linux 7 for DCImanager, VMmanager and BILLmanager d.drevko

Red Hat has announced the end-of-life (EOL) for CentOS Linux 7. As a result, without ongoing support, CentOS will no longer receive critical security updates. We strongly recommend migrating DCImanager, VMmanager, and BILLmanager to an up-to-date operating system in advance.

Note:

The migration process includes installing the necessary packages and tools to support the current operating system, as well as migrating configuration files and data to ensure stable and secure operation after the migration is complete.

The following are migration instructions for each product:

Migration from CentOS 7 to AlmaLinux 8 for VMmanager

There are a number of actions to be performed:

Preparation

  1. Check hardware compatibility with AlmaLinux 8 by booting AlmaLinux in Live Media mode.
  2. Migrate virtual machines to another cluster node when you change the OS on a cluster node. (Read more in “Migration of virtual machines�).
  3. Create a backup of the platform on an external storage. (Read more in "Backing up the platform").

Changing the OS

  1. Connect to the server via SSH.
  2. Install the latest available software update: yum update -y
  3. Reboot the server: reboot
  4. Install the Elevate software: yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
  5. Install the Leapp framework: yum install -y leapp-upgrade leapp-data-almalinux
  6. Check if the system is ready for an OS change: leapp preupgrade
  7. Examine the command output and the report file /var/log/leapp/leapp-report.txt for information about possible problems when changing OS.
  8. Configure the Leapp framework:
    • rmmod pata_acpi
    • leapp answer --section remove_pam_pkcs11_module_check.confirm=True

Configuring the firewall. On the server with the platform, change the firewall settings:

 docker exec -it vm_box bash
 cd /opt/ispsystem/vm
 /usr/bin/ansible-playbook -i :22, -e targets=all -e ansible_python_interpreter='auto_silent' -e datacenter_type='common' -e ssh_port='22' -e network_autosetup_enabled='1' -e is_lxd='0' -e dc_ips='' -e dc_ips6='' -e closed_contour='0' etc/playbooks/node/firewall.yml --timeout 60 -b
 

Done! Once these steps are completed, your platform will be successfully migrated to the supported AlmaLinux 8, ensuring stable and secure system operation.

Migration to AlmaLinux 8 without reinstalling DCImanager 6

Operating system (OS) migration is an important process that requires care and consistency to ensure the platform runs smoothly. In the case of changing the operating system from CentOS 7 to AlmaLinux 8 without reinstalling DCImanager 6, there are features and steps that are not provided by the CentOS developers. Therefore, the migration procedure may fail and the platform will be unavailable during the OS change process on the server with the platform.

To successfully complete the migration, you must follow the instructions to ensure the platform runs safely and smoothly. Here are the step-by-step instructions for migrating from CentOS 7 to AlmaLinux 8 using the Elevate software:

  1. Check the compatibility of the hardware with AlmaLinux 8. You can boot AlmaLinux 8 in Live Media mode to perform this test.
  2. Connect to the server via SSH and back up the platform to prevent potential malfunctions during the migration:
     dci backup
     
  3. The backup will be saved in the /opt/ispsystem/dci/backup/ directory. Save the backup to an external media.
  4. Install the latest available software updates and reboot the server:
     yum update -y
     reboot
     
     
  5. Install the Elevate software and the Leapp framework:
     yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
     yum install -y leapp-upgrade leapp-data-almalinux
     
     
  6. Check that the system is ready for the OS change:
     leapp preupgrade
     
  7. Examine the command output and the report file /var/log/leapp/leapp-report.txt to identify possible problems when changing the OS.
  8. Configure the Leapp framework and run the OS change:
     rmmod pata_acpi
     leapp answer --section remove_pam_pkcs11_module_check.confirm=True
     leapp upgrade
     
     
  9. Reboot the server and check the OS version:
     reboot
     cat /etc/os-release
     
     

Migration via DCImanager 6 backup

In case of migration from CentOS 7 to any supported OS, you need to follow a certain sequence of actions. Step-by-step instructions for migration via DCImanager 6 backup are provided below:

  1. Create a new token value for your license in your client area at my.ispsystem.com or by contacting technical support.
  2. Create a backup of the platform:
     dci backup
     
  3. The copy will be saved in the /opt/ispsystem/dci/backup/ directory. If there is a location on the server in addition to the platform, back up the /opt/ispsystem/dci/os_templates/ directory. Save the backups to an external media.
  4. If there is a location on the server in addition to the platform, stop the platform:
     dci down
     
  5. Install a supported OS and connect to the server via SSH.
  6. If you do not have the tar archiver or curl utility installed on your system, install them via the appropriate commands for the OS you are using.
  7. Download the installer and make the installer file executable:
     curl -O https://download.ispsystem.com/6/dci/dcibox/dci
     chmod +x dci
     
     
  8. Create the directory /opt/ispsystem/license/ and copy the previously created platform backup to the directory /opt/ispsystem/dci/backup/.
  9. Start restoring the platform from the backup:
     ./dci restore -b=<backup_file>
     
  10. Activate the license in the DCImanager 6 interface and follow the additional steps if the server has a location.
  11. Update the database:
     docker exec -it mysql bash -c "mysql_upgrade -u root -p$MYSQL_ROOT_PASSWORD"
     

Successfully following these steps will ensure a safe and smooth migration of your platform to the new OS.

Moving BILLmanager and license between servers

Moving BILLmanager to a new server may be necessary when replacing hardware or migrating to a supported operating system. This requires installing on a new server, connecting via SSH, and moving files.

It is important to make sure that the BILLmanager version on the new server is not lower than on the old one. Migration is possible between servers with different operating systems.

Preparation:

  1. Prepare the new server, install BILLmanager on it, activate the trial license via the ISPsystem client area.
  2. Enable maintenance mode on the old server for the duration of the migration.
  3. Import user data from the old server to the new server.
  4. Move custom XML files, addons and plugins to the new server. This can be accomplished by using the scp commands.
  5. Move the storefront settings from the old server to the new server by copying the appropriate directories.
  6. Install missing software packages, such as service processing modules, payment systems, and mail gateways, on the new server.
  7. Link the BILLmanager license to the new server by activating the commercial license through your client area.
  8. Disable maintenance mode on the old server after a successful migration.

After the migration is complete, it is recommended to disable or uninstall BILLmanager from the old server to avoid conflicts due to identical service processing module settings.

Preparing a new server includes installing BILLmanager, activating the trial license via the ISPsystem client area and logging in to BILLmanager via a browser to activate the license.

Make sure that both servers have active licenses and activate the commercial license on the new server after the migration.

Instructions on moving BILLmanager to a new server:

Step 1: Enabling maintenance mode

Maintenance mode temporarily stops the operation of processing modules and mail gateways in BILLmanager. To enable it on the old server, create an empty file

 /usr/local/mgr5/etc/billmgr.DoNothing
 

Step 2: Data import

On the old server:

  1. Create a backup from the BILLmanager web interface under Tools → Backup → click Run. Save the backup archive.
  2. Save the branding settings.
  3. Copy the directories to the new server using the scp commands:
     scp /usr/local/mgr5/skins/dragon/local_* root@:/usr/local/mgr5/skins/dragon/
     scp /usr/local/mgr5/etc/brand_settings.billmgr.xml root@:/usr/local/mgr5/etc/
     
     

On the new server:

  1. Enter Tools → Backup →click Download, select the backup archive from the previous server and click Restore.
  2. After restoring from backup to a new server, the IP address of the old server can be specified in the configuration file. Specify the IP address of the new server in the ihttpd configuration file /usr/local/mgr5/etc/ihttpd.conf. Restart BILLmanager:
     /usr/local/mgr5/sbin/mgrctl -m billmgr exit
     

Step 3: Moving custom XML files, addons and plugins

If you have custom XML files, addons, and plugins, perform the following:

  • Create the /usr/local/mgr5/backup/ directory on the new server if such a directory does not already exist.
  • Move existing custom files using the scp commands:
     scp -r /usr/local/mgr5/etc/xml/ root@<new_server_IP>:/usr/local/mgr5/backup/
     scp -r /usr/local/mgr5/addon/ root@@<new_server_IP>:/usr/local/mgr5/backup/
     scp -r /usr/local/mgr5/src/ root@@<new_server_IP>:/usr/local/mgr5/backup/
     
     
  • Copy the contents of the directories using the commands:
     cp -n /usr/local/mgr5/backup/xml/* /usr/local/mgr5/etc/xml/
     cp -n /usr/local/mgr5/backup/addon/* /usr/local/mgr5/addon/
     cp -n /usr/local/mgr5/backup/src/* /usr/local/mgr5/src/
     
     

Step 4: Moving storefront files

To move the storefront from the old server to the new server, copy the following directories to the new server:

 scp -r /usr/local/mgr5/skins/showroom/ root@<new_server_IP>:/usr/local/mgr5/skins/showroom/
 scp -r /usr/local/mgr5/etc/showroom.sample.dragon/ root@<new_server_IP>:/usr/local/mgr5/etc/showroom.sample.dragon/
 
 

Step 5: Installing missing packages

After moving the database, on the new server, run the installation of all missing service processing module packages, payment systems, and mail gateways. Run the command:

 /usr/local/mgr5/sbin/mgrctl -m billmgr fix.modules
 

Step 6: Linking a commercial license to a new server

After moving BILLmanager to a new server, enter your client area where you ordered the license. Delete the trial license from your client area. In the commercial license settings, enter the IP address of the new server. Update the license file by clicking Update License in the BILLmanager web interface or by uploading the license manually using the command:

 /usr/local/mgr5/sbin/licctl fetch billmgr
 

Step 7: Disabling maintenance mode

To disable maintenance mode, delete the /usr/local/mgr5/etc/billmgr.DoNothing file.

We also plan to provide support of Alma Linux 9 for DCImanager and VMmanager products this year, but please note that the Leapp migration tool for OC CentOS 7 assumes a split migration process: first from OC Centos 7 to AlmaLinux 8, and only then from AlmaLinux 8 to AlmaLinux 9.

Off
�а главной
Off
/system/files/2024-06/23-05-04-1600x702.png
Т�г
English
Изображение анон�а 440х250
alt

25/06/2024 - source

Authorization service changes in IT infrastructure management products

Authorization service changes in IT infrastructure management products d.drevko

Significant updates of VMmanager 6 and DCImanager 6 will take place in March 2024 in relation to authorization information exchange between platform services.

Version 3 of auth/v3 authorization service will be fully disabled and superseded by the up-to-date version 4.

Why do we make transition to auth/v4 version?

This approach eliminates discrepancies between authorization services: transition to auth/v4 allows to avoid outdated session information in auth/v3 causing potential operation errors.

Besides, desynchronization between database management systems can be eliminated: new version of authorization service helps avoiding user management errors, for instance, when creating a user prior to invitation.

Advantages of new authorization service:

  • Improved performance: auth/v4 is faster than auth/v3 resulting in higher speed of authorization and request processing.
  • Improved security*: new version of authorization service enables the use of ACL and authentication limits for increased system security.
    *relevant to services, whose previous operation was based on auth/v3
  • Transition to auth/v4 ensures single entry point for authorization and user management. This makes it simpler and easier to administer systems, integrate platforms with third-party software, work with API and perceive information in general due to concentration of messages from multiple services in a single space.
  • Transition to the new version of authorization service allows to reduce the number of containers, thus decreasing usable disk space of the platform and speeding up its commissioning and decommissioning. Besides, service logging becomes faster, which enables more efficient linking of URI names, such as /auth/v4/ or /vm/v3/ (endpoints) to actual location of services (container IP address and service port). Fast logging results in shorter time period between product commissioning and actual operation.

What is the idea?

Once VMmanager 6 and DCImanager 6 updates are installed in March scripts, billing systems and/or other software using authorization service version 3 (auth/v3) without version 4 (auth/v4) support, will not be able to transfer authorization data or maintain correct operation with ISPsystem products.

Please consider the following to ensure further efficient operation of VMmanager 6/DCImanager 6 with third-party solutions when using auth/v4:

  • For BILLmanager users: up-to-date versions of this billing platform already support this type of authorization, and no additional actions are required on your end.
  • For HostBill or WHMCS users: you will need to update these billing systems to up-to-date versions. The oldest acceptable WHMCS version is the one dated November 2023. Up-to-date versions of both of these systems support auth/v4.
  • For platform users with their own scripts and in-house billing: you will need to make unassisted corrections.

Also please note, that once VMmanager 6 и DCImanager 6 updates are installed in March, you will not be able to reactivate authorization version 3.

Instruction for transition to authorization service version 4, using VMmanager 6 as an example:

  1. Open Swagger for VMmanager 6, section REST API Documentation Tool and find the section related to authorization service (usually section auth_v4).
    the section related to authorization service
  2. Find API methods related to user creation, updating and deleting in the current version of authorization service (auth/v3).
  3. Create new API methods for user management in the new version of authorization service (auth/v4). Find more details in our documentation: https://docs.ispsystem.com/vmmanager-admin/developer-section/api/auth-api-v4.
  4. Update Swagger documentation to reflect API method changes and add the description of new features and parameters available for auth/v4.
  5. Make sure that all requests to authorization service are now using new API methods for user management in auth/v4.
  6. Test authorization-related features to make sure that all changes operate correctly.

eel free to contact technical support for any questions using your Profile.

On
�а главной
Off
/system/files/2024-02/blog-04-2280x1000_1.png
Т�г
English
Изображение анон�а 440х250
alt

26/02/2024 - source

ISPsystem Profile

Company Name

ISPsystem

Company Website

https://www.ispsystem.com/

HQ Location

Dekabrskyh sobytiy 125, Irkutsk, 664007, RU

Employees

101-250

Social

Financials

PRIVATE