Usage Questions¶
1. How is OpsAny's permission model designed, and how should I grant permissions?¶
- User roles and permissions
There are three roles: Administrator, Regular user, and Developer.
- Administrator: can see all data (see data permissions below) but not all pages; permissions must be granted by creating permission policies (see page permissions below).
- Regular user: sees only the pages and data that have been granted.
-
Developer: like a regular user, but can open the Developer Center.
-
OpsAny has two kinds of permissions:
- Page permissions: which platform, which page, and which buttons a user can see. Configured in the 【Unified Permissions】 platform following the RBAC (Role-Based Access Control) model, by creating "permission policies".
-
Data permissions: which specific instances a user can see — which hosts, which scripts, which applications. Instance permissions are granted by creating authorization policies in the 【Resource Platform】. Exception: the 【Bastion Host】 authorizes independently through its own permission policies.
-
Summary: administrators see all data by default and need no data authorization, but the pages they can access must be granted. Regular users need both page and data authorization. This differs from public clouds: most public clouds have no CMDB concept, so page and data permissions are granted together. In OpsAny, data permissions are managed centrally by the 【Resource Platform】 CMDB.
2. What if I forget the admin password? What if MFA stops working? What if the account is locked?¶
First, a newly installed platform changes the password automatically when installation finishes and prints it, and also writes the new password to 【$INSTALL_PATH/conf/.passwd_env】. (This prevents the weak-credential risk of leaving the default admin password in place.)
If you changed the password yourself and forgot it, there is a script to re-initialize the admin password in the opsany-paas-login container.
# Reset the admin password
docker exec -it opsany-paas-login sh -c "python /opt/opsany/paas/login/init_admin.py"
If the account is locked after too many failed attempts, there is a script to unlock the admin account in the opsany-paas-login container. To unlock a non-admin user, sign in as an administrator and unlock it under Unified Permissions → User Management.
# Unlock admin
docker exec -it opsany-paas-login sh -c "python /opt/opsany/paas/login/unlock_admin.py"
If MFA stops working, there is a script to reset the admin user's MFA in the opsany-saas-ce-rbac container. To unbind MFA for a non-admin user, sign in as an administrator and unbind it under Unified Permissions → User Management.
# Unbind MFA for admin
docker exec -it opsany-saas-ce-rbac sh -c "python /opt/opsany/rbac/rbac/utils/reset_admin_mfa"
3. How do I replace the HTTPS certificate?¶
Put the certificate into ${INSTALL_PATH}/conf/nginx-conf.d/ssl/, named after $DOMAIN_NAME, then restart the container: docker restart opsany-base-openresty.
For example, the demo environment applies for an HTTPS certificate after installation and replaces it like this.
[root@demo ~]# /bin/cp 7310312_demo.opsany.com.pem /data/opsany/conf/nginx-conf.d/ssl/demo.opsany.com.pem
[root@demo ~]# /bin/cp 7310312_demo.opsany.com.key /data/opsany/conf/nginx-conf.d/ssl/demo.opsany.com.key
[root@demo ~]# docker restart opsany-base-openresty
4. How do I view log files¶
Log files live in the logs directory under the installation path. Each platform has its own directory, named after the platform's APPID. Tips for reading logs:
-
- Clear the log first so old entries do not confuse you.
-
- Perform the operation in the UI, then read the log it produces.
-
- Send the log to the community WeChat group for help.
ls /data/opsany/logs
- Unified permissions (rbac)
- Workbench (workbench)
- Resource platform (cmdb)
- Control platform (control)
- Job platform (job)
- Basic monitoring (monitor)
- Cloud management platform (cmp)
- Bastion host (bastion)
- Application platform (devops)
- Pipeline (pipeline)
- Continuous deployment (deploy)
- Artifact repository (repo)
Example:
[root@ops ~]# ls -l /data/opsany/logs/control/
total 2184
-rw-r--r-- 1 root root 117858 Nov 3 11:54 celery-beat.log # Scheduled task log, e.g. scheduled jobs in the Job Platform, automatic cloud host sync in the Cloud Management Platform.
-rw-r--r-- 1 root root 414197 Nov 3 11:54 celery.log # Background task log, e.g. cloud host sync, host onboarding, adding monitoring.
-rw-r--r-- 1 root root 7126 Nov 2 21:41 component.log # System unavailable — usually check this log
-rw-r--r-- 1 root root 827069 Nov 3 11:54 control.log # Feature misbehaving — usually check this log; it carries the concrete error.
-rw-r--r-- 1 root root 438828 Nov 3 11:54 nginx-access.log
-rw-r--r-- 1 root root 0 Nov 2 21:18 nginx-error.log
-rw-r--r-- 1 root root 0 Nov 2 21:18 nginx-supervisor.log
-rw-r--r-- 1 root root 318597 Nov 3 11:54 uwsgi.log # Process startup log — check this when a service will not start.
-rw-r--r-- 1 root root 0 Nov 2 21:18 wb_mysql.log
5. The Bastion Host cannot connect to a target host — how do I troubleshoot?¶
Possible causes:
- Port 22 is unreachable on the target host
- Wrong username or password
- Certificate error
- The SSH protocol is not supported
How to troubleshoot:
Test by signing in manually
docker exec -it opsany-paas-websocket /bin/sh
ssh root@target-host
6. The Bastion Host cannot connect after the operating system was reinstalled?¶
Reinstalling the operating system changes the host fingerprint, so the Bastion Host refuses the connection — deliberately, for security. This is not ignored automatically yet; restart the WebSocket service.
docker restart opsany-paas-websocket
7. Why does host onboarding succeed while the Bastion Host fails to connect?¶
Host onboarding and Bastion Host connections are implemented quite differently.
- Host onboarding: goes through the Proxy, which reaches the target host over Agent/SSH.
- Bastion Host: goes through the WebSocket container, which reaches the target host over SSH/Telnet.
So when SSH onboarding fails, test from the proxy container; when the Bastion Host fails, test from the websocket container.
8. How do I use the API field correctly in the Workbench ITSM ticket process designer?¶
-
OpsAny only fetches data, so only GET requests are supported.
-
The API can come from anywhere. If it is outside the platform and needs authentication, supply extra Header parameters.
-
The "data extraction key path" declares how to read the data, for example:
# What the API actually returns
{
"code": 200,
"api_code": 20000,
"data": [
{
....
}
]
}
# After clicking Test Connection you get:
{
"status": true,
"message": "request sent successfully",
"data": {
"code": 200,
"api_code": 20000,
"data": [
{
....
}
]
}
}
# So the "data extraction key path" must be: data.data
Therefore none of your keys may contain a dot.
# Dropdown (single) and dropdown (multi) share the same structure:
# key and name are mandatory, and key must be globally unique. Other structures will not work.
[
{
"key": "key1",
"name": "name1"
},
{
"key": "key2",
"name": "name2"
},
{
"key": "key3",
"name": "name3"
}
]
# Cascading menus need this structure:
# key, name, and children are mandatory, and key must be globally unique
[
{
"key": "key1",
"name": "name1",
"children": [
{
"key": "key1.1",
"name": "name1.1"
},
{
"key": "key1.2",
"name": "name1.2"
},
{
"key": "key1.3",
"name": "name1.3"
}
]
},
{
"key": "key2",
"name": "name2",
"children": [
{
"key": "key2.1",
"name": "name2.1"
},
{
"key": "key2.2",
"name": "name2.2"
},
{
"key": "key2.3",
"name": "name2.3"
}
]
},
{
"key": "key3",
"name": "name3",
"children": [
{
"key": "key3.1",
"name": "name3.1"
},
{
"key": "key3.2",
"name": "name3.2"
},
{
"key": "key3.3",
"name": "name3.3",
"children": [
{
"key": "key3.3.1",
"name": "name3.3.1"
},
{
"key": "key3.3.2",
"name": "name3.3.2"
},
{
"key": "key3.3.3",
"name": "name3.3.3"
}
]
}
]
}
]
- Note: we neither store nor validate your data, so keys and names in your API response must not contain spaces, the pipe character (
|), dots (.), or other special characters. - Remark: key values must be globally unique, including within cascading menus.
- Test endpoints:
# Dropdown (single and multi) test endpoint https://DOMAIN_NAME/o/workbench/api/workbench/v0_1/api-fields-example/ # Cascading menu test endpoint https://DOMAIN_NAME/o/workbench/api/workbench/v0_1/api-fields-tree-example/
9. I entered physical machines, racks, zones, and data centers, but the view shows nothing and bulk operations do not work?¶
Data entered on the Resource Platform appears in the views only after relationships are configured. The host view and the physical view both render data along the data center → zone → rack hierarchy. The same applies to bulk relationship assignment in the Resource Warehouse. For example, you may want to place many physical machines into one rack but cannot select that rack — because the rack is not linked to a zone, or the zone is not linked to a data center. Missing relationships cause this.
10. I added a custom field to physical machines, virtual machines, and cloud hosts, but it does not appear in the host view?¶
OpsAny splits hosts into three types: physical machines, virtual machines, and cloud hosts. View management therefore shows only the fields common to all three models. A custom field added to only one model — say virtual machines — will not appear in the view, though it does appear in the Resource Warehouse.
11. What if the monitoring plugin fails to install?¶
When onboarding hosts in the Control Platform you can choose automatic or manual installation of monitoring plugins. With so many operating systems and differing user environments, failures do happen. Check as follows:
-
- Check whether the Agent is running and its configuration is correct.
# Check the service status.
systemctl status zabbix-agent
# Check whether "Server=" and "ServerActive=" in the configuration point at the Server IP
grep -v '^#' /etc/zabbix/zabbix_agentd.conf
-
- Open the Zabbix web UI and check the status
Check the host status on the Zabbix web UI host page and look for the cause.
