> For the complete documentation index, see [llms.txt](https://doc.engenius.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.engenius.ai/edcc-user-manual/appendix/glossary.md). # Glossary ## Appendix B: Glossary of Terms *A comprehensive glossary of key terms and concepts used throughout the EDCC User Manual.* *** ### A **Action**: An operation that can be performed on a selected item, such as a node or a backup file. Actions are typically found in the **Actions** column of a table or in a toolbar. **Apply Button**: A common interface element in the EDCC interface that confirms and saves any changes made in a dialog box or on a settings page. *** ### B **Backup (Configuration)**: A snapshot of the specific configuration settings for all nodes within a selected POD. Used for node-level recovery and POD templating. **Backup (System)**: A complete backup of the entire EDCC platform, including all user accounts, system settings, and global configurations. Used for platform-level disaster recovery or migration. **BMC (Baseboard Management Controller)**: A specialized microcontroller embedded on the motherboard of a server. It allows for out-of-band management and monitoring of the server's hardware, independent of the main operating system. EDCC communicates primarily with the BMC using Redfish protocol. *See also: Redfish Protocol, Out-of-Band Management.* **BMC SEL (System Event Log)**: A hardware-level log stored within the BMC that records all significant hardware-related events, such as sensor warnings, power state changes, and component failures. Distinct from the platform-level Event Log. *See also: Event Log, Sensors Tab.* *** ### C **CONFIGURE Module**: The EDCC module containing POD-level configuration tools including OS Deployment, Firmware Provisioning, and General Settings. Only accessible when POD scope is selected and requires Admin permissions. *** ### D **Dashboard**: The main monitoring interface providing POD health status, infrastructure metrics, and system activity overview. Available at Organization, Hierarchy View, and POD scopes. **De-register**: The action of permanently and irreversibly removing a node from the EDCC system. The node will no longer be listed in the **Inventory** and must be registered again to be managed. *** ### E **Event Log**: The EDCC platform's centralized logging system, which records both Device Events (e.g., node online/offline) and System Events (administrator actions). This is distinct from the hardware-focused BMC SEL. *See also: BMC SEL.* *** ### F **Firmware Provisioning**: The EDCC feature that allows for the automated, scheduled update of BMC and BIOS firmware for all nodes within a POD based on a defined maintenance window. *** ### G **Group**: A logical label or tag used in the **Node List** to filter and organize nodes. A node can belong to multiple groups simultaneously. Groups are used for administrative convenience and do not affect node configuration. *** ### H **Hierarchy View (HV)**: An optional management layer within the three-tier hierarchy, positioned between an **Organization** and its **PODs**. An HV acts as a container to group multiple PODs for aggregated, monitor-only views. *See also: Organization, POD, Management Scope.* *** ### I **Inventory**: The central holding area within EDCC for all registered nodes that have not yet been assigned to a POD. Nodes in the **Inventory** are considered unmanaged assets and cannot be monitored or configured until assigned to a POD. *** ### M **MANAGE Module**: The primary EDCC module for daily operations, monitoring, and node management, including **Dashboard**, **Node List**, **Node Detail**, and **POD View**. **Management Tree**: The collapsible, hierarchical menu accessed via the hamburger menu that allows users to navigate and select their management scope (**Organization**, **Hierarchy View**, or **POD**). *** ### N **Node**: The standard term used in EDCC to refer to a managed EnGenius server (EAS1210/EAS2210 series). **Node Detail**: The comprehensive management interface for individual nodes, containing six specialized tabs: **Summary**, **System Information**, **Sensors**, **BMC SEL**, **Operations**, and **Services**. **Node List**: The central node management interface for viewing, organizing, and performing bulk operations on nodes within the current management scope. **Notification Center**: The centralized UI element (bell icon) for viewing real-time system and management scope notifications. *** ### O **Operations Tab**: The **Node Detail** tab restricted to Admin roles that provides direct BMC command execution for power control, firmware updates, and maintenance operations. High-risk operations with immediate hardware effects. **Organization (Org)**: The highest level in the EDCC three-tier management hierarchy. An Organization acts as the top-level container for all users, PODs, and Hierarchy Views. *See also: Hierarchy View, POD, Management Scope.* **Organization Admin**: A user role with the highest level of permissions, including access to **Team Members** management and **System Settings**. Automatically inherits Admin rights for all PODs within the Organization. **OS Repository**: The feature within OS Deployment that serves as a centralized library for storing bootable ISO image files used for remote OS installation. **Out-of-Band Management**: A method of managing a server's hardware (e.g., power, firmware) through a dedicated management channel (the BMC), even if the server's main operating system is turned off or unresponsive. *See also: BMC, Redfish Protocol.* *** ### P **POD (Point of Deployment)**: The primary management unit in EDCC where nodes are actively managed. It functions as a container for grouping nodes for unified monitoring, bulk operations, and applying POD-wide settings like time zones and firmware schedules. The only scope where configuration operations are permitted. *See also: Organization, Hierarchy View, Management Scope.* **POD Admin**: A user role with administrative permissions for specific PODs, including configuration changes and operations execution within assigned PODs. Does not have access to Organization-level functions. **POD View**: The visual topology management interface that provides drag-and-drop planning of rack layouts and server placement within a POD. **Profile (Service Profile)**: A saved template of monitoring parameters (e.g., check interval, timeout) that defines how EDCC's Redfish services should poll nodes for health and system information. **Protect (Backup)**: An action that locks a Configuration Backup to prevent it from being accidentally deleted or modified. *** ### R **Re-Backup**: An action that updates an existing Configuration Backup with the node's most current settings, allowing for versioning without creating a new backup file. **Redfish Protocol**: An industry-standard RESTful API protocol used by EDCC for secure, out-of-band communication with server BMCs. Enables hardware monitoring, power control, firmware updates, and remote operations independent of the server's operating system status. *See also: BMC, Out-of-Band Management.* **Register**: The process of adding a new node to the EDCC system, which places it in the global **Inventory**. Can be accomplished through IP scanning, manual entry, or bulk CSV import. **Remove from POD**: The action of moving a node out of a POD and returning it to the unmanaged state in the global **Inventory**. This action permanently deletes all POD-specific history and configuration data for that node. **Restore**: The action of overwriting current settings with data from a backup file. This can be done at the node level (Configuration Restore) or platform level (System Restore). **Warning**: Restore operations are irreversible. *** ### S **Scope (Management Scope)**: The user's current context or viewpoint within the EDCC interface, determined by what is selected in the **Management Tree** (**Organization**, **Hierarchy View**, or **POD**). The selected scope dictates which nodes are visible and what actions are available. **Sensors Tab**: The **Node Detail** tab providing detailed, real-time hardware sensor monitoring including temperature, voltage, fan speed, and power readings with manufacturer-defined thresholds. **Summary Tab**: The primary **Node Detail** tab combining node identification, live sensor charts, and essential configuration settings in a unified dashboard view. **System Settings**: The Organization Admin-only administration area containing **Inventory**, **System Information**, **Application Settings**, and **Backup & Restore** functions. *** ### T **Team Members**: The Organization Admin-only interface for user account management, role assignment, and POD access delegation. **Two-Factor Authentication (2FA)**: An optional security feature that requires users to provide a second form of verification (a time-based code from an authenticator app) in addition to their password when logging in. *** ### V **Virtual Device**: A placeholder item in the **POD View** that represents a non-managed piece of equipment (e.g., a switch, PDU, or future server). It is used purely for visual planning and capacity management and has no real-world management counterpart. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.engenius.ai/edcc-user-manual/appendix/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.