EATON Brightlayer Data Centers Software

ទាក់ទងផ្នែកជំនួយ
For your convenience, Eaton provides one site where you can access the information that you need for our Bright Layer Data Center products. You can access the technical support portal by going to https://eaton.my.site.com.
- Online contact information for technical assistance and customer services
- ការទាញយកផលិតផល និងឯកសារ
- ធនធានមានប្រយោជន៍ផ្សេងទៀតដែលសមរម្យសម្រាប់ផលិតផលរបស់អ្នក។
សេចក្តីផ្តើម
This document provides the security hardening information and best practice recommendations for Brightlayer 8.0 GA release, which has been validated and certified by the Eaton Cybersecurity standards.
The following product tiers are covered by this document:
- DIT_LITE 8.0 (All editions)
- DIT 8.0 (All editions)
- DCIM 8.0 (All editions)
- EPMS 8.0 (All editions)
- Power 8.0 (All editions)
Eaton Product Cybersecurity
Eaton is committed to minimizing the cybersecurity risk in its products and deploying cybersecurity best practices in its products and solutions, making them more secure, reliable, and competitive for customers. Cybersecurity risk management throughout the lifecycle of a product requires the consistent application of security management and monitoring practices. Eaton assumes the customer will integrate the recommendations provided into their overall cybersecurity risk management and lifecycle planning.
Eaton Secure Development Lifecycle
Eaton uses a Secure Development Lifecycle (SDLC) for new product development and maintenance releases. The Eaton SDLC has been certified by UL under UL 2900 and IEC 62443-4-1 cybersecurity standards. All software releases go through this SDLC (including patches and updates). Eaton is requiring cryptographic code signing to provide integrity and authenticity of all firmware and software. Implementation has started on some products will be implemented on all products going through the Eaton SDLC starting in January 2020.
This SDLC process includes threat modeling and architecture analysis where security requirements (derived from several sources including NIST SP800-82, IEC-62351, UL 2900, IEEE1686, U.S. DHS, and others) are evaluated, severity rated, and applied to the product as applicable.
More information on the Eaton SDLC and UL certifications can be found at the following links: https://www.eaton.com/us/en-us/markets/innovation-stories/Managing-Cybersecurity-Risks.html
Vulnerability Disclosure and Response
Full lifecycle monitoring and analysis of emerging cybersecurity threats and vulnerabilities is critical and requires a continuous process. Eaton publishes cybersecurity notifications and known vulnerabilities for its products on www.eaton.com/cybersecurity. Users are also able to report cybersecurity issues and receive automated cybersecurity notifications on this site. Eaton also has a vulnerability disclosure policy that is documented at this link:
https://www.eaton.com/us/en-us/company/news-insights/cybersecurity/vulnerabilitydisclosure.html
For non-Eaton and Commercial Off the Shelf (COTS) products, Eaton recommends monitoring vendor sites, the ICS CERT, and NIST National Vulnerability Database (NVD) for known vulnerabilities in products and mitigating or remediating the vulnerabilities as recommended though patches, updates, or compensating controls. Eaton recommends monthly vulnerability management and review activities be integrated into overall lifecycle maintenance practices.
Eaton Best Practices and Hardening Guideline
Eaton provides customers guidelines that should be considered for their systems. www.eaton.com /assemblies-security
Eaton is committed to minimizing the cybersecurity risk in its products and deploying cybersecurity best practices in its products and solutions, making them more secure, reliable, and competitive for customers. Cybersecurity risk management throughout the lifecycle of a product requires the consistent application of security management and monitoring practices. Eaton assumes the customer will integrate the recommendations provided into their overall cybersecurity risk management and lifecycle planning. The cybersecurity configuration and maintenance guidance apply to assembled systems of automation and control components with internal facing and/or external connectivity over wired Ethernet, wireless, or serial communications or with physical ports for USB, serial, or removable media connections for diagnostics, configuration, and maintenance. The guidance is expected to be applied as applicable to the individual components of the assembled system and adjacent components and networks. The following Eaton whitepapers are available for more information on general cybersecurity best practices and guidelines:
Cybersecurity Considerations for Electrical Distribution Systems (WP152002EN) Cybersecurity Best Practices
Cybersecurity Best Practices Checklist Reminder (WP910003EN)
Server Security Planning
Server security planning must be executed before any actual installation, configuration and deployment tasks can take place. The following factors are critical to include for the planning:
- Organizational security policy
- Detailed BLSS Server security requirements including authentication, authorization control and flow, including but not limited to:
- Password strength control
- Maximum allowed incorrect password attempts before automatic account lockup.
- Multi-Factor-Authentication
- Single-Sign-On: Active Directory / SAML 2.0
- User Access Control List setup via User Group based access privilege definition.
- Detailed BLSS Server performance requirements
- Constraints of the available resources including hardware and operating system, etc.
- Secure and accessible RedHat Enterprise Linux / Oracle Linux YUM repository for providing up-to-date cybersecurity mitigation OS patch updates.
- Define the first-use BLSS Web administrator password to be used to reset the administrator password upon the first BLSS application Web ចូល។
- Define the OS administrator password to be used to reset the OS administrator password upon the first OS login.
- If the given BLSS instance is deployed using the OVF installer, SELinux is set to enforcing by default.
- If the given BLSS instance is deployed using the OVF installer, the SSH session timeout is set at 600 seconds.
- If the given BLSS instance is deployed using the OVF installer, customer-created-users’ password expiration period is set at 90 days. It is imperative to update these users’ passwords before their expiration dates.
- If the given BLSS instance is deployed using the OVF installer, SSH login is disabled with empty passwords.
- If the given BLSS instance is deployed using the OVF installer, a user is not able to set the password to the same as any one of the last 5 passwords.
Installation and Deployment Planning
កំឡុងពេលធ្វើផែនការ សtage, the following important specific topics must be reviewed and determined:
Identify the purpose(s) of the server:
To ensure the security, stability, and performance of the server, please ensure that the server is only used for BLSS application and no other 3rd-party applications (except for those who are needed as prerequisites for the OS and the BLSS application) are running on this server. Ensure that the role of the server is well-identified and determined that whether it will be used as an All-In-One Server, Master Server, Master Database Server, or Probe Server. Once the role of the server is determined, it cannot be changed arbitrarily. Should the changes be required, ensure that the changes have gone through with discussions, considerations, documentation and follow the proper change management to implement.
- Choose a supported OS. For release 8.0, the following operating systems can be selected:
- RedHat Enterprise Linux 8.10 and 9.6
- Oracle Linux 8.10 and 9.6
Always refer to the product server installation guide / release notes to determine the highest-supported operating system version number. It is not recommended to upgrade the operating system outside of the certified operating system versions to avoid potential risks, such as 3rd party library incompatibility / dependency issues. If RedHat Enterprise Linux is the chosen operating system, ensure that the commercial RedHat Enterprise Linux subscription is purchased from Red Hat. Use unauthorized Linux YUM repository is extremely dangerous to the system security since it opens the system up for malicious RPM package attacks.
Operating System Security Hardening
If operating system security hardening is required, it is critical to perform the security hardening after the application is successfully installed and running. The application installation prerequisite is based-upon the default/out-of-box operating system RPM packages and configuration settings. Any deviation from the required operating system environment would most likely to cause the installation to fail and/or embed serious application stability risks during future operation.
After the application is validated successfully, the security hardening may only proceed after at least one known-good VM snapshot or application backup is made. The security hardening process shall be carried out carefully in the trial and error manner to ensure the application functionalities are not impacted adversely.
ការការពារមេរោគ
If 3rd party antivirus software is to be installed on the server, it should only be installed after the application software is successfully installed and validated. A known-good virtual-machine-snapshot and/or full application backup is a must before any antivirus software can be installed. It is known that some of the antivirus programs would block / disable key shared libraries and system files. When such a condition arises, a white list should be added to the antivirus program to exempt these key shared libraries and system files from being blocked.
- Identify the appropriate installation media. Among the available installation media options:
- The product full-installation package requires the customer’s IT to build the operating system which conforms to the requirements of the product server installation guide prior to the installation. Installation performs based upon the full installation package gives the customer the maximum flexibility in controlling the security setup. It is important to point out that it is the customer IT’s responsibility to deploy, configure and maintain the operating system that meets the requirements of Eaton software products. Eaton is not responsible for setting up and/or maintaining the OS including its security unless a mutually agreed deployment project with well-defined scope has been assigned to the Eaton’s professional service team.
- The product OVF install package offers the application together with its operating system to the customer as an appliance. The lifecycle management within the appliance including the operating system can be managed through the periodical patch releases providing the customer has not altered the appliance, including both the application and the operating system, in any way.
- Identify the network services that will be provided on the server: HTTP/HTTPS is a must-have network service for the Master Server. HTTPS is recommended for any environment. For production environment, a commercial SSL certificate needs to be purchased from one of the trusted certificate authorities by the owner of the domain. A self-signed certificate is only appropriate for lab environment.
SSHD service is only required during the initial application deployment and maintenance process. SSHD can be disabled fully during the remaining time. Full SSH-less deployment and maintenance features are coming to allow a customer to perform deployment and maintenance all through the Server Admin Web interface. SSHD service can then be completely disabled.
Chrony/NTP shall be functioning properly to keep the system clock in sync among the BLSS application server nodes. Clock synchronization is essential for successful security hardening. - Identify the OS, any network service software, both client and server, to be installed on the server and any other support servers.
- RedHat Enterprise Linux/Oracle Linux 8.10/9.6 x86 64-bit version
- OpenSSL 1.1.1X (for OS 8.x) and OpenSSL 3.0.X(for OS 9.x)
Apache 2.4 and above, note that make sure it is installed by a standard installation and be installed under the default directory, and a model.ssl module needs to be installed. (Required only for master server or all-in-one server) By default, the BLSS installer will install and configure Apache automatically. It is recommended to let the BLSS installer to perform such automatic installation and configuration instead of manually set up Apache. Please do not install additional 3rd party Apache component without consulting BLSS support first.
- Identify the users or categories of users on the server and any support hosts.
At the OS level, BLSS requires the following users and groups:- root user and group
- vdc user and group
- Determine the privileges that each category of user will have on the server and support hosts.
- /opt/VDC must be owned by the vdc user and vdc group
- /opt/VDC.BACKUP must be owned by the vdc user and vdc user
- Under /opt/VDC/, these are the required set-uid programs:
- /opt/VDC/bin/vdcrun
- /opt/VDC/bin/read_hardinfo8
- /opt/VDC/bin/read_hardinfo9
- Determine how the server will be managed (e.g., locally, remotely from the internal network, remotely from external networks).
We recommend that the BLSS server must be accessible by either direct KVM console access or Hypervisor host level console access for emergency accesses. Network-based SSH access is to be used for scheduled maintenance work. - Decide if and how users will be authenticated and how authentication data will be protected.
By default, users are authenticated via the local OS-level user authentication mechanism. If required, Active Directory-based authentication mechanism can be enabled. - In the OVF appliance, sudo access configuration is set up. During day-to-day operations, there is no need for explicit administrative privilege elevation. However, the administrative privilege elevation is required during the system upgrade process. The sudo configuration can be shared with the customers who desires to ensure sudo for the applications installed by the full installation package.
- The following crontab entries are required for the application server:
vdc user cron jobs:
| Crontab Entry | គោលបំណង | ម៉ាស៊ីនបម្រើពាក្យសុំ | អ្នកប្រើប្រាស់ |
| RPT | Report data aggregator | All-in-One Probe Server | វីឌីស៊ី |
| opensearch-backupctl.sh | Backup the OpenSearch engineer data | All-in-One Master Server | វីឌីស៊ី |
| vdcmon | Watchguard for all application services with self- recovery capability | All Servers | វីឌីស៊ី |
| bkpvdc | Daily backup for the entire application server | All Servers | វីឌីស៊ី |
| watchspace.sh | Disk consumption monitor | All Servers (not including master without DB architecture) | វីឌីស៊ី |
| clean_rdgc_expired_files.sh | Clean execution history of RDGC from probe server | Probe Server | វីឌីស៊ី |
OS-level administration recommendations include the following:
- Ability to disable unnecessary network services that may be built into the OS or server software. Other than the required network services, such as: SSHD, DNS, Chrony/NTP, other network services can be disabled. However, network services, such as Email, etc. needs to be handled with care to avoid interruption of the critical features, such as email alert notification.
- Ability to log appropriate server activities to detect intrusions and attempted intrusions.
The BLSS application can detect intrusions and attempted intrusions by monitoring these logs, which are /var/secure, /var/tmp, /var/message, /var/lastlog etc. - Provision of a host-based firewall capability to restrict incoming traffic.
- Support for strong authentication protocols and encryption algorithms
- BLSS installer does not set any OS user passwords or security policies. Administrators are responsible for setting the OS level user passwords which confirm to the security policy.
- By default, BLSS enforces the application-level user password policy which requires the passwords to be at least 8 characters, with at least one uppercase letter, and with at least one number.
- Due to the sensitivity nature of the SSL certificate, BLSS does not configure HTTPS out of the box. It is recommended for the administrators to install commercial SSL certificates as a part of the deployment process. HTTPS enablement is mandatory for those BLSS instances which are accessible on the public Internet.
- BLSS supports the RSA private keys used to protect various customer credential information. The length of the key used is 2048 bits.
- For authentication integration with SAML 2.0, BLSS supports the RSAwithSHA 256 encryption which used to encrypt all requests to the application. The length of the key used is 4086 bits.
Support for two-factor authentication
BLSS Web authentication module supports two-factor authentication, which included Google Authenticator, Microsoft Authenticator and DUO Authenticator.
ច្រកម៉ាស៊ីនមេ
- The application uses various network ports to connect server components and monitored devices. Customers need to enable these ports for proper system setup. Below is a summary of the required ports in the architecture.
- External-to-Application-Servers Network Connectivity Requirements
- The following ports are used for communication among clients and Brightlayer servers.
ពីម៉ាស៊ីនភ្ញៀវ 3D ទៅម៉ាស៊ីនមេ
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| The Windows PCrunning 3D client | ណាមួយ។ | Master Server | ៥/៥ | ទាមទារ | To access HTTP services |
ពី Web ម៉ាស៊ីនភ្ញៀវទៅម៉ាស៊ីនមេ
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Web អតិថិជន | ណាមួយ។ | Master Server | ៥/៥ | ទាមទារ | To access HTTP services |
ពីឧបករណ៍ដែលបានត្រួតពិនិត្យ SNMP ទៅម៉ាស៊ីនមេស៊ើបអង្កេត
| ប្រភពដើម | Originating Port | គោលដៅ | គោលដៅ
ច្រក |
ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| SNMP Monitored
ឧបករណ៍ |
ណាមួយ។ | Probe Server | 162 | ស្រេចចិត្ត | To receive SNMP Traps |
ពី Web Client to RDG Client
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Web អតិថិជន | ណាមួយ។ | RDG Client | 80 | ទាមទារ | Redirect to 443/TCP |
| Web អតិថិជន | ណាមួយ។ | RDG Client | 443 | ទាមទារ | Web ម៉ាស៊ីនមេ |
Inter-Application-Servers Network Connectivity Requirements
The following ports are used for communications among distributed Brightlayer servers.
ពី Master Server ទៅ Probe Server (ការដំឡើងចែកចាយ)
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Master Server | ណាមួយ។ | Probe Server | 5432 | ទាមទារ | To access database |
| Master Server | ណាមួយ។ | Probe Server | 12005 | ទាមទារ | Probe Communication |
ពី Master Server ទៅ Master DB (ការដំឡើងចែកចាយ)
| ប្រភពដើម | OriginatingPort | គោលដៅ | DestinationPort | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Master Server | ណាមួយ។ | Master DB Server | 5432 | ទាមទារ | To access database (If Master DB is ona separate server) |
From Master Server to Probe, Master DB, RDG Server
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Master Server | ណាមួយ។ | Probe Server Master DB Server RDG Server | 12007 | ទាមទារ | To access RSA service |
ពី Probe Server ទៅ Master Server (ការដំឡើងចែកចាយ)
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Master DB Server | ណាមួយ។ | Probe Server | 5432 | ទាមទារ | To access database |
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Probe Server | ណាមួយ។ | Master Server | ៥/៥ | ទាមទារ | ការចម្លងដើម្បីចូលប្រើសេវាកម្មមេ |
| Probe Server | ណាមួយ។ | Master Server | 5432 | ទាមទារ | To access database (If Master is an All-In- One or combinedwith Master DB) |
ពី Probe Server ទៅ Master DB (ការដំឡើងចែកចាយ)
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Master DB Server | ណាមួយ។ | Probe Server | 5432 | ទាមទារ | To access database (If Master DB is on separate server) |
From Primary Production Servers to Disaster Recovery Servers
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Production Servers | ណាមួយ។ | Disaster Recovery Servers | 22 | ទាមទារ | To sync up Brightlayer fileប្រព័ន្ធ |
From Disaster Recovery Servers to Primary Production Servers
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Disaster Recovery Servers | ណាមួយ។ | Production Servers | 22 | ទាមទារ | To sync up Brightlayer fileប្រព័ន្ធ |
From Probe Server to RDG Server
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| Probe Server | ណាមួយ។ | RDG Server | 443 | ស្រេចចិត្ត | MQTT Subscription |
From RDG Client to RDG Server
| ប្រភពដើម | Originating Port | គោលដៅ | ច្រកគោលដៅ | ទាមទារ / ស្រេចចិត្ត | គោលបំណង |
| RDG Client | ណាមួយ។ | RDG Server | 443 | ស្រេចចិត្ត | MQTT Subscription |
Intra-Application-Servers Network Connectivity Requirements
The ports listed below are designated for the Brightlayer application within each Brightlayer server. While these ports do not facilitate inbound or outbound traffic external to the server, it is essential to ensure they are exclusively reserved for Brightlayer application use.
| ប្រភេទម៉ាស៊ីនមេ | ច្រក | គោលបំណង |
| Master/Master DB/Probe Server | 9991 | VDCMON |
| Master Server | 9992 | SYSLOG |
| Master Server | 12001 | BI |
| Master Server | 12002 | OpenSearch |
| Master Server | 12006 | MQ broker |
| Master Server | 12008 | Master service |
| Master Server | 5433 | BI Migrate |
| Probe Server | 8086 | លំហូរចូល DB |
| Probe Server | 8087 | តេឡេក្រាហ្វ |
| RDG Server | 1442 | RDGS Communication |
| RDG Server | 1443 | RDGS MQTT broker |
| RDG Client | 8282 | RDGC Automation Connector in container |
| RDG Client | 8080 | RDGC Admin |
| RDG Client | 8181 | RDGC Automation Connector |
| RDG Client | 8081 | RDGC Management |
ការគ្រប់គ្រងសុវត្ថិភាព
Server administrators are system architects responsible for the overall design, implementation, and maintenance of a server. Security administrators are dedicated to performing information security functions for servers and other hosts, as well as networks.
It is recommended to enable Active-Directory integration for BLSS applications. With Active-Directory Integration enabled, the rights of security administrators and server administrators are completely separated. BLSS also supports SAML 2.0 integration which allow seamless end user experience in a Windows environment.
Best-Practices
The recommended best practices are critical to operating and maintaining a secure server.
To ensure the security of a server and the supporting network infrastructure, organizations should implement the following practices:
- Configuration/Change Control and Management
BLSS controls and manages the application via user groups, restrict the activities of all users by assigning “just-right” permissions to specific user groups.
- Contingency, Continuity of Operations, and Disaster Recovery Planning
By default, the BLSS application executes a backup script after midnight to create a full daily backup which contains the complete data and program backup of the entire system. Using this backup, an administrator can restore the entire application fully. It is vital that the backup directory, /opt/VDC.BACKUP, is kept on a different storage device than the main application data and programs to avoid single-point-failure catastrophes.
BLSS also offers Disaster recovery (DR) solution which allows an organization to quickly resume mission critical functions through the use of synchronized primary and secondary servers. If the primary server becomes unavailable, the server administrator will follow the processes outlined in the DR document to manually bring the secondary server online as a substitute system.
With the backup-and-restore continuity of operations plan and disaster recovery plan established in advance, it allows an organization or facility to maintain operations in the event of disruption.
Securing the Server Operating System
Many security issues can be eliminated if the operating system can be configured and maintained correctly.
Patch and Upgrade Operating System
For each BLSS version, there is a list of certified OS and there is another list of supported OS. It is highly recommended to keep the OS version within these 2 lists and apply the security patches with command such as the following:
dnf update –security
Hardening and Securely Configuring the OS
Direct root user login can be disabled with the following procedure: 
- បើក sshd_config file.
vim /etc/ssh/sshd_config - Change the yes to no of PermitRootLogin to disable direct root login. PermitRootLogin no
- Restart the sshd service to enable the changes.
systemctl restart sshd.service
Configure OS User Authentication
- Linux-PAM (Pluggable Authentication Modules) is recommended to enhance the server security. The advantage of using Linux-PAM is that organizations can systematically set up secure password management rules which used to control the requirement rules and length of passwords.
By establishing a password life mechanism, users are forced to change account passwords on a regular basis. It is worth noting that when an account becomes invalid due to the password is not changed in time, it may impact the expected behavior for BLSS if such a user is a system user, e.g. the vdc user.
Therefore, it is recommended to set up a mechanism to promptly remind users to change their passwords.
It is important to ensure that the application required user IDs, i.e. vdc, do not expire in the operating system. Immediate application failures can be expected should these user IDs become expired.
Securing the Server Software
Server Resource Constraints
BLSS applications are resource intensive. It is vital to well-define the system resource constraints to ensure the server can provide enough resources for the BLSS application, yet still capable of protecting the server against possible resource-abuse attacks.
តម្លៃ (អប្បបរមា)
| Value (minimum) | |||
| ធាតុ | BLSS | Postgres | Root/Any User |
| ស្នូល file ទំហំ | 0 | ||
| data seg size | គ្មានដែនកំណត់ | ||
| scheduling priority | 0 | ||
| file ទំហំ | គ្មានដែនកំណត់ | ||
| pending signals | 94054 | ||
| max locked memory | 8192 | ||
| max memory size | គ្មានដែនកំណត់ | ||
| បើក files | soft/nofile/65536 hard/nofile/៣២ | soft/nofile/65536 hard/nofile/៣២ | soft/nofile/65536 hard/nofile/៣២ |
| ទំហំបំពង់ | 8 | ||
| POSIX message queues | 819200 | ||
| real-time priority | 0 | ||
| stack size | soft/stack/10240 hard/stack/10240 | soft/stack/10240 hard/stack/10240 | soft/stack/10240 hard/stack/10240 |
| cpu time | គ្មានដែនកំណត់ | ||
| max user processes | soft/nproc/94054 hard/nproc/94054 | soft/nproc/94054 hard/nproc/94054 | soft/nproc/94054 hard/nproc/94054 |
| អង្គចងចាំនិម្មិត | គ្មានដែនកំណត់ | ||
| file សោ | គ្មានដែនកំណត់ | ||
| vm.max_map_count | 262144 | ||
| kernel.shmmax | 12355151872 | ||
| kernel.shmall | 6032789 | ||
ឯកសារ/ធនធាន
![]() |
EATON Brightlayer Data Centers Software [pdf] ការណែនាំអ្នកប្រើប្រាស់ Brightlayer Data Centers Software, Data Centers Software, Software |

