[{"data":1,"prerenderedAt":189},["ShallowReactive",2],{"blog-all-en":3},[4,27,42,56,72,86,101,117,134,150,164,177],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"date":11,"category":12,"archives":13,"author":14,"_type":18,"_id":19,"_source":20,"_file":21,"_stem":22,"_extension":23,"coverImage":24,"plainText":25,"authorNames":26},"\u002Fen\u002Fblogs\u002Fhi3093-dev-board-i2c","blogs",false,"","Sensor Function Adaptation and Debugging for the Hi3093 Development Board (openubmc.cn)","This article describes the common debugging and adaptation methods for adapting I2C sensors based on the .","2025\u002F08\u002F25","case","2025-08",[15],{"name":16,"description":17},"郭馨","openUBMC project team leader at Kunlun Technology (Beijing) Co., Ltd.","markdown","content:en:blogs:hi3093-dev-board-i2c.md","content","en\u002Fblogs\u002Fhi3093-dev-board-i2c.md","en\u002Fblogs\u002Fhi3093-dev-board-i2c","md","\u002Fcategory\u002Fblog\u002Fhi3093-dev-board-i2c\u002FHi3093_board-en.png","Sensor Function Adaptation and Debugging for the Hi3093 Development Board (openubmc.cn) Introduction This article describes the common debugging and adaptation methods for adapting I2C sensors based on the  MYC-LHi3093 development board . Material Preparation Hi3093 core board Power adapter of the core board Network cable Type-C USB cable Jumper wires Expansion board (with the LM75 sensor) I2C Tool Application Currently, openUBMC 2506 version does not support I2C tools to perform i2cdetect and i2ctransfer operations. This article references the post  Self-made I2C Debugging Tool  (i2cdetect and i2ctransfer for openUBMC) and uploads i2cdetect and i2ctransfer to the \u002Fdata directory using SCP. Sensor Debugging According to the hardware schematic diagram of the development board, connect the BMC I2C bus through pin headers on the development board to the external debugging board through jumper wires. The following figure shows the connections of the power supply, GND, SDA, and SCL on I2C9.  It is known that I2C9 is mounted with LM75(0x48), LM75(0x4f), and PCA9546(0x70), and PCA9546 channel0 is connected to LM75(0x49). Run the  .\u002Fi2cdetect 9  command in the \u002Fdata directory. It shows that preceding devices have been detected correctly.  Run the  .\u002Fi2ctransfer 9  w2@0x70 0x01 command to enable PCA9546 channel0. Then run the  .\u002Fi2cdetect 9  command. LM75(0x49) can be detected now.  The lower four bits of the PCA9546 control register correspond to four channels. You can use i2ctransfer to enable a specified channel and check whether the I2C device connected to the channel is normal.  You can run the following commands to enable the four channels of PCA9546 independently. Writing 0x00 to PCA9546 can disable all channels. Channel ID Command Channel 0 i2ctransfer \u003Ci2cbus> w1@0x70 0x01 Channel 1 i2ctransfer \u003Ci2cbus> w1@0x70 0x02 Channel 2 i2ctransfer \u003Ci2cbus> w1@0x70 0x04 Channel 3 i2ctransfer \u003Ci2cbus> w1@0x70 0x08 Sensor Configuration The following uses the board name openUBMC as an example. Configure the  vpd\u002Fvendor\u002FHuawei\u002FServer\u002FKunpeng\u002FopenUBMC\u002Froot.sr  file as follows: Add I2c_9 to ManagementTopology > Anchor > Buses. Add the LM75 sensor chip and Connectors configuration under I2c_9. Within the Connector section, configure Connector_DemoCard to indicate that PCA9546 is located in the CSR of the downstream component DemoCard. Under Objects, configure the LM75 object, Entity, and ThresholdSensor. Since this sensor obtains values through periodic polling, Scanner must also be configured. Also under Objects, configure Connector_DemoCard. An IdentifyMode value of 2 indicates that the downstream component is not a Tianchi component. Non-Tianchi components utilize three configuration items (Bom, Id, and AuxID) to determine the downstream component CSR name, which is formatted as: Bom_Id_AuxId.csr. In this example, the downstream component CSR name is 14100513_DemoCard_0.sr. The I2c_9 configuration within Buses indicates that the bus connecting to the downstream board is I2C9. Note that Position of any two connectors within the same CSR file cannot be duplicated. {\n     \"ManagementTopology\" : {\n         \"Anchor\" : {\n             \"Buses\" : [\n                 \"I2c_1\" ,\n                 \"I2c_2\" ,\n                 \"I2c_3\" ,\n                 \"I2c_4\" ,\n                 \"I2c_5\" ,\n                 \"I2c_6\" ,\n                 \"I2c_7\" ,\n                 \"I2c_8\" ,\n                 \"I2c_9\" ,\n                 \"I2c_11\"\n             ]\n         },\n         \"I2c_9\" : {\n             \"Chips\" : [\n                 \"Lm75_1\" ,\n                 \"Lm75_2\"\n             ],\n             \"Connectors\" : [\n                 \"Connector_DemoCard\"\n             ]\n        }\n     },\n     \"Objects\" : {\n         \"I2c_9\" : {\n             \"Id\" :  9\n         },\n         \"Lm75_1\" : {\n             \"OffsetWidth\" :  1 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  144\n         },\n         \"Lm75_2\" : {\n             \"OffsetWidth\" :  1 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  158\n         },\n         \"Scanner_InletLM75\" : {\n             \"Chip\" :  \"#\u002FLm75_1\" ,\n             \"Size\" :  1 ,\n             \"Offset\" :  0 ,\n             \"Mask\" :  255 ,\n             \"Period\" :  1000\n         },\n         \"Scanner_OutletLM75\" : {\n             \"Chip\" :  \"#\u002FLm75_2\" ,\n             \"Size\" :  1 ,\n             \"Offset\" :  0 ,\n             \"Mask\" :  255 ,\n             \"Period\" :  1000\n         },\n         \"ThresholdSensor_InletTemp\" : {\n             \"AssertMask\" :  516 ,\n             \"DeassertMask\" :  516 ,\n             \"ReadingMask\" :  4626 ,\n             \"Linearization\" :  0 ,\n             \"M\" :  100 ,\n             \"RBExp\" :  224 ,\n             \"UpperCritical\" :  60 ,\n             \"LowerCritical\" :  5 ,\n             \"PositiveHysteresis\" :  2 ,\n             \"NegativeHysteresis\" :  2 ,\n             \"OwnerId\" :  32 ,\n             \"OwnerLun\" :  0 ,\n             \"EntityId\" :  \"\u003C=\u002FEntity_InletTemp.Id\" ,\n             \"EntityInstance\" :  \"\u003C=\u002FEntity_InletTemp.Instance\" ,\n             \"Initialization\" :  127 ,\n             \"Capabilities\" :  104 ,\n             \"SensorType\" :  1 ,\n             \"ReadingType\" :  1 ,\n             \"SensorName\" :  \"Inlet_Temp\" ,\n             \"Unit\" :  128 ,\n             \"BaseUnit\" :  1 ,\n             \"ModifierUnit\" :  0 ,\n             \"Analog\" :  1 ,\n             \"MaximumReading\" :  127 ,\n             \"MinimumReading\" :  128 ,\n             \"Reading\" :  \"\u003C=\u002FScanner_InletLM75.Value\"\n         },\n         \"Entity_InletTemp\" : {\n             \"Id\" :  99 ,\n             \"Name\" :  \"Inlet_Temp\" ,\n             \"PowerState\" :  1 ,\n             \"Presence\" :  1 ,\n             \"Instance\" :  96\n         },\n         \"ThresholdSensor_OutletTemp\" : {\n             \"AssertMask\" :  29312 ,\n             \"DeassertMask\" :  29312 ,\n             \"ReadingMask\" :  6168 ,\n             \"Linearization\" :  0 ,\n             \"M\" :  100 ,\n             \"RBExp\" :  224 ,\n             \"UpperCritical\" :  65 ,\n             \"UpperNoncritical\" :  50 ,\n             \"PositiveHysteresis\" :  2 ,\n             \"NegativeHysteresis\" :  2 ,\n             \"OwnerId\" :  32 ,\n             \"OwnerLun\" :  0 ,\n             \"EntityId\" :  \"\u003C=\u002FEntity_OutletTemp.Id\" ,\n             \"EntityInstance\" :  \"\u003C=\u002FEntity_OutletTemp.Instance\" ,\n             \"Initialization\" :  127 ,\n             \"Capabilities\" :  104 ,\n             \"SensorType\" :  1 ,\n             \"ReadingType\" :  1 ,\n             \"SensorName\" :  \"Outlet_Temp\" ,\n             \"Unit\" :  128 ,\n             \"BaseUnit\" :  1 ,\n             \"ModifierUnit\" :  0 ,\n             \"Analog\" :  1 ,\n             \"MaximumReading\" :  127 ,\n             \"MinimumReading\" :  128 ,\n             \"Reading\" :  \"\u003C=\u002FScanner_OutletLM75.Value\"\n         },\n         \"Entity_OutletTemp\" : {\n             \"Id\" :  99 ,\n             \"Name\" :  \"OutletTemp\" ,\n             \"PowerState\" :  1 ,\n             \"Presence\" :  1 ,\n             \"Instance\" :  97\n         },\n         \"Connector_DemoCard\" : {\n             \"Bom\" :  \"14100513\" ,\n             \"Slot\" :  2 ,\n             \"Position\" :  4 ,\n             \"Presence\" :  1 ,\n             \"Id\" :  \"DemoCard\" ,\n             \"AuxId\" :  \"0\" ,\n             \"Buses\" : [\n                 \"I2c_9\"\n             ],\n             \"SystemId\" :  1 ,\n             \"ManagerId\" :  \"1\" ,\n             \"ChassisId\" :  \"1\" ,\n             \"IdentifyMode\" :  2\n         }\n     }\n }\n As a CSR file is added, you need to add the path of the  14100513_DemoCard_0.sr  file to  vpd\u002Fvendor\u002FHuawei\u002FServer\u002FKunpeng\u002FopenUBMC\u002Fprofile.txt . In this example, the configuration is as follows: Huawei\u002FServer\u002FKunpeng\u002FopenUBMC\u002FPSR\u002F14100513_DemoCard_0.sr\n PCA9546 can be configured as Pca9545. Note that  Objects > I2cMux_Pca9545_i2c9_chan0 needs to be configured  with  ChannelId . Configure  14100513_DemoCard_0.sr  as follows: {\n     \"FormatVersion\" :  \"3.00\" ,\n     \"DataVersion\" :  \"3.00\" ,\n     \"ManagementTopology\" : {\n         \"Anchor\" : {\n             \"Buses\" : [\n                 \"I2c_9\"\n              ]\n         },\n         \"I2c_9\" : {\n             \"Chips\" : [\n                 \"Pca9545_i2c9_chip\"\n             ]\n         },\n         \"Pca9545_i2c9_chip\" : {\n             \"Buses\" : [\n                 \"I2cMux_Pca9545_i2c9_chan0\"\n             ]\n         },\n         \"I2cMux_Pca9545_i2c9_chan0\" : {\n             \"Chips\" : [\n                 \"Lm75_3\"\n             ]\n         }\n     },\n     \"Objects\" : {\n         \"Pca9545_i2c9_chip\" : {\n             \"OffsetWidth\" :  0 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  224 ,\n             \"WriteTmout\" :  0 ,\n             \"ReadTmout\" :  0 ,\n             \"HealthStatus\" :  0\n         },\n         \"I2cMux_Pca9545_i2c9_chan0\" : {\n             \"ChannelId\" :  0\n         },\n         \"Lm75_3\" : {\n             \"OffsetWidth\" :  1 ,\n             \"AddrWidth\" :  1 ,\n             \"Address\" :  146\n         },\n         \"Scanner_NicLM75\" : {\n             \"Chip\" :  \"#\u002FLm75_3\" ,\n             \"Size\" :  1 ,\n             \"Offset\" :  0 ,\n             \"Mask\" :  255 ,\n             \"Period\" :  1000\n         },\n         \"ThresholdSensor_DemoTemp\" : {\n             \"AssertMask\" :  31381 ,\n             \"DeassertMask\" :  31381 ,\n             \"ReadingMask\" :  16191 ,\n             \"Linearization\" :  0 ,\n             \"M\" :  100 ,\n             \"RBExp\" :  224 ,\n             \"UpperNonrecoverable\" :  70 ,\n             \"UpperCritical\" :  65 ,\n             \"UpperNoncritical\" :  55 ,\n             \"LowerNonrecoverable\" :  0 ,\n             \"LowerCritical\" :  5 ,\n             \"LowerNoncritical\" :  10 ,\n             \"PositiveHysteresis\" :  2 ,\n             \"NegativeHysteresis\" :  2 ,\n             \"OwnerId\" :  32 ,\n             \"OwnerLun\" :  0 ,\n             \"EntityId\" :  \"\u003C=\u002FEntity_NicTemp.Id\" ,\n             \"EntityInstance\" :  \"\u003C=\u002FEntity_NicTemp.Instance\" ,\n             \"Initialization\" :  127 ,\n             \"Capabilities\" :  104 ,\n             \"SensorType\" :  1 ,\n             \"ReadingType\" :  1 ,\n             \"SensorName\" :  \"Nic_Temp\" ,\n             \"Unit\" :  128 ,\n             \"BaseUnit\" :  1 ,\n             \"ModifierUnit\" :  0 ,\n             \"Analog\" :  1 ,\n             \"MaximumReading\" :  127 ,\n             \"MinimumReading\" :  128 ,\n             \"Reading\" :  \"\u003C=\u002FScanner_NicLM75.Value\"\n         },\n         \"Entity_NicTemp\" : {\n             \"Id\" :  9 ,\n             \"Name\" :  \"Nic_Temp\" ,\n             \"PowerState\" :  1 ,\n             \"Presence\" :  1 ,\n             \"Instance\" :  98\n         }\n     }\n }\n Sensor WebUI After the preceding configurations are complete, the sensor WebUI is properly displayed. html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[16],{"_path":28,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":29,"description":30,"date":31,"category":12,"author":32,"_type":18,"_id":36,"_source":20,"_file":37,"_stem":38,"_extension":23,"coverImage":39,"plainText":40,"authorNames":41},"\u002Fen\u002Fblogs\u002F20250815","Business Practice | PowerLeader Computer's Smart UART HMI Based on openUBMC","This article explores how PowerLeader Computer System Co., Ltd. successfully implemented an in-house developed Human-Machine Interface (HMI) solution leveraging the openUBMC framework. You will know the technical architecture, design principles, and implementation strategies behind PowerLeader's smart UART HMI. As a critical component within the openUBMC ecosystem, this solution demonstrates advanced engineering practices and serves as a practical guide for developers.","2025\u002F08\u002F15",[33],{"name":34,"description":35},"邱豪","System engineer and BMC R&D director at PowerLeader, who has been deeply engaged in the design and development of openUBMC projects.","content:en:blogs:20250815.md","en\u002Fblogs\u002F20250815.md","en\u002Fblogs\u002F20250815","\u002Fcategory\u002Fblog\u002F20250815\u002Fimg01.webp","Business Practice | PowerLeader Computer's Smart UART HMI Based on openUBMC This article explores how PowerLeader Computer System Co., Ltd. successfully implemented an in-house developed Human-Machine Interface (HMI) solution leveraging the openUBMC framework. You will know the technical architecture, design principles, and implementation strategies behind PowerLeader's smart UART HMI. As a critical component within the openUBMC ecosystem, this solution demonstrates advanced engineering practices and serves as a practical guide for developers. Smart UART HMI Targeting Latency-Critical Edge Computing A smart UART HMI provides a lightweight and highly reliable local management portal for server BMCs. It is especially effective in latency-critical edge computing scenarios. As server applications expand into domains like edge computing, legacy remote management systems such as Intelligent Platform Management Interfaces (IPMIs) and web interfaces fall short in meeting rapid troubleshooting needs. On-site visual monitoring is essential when network connections fail or remote management tools become unavailable. It allows administrators to perform emergency operations directly through a local display interface, thereby improving overall system resilience.  In addition, edge computing nodes are deployed in remote or physically isolated environments. A local monitoring display minimizes reliance on remote management systems and shortens response time for troubleshooting. Local, instant visual alerting is essential for mitigating the risk of system outages, particularly during hardware faults such as fan failures or overheating where remote management latency is a concern.  The power-efficient design of the smart UART HMI outperforms conventional display terminals, effectively reducing long-term O&M costs. The smart UART HMI offers a cost-effective hardware solution with seamless integration capabilities, making it ideal for mass production scenarios. The smart UART HMI supports local control capabilities, allowing users to directly manage the server's BMC via the touchscreen, such as restarting the server, adjusting fan policies, or switching power modes. On-site O&M flexibility is thus significantly enhanced.  In scenarios with unstable network connections, administrators can leverage the smart UART HMI to access BMC or system logs and back up logs in real-time, enabling efficient troubleshooting and post-incident analysis.  PowerLeader's smart UART HMI integrates core modules to offer comprehensive monitoring and control capabilities, such as serial port redirection, log backup, device management, real-time system status monitoring, and alert supervision. The implementation of the smart UART HMI has significantly enhanced the real-time responsiveness, operational efficiency, and intelligent capabilities. Maintenance teams in manufacturing and data center environments now benefit from faster, smarter, and more responsive server management.  Implementation of the Smart UART HMI As a typical component in BMC management systems, the smart UART HMI requires the integration of cross-domain technical capabilities, including BMC software development, hardware design, underlying protocols (such as I2C and serial), and terminal desktop application development.  Hardware Design By redesigning the BMC's low-speed bus interface, a set of I2C lines is routed to the chassis exterior, enabling direct communication between the BMC and the smart UART HMI. In addition, the smart UART HMI is mounted onto the chassis using snap-in mechanisms. You can detach or change it when needed. By integrating an I2C-to-serial conversion module on the expansion board, the system emulates specific serial protocols over I2C to enable communication between the BMC and the smart UART HMI.  Software Design The openUBMC component is introduced to implement the functions of the smart UART HMI. By leveraging the resource collaboration interface of openUBMC, PowerLeader's smart UART HMI components can easily obtain the asset information, network information, and system event logs (SELs) of the server, and send the information to the smart UART HMI via the serial port. The openUBMC component framework monitors and polls the overall server status, component status, and temperature data. It accurately transmits the server's health information to the smart UART HMI, enabling visual alerting. Serial commands issued by the smart UART HMI are routed to this component, which parses the incoming instructions and maps them to corresponding resource coordination interface methods. This enables interactive control operations such as system power on\u002Foff, BMC reboot, and fan mode configuration.  Serial Port Redirection The PowerLeader's smart UART HMI supports serial port redirection. BMC serial port logs are transmitted to the smart UART HMI, significantly enhancing real-time on-site O&M efficiency by accelerating fault diagnosis processes. Building on this technical foundation, this innovative mechanism is designed to periodically back up serial log data, delivering \"black box\" reliability for server diagnostics and data protection. This function ensures critical operational data persistence even under critical failure scenarios like power outages or network disruptions. The following describes how to implement the logic process of serial port redirection. This is used as a technical reference for developer community members.  Wrap-up PowerLeader Computing is an active contributor to the openUBMC community, leveraging its proprietary component to rapidly implement innovative designs that showcase the true potential of openUBMC's open-source ecosystem. PowerLeader Computing is committed to actively sharing industry best practices within the developer community, fostering collaborative growth alongside fellow developers. We aim to drive innovation in the BMC domain by collaborating with a growing number of community developers, working together to advance the openUBMC ecosystem. Follow openUBMC Community official website:  https:\u002F\u002Fwww.openubmc.cn Code repository address:  https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fnetwork_adapter",[34],{"_path":43,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":44,"description":45,"date":46,"category":12,"archives":13,"author":47,"_type":18,"_id":51,"_source":20,"_file":52,"_stem":53,"_extension":23,"plainText":54,"authorNames":55},"\u002Fen\u002Fblogs\u002Fpki-cert-service-guide","PKI Practice: Building a Complete Certificate Service System (openubmc.cn)","This tutorial provides a hands-on guide based on EJBCA, designed to compliance the CA\u002FRA workflow in a demo environment. It walks through key operational steps including certificate profile creation, end entity profile configuration, approval process activation, and RA certificate issuance and download. This tutorial focuses on practical execution, making it ideal for experiments, proof-of-concept (PoC) setups, or internal demonstrations. Please note that this tutorial does not cover production-level security hardening or compliance requirements.","2025\u002F08\u002F11",[48],{"name":49,"description":50},"沈威","Active openUBMC community developer, who is eager to explore and share new ideas on BMC and open source firmware.","content:en:blogs:pki-cert-service-guide.md","en\u002Fblogs\u002Fpki-cert-service-guide.md","en\u002Fblogs\u002Fpki-cert-service-guide","PKI Practice: Building a Complete Certificate Service System (openubmc.cn) 1. Introduction This tutorial provides a hands-on guide based on EJBCA, designed to compliance the CA\u002FRA workflow in a demo environment. It walks through key operational steps including certificate profile creation, end entity profile configuration, approval process activation, and RA certificate issuance and download. This tutorial focuses on practical execution, making it ideal for experiments, proof-of-concept (PoC) setups, or internal demonstrations. Please note that this tutorial does not cover production-level security hardening or compliance requirements. Objective : Master the core operations of EJBCA and complete the entire process from template configuration to certificate issuance.  2. Terms RA : registers end entities and reviews their identities. Certificate profile : presets key usages, SANs, and validity periods.  3. Experiment Environment and Prerequisites OS: Ubuntu 20.04 Server (installed offline) Software to be preset: Docker and docker-compose (apt package)  4. EJBCA Docker Deployment and Persistence This chapter explains how to deploy the EJBCA certificate service using Docker, with a focus on ensuring persistent data storage on a dedicated drive. This setup helps prevent data loss in the event of container or virtual machine restarts. Key topics cover configuring data persistence of the internal database (H2 by default), running containers using docke-compose, and setting up remote access through appropriate configuration parameters. 4.1 Environment Setup and Proxy Configuration Some EJBCA Docker images (such as  keyfactor\u002Fejbca-ce ) need to be pulled from the public network. To ensure environment availability, configure the HTTP\u002FHTTPS proxy of Docker Daemon. Step 1 Configure the systemd proxy. Docker Daemon runs under the systemd management. You need to add the following configurations to inherit the system proxy. sudo  mkdir  -p  \u002Fetc\u002Fsystemd\u002Fsystem\u002Fdocker.service.d\n sudo  nano  \u002Fetc\u002Fsystemd\u002Fsystem\u002Fdocker.service.d\u002Fhttp-proxy.conf\n Content: [Service]\n Environment=\"HTTP_PROXY=http:\u002F\u002F192.168.xxx.xxx:7890\"\n Environment=\"HTTPS_PROXY=http:\u002F\u002F192.168.xxx.xxx:7890\"\n Environment=\"NO_PROXY=127.0.0.1,localhost,192.168.13.119\" \u002F\u002F Change the IP address to the host IP address of your virtual machine.\n Step 2 Reload and restart Docker. sudo  systemctl  daemon-reload\n sudo  systemctl  restart  docker\n sudo  systemctl  status  docker  --no-pager  -l\n If the output contains  Active: active (running) , the proxy configuration takes effect. Step 3 Check whether the proxy has taken effect. docker  info  |  grep  -i  proxy\n If the following information is displayed, the proxy has taken effect: HTTP  Proxy:  http:\u002F\u002F192.168.xxx.xxx:7890\n HTTPS  Proxy:  http:\u002F\u002F192.168.xxx.xxx:7890\n 4.2 Data Persistence Configuration Save the H2 database in files, and set the database as follows:  jdbc:h2:\u002Fmnt\u002Fpersistent\u002Fejbcadb;DB_CLOSE_DELAY=-1 . Host mount path:  \u002Fopt\u002Fejbca-data:\u002Fmnt\u002Fpersistent Do not use  --rm  to start the container. Set the host permission:  chown -R 10001:10001 \u002Fopt\u002Fejbca-data 📌 Note: In a formal environment, it is recommended to use external database, such as PostgreSQL or MySQL, to improve system reliability and disaster recovery capabilities. Deployment Using Docker Compose Create a directory structure. mkdir  -p  \u002Fopt\u002Fejbca-compose\n cd  \u002Fopt\u002Fejbca-compose\n mkdir  -p  \u002Fopt\u002Fejbca-data\n chown  -R  10001:10001  \u002Fopt\u002Fejbca-data\n Create and compile  docker-compose.yml  in the current directory. version :  \"3.3\"  # Use Docker Compose v3.3.\n \n services :\n   ejbca :  # Define the service ejbca.\n     image :  keyfactor\u002Fejbca-ce:latest  # Use the latest EJBCA image (community-edition) provided by Keyfactor.\n     container_name :  ejbca  # Set the container name to ejbca.\n     hostname :  myejbca.test.local  # Set the internal host name of the container, which affects fields such as CN in the certificate.\n \n     environment :  # Set environment variables to configure the EJBCA startup behavior.\n       -  DATABASE_JDBC_URL=jdbc:h2:\u002Fmnt\u002Fpersistent\u002Fejbcadb;DB_CLOSE_DELAY=-1  # Use the embedded H2 database. The data is stored in the mount directory.\n       -  TLS_SETUP_ENABLED=true  # Enable automatic TLS settings (for HTTPS access).\n       -  SMTP_DESTINATION=192.168.xx.xx  # Set the SMTP email server address (for sending notification emails).\n       -  SMTP_DESTINATION_PORT=25  # Set SMTP service port. The default value is 25. (Encryption is disabled.)\n       -  SMTP_FROM=ejbca@example.local  # Set the email sender address.\n       -  SMTP_TLS_ENABLED=false  # Do not enable STARTTLS for SMTP.\n       -  SMTP_SSL_ENABLED=false  # Do not enable SSL\u002FTLS encryption for SMTP.\n \n     ports :  # Map the container port to the host.\n       -  \"80:8080\"  # Map the host port 80 to the container port 8080 (HTTP).\n       -  \"443:8443\"  # Map the host port 443 to the container port 8443 (HTTPS).\n \n     volumes :  # Mount the data volume to map the directory in the container to the host for data persistence.\n       -  \u002Fopt\u002Fejbca-data:\u002Fmnt\u002Fpersistent  # Mount the \u002Fopt\u002Fejbca-data directory on the host to the container to persist data such as the database.\n \n     restart :  unless-stopped  # If the container exits abnormally, the container is automatically restarted unless you manually stop the container.\n Start the container service.： docker-compose  up  -d\n docker-compose  logs  -f\n ⚙️ You can use Compose to easily manage configuration versions, facilitating team collaboration and version recovery. 4.4 Remote Access Configuration Set the container's hostname in advance, which affects CN of the TLS certificate. hostname :  myejbca.test.local\n 4.5 Certificate Trust Management After downloading the super administrator certificate ·, double-click to import it. 4.6 Login Process Summary Run  docker-compose logs -f  to search for SuperAdmin URL and one-time password in the container logs. ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *                                                                                                     *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *    URL:      https:\u002F\u002Fmyejbca.test.local:443\u002Fejbca\u002Fra\u002Fenrollwithusername.xhtml ? username = superadmin  *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *    Password: urAMy0He5c\u002FhHy+DYyDFNy4E                                                                *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *                                                                                                     *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *  Once the P12 is downloaded, use  \"urAMy0He5c\u002FhHy+DYyDFNy4E\"  to import it.                            *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  *                                                                                                     *\n ejbca     |  2025-08-05  09:11:31,656+0000  INFO   [\u002Fopt\u002Fkeyfactor\u002Fbin\u002Fstart.sh] ( process:1 )  ******************************************************************************************************\n Access the URL, enter the password, set the export password, and download the  .p12  certificate. Import the certificate and access  https:\u002F\u002Fmyejbca.test.local\u002Fejbca\u002Fadminweb . If the system displays a message indicating that the client certificate is not provided, check whether the certificate is successfully imported, the proxy is disabled, and the domain name is correctly resolved. ✅ So far, the EJBCA deployment, persistence, and management login process is completed. Important Notes (Must Be Followed) ✅  You must  add  myejbca.test.local  to the hosts file or set up a local DNS server. Otherwise, the browser may fail to resolve the domain name.  \n✅ The default algorithm for the super administrator certificate is DILITHIUM2, which may vary by version. However, Windows probably cannot recognize DILITHIUM2. To ensure compatibility, it is advised to switch the algorithm to RSA 4096.  \n✅  No proxy should be enabled . Otherwise, EJBCA may fail to correctly process client certificate authentication.  \n✅  Ensure that the Windows\u002FmacOS\u002FLinux certificate is correctly imported  to avoid the \" No client certificate was presented \" error.  \n✅  It is recommended that you use the Chrome browser in Incognito mode for the first time  to avoid the \" No client certificate was presented \" error caused by cache problems.  5. Initial CA Creation and Certificate Level Setup 5.1 Managing Certificate Profiles Log in to the EJBCA management console. Choose  CA Functions > Certificate Profiles . 5.2 Creating a Certificate Profile Method 1: Cloning an Existing Profile Find an appropriate profile (for example,  ENDUSER ) in the list. Click  Clone , enter the new name, and save the profile. Method 2: Manually Creating a Profile Click  Add  and enter the name. The editing page is displayed. Set necessary information as required, including  Key Usage ,  Extended Key Usage , validity period, and Subject DN. Save the settings and return to the list for check. 5.3 Creating a Crypto Token Choose  CA Functions → Crypto Tokens 。 Click  Create new  and enter the following information: Name ：Enter the name of your crypto token. Type ：Select  SOFT 。 Auto-activation(Optional) ：If selected, the crypto token can be automatically activated. Allow export of private keys ：Select  Allow  if you want to export the private key. Authentication Code ：Enter the authentication code and confirm it.  dd if=\u002Fdev\u002Frandom bs=1 count=128 2>&1| sha256sum | awk '{print $1} Save the settings and ensure that the status is  Active  in the list。 5.4 Generating a Key Pair Access the x Crypto Token  details page. Enter the key name, for example,  signKey , in  Crypto Token currently does not contain any key pairs . Select a key algorithm, for example,  RSA 4096 . Click  Generate new key pair . Note : The default profile cannot be modified. You need to clone it before creating a new one. 5.5 Creating a CA Choose  CA Functions → Certification Authorities 。 The default  ManagementCA (Active)  is displayed in the list on the top.  You do not need to select it 。 Scroll to the  Add CA  area at the bottom of the page.\n Enter the new CA name, for example,  DemoCA , in the text box. Click  Create…  on the right. The CA configuration wizard is displayed. Enter necessary fields on the  Create CA  page. Click  Create  at the bottom to save the CA. If the configuration is correct, the CA list is displayed and the  DemoSubCA (Active)  status is displayed. (Optional) If you want to manually upload the certificate issued by the root CA, select the new CA in the list and select  Import CA certificate…  to upload the chain file. The intermediate CA is created. You can use it to issue end-entity certificates. 5.6 (Example) Creating a Root CA 1️⃣ CA type and key configuration Parameter Description CA Type ✅  X.509 CA ; Standard X.509 CA Crypto Token ✅ Select the created  Crypto Token , for example,  demoCrypto . Signing Algorithm ✅  SHA256WithRSA ; Secure signature algorithm Alternative Signing Algorithm ❌  None ; No backup signature algorithm is required. Key Sequence Format ✅  Numeric (0-9) ; Serial number of the CA certificate Key Sequence ✅  00000  ; Initial serial number, which can be changed. Description ✅ Root CA description, including the purpose and management unit.  2️⃣ Certificate policies (Directives) Parameter Description Enforce unique public keys ✅ Enforces the public key to be unique. Enforce key renewal ❌ Not required for the root CA. Enforce unique DN ✅ Ensures  DN  uniqueness (applicable to small-scale CAs). Enforce unique Subject DN SerialNumber ❌ Applicable only to large-scale CAs (not required for CAs with fewer than 20 certificates). Use Certificate Request History ❌ Records certificate request history (not required for the root CA). Use User Storage ✅ Stores user information. Use Certificate Storage ✅ Stores issued certificates.  3️⃣ CA certificate data Parameter Description Subject DN ✅  CN=test EnterpriseIT Root CA Signed By ✅  Self Signed ; Root CA must be self-signed. Certificate Profile ✅  ITROOTCA_profile ; Select the cloned root CA.   This parameter can be modified. Validity ✅  20y ; The certificate validity period is 20 years. Subject Alternative Name ❌ Not required for the root CA. Certificate Policy OID ❌ (Optional) By default, this parameter is left blank. Use UTF-8 in policy notice text ✅ Ensures international character support. PrintableString encoding in DN ❌ Do not select this parameter to avoid affecting internationalization. LDAP DN order ✅ Ensures that  DN  is sorted according to the LDAP specifications. Serial Number Octet Size ✅  20 ; 20-byte is recommended to ensure uniqueness. Name Constraints, Permitted ❌ Disabled for the root CA. Leave this parameter empty. Name Constraints, Excluded ❌ Disabled for the root CA. Leave this parameter empty.  4️⃣ CRL configuration Parameter Description Microsoft CA Compatibility Mode ❌ Disabled for the root CA. This parameter is applicable only to Windows AD CS. Authority Key ID ✅ Enabled and marked as  Critical . This parameter is used to identify the CRL issuer. It is recommended that it be enabled for the root CA and intermediate CA. CRL Number ✅ Enabled and marked as  Critical . This parameter is used to ensure that the CRL version is unique. It is recommended that it be enabled for the root CA and intermediate CA. Issuing Distribution Point on CRLs ❌ Disabled for the root CA. This parameter is applicable only to large-scale CAs with hierarchical CRL structures. CA issuer URI ❌ Left empty. Users provide this URI during final certificate download stage. Keep expired certificates on CRL ❌ Disabled for the root CA. Determine if this parameter should be enabled for the intermediate CA based on actual requirements. After this parameter is enabled, the certificate is still displayed in the CRL even if it expires. Use CRL partitions ❌ Not required for the root CA due to its low load. This parameter is applicable to CA that manages a large number of certificates. CRL Expire Period ✅  30d . Set the period to a longer one for the root CA and to a shorter one for the intermediate CA. CRL Issue Interval ✅  7d . Periodically updates the CRL. It is recommended that the active CA use  7d . CRL Overlap Time ✅  12h . The old CRL and new CRL overlap for 12 hours to prevent certificate verification failures. Delta CRL Period ❌  0m . Delta CRL is not used for the root CA. It is enabled only for CAs that require high real-time performance. Generate CRL Upon Revocation ❌ Disabled for the root CA, and enabled for the intermediate CA as required. A new CRL is generated immediately after a certificate is revoked. Allow changing revocation reason ✅ Enabled. This parameter allows to change the reason for certificate revocation. It is applicable to all CAs. Allow invalidity date ✅ Enabled. This parameter allows to set the certificate invalidity date. It is applicable to all CAs.  5️⃣ Approval settings Parameter Description Add\u002FEdit End Entity ❌ None . Root CA does not manage end entities. Key Recovery ❌ None . Root CA does not provide key recovery. Revocation ❌ None . Root CA rarely revokes its own certificates. CA Service Activation ❌ None . Root CA is manually activated.  6️⃣ Other data Parameter Description Validators ✅  Finish User . Enable the certificate verification policy. CMP RA Authentication Secret ❌ Leave this parameter empty. This parameter needs to be configured only when the CMP protocol is used. Monitor if CA active (healthcheck) ✅  Activate . Enable CA running monitoring, which applies to all CAs. Request Processor ❌  None . Root CA usually does not need to process external requests.  7️⃣ Creation\u002FRenewal of Externally Signed CAs Parameter Description Renew CA ❌ Creates a new root CA instead of regenerating the key and re-signing the existing CA. This avoids problems caused by root CA certificates with the same name. CA Chain Certificates ✅ Uploads the certificate chain file (in PEM\u002FDER format) only when the CA is signed externally. If the root CA has been installed locally, you do not need to upload the file.  8️⃣ CA Creation After confirming all parameters are correct, click  Create  to generate a CA. 1. Download and verify the root CA certificate. Run the following OpenSSL commands to verify the certificate format and validity: # Verify PEM certificates.\n openssl  x509  -in  rootca.pem  -text  -noout\n \n # Verify DER certificates.\n openssl  x509  -in  rootca.der  -inform  DER  -text  -noout\n \n # Check the certificate's SHA256 fingerprint information.\n openssl  x509  -noout  -fingerprint  -sha256  -in  rootca.pem\n \n # Verify the self-signed certificate validity.\n openssl  verify  -CAfile  rootca.pem  rootca.pem\n 2. Deploy and verify the CRL. If the CRL URL is configured, run the following command: # Verify the CRL file.\n openssl  crl  -in  rootca.crl  -text  -noout\n Ensure that the CRL can be accessed through the web. 🚀  The root CA has been created and can be used to issue intermediate CAs!  🎉 5.7 Creating an Intermediate CA Certificate 1️⃣ CA type and key configuration Parameter Description CA Type ✅  X.509 CA ; Standard X.509 CA Crypto Token ✅ Select the created Crypto Token, for example,  demoCrypto . Signing Algorithm ✅  SHA256WithRSA ; Secure signature algorithm Alternative Signing Algorithm ❌  None ; No backup signature algorithm is required. Key Sequence Format ✅  Numeric (0-9) ; Serial number of the CA certificate Key Sequence ✅  00001 ; Initial serial number, which should be different from that of the root CA. Description ✅ Intermediate CA description, including the purpose and management unit.  2️⃣ Certificate policies (Directives) Parameter Description Enforce unique public keys ✅ Enforces the public key to be unique. Enforce key renewal ✅ Recommended to be enabled for intermediate CAs to ensure security. Enforce unique DN ✅ Ensures the DN to be unique. Enforce unique Subject DN SerialNumber ❌ Not required when the number of certificates is fewer than 20. Use Certificate Request History ✅ Records certificate request history. Use User Storage ✅ Stores user information. Use Certificate Storage ✅ Stores issued certificates.  3️⃣ CA certificate data Parameter Description\u002FExample Value Subject DN ✅  CN=test Intermediate CA   Signed By ✅  test EnterpriseIT Root CA  The intermediate CA must be signed by the root CA. Certificate Profile ✅  INTERMEDIATE_CA_profile  Configured for the intermediate CA after cloning. Validity ✅  10y  Generally, the validity period is 10 years, which is shorter than that of the root CA. Subject Alternative Name ❌ Not required for the intermediate CA. Certificate Policy OID ❌ Leave this parameter empty by default or enter a value as required. Use UTF-8 in policy notice text ✅ Ensures international character support. PrintableString encoding in DN ❌ Do not select this parameter to avoid affecting internationalization. LDAP DN order ✅ Arranges the DN according to LDAP specifications. Serial Number Octet Size ✅  20  20-byte is recommended. Name Constraints, Permitted ❌ Disabled by default. Leave this parameter empty. Name Constraints, Excluded ❌ Disabled by default. Leave this parameter empty.  4️⃣ CRL configuration Parameter Description Microsoft CA Compatibility Mode ❌ Disabled, typically. This parameter is used only in the Windows AD environment. Authority Key ID ✅ Enabled and marked as Critical. CRL Number ✅ Enabled and marked as Critical. Issuing Distribution Point on CRLs ❌ Disabled, typically. CA issuer URI ❌ Leave this parameter empty or enter a download address as required. Keep expired certificates on CRL ❌ Recommended to be enabled for the intermediate CA and retain expired certificates. This parameter is disabled currently; otherwise, the CRL size will become large. Use CRL partitions ❌ Not required, typically. CRL Expire Period ✅  7d  7-day is recommended to ensure timely update. CRL Issue Interval ✅  1d  The CRL is issued every day to ensure timely update. CRL Overlap Time ✅  12h  The new CRL overlaps with the old CRL for 12 hours to ensure smooth transition. Delta CRL Period ❌  0m  Delta CRL is not used. Generate CRL Upon Revocation ✅ Enabled. The CRL is updated immediately after the certificate is revoked. Allow changing revocation reason ✅ This parameter allows to change the reason for certificate revocation. Allow invalidity date ✅ This parameter allows to set the certificate invalidity date.  5️⃣ Default CA defined validation data Parameter Description Default CRL Distribution Point ❌ Leave this parameter empty or enter a value as required to distribute CRLs. Default CRL Issuer ❌ Leave this parameter empty. Typically, this parameter does not need to be set. Default Freshest CRL Distribution Point ❌ Leave this parameter empty. Typically, this parameter does not need to be set. OCSP Service Default URI ❌ Leave this parameter empty or enter an OCSP address as required. CA Issuer Default URI ❌ Leave this parameter empty or provide a URI later.  6️⃣ Approval settings and other data Currently, only  None  is available for approval settings, indicating that no additional approval process is required. If it is required, check the global approval policy Supervision Functions of EJBCA. Parameter Description Validators ✅  Finish User . Enable the certificate verification policy. CMP RA Authentication Secret ❌ Leave this parameter empty. This parameter needs to be configured only when the CMP protocol is used. Monitor if CA active (healthcheck) ✅  Activate . Enable running monitoring. Request Processor ❌  None . Generally, external request processing is not required.  7️⃣ Intermediate CA creation After confirming all parameters are correct, click  Create  to generate a CSR. Submit the CSR to the root CA for signature, download the signed certificate, and verify it. openssl  x509  -in  intermediate_ca.pem  -text  -noout\n openssl  verify  -CAfile  rootca.pem  intermediate_ca.pem\n 🚀 The intermediate CA has been created and can be used to issue end entity certificates! 🎉  6. RA Common User Creation and Permission Configuration 6.1 Creating an RA Role Access the RA Web page  and choose Role Management > Roles > Create New Role. Role Management →Roles →Create New Role\n Enter role information. ： Field Recommended Value Namespace No namespace Role name test RA Users Set the permissions for Certificate Authorities. ： Select a CA, for example,  Intermediate CA  or Root CA, from the Available list and click  Add . Set the permissions for End Entity. (Recommended): ✅ Create end entities ✅ Create certificates ✅ ...by using username and password ✅ ...by using a request ID ✅ View end entities and certificates Set the permissions for End Entity Profiles. ： Select  EMPTY  from the Available list and click  Add . Click  Add  to save the created role. 6.2 Creating an RA Commer User (End Entity) Access the  EJBCA Admin Web  page and choose  RA Functions > Add End Entity . Enter the user details. Field Recommended Value End Entity Profile EMPTY Username test_signuser Password 123 Confirm Password 123 Batch generation Not selected E-mail cert-user@example.com CN test RA user S1 O test C CN Certificate Profile ENDUSER CA test Intermediate CA Token P12 file Click  Add . End Entity is created. 6.3 Downloading the User Certificate Access the  RA Web  page and choose  Enroll > Use Username . Use the created username and password to log in. Username:  test_signuser Password:  123 Select a key algorithm after logging in. Select the  RSA 4096  algorithm, and generate and download the  .p12  user certificate. 6.4 Adding a User to the RA Role Access the  RA Web  page and choose  Search > End Entities . Copy the CN of the certificate created earlier. Access the  RA Web  page and choose  Role Management > Roles > Members > Add Role Member . Enter the information about the role member. Field Recommended Value Role test RA Users Token Type Certificate CA test Intermediate CA Match with CN Common Name Match Value Paste the copied certificate CN. Description RA common user Click  Add  to add the role member. Restart the EJBCA service  for the permission to take effect (recommended). docker restart ejbca 6.5 Logging In to the RA WebUI Non-administrator  roles import the downloaded · certificate to the browser. Access the RA Web page for automatic authentication and login. Perform authorized RA operations, such as creating and viewing certificates. 6.6 Important Notes (Must Be Followed) ✅ You are advised to use the Chrome browser in incognito mode for the first login to quickly start the verification and avoid the error \"No OAuth providers configured. Please log in using a valid certificate\" caused by cache problems. ✅  Use HTTPS  to access, for example,  https:\u002F\u002F192.168.xxx.xxx\u002Fejbca\u002Fra\u002F , to avoid the error \"No OAuth providers configured. Please log in using a valid certificate.\"  7. Certificate Profile Settings This section describes the meanings and recommended usage of the Certificate Profile configuration items in the EJBCA. It is applicable to certificate issuance requirements for common devices such as HTTPS, web, device, and client.  7.1 Basic Information Configuration Item Description Certificate Profile ID Unique identifier of the profile in the database, which is used only for internal identification. Type Available end entity, subordinate CA, and root CA. Available Key Algorithms Available key algorithms, such as RSA, ECDSA, Ed25519, and DILITHIUM. Available ECDSA curves Available ECDSA curves. No curve is enabled currently. Available bit length Key size supported (for RSA), such as 2048 and 4096. Signature algorithm Signature hash algorithm used for certificate issuance, for example, SHA3-256withRSA. Alternative Signature Whether to enable the alternative signature algorithm, such as ECDSA and EdDSA. End date or end date of the certificate Default validity period. For example, \"2y\" indicates two years. Validity Offset Offset of the issue date. The start time can be set forward or backward. Expiration Restrictions Maximum expiration time, which is used for compliance control. Profile Description Certificate profile description, which is used to note the purpose (for example, \"terminal device certificate\").  7.2 Permissions Control Configuration Item Description Recommended Setting Allow Validity Override Allow the default validity period to be overwritten when a certificate is issued. ✅ which is used when the validity period needs to be manually adjusted. Allow Expired Validity End Date Allow the end time to be set to an expired time (for test or audit). ✅ (for debugging) Allow Extension Override Allow the extension fields in the CSR to overwrite the predefined extension fields in the profile. ❌ Enabling this function can harm profile uniformity and create potential risks. Allow certificate serial number override Allow the certificate serial number to be customized during issuance. ❌ Enable this function only under specific circumstances (for example, for certificate cloning and replacement). Allow Subject DN Override by CSR Allow the subject information (such as CN\u002FO) in the CSR to overwrite the profile configuration. ✅ which is applicable to the automatic issuance process. Allow Subject DN Override by End Entity Information Allow the subject field to be specified based on the end entity information (user input). (Recommended) ✅, which provides high flexibility. Allow Key Usage Override Allow the keyUsage field in the CSR to overwrite the profile configuration. ❌ Enabling this function creates inconsistencies that compromise security. Allow Backdated Revocation Allow the revocation time to be set to a historical time for retrospective revocation. ✅ which is required in some audit\u002Fcompliance scenarios. Use Certificate Storage Enable the certificate to be stored in the database. This item must be enabled unless it is used for special offline purposes. ✅ Store Certificate Data Store the complete original certificate data (used with OCSP\u002FCRL). ✅ It is recommended that this function be enabled together with the storage function. ✅ Suggestion:  Keep profiles consistent in the production environment. Disable override permissions unless needed to stop CSR or End Entities from making unauthorized changes.  7.3 X.509v3 Extension—Basic Information Extension Item Description Recommended Setting Basic constraints Must be a CA certificate (the value must be FALSE for end entity certificates) ✅ Enabled; key setting CA key identifier Information about the CA that issues the certificate. ✅ Enabled Subject key identifier Unique ID of the certificate. ✅ Enabled  7.4 X.509v3 Extension—Key Usage Item Description digitalSignature Used for signature verification, such as identity authentication and code signature. nonRepudiation Indicates that the signature is non-repudiable (legal scenario). dataEncipherment Used to encrypt non-key data. keyEncipherment Used to encrypt key materials, such as symmetric keys. keyAgreement Key negotiation protocol (such as DH) cRLSign Used by the CA to sign CRLs. keyCertSign Used by the CA to sign certificates. encipherOnly Used with keyAgreement (only for encryption). decipherOnly Used with keyAgreement (only for decryption). Forbid encryption usage for ECC keys Forbids encryption usage for ECC keys. 7.5 X.509v3 Extension—Extended Key Usage Extended Key Usage Description TLS client TLS authentication on the client TLS server TLS authentication on the server EAP over LAN (EAPOL) Enterprise identity authentication EAP over PPP Point-to-Point Protocol (PPP) identity authentication ETSI TSL Signing ETSI TSL signing ICAO Deviation List Signing ICAO signing ICAO Master List Signing ICAO primary list signing Intel AMT management Dedicated to Intel management certification Internet Key Exchange for IPsec IPsec key exchange Kerberos Client Authentication Kerberos client authentication Kerberos KDC Kerberos key center MS CA Key Exchange Microsoft CA key exchange MS Commercial Code Signing Microsoft commercial code signing MS Document Signing Microsoft document signing MS EFS Recovery Microsoft EFS recovery MS Encrypted File System Microsoft encrypted file system MS Individual Code Signing Microsoft individual code signing MS Smart Card Sign-in Microsoft smart card login authentication OCSP Issuer Online Certificate Status Protocol (OCSP) signing certificate PDF Signing PDF signing PIV Card Authentication PIV card authentication RFC9336 Document Signing RFC9336-compliant document signing SCVP Client Simplified Certificate Verification Protocol (SCVP) client SCVP Server SCVP server SIP Domain VoIP\u002FSIP domain name authentication SSH Client SSH client authentication SSH Server SSH server authentication codeSigning Software\u002FDriver signing Any EKU Common EKU support emailProtection S\u002FMIME email signing\u002Fencryption clientAuth TLS client authentication timeStamping Timestamp signing serverAuth Server identity authentication (HTTPS, etc.) 7.6 Name Extension Item Description Suggestion Subject Alt Name IP address, DNS, and Uemail can be used as certificate identifiers. ✅ Enabled Issuer Alternative Name Additional CA name.\tOptional Optional Name Constraints Constraints for subject namespaces. Optional (used in high-security scenarios) 7.7 Validation Data Item Description Suggestion CRL Distribution Point CRL URL ✅ Enabled; key setting Delta CRL（Freshest CRL） Incremental CRL Enable on demand Authority Information Access (AIA) OCSP\u002FCA information ✅  7.8 Private Key Validity Period Item Description Start Offset Start offset time of the private key Period Length Validity period of the private key (independent of the certificate validity period)  7.9 ETSI Compliant Extensions (Typically for High-compliance PKI Use Cases) Item Description Certifications Statement Identifies certificates used for legal or compliance purposes. Assured validity Ensures the validity of short-term certificates.  7.10 Other Extensions Extension Usage OCSP No Check Disables OCSP check (useful only for OCSP responders). Microsoft Profile Value\tSpecial extensions for Windows AD integration CA\u002FB Forum OID Identifier extension for CA\u002FB-compliant organization  7.11 Approval Settings and Additional Fields Configuration Item Description Add\u002FEdit End Entity Bound approval process Key Recovery Whether key recovery is supported (for example, for backup and restoration) Revocation Approval Whether approval is required for revocation CN Suffix A character string automatically added to the end of Subject CN Subject Subset Restriction Restriction on the Subject fields that can be used  7.12 CA & Release Settings Item Description Available CA CA that can use the certificate profile Publisher Publishing to LDAP, databases, or external services Single Certificate Limit Whether an end entity can have only one valid certificate Account Binding Namespace Device account binding (for example, IoT)  To configure the code signing certificate profile, adjust the keyUsage and extendedKeyUsage fields. 📌 You are advised to create different profiles for different applications (such as VPN, HTTPS, code signing, and client authentication) to facilitate management and compliance control.  8. Approval Configuration and Management 8.1 Creating an Approval Profile (Approval Configuration) Choose  Watchdog > Approval Profiles . Type a name (for example,  test ) at the bottom and click  Add . Click  Edit  in the list to enter the detailed settings. 8.2 Basic Parameter Settings Field Suggestion\u002FExample Approval Profile Type Accumulative Approval Partitioned Approval (can be used in cross-department cases) Request Expiration Period 8h (The request will be voided if not approved within the expiration period.) Approval Expiration Period 8h (Re-approval is required after the expiration period.) Max Extension Time 0d (The period cannot be extended.) Allow Self Approved Request Editing Deselected (Self-approval is prohibited in production.) 8.3 Approval Steps Set  Number of Required Approvals . Development\u002FTest:  1  (1-of-1). Production\u002FSensitive operations:  2  (2-of-2) or partitioned approval. Notification email: Notification message email recipient :  approval-admin-group@example.org supervisor@example.org Notification message email sender :  no-reply@192.168.xxx.xx Example theme profile:\n [AR-${approvalRequest.ID}-${approvalRequest.STEP_ID}-${approvalRequest.PARTITION_ID}] Approval Request\n Variables that can be referenced in the body:  ${approvalRequest.TYPE} ,  ${approvalRequest.REQUESTOR} , and  ${approvalRequest.WORKFLOWSTATE} . 8.4 Binding to a Specific Action End Entity Profile: Choose  CA Functions > End Entity Profiles >   > Approval Settings>  Add\u002FEdit End Entity to be approved > Approval Profile and then click  Save . Common options:  Add\u002FEdit End Entity  and  Key Recovery  (if enabled) Certificate Profile: Choose  CA Functions > Certificate Profiles >   > Approval Settings > Operation > Approval Profile  and then click  Save . Sensitive administrator actions : It is recommended that 2-of-2 or partitioned approval be used for intermediate CA change and revocation. 8.5 Testing and Verification Use a common RA account to start an operation (for example, creating an end entity) that requires approval on the RA WebUI. Choose Inspector Function > Approvals to check the approval queue, and use another approver account to complete the approval. Confirm that the operation was executed automatically and the email notification was received successfully. 8.6 FAQs No email received: Check the SMTP configuration, firewall, and recipient name, and view container logs. Stuck in pending status: Number of Required Approvals is set too high or the approver does not have the permission. Can be self-approved: Allow Self Approved Request Editing is selected by mistake. This function should be disabled in production. Expired: Request\u002FApproval Expiration is set too short. The value can be changed to 8h to 24h. 9. End Entity Profile Settings Path:  RA Functions > End Entity Profiles . The End Entity Profile defines the fields that can be populated, specifies which are mandatory or modifiable, and determines the default Certificate Profile, CA, and Token. 9.1 Creating and Opening an End Entity Profile Choose RA Functions > End Entity Profiles. Enter the profile name (for example, test) at the bottom and click Add Profile. Select the profile from the list and click Edit Endpoint Entity Profile. 9.2 Basic Information (Username\u002FPassword\u002FEmail) Generally, the  username\u002Fpassword  does not need to be specified in the profile. The profile only sets the rules and methods. The  username\u002Fpassword\u002Fenrollment code  can be specified  during end entity creation or application submission . Recommended practice Username: Select Auto-generated (for auto and batch operations), or manually specify the username when creating an end entity. Password (or Enrollment Code): Select Required to use the one-off Enrollment Code. Enter the specific value when creating an end entity or submitting the application on the RA. Minimum password strength\u002Flength: Retain the policy (for example, the length is greater than or equal to 8), but do not enter the specific password. Maximum number of failed login attempts: Set the number as needed. Select Modifiable if you need to temporarily change this limit. Batch generation: Disable this function. Avoid storing enrollment codes in plaintext. E-mail: Set it based on the Required\u002FModifiable setting. It is used for notification and identification. Impact of different application paths on username\u002Fpassword RA Web > Enroll > Use Username: Username and Password\u002FEnrollment Code are specified when an end entity is created. The user uses this account to log in to the system and obtain the certificate. RA Web > Enroll > Use Request ID: The system allocates Request ID. Password\u002FEnrollment Code is set when the request is created. The applicant uses the ID and code to obtain the certificate. User Generated (CSR): Token=User Generated. Retain Required to generate a one-off code. The applicant uses the CSR and code to complete the issuance. Directives Reverse Subject DN and Subject Alt Name Checks: You can also deselect this option. Allow merge DN for all interfaces: Generally, this option is not selected. It is selected only when DN combination is required for multiple APIs. Allow multi-value RDNs: This option is selected only when special requirements are met. (It is disabled by default, which is more secure.) 9.3 Subject DN Attributes—(Setting by Users) Available attributes are displayed on the left, and selected attributes are displayed on the right. Add the required fields to the right and set  Required\u002FModifiable\u002FValidation  for each field. Common recommendations (client\u002Fgeneral): Field Suggestion CN, Common name Required; Modifiable is determined by the RA. emailAddress, E-mail address in DN Optional. To bind with the email system, set it to Required. O, Organization \u002F OU, Org. Unit Service-dependent. You are advised to disable Modifiable to prevent arbitrary input. C, Country The value is fixed to CN or the country where the user is located. Generally, the value cannot be changed. If stricter verification is required, you can specify a regular expression or format rule in  Validation . 9.4  Other Subject Attributes —(Setting by Users) Subject Alternative Name (SAN) : Client certificate: RFC 822 Name (e-mail address) (same as the account email address) Server certificate: DNS Name and IP Address (added by domain name\u002FIP address) Device certificate: OtherName (written into the device ID\u002FOID) (Optional) ** Subject Directory Attributes: Attributes such as  Date of birth (YYYYMMDD)  are used only for archiving or compliance needs. You are advised not to enable multiple directory attributes. Addition method: Select an item in the  Other Subject Attributes  area and click  Add . You can also mark it as  Required\u002FModifiable  if supported by the interface. 9.5 Main Certificate Data Field Suggestion\u002FDescription Default Certificate Profile Select a certificate profile (for example, ENDUSER or SERVER). Available Certificate Profiles Select only the allowed profiles. Default CA \u002F Available CAs Specify the CAs that can issue the certificate. Note: Changing the available CAs impacts which roles can access the profile. Default Token \u002F Available Tokens P12 file (downloaded directly on the RA) or User Generated (CSR created by the user) 9.6 Other Certificate Data Custom certificate serial number : disabled by default Certificate Validity Start\u002FEnd Time : controlled by Certificate Profile by default. If a temporary certificate is required, enable this item and select Modifiable. Name Constraints (Permitted\u002FExcluded) : used for intermediate CAs. Generally, this item is disabled in end entity profiles. Custom certificate extension data \u002F ETSI PSD2 QC Statement \u002F CA\u002FB Forum Organization Identifier : Enable it as required for compliance. 9.7 Other Data\u002FRestrictions Field Suggestion Number of allowed requests 1  (preventing repeated issuance) Allow renewal before expiration Example:  30  days.  -1  indicates no limit. Revocation reason to set after certificate issuance Active  by default (typically left unchanged) Redact Subject Name from logs Enable this feature only for strict privacy or compliance needs. Send Notification Enable it when needed for SMTP settings. 9.8 Saving and Authorization Click  Save . Choose  RA Web > Role Management  and check that the related role has been authorized to use the end entity profile (visible\u002Fcreatable). Choose  Search > End Entities  and use the profile to create a test user to check the following:\n Check whether the DN\u002FSAN is added to the database according to the rules. Check whether the certificate uses the expected  Certificate Profile\u002FCA\u002FToken . Check whether the download or import is successful (P12\u002FPEM\u002FCSR process).  10. Applying for an End Entity Certificate as an RA Common User Choose  RA Web → Enroll 。 By default, you are advised to use  By the CA  (the CA generates the key) for stability and fewer errors; no CSR is needed. 10.1 Path and Prerequisites Profiles have been prepared in  End Entity Profiles  (Section 9) and  Certificate Profiles . Users have access permission. When approval is enabled (see Section 8), submissions go into the pending queue. Certificates are issued once they are approved. 10.2 Recommended: By the CA (No CSR Required) Choose  Enroll > Make New Request . Select  Certificate Type  (End Entity Profile) and  Certificate subtype  (Certificate Profile). Set  Keypair generation  to  By the CA . Expand  Provide request info  and enter  Subject DN \u002F SAN  (such as CN, email address, DNS, and IP address) as required. Download the  *.p12  file. 10.3 Optional: Provided by user (Uploading a CSR) This option is used only when the key must be generated on the client or server for reasons like compliance, using an HSM or dedicated device, or migrating an existing key. Generate a private key and CSR locally. Select  Provided by user  and paste the complete CSR, including  BEGIN\u002FEND CERTIFICATE REQUEST , into the text box. Submit the CSR and download the certificate as prompted (the private key is not included). 10.4 Approval Association and Notification If a profile is bound to an  Approval Profile , the profile will be pending approval upon submission. After the profile is approved, the profile will be automatically issued or available for download. The email subject and body comply with the notification requirements in Section 8. 10.5 FAQs Field failure : The DN\u002FSAN is inconsistent with that in the profile. Adjust the DN\u002FSAN according to Section 9. Unable to download P12 : Download is blocked by the browser, or password policies conflict. Use another browser or check the password length and character set. CSR rejected : The Subject\u002FSAN in the CSR conflicts with that in the profile. Rebuild the CSR using the profile or use  By the CA . Approval suspended : The number of approvers does not meet the requirement, or the approver does not have the required permission. Check the status under Monitor > Approvals. html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[49],{"_path":57,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":58,"description":59,"date":60,"category":61,"author":62,"_type":18,"_id":66,"_source":20,"_file":67,"_stem":68,"_extension":23,"coverImage":69,"plainText":70,"authorNames":71},"\u002Fen\u002Fblogs\u002F202508071","openUBMC Observability: Full Insight into the System for a New BMC Vision","As digital transformation surges forward, system complexities escalate continuously. The efficient monitoring and management of distributed systems have become a key challenge. As a bridge between hardware and software, the baseboard management controller (BMC) is responsible for device management, monitoring, and maintenance. openUBMC 25.06 introduces the Observability component to provide complete observability capabilities based on openTelemetry, enabling developers to clearly understand system status, quickly locate issues, and optimize system performance.","2025\u002F08\u002F07","essentials",[63],{"name":64,"description":65},"许强","openUBMC Interface SIG maintainer, focusing on enhancing interface management efficiency and optimizing BMC firmware locating.","content:en:blogs:202508071.md","en\u002Fblogs\u002F202508071.md","en\u002Fblogs\u002F202508071","\u002Fcategory\u002Fblog\u002F20250807\u002Fimg01-en.png","openUBMC Observability: Full Insight into the System for a New BMC Vision As digital transformation surges forward, system complexities escalate continuously. The efficient monitoring and management of distributed systems have become a key challenge. As a bridge between hardware and software, the baseboard management controller (BMC) is responsible for device management, monitoring, and maintenance. openUBMC 25.06 introduces the Observability component to provide complete observability capabilities based on openTelemetry, enabling developers to clearly understand system status, quickly locate issues, and optimize system performance. This article explores the advantages, value, and prospects of openUBMC Observability. We look forward to your participation in the capability development of openUBMC Observability. Advantages 1. Unified Data Collection and Management openUBMC uses openTelemetry to implement unified collection and management of metrics, logs, and traces. All data, including hardware status, system performance, and software status, is integrated and reported to openUBMC to ensure data integrity and consistency. Standard programming APIs  \nopenUBMC encapsulates and provides application programming interfaces (APIs) based on openTelemetry to simplify data collection. Developers can easily integrate telemetry data into the BMC system through simple API calls. Standard data formats  \nThe unified telemetry framework defines compatible and consistent formats for metrics, logs, and traces, facilitating subsequent data processing and analysis. Standard transmission protocols  \nopenTelemetry Protocol (OTLP) is used, supporting both gRPC and HTTP\u002FJSON. gRPC is applicable to high-performance scenarios for efficient data transfer. HTTP\u002FJSON provides wide compatibility, facilitating integration with existing systems and tools.  2. Seamless Integration with Mainstream Tools openTelemetry Collector allows openUBMC Observability to seamlessly integrate with tools such as Prometheus, Zipkin, Jaeger, and Elasticsearch, Logstash, and Kibana (ELK). In this way, powerful data visualization and analysis capabilities are provided to help users better understand and optimize system performance. Data collection and processing \nopenTelemetry Collector supports multiple data formats and protocols, and can flexibly process telemetry data (metrics, logs, and traces) from various data sources. Data conversion and export \nopenTelemetry Collector can convert collected data and export it to different target systems, such as Prometheus, Grafana, and Jaeger. This enables the observability data from the BMC to be simultaneously used by multiple tools, thereby improving data utilization.  3. Powerful Distributed Tracing Capability With the visualized analysis capability of platforms such as Zipkin, openUBMC can clearly display the complete call paths. Developers can easily trace every operation from hardware to software, and thus quickly locate performance bottlenecks and faults.  4. High Scalability and Flexibility openUBMC provides APIs to support highly scalable observability. Developers can customize data collection and processing logic as required to meet observation requirements in different scenarios. Value Data-driven benefits: By monitoring the hardware and software status in real time, openUBMC aggregates and analyzes data to accurately identify performance bottlenecks and potential risks. With targeted data collection, it identifies and locates anomalies early in the development phase, effectively preventing failures and enhancing overall system stability and reliability. During fault locating, clear call traces and accurate performance data enable developers to quickly define the fault scope, accurately trace the root cause, and significantly shorten the fault rectification time. The following issues were identified using the observability component during the R&D of the 25.06 version: Flash log flooding  \nBy monitoring the flash write volume and analyzing its growth trend, openUBMC detected and prevented flash lifespan degradation caused by excessive writes.   Hardware access failure \nBy monitoring hardware access metrics and filtering access errors, openUBMC detected and prevented faulty hardware through the error growth trend analysis.   Improper CSR configuration  \nBy monitoring hardware access metrics and analyzing the collected data, openUBMC detected and prevented improper or invalid device access configurations in the CSR, optimizing hardware access cycles and improving overall BMC performance.   Prospects: Jointly Building openUBMC Observability openUBMC Observability is open and extensible. We welcome more developers and community partners to join us in improving and optimizing the capability. Looking ahead, we will continue focusing our efforts on the following key areas: Enhance deep integration of hardware and software.  \nDeepen the collaborative observability between hardware and software to provide a more comprehensive device management perspective. Introduce AI-driven anomaly detection.  \nUse AI technologies to intelligently analyze observed data and detect potential issues in advance. Building a developer-friendly tool chain  \nProvide more easy-to-use tools and plug-ins to lower the barrier for developers to use openUBMC Observability. Promoting community co-construction  \nWork with community developers to improve openUBMC Observability through technical sharing and open source contributions. Summary Full Insight into the System for a New BMC Vision openUBMC Observability is built based on openTelemetry. It not only improves system stability and performance, but also provides developers with an efficient and flexible platform for development and observation. We believe that through the joint efforts of the community and partners, openUBMC Observability will become more comprehensive and deliver more benefits to developers and users. If you are interested in openUBMC Observability, we warmly invite you to join our community. Let's explore and build a smarter, more reliable BMC system. Join Us to Build openUBMC Observability You are welcome to share your ideas and questions through the community forum, submit issues, or join Interface SIG regular meetings. GitCode repository:  https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fobservability Community forum:  https:\u002F\u002Fdiscuss.openubmc.cn",[64],{"_path":73,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":74,"description":75,"date":60,"category":61,"author":76,"_type":18,"_id":80,"_source":20,"_file":81,"_stem":82,"_extension":23,"coverImage":83,"plainText":84,"authorNames":85},"\u002Fen\u002Fblogs\u002F202508072","AI-Powered R&D: Rapid NCSI Protocol Command Parsing in openUBMC","NCSIis a critical protocol enabling communications between the baseboard management controller (BMC) and the network controller. During the development of the openUBMC 25.06 version, I encountered several bottlenecks:",[77],{"name":78,"description":79},"钱昱霏","BMC developer, specializing in software development and improving automation efficiency, with unique insights into AI-assisted R&D.","content:en:blogs:202508072.md","en\u002Fblogs\u002F202508072.md","en\u002Fblogs\u002F202508072","\u002Fcategory\u002Fblog\u002F20250807\u002Fimg07.webp","AI-Powered R&D: Rapid NCSI Protocol Command Parsing in openUBMC Background: Repetitive Work in Protocol Command Development NCSI  (Network Controller Sideband Interface)  is a critical protocol enabling communications between the baseboard management controller (BMC) and the network controller. During the development of the openUBMC 25.06 version, I encountered several bottlenecks: High code duplication : Except for the request\u002Fresponse payload structure, the code logic for different NCSI commands was nearly identical, leading to extensive boilerplate. Manual generation of test data : Binary test data had to be calculated and written manually. This process was complex and highly prone to error. Dense and vague documentation : The NCSI protocol specification is English-only and technically dense, requiring significant effort to read and often leading to misinterpretation of certain sections. To ensure a high-quality delivery, I turned to the cutting-edge capabilities of AI-assisted coding, hoping to harness the power of LLMs to streamline this development work. Pattern Analysis: Identifying the \"Automatable\" Core Blindly relying on AI to write code independently can be counterproductive, as current AI tools cannot fully replace human expertise. The first step was to analyze the code structure and functional modules to identify areas where the AI could be most effective. 1. Protocol Documentation Understanding and Command Extraction Modern LLMs excel at natural language understanding, especially with English documentation. This strength was used to extract the request and response packet formats for each NCSI command directly from the protocol specification.  2. Writing Command Handler Functions To guide the LLM and prevent unnecessary deviation, I pre-defined the function signatures for the protocol request and response handlers. Existing openUBMC code was provided as context to ensure the generated code adhered to the community's coding style. BMC-specific requirements, such as logging operational history, were also provided as templates, instructing the LLM to include operation log recording in all setter-type command functions. 3. Generating Test Cases for Protocol Compliance To guarantee the quality of the generated code, openUBMC's Unit Test (UT) framework was used for rapid verification. Crucially, the test code itself was also generated using the LLM. Leveraging the LLM's understanding of the NCSI binary protocol, it could quickly derive the necessary test data, eliminating the tedious, error-prone process of manually crafting binary packets. Coding in Practice: Practical Prompt Templates I utilized a combination of GPT-4.1 and Cursor for the toolset. Through iterative practice, I summarized a set of high-efficiency prompt templates, which are shared below. Key Results: 80+ functions and corresponding test cases generated automatically, with the accuracy exceeding 90% and the UT coverage above 86%. Overall development efficiency increased by 65%, saving an estimated 30+ person-days. Code style was consistent with community standards, leading to a smooth review by the SIG Committer. Knowledge Background Setup Thanks to Cursor's powerful context awareness, existing code files in the repository were automatically included in the LLM's analysis (for example, Lua syntax and style). However, the NCSI protocol document was external. Crucially, Cursor supports integrating the full protocol document as a knowledge base. I imported the public NCSI specification into Cursor, providing the AI with a solid theoretical foundation for the command parsing work.  Template Breakdown I broke the task into three steps, using an iterative generation and Q&A approach to further boost code accuracy, and wrote corresponding prompts: Generate NCSI command response and parsing functions. Generate corresponding UT functions and test data for the created functions. Optimize all newly added code. Prompt Example 1: Generating New Functions Based on the existing code pattern below, generate the corresponding function for the new NCSI command [COMMAND_NAME]:\nReference Header File Definitions:\nCommand type macros: Refer to command constants in header files under test-main\u002Fncsi path.\nPacket structure definitions: Refer to request\u002Fresponse structs in the header file.\nLength macros: Refer to *_REQ_LEN, *_RSP_LEN, *_PAD_LEN, etc. in the header file.\n\nExisting Pattern:\nfunction ncsi_cmd.ncsi_enable_channel(package_id, channel_id, eth_name)\n\nRequirements:\n1. Function name must be ncsi_[COMMAND_NAME].\n2. Parameters must be package_id, channel_id, eth_name.\n3. Must include the same parameter validation logic.\n4. Must call the corresponding module function.\n5. Must return the same error codes.\n\nPlease generate the complete function code.\n  Prompt Example 2: Generating Test Cases Based on the testing pattern below, generate a complete test case file for the [MODULE_NAME] module:\n\nExisting Testing Pattern:\nfunction TestNCSIBroadcastFilter:test_enable_broadcast_filter()\n\nRequirements:\n1. Create a test class TestNCSI[MODULE_NAME] for [MODULE_NAME].\n2. Include setUp and tearDown methods.\n3. Generate a test case for every public function.\n4. Include both success and failure scenario tests.\n5. Validate the request packet format.\n6. Include boundary condition tests.\n\nPlease generate the complete test file.\n  Prompt Example 3: Code Optimization Code Optimization Suggestions\n\nAnalyze the code under the src\u002Flualib\u002Fncsi\u002Fncsi_protocol\u002F directory.\nIdentify repetitive patterns that can be further optimized.\n\nCurrently optimized patterns:\n1. Using the handle_channel_operation generic function.\n2. Using ncsi_utils.create_custom_cmd_table.\n3. Using the command table pattern.\n\nAnalyze what other repetitive code can be further optimized and provide specific optimization plans and code implementations.\n  Conclusion and Outlook While the dream of \"one-click complete code generation\" isn't fully realized yet, the practical value of LLMs in R&D assistance is exceptionally high. This new development paradigm is poised to disrupt traditional workflows, bringing a revolutionary experience to the BMC and firmware fields. I look forward to seeing more AI-assisted coding practices within the openUBMC community to spark further innovation. Developers are welcome to share their experiences and insights as we collectively explore the boundless possibilities of AI-assisted coding! Welcome to follow us! openUBMC official website:  https:\u002F\u002Fwww.openubmc.cn Code repository:  https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fnetwork_adapter",[78],{"_path":87,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":88,"description":89,"date":90,"category":12,"author":91,"_type":18,"_id":95,"_source":20,"_file":96,"_stem":97,"_extension":23,"coverImage":98,"plainText":99,"authorNames":100},"\u002Fen\u002Fblogs\u002F20250726","Business Practice | How the openUBMC Community Development Pipeline Drives High-Quality Delivery for Yangtze Computing","In software development, the build phase is critical because it directly impacts development efficiency and software quality. To support local deployment of openUBMC and improve development efficiency within the enterprise, Yangtze Computing has introduced a developer build solution and a pipeline build solution. The offline deployment–based solutions cover infrastructure configuration and build system design, helping gain a deep understanding of how to construct and optimize the openUBMC build system.","2025\u002F07\u002F26",[92],{"name":93,"description":94},"易重辉","BMC software development engineer at Wuhan Yangtze Computing Technology Co., Ltd., who is dedicated to openUBMC software development and has extensive expertise in BMC build and valuable insights for optimizing development processes.","content:en:blogs:20250726.md","en\u002Fblogs\u002F20250726.md","en\u002Fblogs\u002F20250726","\u002Fcategory\u002Fblog\u002F20250726\u002Fimg01-en.png","Business Practice | How the openUBMC Community Development Pipeline Drives High-Quality Delivery for Yangtze Computing Introduction In software development, the build phase is critical because it directly impacts development efficiency and software quality. To support local deployment of openUBMC and improve development efficiency within the enterprise, Yangtze Computing has introduced a developer build solution and a pipeline build solution. The offline deployment–based solutions cover infrastructure configuration and build system design, helping gain a deep understanding of how to construct and optimize the openUBMC build system. Infrastructure Configuration (1) Infrastructure and Resource Update Overview  Like many companies, Yangtze Computing conducts most of its development in a pure intranet environment. A key challenge is making community infrastructure compatible with the enterprise's internal systems. To address this, Yangtze Computing has designed a technical solution that deploys openUBMC community resources through unidirectional data flows. Data moves from the Internet to the non-confidential intranet and then to the confidential intranet. This network design ensures both data security and development environment stability. Due to security requirements, additional deployment procedures have been introduced. To improve efficiency, automation is essential. Therefore, in Yangtze Computing's deployment process, the cross-network transfer of source code and Conan is fully automated via scripting. (2) Infrastructure Configuration  The infrastructure Yangtze Computing sets up for the localized openUBMC deployment is complete, user-friendly, and secure. It provides strong technical support for their commercial release of openUBMC and helps streamline the BMC software development process. It also provides guidance for other enterprise developers building similar development environments and workflows. 3 Developer Build Solution  Docker images form the foundation for both manual developer builds and automated pipeline builds. Uploading Docker images to a compile server allows developers to directly build services. Uploading Docker images to a container image repository enables pipelines to build services automatically. On a compile server, an independent compile container is created for each developer. This design isolates each developer's environment to prevent cross-interference. Developers can connect to the compile containers through SSH and carry out development. In practice, they can use pre-configured compile containers in a secure desktop environment, allowing them to focus on coding and debugging without worrying about environment setup. In addition, Yangtze Computing's compile containers support personal data persistence and include a read-only public directory. This design simplifies upgrades to the compilation environment and the transfer of development materials during maintenance. 4 Pipeline Build Solution (1) Pipeline Requirement Analysis  Code gated check-in requirements: Component gated check-in pipeline : When component code is merged, the gated check-in pipeline is triggered, performing static code analysis, unit tests, and unit test coverage calculation. Code can be successfully merged only after passing these checks, ensuring high code quality. Product gated check-in pipeline : When a product version changes due to component updates, a gated check-in is performed to verify that the product package can be built, ensuring the integrity and availability of the product version. Version build and release requirements: When a component version is released, its binary files must be built and archived to support subsequent use and management. When a test version is released, an HPM package must be built and archived. Additionally, a smoke test is triggered to preliminarily verify that the basic product functions are working correctly. (2) Component Pipeline Design Overview  When code is merged into the component repository, the component gated check-in pipeline is triggered. The component code is pulled and subjected to checks, including static code analysis, unit tests, and component package verification. The results are sent to the development team, and the gated check-in outcome determines whether the code can be merged.  When a component version is ready for release, the component build pipeline is triggered either periodically or manually. The component code is pulled for version building, and the resulting version is released in the Conan repository to enable component updates and sharing. (3) Product Pipeline Design Overview  When code is merged into the Manifest repository, the product gated check-in pipeline is triggered. It pulls the component code, verifies whether the code can be merged, and checks the packaging conditions to ensure that a complete package can be generated. Subsequently, a signature request can be triggered to ensure product security.  When a product version is released, the product build pipeline is triggered either periodically or manually. It pulls the component code, builds and releases the version, and performs smoke tests to verify product performance and functionality. (4) Simulation of Pipelines in Software Development To illustrate the functions and mechanisms of the four pipelines, this blog uses arrows to represent each pipeline type, simulating the build and release processes for three components (A, B, and C) and their associated products. Specifically, the blue downward arrow represents the gated check-in pipeline, the cyan rightward arrow represents the build pipeline, the arrow with black border represents the component pipeline, and the arrow with red border represents the product pipeline.  As shown in the preceding figure, the pipeline design closely aligns with the software engineering process. Version release after multiple iterations of feature integration : For both components and products, a version is released through a build pipeline after passing several gates. Assurance of versions built from the product repository : The product gated check-in pipeline succeeds only after the components have been released through the build pipeline and the changes have been merged into the Manifest repository. If the components are not built, the product gated check-in pipeline will fail and an error is reported indicating the missing components. Update of multiple component dependencies : When a requirement involves several component dependencies, their version updates can be incorporated in a single merge request. Separation between product and component version releases : After a component version is released through the build pipeline, it does not need to be immediately merged into the product repository. Instead, the version can be released and aligned according to the respective development pace of the component and the product. The component gated check-in pipeline, product gated check-in pipeline, component build pipeline, and product build pipeline work together to ensure the quality and efficiency of software development. The gated check-in pipelines strictly control code merging, while the build pipelines handle building and releasing versions. Together, they ensure that software development proceeds smoothly in accordance with the defined processes and standards. 5 Scenario-specific Solutions Deployment scenario: An enterprise builds a Conan repository and plans to migrate Conan binary files from the community repository to its own development environment.   Solution 1: Establish a connection between the community Conan repository and the enterprise's local Conan repository using repository cascading. Theoretically, all binary files can be downloaded from the community repository. This approach works in scenarios where real-time communication with the community repository is possible. While the process is straightforward, it may be impacted by network stability and permission controls.  Solution 2: Run Conan download to download the files and upload them to the enterprise's local Conan repository. Theoretically, all binary files can be downloaded from the community repository.  Solution 3: Use bingo to download the files and upload them to the local Conan repository. In this approach, only the binary files required by a specific component or product version can be downloaded, limiting access to all other binaries in the community. However, this approach is practical for handling specific dependencies. In short, if you have access to the official Conan repository of the openUBMC community, choose Solution 1 for cascading. For offline deployment, opt for Solution 2. If you only need to package the binary files required by a specific component or product, go with Solution 3. 6 Summary The openUBMC-based developer build and pipeline build practices at Yangtze Computing showcase a comprehensive and systematic build process. Developers within the openUBMC community have drawn significant inspiration from well-structured infrastructure configuration, seamless developer build implementation, a well-designed pipeline build, and efficient approaches to Conan's remote-local deployment. Throughout the development process, developers can leverage this experience and project-specific insights to continually optimize the build system, enhance development efficiency, and maintain high software quality. As a result, developers are better positioned to succeed in the competitive market, speed up software delivery and iteration, and better address user needs and market demands.",[93],{"_path":102,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":103,"description":104,"date":105,"category":106,"author":107,"_type":18,"_id":111,"_source":20,"_file":112,"_stem":113,"_extension":23,"coverImage":114,"plainText":115,"authorNames":116},"\u002Fen\u002Fblogs\u002Fsig-meeting-guide","SIG Meeting Guide: How to Participate and Organize in the openUBMC Community","openUBMC 开源社区按照不同的SIG（Special Interest Group）来组织开发及版本相关工作。","2025\u002F07\u002F17","guide",[108],{"name":109,"description":110},"openUBMC小助手","The openUBMC Assistant actively supports the openUBMC community by sharing the latest tech trends, detailed article insights, and engaging interactive content for developers. It aims to create an open, collaborative, and vibrant community for every member.","content:en:blogs:sig-meeting-guide.md","en\u002Fblogs\u002Fsig-meeting-guide.md","en\u002Fblogs\u002Fsig-meeting-guide","\u002Fcategory\u002Fblog\u002Fsig-meeting-guide\u002Fimg01.png","SIG Meeting Guide: How to Participate and Organize in the openUBMC Community The openUBMC open source community uses Special Interest Groups (SIGs) to manage development tasks and releases. SIGs hold regular meetings for technical review, task management, and design discussions. This guide helps developers join meetings and assists core members in organizing them effectively. Meeting Format and Platforms openUBMC community meetings are held online to support global participation.  Developer Calendar : You can view all scheduled meetings on the openUBMC Developer Calendar, accessible via the community portal website.  Platforms : Meetings typically use platforms like WeLink or Tencent Meeting. Please download and install the required software in advance. The Role of Etherpad The openUBMC community uses Etherpad for registering topics, recording content, and finalizing meeting minutes. Access: Every SIG has a permanent Etherpad link, found on the SIGs page or in the meeting notification. Editing: Log in with your community account to start editing and adding discussion topics. Maintenance: SIG maintainers and committers are responsible for maintaining the content and format of their SIG's Etherpad. Refer to the community's  Etherpad Template  for guidance. Meeting Subscription When a new meeting is created, a notification is sent via the SIG's mailing list. To receive these notifications, you must subscribe. Go to the community email management page.  Select the desired SIG mailing list. Enter your email address and click Subscribe.  Check your inbox, click the confirmation link, and confirm your subscription. Meeting Management SIG maintainers and committers have the authority to reserve community meeting resources.  Go to the  Personal Center  and click  Create Meeting . Select the target SIG and fill in the required meeting information.  Once created, the meeting details will be visible on Developer Calendar.  Tips for Highly Effective Meetings For productive SIG meetings, follow these best practices: Preparation: Define Goals and Agenda Categorize topics  \nDefine the category for each topic. Decision-making topics and discussion topics require different approaches, helping organizers manage time. Pre-meeting consensus (decisions)  \nFor decision-making topics, collect feedback from key SIG members (via issues and forums) before the meeting. Clearly state what needs to be decided to avoid long, rambling discussions. Pre-meeting context (discussions)  \nFor discussion topics, share background material (design docs and issue links) in advance. State the discussion goal clearly and collect opinions from core members beforehand. Publish agenda early  \nSet a fixed, periodic schedule. Send the meeting notice one week in advance to allow attendees to plan. Confirm the final agenda one day prior to avoid discussing irrelevant topics. Encouraging asynchronous preparations  \nEncourage members to discuss issues, pull requests (PRs), or proposals in issues, PRs, or the forum first. The meeting should not be a \"read-the-document\" session. Execution: Efficient Collaboration and Record Keeping Strictly follow the agenda & time:  Appoint a moderator to control the pace and prevent tangents. Use timeboxing to limit discussion time for each topic. Prioritize real-time discussion:  Solve issues that can be handled through issues, PRs, email, or the forum asynchronously. Reserve synchronous meeting time for critical decisions or complex real-time problem-solving. Ensure transparency & inclusivity:  All SIG discussions must be public. Anyone should be allowed to offer input. Record complex discussions in the Etherpad so non-attendees can still understand the process. Clear decision mechanism: Adopt lazy consensus: A proposal passes by default unless there is a strong objection. Use voting for major decisions: Major decisions require a formal voting mechanism (forum\u002Femail polls), and the outcome must be recorded in the meeting minutes. Key Principles ✅  Open & transparent : All discussions and decisions are public and auditable. Avoid private decisions. ✅  Inclusive & collaborative : Encourage new members to participate. Prevent core members from dominating the discussion. ✅  Results-oriented : Every meeting must have clear output (a decision, a task, or a document). ✅  Respect time : Start and end on time. Avoid pointless discussion.",[109],{"_path":118,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":119,"description":120,"date":121,"sig":122,"archives":123,"category":12,"author":124,"_type":18,"_id":128,"_source":20,"_file":129,"_stem":130,"_extension":23,"coverImage":131,"plainText":132,"authorNames":133},"\u002Fen\u002Fblogs\u002FMigration_system","Hi3093 Development Board Hands-on Guide (openubmc.cn)","openUBMC supports QEMU simulation and debugging. However, there is no efficient debugging method for hardware debugging. After trying many development boards, I summarized some openUBMC startup experience based on the MYC-LHi3093 development board for your reference.","2025\u002F07\u002F12","sig-docs","2025-07",[125],{"name":126,"description":127},"范信鑫","openUBMC community developer, focusing on making openUBMC easy to start with, developing the community, and creating new features.","content:en:blogs:Migration_system.md","en\u002Fblogs\u002FMigration_system.md","en\u002Fblogs\u002FMigration_system","\u002Fcategory\u002Fblog\u002FMigration_system\u002Fimage35.png","Hi3093 Development Board Hands-on Guide (openubmc.cn) Introduction openUBMC supports QEMU simulation and debugging. However, there is no efficient debugging method for hardware debugging. After trying many development boards, I summarized some openUBMC startup experience based on the MYC-LHi3093 development board for your reference. Material Preparation Hi3093 core board Power adapter of the core board Network cable Type-C USB cable SD card of 8 GB or larger (used to restore the openEuler environment if necessary) Environment Preparation The Hi3093 core board is delivered with the openEuler OS by default. We need to replace the openEuler OS with openUBMC RTOS. To do so, complete the following tasks in sequence: Customize and create an openUBMC RTOS image. Plan and format the core board's storage partitions to ensure compatibility with the openUBMC partition table. Creating an openUBMC RTOS Image For details about how to set up the openUBMC development environment, see \" Ubuntu Development Environment Setup | openUBMC \". To facilitate subsequent network communication with the core board,  you are advised to deploy the Ubuntu environment on a VM  and complete all initialization steps in the VM. This section uses VirtualBox to set up the openUBMC development environment. Follow the following steps to set up the environment and create the openUBMC image: Download the Ubuntu 24.04 ISO file and install it in VirtualBox. You are advised to reserve 50 GB storage space. ⭐ If you do not want to manually create a package, you can download the  pre-built Hi3093 image  to skip the build process. Just place related files in their corresponding directories. The  2506_gx.zip  package stores all required files for burning.  *.hpm  is the HPM package designated for deploying the development board environment. ❗ If you manually create a package and use openUBMC 25.03, ensure that the IAM version in the  build\u002Fsubsys\u002Frc\u002Fsecurity.yml  file is  1.0.1 or later .  Set up the openUBMC environment following instructions in \" Ubuntu Development Environment Setup | openUBMC \". Install the openUBMC debugging tool  busybox  and integrate it into manifest. 4.Run the  bingo build  command in the manifest directory to create the openUBMC image. The  rootfs_BMC.img  image file can be found in  temp\u002Fbuild_openUBMC_debug_dev\u002Foutput .  In addition, you need to retrieve  initrd_boot.cpio.gz  (initial Linux RAM disk image) and  uImage  (Linux kernel image) from the  temp  directory.  1.1 Image Burning and Partition Table Configuration 1.1.1 Connecting to the Core Board We need to connect to the Hi3093 core board through a serial port or other available methods. The following figure shows the core board connection.  ❗ During the connection, strictly follow the instructions in the figure. Otherwise, the subsequent operations will fail. 1.1.2 Starting the Core Board The core board is started in eMMC boot mode. Set SW2 as follows.  ⭐ You can refer to the core board's user manual for details about how to start the core board in eMMC boot mode. 1.1.3 Connecting to the Core Board's Serial Port After the core board is connected through a Type-C USB cable, you can use serial terminal software to access the serial console interface. Use Xshell to establish a connection.  Select the SERIAL connection mode and access the serial console interface. Then, configure the port number. You need to test the COM port number. If the connection is successful, Connected is returned.  1.1.4 Starting and Logging In to the Core Board After Xshell establishes a connection to the serial port, start the core board. You can view the print in the Xshell serial console.  Upon completion of the serial display scrolling, a login prompt will appear. If the serial console remains a blank screen, press the Enter key multiple times to invoke the login interface. If you log in for the first time, the account is root, and the password needs to be manually set (see prompts).  1.1.5 Preparing an SD Card Subsequent operations will result in modification of the development board's boot image. However, the SPI lacks SSH connectivity. Therefore, you need to prepare an SD card to back up the image. The procedure is as follows: Run the  fdisk -l  command to display available partitions, find the SD card partition, and initialize the partition. (The initialization command is not restricted as long as the development board can identify it, for example, mkfs.vfat.) Run mount to  mount  the SD card partition to a directory. Upload the SPI burning file provided by the vendor (MYiR) through SSH and copy the file to the SD card partition. If the openEuler environment needs to be restored, you only need to remount the SD card. 1.1.6 Configuring the Partition Table To ensure that the user partition of eMMC can be correctly accessed after openUBMC is started, you need to perform manual partitioning and solidify the partition table in advance. The final partition configuration is as follows:  The actions are as follows: fdisk  \u002Fdev\u002Fmmcblk0\n \n \u002Fdev\u002Fmmcblk0p1:  Execute  n,  select  p  to  create  a  primary  partition,  and  input  16  for  StartLBA  and  2097167  for  EndLBA.\n \n \u002Fdev\u002Fmmcblk0p2:  Execute  n,  select  p,  and  input  2097168  for  StartLBA  and  9269839  for  EndLBA.  Then  execute  t  and  input  c.\n \n \u002Fdev\u002Fmmcblk0p3:  Execute  n,  select  e  to  create  an  extended  partition,  and  input  9269840  for  StartLBA  and  12648447  for  EndLBA.\n \n \u002Fdev\u002Fmmcblk0p5:  Execute  n,  select  l  to  create  a  logical  partition,  and  input  9269856  for  StartLBA  and  9899001  for  EndLBA.  Then  execute  t  and  input  c.\n \n \u002Fdev\u002Fmmcblk0p6:  Execute  n,  select  l,  and  input  9899018  for  StartLBA  and  11367023  for  EndLBA.\n \n \u002Fdev\u002Fmmcblk0p7:  Execute  n,  select  l,  and  input  11367040  for  StartLBA  and  11891327  for  EndLBA.\n \n \u002Fdev\u002Fmmcblk0p8:  Execute  n,  select  l,  and  input  12615680  for  StartLBA  and  12648447  for  EndLBA.\n \n \u002Fdev\u002Fmmcblk0p9:  Execute  n,  select  l,  and  input  11891344  for  StartLBA  and  12615663  for  EndLBA.\n \n Then,  execute  w  to  save  all  the  configurations.\n After the partitions are created, format each partition. For partitions designated as Win95 FAT32, use the mkfs.vfat utility for formatting, for example,  mkfs.vfat \u002Fdev\u002Fmmcblk0p2 . Other partitions need to be formatted using mkfs.ext4, for example,  mkfs.ext4 \u002Fdev\u002Fmmcblk0p1 . 1.1.7 Burning the Image Core Board Network Configuration To burn related image files to the core board, you need to upload the image files to the core board using a file transfer mode such as SFTP. Run the  ifconfig eth2 up 192.168.1.123  command to configure the network on the core board first.  1.1.8 Configuring the Windows Network and Uploading the Image Package Open the network connection page of Windows. Select the appropriate Ethernet (you need to identify the correct Ethernet interface, which can be determined by removing and inserting the Ethernet cable).  Configure the IP address of the Ethernet to be in the same network segment as the core board.  After the configuration, test the network connection on the Windows PC.  If the preceding print is displayed, the connection is successful. Then, you can upload the image files to the  \u002Ftmp  directory of the core board via SFTP. This transfer can be performed using Xshell's SFTP functionality or WinSCP. The following uses WinSCP as an example:  After the connection is successful, upload the following files in  MYD-LHI3093-V2\\SoftwareFiles\\02-Images . ⭐ The files are core board documents provided by MYiR. Upload the openUBMC image package  rootfs_BMC.img  to the  \u002Ftmp  directory and rename the package  Hi3093_ext4fs.img .   Image Package Burning Hi3093 provides an upgrade script. You only need to perform the following procedure through the serial console interface of the core board to complete the upgrade. qemu-aarch64  ~  # cd \u002Ftmp\u002F\n qemu-aarch64  \u002Ftmp  # ls\n Hi3093_ext4fs.img       hi3093_upgrade.sh   l1fw_rsa_4096.bin\n Hi3093_ext4fs_cms.bin   l0fw_rsa_4096.bin   u-boot_rsa_4096.bin\n qemu-aarch64  \u002Ftmp  # \u002Fhi3093_upgrade.sh 4096\n \u002Fdev\u002Fmmcblk0gp0\n \u002Fdev\u002Fmmcblk0gp2\n \u002Fdev\u002Fmmcblk0gp1\n update  temp  L0FW...\n 70+1  records  in\n 70+1  records  out\n 72088  bytes  (72  kB,  70  KiB ) copied, 0.0156561 s, 4.6 MB\u002Fs\n update  temp  L1FW...\n 178+1  records  in\n 178+1  records  out\n 182876  bytes  (183  kB,  179  KiB ) copied, 0.0365372 s, 5.0 MB\u002Fs\n update  temp  u-boot...\n 504+1  records  in\n 504+1  records  out\n 516616  bytes  (517  kB,  505  KiB ) copied, 0.111703 s, 4.6 MB\u002Fs\n update  temp  rootfs_hdr...\n 36+0  records  in\n 36+0  records  out\n 36864  bytes  (37  kB,  36  KiB ) copied, 0.00683788 s, 5.4 MB\u002Fs\n update  temp  rootfs...\n 376+1  records  in\n 376+1  records  out\n 394268672  bytes  (394  MB,  376  MiB ) copied, 2.40696 s, 164 MB\u002Fs\n emmc  update  success,  please  reboot  your  board...\n The \"`emmc update success, please reboot your board...``\" message indicates that the burning is successful. Before rebooting the board, download the \u002Fboot\u002Fhi1711_asci.dtb file on the core board to the Windows PC as a backup over SSH. Run the  reboot  command. Note that the reboot does not mean that the openUBMC image is successfully upgraded. You need to modify the U-Boot configuration to load  initrd_boot.cpio.gz  and  uImage  of openUBMC. 1.1.8.1 U-Boot Configuration Modification Since only the image file has been modified, and the Linux kernel's uImage file remains unchanged, replacement must be executed via TFTP. After the reboot, press Enter until the U-Boot configuration page is displayed.  Before U-Boot configuration, ensure that the core board's U-Boot can access the TFTP server hosted on the Ubuntu development server. Install tftpd in the Ubuntu environment. sudo  apt  install  tftpd-hpa\n After the installation, save the  initrd_boot.cpio.gz  and  uImage  files, as well as the  DTB  file (renamed hi3093.dtb) downloaded from the core board to \u002Fvar\u002Flib\u002Ftftproot. Then, you need to configure the network in VirtualBox Ubuntu VM. For details, refer to \" VirtualBox Network Configuration for PC, VM, and Development Board Ping \". Open the VirtualBox network manager and configure the network as follows:    After the preceding configurations are complete, perform a ping test from Windows to ascertain reachability of the network hosting Ubuntu 24.04.  However, U-Boot will still be unable to ping the Ubuntu environment; therefore, a network bridge must be established. In the Windows network connection configuration page, select both the virtual network and the Ethernet connected to the core board, then right-click and select  Bridge Connections .  ⭐ After the preceding configuration is complete, configure the IP address and gateway of the core board in U-Boot. setenv  ipaddr  192.168.1.123\n setenv  netmask  255.255.255.0\n setenv  gateway  192.168.1.1\n setenv  serverip  192.168.1.111\n Ping 192.168.1.111. If the ping fails, check the network connection. For troubleshooting methods, refer to \" VirtualBox Network Configuration for PC, VM, and Development Board Ping \".  After the communication is established, download the  uImage  and  initrd_boot.cpio.gz  files through TFTP in U-Boot. setenv  tftp_dtb  \"tftp ${ dtb_load_addr } hi3093.dtb\"\n run  tftp_dtb  # Download the DTB file.\n run  tftp_network_boot  # After the execution, ensure that the download is complete.\n run  run_linux  # After the execution, the system is automatically started.\n  Wait until the openUBMC RTOS is started. The serial port information of openUBMC is displayed.  1.2 openUBMC Environment Configuration The default IP address of openUBMC is 192.168.2.100, and the gateway is also 192.168.2.100. The IP address is not in the same network segment as the previous configuration. Therefore, we need to modify the Ethernet configuration to log in to openUBMC. Cancel the Ethernet configuration of the core board in the previously configured bridge.  Right-click Ethernet and manually configure the IP address.  After the configuration, the Telnet connection can be established.  Run the  source \u002Fetc\u002Fprofile  command to enable utilities such as busctl. 1.2.1 openUBMC Password Generation The initial BMC does not have a password. You can run the cat  \u002Fetc\u002Fshadow  command to check whether there is a long encrypted message. If no, you need to manually add a password. # Activate busctl.\n source  \u002Fetc\u002Fprofile\n \n # Change the password.\n busctl  --user  call  bmc.kepler.account  \u002Fbmc\u002Fkepler\u002FAccountService\u002FAccounts\u002F2  bmc.kepler.AccountService.ManagerAccount  ChangePwd  a{ss}\n ay  3  Interface  Web  UserName  Administrator  ClientAddr  127.0.0.1  10  65  100  109  105  110  64  57  48  48  48\n 65  100  109  105  110  64  57  48  48  48  corresponds  to  the  ASCII  code  of  password  Admin@9000.  You  can  customize  the  password  in  this  way.  However,  you  cannot  log  in  to  the  system  using  SSH  because  OpenSSH  lacks  some  files ;  but  you  can  use  the  IPMI  tool  to  test  whether  the  password  is  correct.\n >  . \\i pmitool.exe -H 192.168.2.100 -I lanplus -p 623 -U Administrator -P Admin@9000 -C 17 mc info\n Device  ID                  :  1\n Device  Revision            :  1\n Firmware  Revision          :  25.00\n IPMI  Version               :  2.0\n Manufacturer  ID            :  2011\n Manufacturer  Name          :  Unknown  (0x7DB)\n Product  ID                 :  0  (0x0000)\n Product  Name               :  Unknown  (0x0)\n Device  Available           :  yes\n Provides  Device  SDRs       :  yes\n Additional  Device  Support  :\n     Sensor  Device\n     SDR  Repository  Device\n     SEL  Device\n     FRU  Inventory  Device\n     IPMB  Event  Generator\n     Chassis  Device\n Aux  Firmware  Rev  Info      :\n     0x00\n     0x00\n     0x00\n     0x01\n If the mc info command is executed successfully, the account and password are configured successfully. 1.2.2 Login Through SSH During the SSH connection, an error is reported even if the correct password is entered. This problem is caused by the PAM authentication failure in OpenSSH. # Check the SSH dependency in pam.d.\n ls  -l  \u002Fdata\u002Ftrust\u002Fpam_faillock  \\\n       \u002Flib * \u002Fsecurity\u002Fpam_bmc_login.so  \\\n       \u002Flib * \u002Fsecurity\u002Fpam_selinux.so\n \n # Check whether common-auth, common-account, and common-passwd exist.\n # Generally, these files exist. If \u002Fdata\u002Ftrust\u002Fpam_faillock does not exist, you need to manually create it.\n touch  \u002Fdata\u002Ftrust\u002Fpam_faillock\n chmod  644  \u002Fdata\u002Ftrust\u002Fpam_faillock\n 1.2.3 Login through BMC Web In the initial environment, the BMC certificate is not available. You can use OpenSSL to generate a certificate. Nginx can be started only with a certificate. Certificate preparation file: SSL.p12 Upload  SSL.p12  to the  \u002Ftmp  directory of openUBMC using SFTP or other methods, and then import the certificate. date  -s  \"2025-06-09\"  &&  busctl  --user  call  bmc.kepler.certificate  \u002Fbmc\u002Fkepler\u002FCertificateService  bmc.kepler.CertificateService  ImportCertWithKey  a{ss}isss  3  Interface  Busctl  UserName  Administrator  ClientAddr  127.0.0.1  1  URI  \u002Ftmp\u002FSSL.p12  \"\"\n 💥  2025-06-09  in the preceding command must be set to a time later than the certificate generation time. Otherwise, an import error occurs. After the import is successful, Nginx and Web can be used properly. Then you can log in to openUBMC on the web page. 1.2.4 Fixing the openUBMC System In U-Boot, we have configured TFTP to download kernel files. However, this process cannot be solidified. You can upgrade the  HPM  package on the web page. During the upgrade, the kernel files are burnt to eMMC. In this way, the core board uses the openUBMC system by default after reboot. In addition, the primary and standby partitions are available. 2 QA 2.1 How Do I Roll Back to openEuler? Access the SPI screen and burn the environment. You can refer to the Hi3093 software development manual.  Download the original boot file package of Hi3093 from  https:\u002F\u002Fgitcode.com\u002Ffxx551\u002FHi3093\u002Freleases\u002Fv1.2 .  Decompress the package, upload the content to the Ubuntu VM, and update it to \u002Fvar\u002Flib\u002Ftftpboot. Note that the hi1711_asic.dtb file name must be changed to  hi3093.dtb .  Enter the U-Boot interface of eMMC, configure the network, and ping the VM. Then, configure tftp_network_boot. setenv  tftp_network_boot  'tftp ${dtb_load_addr} hi3093.dtb;\n ${kernel_load_addr} uImage;\n tftp\n tftp ${initrd_load_addr} initrd_boot.cpio.gz;\n bootm ${kernel_load_addr} ${initrd_load_addr} : ${initrd_size} ${dtb_load_addr}'\n  = >  ping  ${serverip}\n  Using  hi309x_gmac  device\n  ## Warning: gatewayip needed but not set\n  host  192.168.1.111  is  alive\n  = >  run  tftp_network_boot\n  = >  run  run_linux\n   2.2 eMMC Partition Description  2.3 Serial Port Suspended After openUBMC Is Burned，串口卡住 Typically, after openUBMC is started, the serial output is directed to the OS. If redirection of the serial output to the serial console interface is required, run the  ipmcset -d serialdir -v 1  command. This command can be input via SSH, or executed via Telnet after  source \u002Fetc\u002Fprofile  is executed. html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[126],{"_path":135,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":136,"description":137,"date":138,"archives":139,"category":61,"author":140,"_type":18,"_id":144,"_source":20,"_file":145,"_stem":146,"_extension":23,"coverImage":147,"plainText":148,"authorNames":149},"\u002Fen\u002Fblogs\u002Fsecure-and-reliable-application","Trusted Security Applications Based on openUBMC","In today's complex and evolving network security landscape, firmware has become a prime target for attackers, with security threats on the rise. As the foundational layer of a computing system, firmware plays a critical role in the overall security and resilience of the system. Given its position at the lowest layer and its high-level privileges, a compromised firmware can render upper-layer protections ineffective. Therefore, enhancing the security and resilience of firmware is of paramount importance in the current threat environment.","2025\u002F06\u002F25","2025-06",[141],{"name":142,"description":143},"李小川","Computing hardware security technology expert at Huawei Technologies Co., Ltd.","content:en:blogs:secure-and-reliable-application.md","en\u002Fblogs\u002Fsecure-and-reliable-application.md","en\u002Fblogs\u002Fsecure-and-reliable-application","\u002Fcategory\u002Fblog\u002Fsecure-and-reliable-application\u002Fimg0.png","Trusted Security Applications Based on openUBMC Firmware Security Risks In today's complex and evolving network security landscape, firmware has become a prime target for attackers, with security threats on the rise. As the foundational layer of a computing system, firmware plays a critical role in the overall security and resilience of the system. Given its position at the lowest layer and its high-level privileges, a compromised firmware can render upper-layer protections ineffective. Therefore, enhancing the security and resilience of firmware is of paramount importance in the current threat environment. Computing systems exhibit the following characteristics: Privilege restriction: Lower layers can limit the privileges of upper layers, whereas upper layers cannot constrain lower layers. Consequently, attacks targeting the firmware layer have a significant impact on upper-level systems. Attack vulnerability: Upper layers cannot effectively defend against attacks originating from lower layers. If the firmware is compromised, the entire system becomes highly vulnerable. Privilege hierarchy: Lower layers possess greater privileges, with hardware holding the highest level. Since firmware operates close to the hardware, ensuring its security is especially critical.  According to the BMC CVE vulnerability statistics, the number of BMC firmware vulnerabilities has steadily increased from 2012 to 2021. In 2021, the count reached 39, significantly higher than in previous years. These vulnerabilities are predominantly high-risk, including types such as remote exploitation and arbitrary code execution. For instance, vulnerabilities like CVE-2013-1945 and CVE-2012-2959 enable remote attackers to execute arbitrary code, posing a serious threat to system security. With the rapid advancement of AI infrastructure, hardware roots of trust (RoTs) vary in design. Some are built-in, while others are external, leading to differences in security capabilities across devices. This variation makes collaboration challenging and poses risks to data center security. Industry implementations include TPM, SGX, Arm TrustZone, and TPCM, some embedded within SoCs and others placed externally on the board. Therefore, both built-in and external hardware RoTs form the basis of firmware trust. In a trusted computing system, the trust chain begins with the hardware RoT, which plays a key role in maintaining platform integrity. A hardware RoT generally includes components such as a cryptographic engine, hardware true random number generator, one-time programmable memory, secure SRAM, and corresponding secure firmware.  Common hardware RoTs include RTM, RTS, and RTR in TPM\u002FTCM, BSBC boot code in secure boot, root public key hashes stored in eFuse, TPCM in Trusted Computing 3.0, and Microsoft's open-source Caliptra RoT, which includes a platform root of trust (pRoT). Based on built-in or external hardware RoTs, trust chain technologies are used to implement security features such as tamper resistance, protection against supply chain replacement, and prevention of unauthorized channel distribution. Cloud providers leverage RoT chips to enable secure boot and hardware identity protection, and they use both internal and external RoTs to perform trusted measurements and identity authentication for intelligent data center components. Chinese CPU manufacturers typically adopt built-in TPCM solutions to achieve trusted computing 3.0 boot and runtime measurement control for server platforms. Trusted Security Application Practices of openUBMC  The trusted security applications of openUBMC, based on the Hi171x series chips, have been thoroughly validated across various scenarios, including computing servers, storage devices, telecom computing platforms, and edge computing. This provides a comprehensive solution for both hardware and software security protection.  Building on the hardware RoT, hierarchical trust chain transfer is implemented to achieve system-level, full-stack, high-security protection. openUBMC establishes trusted and confidential computing capabilities through features such as firmware resilience, trusted boot, secure upgrade, secure boot, secure runtime, and data protection. Its component-based architecture distributes BMC functions across different modules. It optimizes interactions between components through standardized interfaces, unified data storage, and permission management. In addition, openUBMC defines different security levels according to the service attributes of data. Its data partitioning capabilities protect data of varying sensitivity to minimize the risk of data leakage. openUBMC incorporates a sandbox mechanism that defines varying permission levels and minimal resilience scopes based on component services, establishing a multi-layered protection system.  Based on different trusted partitions, openUBMC designs dedicated data recovery and interface permission degradation processes to achieve chip-level RoT boot security and firmware resilience. This ensures the automatic firmware recovery from tampering. openUBMC also offers comprehensive signature and identity authentication capabilities, including end-to-end firmware package signing, verification, decryption, and key management. These features maximize firmware integrity and help prevent tampering.  The openUBMC community has established a transparent R&D process that encompasses requirement acceptance, implementation design, coding, automated community building, and official releases. In addition, openUBMC has developed a comprehensive vulnerability management system based on the community's source code and third-party libraries. This system enables process-driven management of software vulnerabilities and risks to maximize software security. Summary  The standardization of external RoTs, including hardware design and interfaces, and the open-sourcing of built-in RoTs are expected to be the future trend. In heterogeneous trusted computing systems, memory pooling increases the attack surface. Traditional TPM-based trusted boot technology, DICE environment protection, and RoT interconnection technologies will be integrated and unified. They will become essential security capabilities for smart components. In China, trust chain transfer, secure signatures, and code cross-auditing are major gaps in the security ecosystem. The complexity of security technologies slows down adoption and implementation. Systems like Microsoft's logo certification and the OCP S.A.F.E firmware signing framework provide useful examples for China. The openUBMC community aims to work with upstream and downstream industry partners to build a strong firmware security ecosystem in China. The openUBMC community invites industry peers to join in creating a new firmware ecosystem and establishing a first-class firmware security environment in China.",[142],{"_path":151,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":152,"description":153,"date":154,"sig":122,"archives":155,"category":106,"author":156,"_type":18,"_id":158,"_source":20,"_file":159,"_stem":160,"_extension":23,"coverImage":161,"plainText":162,"authorNames":163},"\u002Fen\u002Fblogs\u002Fstart_openUBMC","Zero to Hero: Getting Started with openUBMC","openUBMC is a leading, open-standard, and developer-friendly open source management software for computing devices. In this blog, we'll guide you step-by-step to get started with openUBMC from scratch.","2025\u002F05\u002F10","2025-05",[157],{"name":126,"description":127},"content:en:blogs:start_openUBMC.md","en\u002Fblogs\u002Fstart_openUBMC.md","en\u002Fblogs\u002Fstart_openUBMC","\u002Fcategory\u002Fblog\u002Fstart_openUBMC\u002Fimage0.png","Zero to Hero: Getting Started with openUBMC openUBMC is a leading, open-standard, and developer-friendly open source management software for computing devices. In this blog, we'll guide you step-by-step to get started with openUBMC from scratch. Environment Setup on Ubuntu The openUBMC official website offers several setup methods. We'll use the Ubuntu installation, which offers the highest level of flexibility. (For a faster start, see the  Docker Developer Environment Setup . 1. Configuring Your GitCode Account First, you need to configure access to the GitCode repository. Go to the (project's homepage) https:\u002F\u002Fgitcode.com\u002FopenUBMC\u002Fmanifest .  Click  Clone . A dialog will show you how to configure your GitCode account and clone the repository.  Execute the recommended  git config  commands in your Ubuntu terminal.  Set up your SSH public key by following steps 2 and 3 as prompted by GitCode.  Note: We recommend using SSH instead of HTTPS for downloading. This avoids complex HTTPS token configuration. Execute this command: git  config  --global  url.\"git@gitcode.com:\".insteadof  \"https:\u002F\u002Fgitcode.com\u002F\"\n 2. Downloading the Manifest Repository The manifest repository is your key to setting up the openUBMC environment automatically. Create a workspace and clone the repository:  mkdir  workspace\n cd  workspace\n git  clone  git@gitcode.com:openUBMC\u002Fmanifest.git\n  Before initialization, download  bmc_sdk.zip  from the  openUBMC community software application center  and place it inside your cloned manifest directory. Execute the environment initialization script: cd  manifest\n python3  init.py  -path  .\u002Fbmc_sdk.zip\n  The  init.py  script performs a comprehensive setup, including: Setting environment proxies. Acquiring sudo permissions. Configuring Ubuntu package mirrors (using Huawei mirror sites). Installing necessary Ubuntu packages (such as python3, gcc, and dbus). Installing the openUBMC developer suite (including RTOS build tools, SDK, and lua-format). Installing Node and npm. Installing the openUBMC build tool, bingo. Configuring Conan remote repositories. Installing QEMU development and runtime dependencies. The successful completion is marked by the final output printout. You have now completed your development environment setup!  3. Configuring Your Conan User The openUBMC documentation requires you to configure the Conan user with your openUBMC community username.  Execute the necessary configuration command. You will see a success message upon completion.  Verify the configuration using the conan search command.  Note: To find your openUBMC community username, log in to the openUBMC official website and look for the name displayed in the upper right corner. Start Your openUBMC Journey Now that the environment is rea dy, let's explore building and running openUBMC. 1. Building the openUBMC Firmware Update Package The manifest repository can also perform an automated full-package build using the openUBMC-provided  bingo  tool. From the manifest directory, run: bingo  build\n  The output shows the build has started. The build process typically takes about 4 to 6 minutes (depending on your host CPU). The final firmware update package ( .hpm  file) will be located at  manifest\u002Foutput\u002Frootfs_openUBMC.hpm . This package is used to update the BMC firmware on a server. 2. Starting openUBMC Simulation (QEMU) Hardware debugging resources are often scarce. openUBMC provides a QEMU-based simulation for easier development. Build the QEMU simulation firmware package: bingo  build  -sc  qemu\n  Once the personal task is reported successful, the simulation firmware package is complete. Find  openUBMC_25.00.00.01_qemu.cpio.gz  in the  manifest\u002Foutput\u002Fpacket\u002Finner  directory.  Start the openUBMC simulation environment with a single command: python3  build\u002Fworks\u002Fpacket\u002Fqemu_shells\u002Fvemake_1711.py\n  Wait 5 to 10 minutes (depending on your host performance). The simulated openUBMC environment will be ready! Interacting with openUBMC Once the simulation starts, you can interact with openUBMC via its interfaces. WebUI : Access openUBMC through its WebUI. Log in with the username and password and explore the various features available.  SSH CLI : Connect to the CLI via SSH: ssh  Administrator@ \u003C your  i p > :10022\n Enter the password to access the CLI and start executing commands.  You are now set up to develop and test with openUBMC! Reference Exploring openUBMC html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[126],{"_path":165,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":166,"description":167,"date":168,"category":106,"author":169,"_type":18,"_id":171,"_source":20,"_file":172,"_stem":173,"_extension":23,"coverImage":174,"plainText":175,"authorNames":176},"\u002Fen\u002Fblogs\u002Fcla","Corporate CLA: Your Guide to Joining the openUBMC Community","CLA 是 Contributor License Agreement 的缩写，一般翻译为贡献者许可协议。","2025\u002F03\u002F30",[170],{"name":109,"description":110},"content:en:blogs:cla.md","en\u002Fblogs\u002Fcla.md","en\u002Fblogs\u002Fcla","\u002Fcategory\u002Fblog\u002Fcla\u002Fimages\u002Fcla-en-1.png","Corporate CLA: Your Guide to Joining the openUBMC Community If your company plans to contribute to the openUBMC community, signing a Contributor License Agreement (CLA) is a must. 1. Why Does Your Company Need to Sign a CLA? A CLA is essential for any open source project. When developers contribute code, the CLA ensures the project maintainers have the necessary legal rights. Ownership and Rights: The CLA declares that the contributor owns the content (or has the proper authorization to contribute it). Redistribution: It allows the project to re-distribute the contribution under the project's existing license. Copyright & Patent: The contributor retains their copyright. If the contribution includes patents, the CLA grants the project a license to use those patents. 2. Signing the Corporate CLA 2.1 Accessing the Signing Page Go to the  official CLA signing page . Click Sign Corporate CLA.  2.2 Completing the Online Form Fill in the required information. Enter your corporate email address. Click to get the verification code. The code will be sent to your corporate email. Enter the code and click SIGN. Note: Use a stable corporate email for signing. This email cannot be changed later.  2.3 Printing,  Stamping, and Signing the Document A follow-up email will arrive with a PDF attachment. This PDF contains the CLA you just signed online. Print the PDF document. Have an authorized representative sign and date it. Affix your official company stamp to the document.  2.4 Submitting the Final CLA Scan the signed and stamped document into a single PDF file. Reply to the email you received in section 2.2, attaching the scanned CLA PDF. 2.5 Notification to Administrators The openUBMC CLA system administrators will check the submitted PDF. Upon successful verification, the email used for signing will receive a confirmation. This confirmation email includes the username and initial password for the super administrator account of your corporate Employee CLA management system.  3. Managing Employee Contributions (CLA System Usage) Once the Corporate CLA is signed, the management system controls which employees can contribute. 3.1 Logging In Go to the  CLA system login page . Click C orporation Manager .  Use the provided super administrator credentials to log in.  3.2 Super Administrator Tasks The super administrator's primary job is to manage system administrators. Log in and immediately change the initial password. Create or delete system administrators. When a system administrator is created, it receives a notification email.  Super administrator vs. System administrator: The super administrator manages system administrator accounts. System administrators perform the day-to-day management of employee contributions. The two roles must use separate accounts. 3.3 System Administrator Tasks System administrators manage the Employee CLAs: Upon logging in, the system administrator sees a list of employees who have signed the Employee CLA but are not yet activated. The system administrator can activate an employee's contribution rights or delete their request.  The system administrator can also view the activated employee list and change an employee's status to inactive if needed.  4. Signing the Employee CLA After the company signs the Corporate CLA, employees must sign the Employee CLA before making their first contribution. 4.1 Accessing the Employee CLA Go to the  employee signing page . Click Corporate Contributor Registration.  4.2 Completing the Online Form Employees must use their corporate email to sign. Fill in the form and get the verification code via email. Submit the form to complete the signing.  4.3 Notification to Administrators The CLA system automatically notifies the company's system administrators. The system administrators then review and activate the employee's contribution rights (see section 3.3).  5.FAQs Who Should Sign the Corporate CLA? An authorized representative of the company. It does not need to be the legal representative. Which Email Can Be Used? Only stable corporate domain emails (for example,  name@yourcompany.com ) are accepted for the Corporate CLA. Generic personal emails (for example, Gmail and QQ) are not allowed for corporate signing. Does the openUBMC Community Commit to an SLA? No. All issue and CVE resolution is done by community contributors. Since there is no commercial commitment, the openUBMC community does not commit to an SLA for issue resolution. If you face any signing difficulties, please contact us: WeChat : openUBMC123 Email :  cla@public.openUBMC.org Ready to contribute? Sign the CLA and join the openUBMC community!",[109],{"_path":178,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":179,"description":180,"date":168,"archives":181,"category":106,"author":182,"_type":18,"_id":184,"_source":20,"_file":185,"_stem":186,"_extension":23,"plainText":187,"authorNames":188},"\u002Fen\u002Fblogs\u002Fcontribution-guide","openUBMC Blog Contribution Guide","注册openUBMC账号，成为社区的一员","2020-03",[183],{"name":109,"description":110},"content:en:blogs:contribution-guide.md","en\u002Fblogs\u002Fcontribution-guide.md","en\u002Fblogs\u002Fcontribution-guide","openUBMC Blog Contribution Guide Want to share your knowledge with the openUBMC community? Contributing a blog post is easy. Here is how you can submit your technical content.  Preparations Before you contribute, please complete these two quick steps: Register an openUBMC account to become an official member of the community. Register with the  openUBMC forum  and get familiar with the forum rules and community discussions.  Contribution Option 1: Forum Featured Posts The easiest way to contribute a blog is by writing a popular post on the openUBMC forum. Review process: Every month, the sig-docs reviews the community forum. Selection criteria: They select experience-sharing posts that have high views and strong discussion. These posts become official openUBMC blogs. Announcement: The final list of selected blogs is announced during the monthly meeting. Tip: To simplify the future blog formatting, try to write your forum post using the official blog document format from the start.  Contribution Option 2: Self-Nominate to sig-docs You can also proactively submit content directly to the sig-docs. Submission: Send your blog content and a short personal bio via email to  docs@public.openubmc.cn . Response: The sig-docs will review your submission and reply within one week. Announcement: Accepted blogs are added to the list announced at the monthly meeting.  Understanding the Blog Format All openUBMC blogs must be written in the Markdown format. Your file must include the following information in the file header (metadata): ---\n title :  'Sample Post'\n date :  '2025\u002F03\u002F30'\n tags :\n     -  Sample\n     -  ABC\n     -  cccc\n sig :  sig-xxx\n archives :  '2020-03'\n author :\n   -  name :  '\u003Cyour name>'\n     title :  'title'\n     description :  'description'\n     avatar :  'avatar'\n description :  \"Just about everything you'll need to style in the theme: headings, paragraphs, blockquotes, tables, code blocks, and more.\"\n ---\n Here you can edit your blog.\n html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html .sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}html.sepia .shiki span {color: var(--shiki-sepia);background: var(--shiki-sepia-bg);font-style: var(--shiki-sepia-font-style);font-weight: var(--shiki-sepia-font-weight);text-decoration: var(--shiki-sepia-text-decoration);}",[109],1784971479655]