Skip to main content

Access

Q: Can aBMC be accessed remotely?​

A: Yes. aBMC is an independent out-of-band management unit. When the device is powered on and the management network port is reachable, the web management interface and the Redfish/IPMI interfaces support remote access, enabling operations such as remote power on/off, KVM console, hardware monitoring, and virtual media. Access over the local area network: in the same internal network, when your computer can reach the aBMC management network, enter the aBMC internal IP address to access it directly.

  • Cross-region access over the Internet: aBMC service ports cannot be exposed directly to the public network. There are two compliant solutions:
  1. Connect to the device's local area network through a VPN, and then access aBMC;
  2. Deploy a cloud proxy server, with the on-site aBMC establishing an outbound long-lived connection, so that remote operations over the Internet rely on the proxy. Do not expose aBMC service ports directly to the public network; this poses a high-privilege security risk. For remote operations across the Internet, prefer the VPN or cloud proxy solution.

Q: aBMC becomes inaccessible while the server is running?​

A: First distinguish between two failure scenarios when troubleshooting:

  • Scenario 1: The aBMC management IP cannot be pinged Check the physical link and Layer 2 / Layer 3 networking first: the network cable, switch port status, IP subnet, VLAN assignment, and access control policies.

  • Scenario 2: The aBMC IP can be pinged, but the web management interface cannot be accessed

    1. If a monitor can be attached on site for troubleshooting A monitor that shows the terminal / system interface normally means the underlying operating system is running. Run a local access test: https://127.0.0.1 1.1 The aBMC page opens properly on the local machine: the aBMC services are running normally, and the fault lies in the network between the operations terminal and the device. Check subnet reachability, switch ACL policies, VPN, proxies, etc.; 1.2 The aBMC page cannot be accessed on the local machine either: the aBMC service is faulty. Troubleshoot in the following order 1.2.1 Check the service status systemctl status aBMC 1.2.2 Service status is active (running): check the service configuration cat /etc/aBMC/config.ini 1.2.2.1 Confirm the enabled access protocol (HTTPS by default) 1.2.2.2 Confirm whether the web listening port has been changed 1.2.2.3 Confirm the Redis communication port configuration 1.2.3 If the service is faulty or not started: use the logs to find out why the service failed to start.

    2. If no monitor can be attached on site, or the monitor is black, garbled, or shows no output 2.1 Use a console debug cable (USB-to-RJ45 serial, baud rate 115200) to connect to the serial terminal and log in to the command-line system; 2.2 After logging in successfully, follow step 1.2 above to troubleshoot the aBMC service.

    3. If neither the monitor terminal nor the console login responds, the BMC program is most likely hung or the system has crashed. Common causes: 3.1 A user business process running as root triggered a kernel fault 3.1.1 Check the system logs and kernel logs first to locate the application bug; 3.1.2 If a kernel crash (Oops/panic) occurred, the logs often cannot be written to disk. Keep capturing serial console logs while reproducing the issue so developers can locate the root cause.

      3.2 The BMC system partition is full (a frequent customer issue) This is usually caused by large amounts of debug logs and temporary files generated by customer-deployed services that are not cleaned up regularly; the exhausted disk then causes system malfunctions.

      3.3 An improper /etc/fstab mount configuration blocks system startup If /etc/fstab is configured to mount a disk automatically at boot without the nofail parameter, any mount failure leaves the system waiting until timeout and stuck during startup. Typical scenarios that trigger this failure include: 3.3.1 Mismatched resource identifiers: a disk UUID hardcoded during development does not match the actual production environment and is not corrected before deployment. 3.3.2 Underlying hardware failure: the disk suffers a physical fault, the kernel gets no response from the device, and the mount request blocks indefinitely. 3.3.3 Device name drift: a mount that relies on the device path (such as /dev/sda1) fails because the kernel enumeration order changes after a reboot. 3.3.4 Unprepared storage media: a newly added disk was never formatted or partitioned, so the system cannot find a valid file system structure when mounting.

Q: How do I use Redis on aBMC?​

A: Redis 7.2 is built into the aBMC system by default. If your services need Redis, use the bundled instance directly; there is no need to install and deploy another one. To customize the Redis port, database number, or access password: 1. Modify the Redis-related parameters in the configuration file /etc/aBMC/config.ini; 2. Restart the aBMC service for the new configuration to take effect.

Note: Do not manually install or start additional Redis processes, to avoid system issues such as port conflicts and resource contention.