cml-admin
$
npx mdskill add automateyournetwork/netclaw/cml-adminAdministers CML systems with user/group management, licensing, and resource monitoring.
- Solves tasks like creating users, checking licenses, and auditing lab usage.
- Uses CML MCP server APIs and environment variables for authentication.
- Determines actions based on user input and available CML administrative tools.
- Delivers structured results via JSON output or direct API responses.
SKILL.md
.github/skills/cml-adminView on GitHub ↗
--- name: cml-admin description: "CML administration — user/group management, system info, licensing, resource monitoring. Use when creating CML users, checking license status, monitoring CML server resources, or auditing lab usage across teams." version: 1.0.0 license: Apache-2.0 tags: [cml, admin, users, groups, system, licensing] --- # CML Administration ## MCP Server - **Command**: `cml-mcp` (pip-installed, stdio transport) - **Requires**: `CML_URL`, `CML_USERNAME`, `CML_PASSWORD` environment variables ## Available Tools ### User Management | Tool | Parameters | What It Does | |------|-----------|-------------| | `get_users` | none | List all CML users | | `create_user` | `username`, `password`, `fullname?`, `email?`, `admin?` | Create a new CML user | | `get_user` | `user_id`/`username` | Get user details (labs, resource usage) | | `update_user` | `user_id`/`username`, fields to update | Update user properties | | `delete_user` | `user_id`/`username` | Delete a CML user | ### Group Management | Tool | Parameters | What It Does | |------|-----------|-------------| | `get_groups` | none | List all CML groups | | `create_group` | `name`, `description?`, `members?` | Create a new group | | `update_group` | `group_id`/`name`, fields to update | Update group properties | | `delete_group` | `group_id`/`name` | Delete a group | ### System Information | Tool | Parameters | What It Does | |------|-----------|-------------| | `get_system_info` | none | CML version, uptime, resource usage (CPU, RAM, disk) | | `get_node_defs` | none | List all available node definitions and their resource requirements | | `get_licensing` | none | License status, node count, expiration | | `get_resource_usage` | none | Current resource utilization across all labs | ## Workflow: Onboard a New Lab User When an admin wants to add a new team member: 1. **Check existing users**: `get_users` to see current user list 2. **Create the user**: `create_user` with their credentials 3. **Add to group** (optional): `update_group` to add user to a team group 4. **Verify**: `get_user` to confirm creation 5. **Share credentials**: Report the username and CML URL to the admin (never share the password in Slack) ## Workflow: Resource Capacity Check Before building a large lab: 1. **Check system resources**: `get_system_info` for CPU, RAM, disk 2. **Check licensing**: `get_licensing` for available node count 3. **Check node definitions**: `get_node_defs` for per-node resource requirements 4. **Calculate**: Does the planned lab fit within available resources? 5. **Report**: "You have X GB RAM free, Y CPU cores available, Z node licenses remaining. Your planned lab needs A GB RAM and B nodes." ## Workflow: System Health Report For CML server health monitoring: 1. **System info**: `get_system_info` — version, uptime, resource usage 2. **Licensing**: `get_licensing` — license status and node count 3. **Resource usage**: `get_resource_usage` — breakdown by lab/user 4. **Active labs**: `get_labs` (from cml-lab-lifecycle) — list running labs 5. **Generate report**: Summary of CML platform health ## Resource Planning Guide Typical per-node resource requirements: | Node Type | vCPUs | RAM | Disk | |-----------|-------|-----|------| | IOSv | 1 | 512 MB | 2 GB | | IOSv L2 | 1 | 768 MB | 2 GB | | CSR1000v / Cat8000v | 1 | 3 GB | 8 GB | | NX-OS 9000v | 2 | 6 GB | 8 GB | | IOS-XR 9000v | 2 | 8 GB | 16 GB | | ASAv | 1 | 2 GB | 8 GB | | Ubuntu Server | 1 | 512 MB | 8 GB | | Unmanaged Switch | 0 | 0 | 0 | | External Connector | 0 | 0 | 0 | **Rule of thumb**: Plan for the CML host to have at least 2x the total RAM needed by all concurrent labs, plus 8 GB for the CML OS itself. ## User Roles | Role | Capabilities | |------|-------------| | **Admin** | Full access: create/delete users, manage all labs, system settings | | **User** | Create/manage own labs, view shared labs | ## Workflow: Audit CML Usage For tracking who's using what: 1. **List all users**: `get_users` 2. **For each user**: `get_user` to see their labs and resource usage 3. **List all labs**: `get_labs` with ownership info 4. **Check resource usage**: `get_resource_usage` for allocation breakdown 5. **Report**: Table of users, their labs, running state, and resource consumption 6. **Identify stale labs**: Labs that have been stopped for days — candidates for cleanup ## Important Rules - **Admin operations require admin credentials** — user management needs admin-level CML access - **Never share passwords in Slack** — report usernames only, instruct admin to share credentials securely - **Check resources before big labs** — don't let users build labs that exceed server capacity - **Monitor licensing** — CML has node count limits; stay within license boundaries - **Record in GAIT** — log all admin operations for audit trail ## Environment Variables - `CML_URL` — CML server URL - `CML_USERNAME` — CML username (admin for full access) - `CML_PASSWORD` — CML password - `CML_VERIFY_SSL` — Verify SSL certificate (true/false)