in order to better understand the ACC architecture and the current components it is made up of, I'll give a brief description here.
ACC has three vital components:
(1) Command-Server
This daemon is the gateway for clients and users to the ACC system, e.g. coming from the WebFrontend you land right here. It is also the central point for authentication and authorization (rights and roles). Lastly it provides system configuration and maintenance functionality of the ACC itself, e.g. backup/restore, Up2Date Cache.
It does provide the functionality for treeviews and caches relevant data, but does not cache other device-specific information, especially monitoring or inventory. In addition the Command-Server provides the scheduled maintenance functionality.
The Command-Server establishes connections to both the Agent-Manager (2) and the Database-Proxy (3).
The Command-Server can be stopped/started via:
/etc/init.d/commandserver.sh
Logfiles can be found here:
/var/log/command-server.log
(2) Agent-Manager
This daemon talks to the device-agent(s) living on your various ASG devices. It is responsible for refreshing and retrieving monitoring and inventory data as well as propagating device maintenance operations like triggering Up2Dates.
It is a double ended-server. One end serves connecting devices, the other serves connections from the Command-Server (2). Additionally, the Agent-Manager establishes connections to the Database-Proxy (3).
The Agent-Manager can be stopped/started via:
/etc/init.d/agentmanager.sh
Logfiles can be found here:
/var/log/agent-manager.log
It has a local file cache located here:
/var/storage/acc/
(3) Database-Proxy
This daemon is a proxy for the other components (1 and 2) to reach the backend database and execute operations and queries. It contains a multiplex-mechanisms so that many many clients (devices and users) can share access to the database backend.
The database itself contains user and ACL data, contacts for devices and users, the current GeoIP locations of devices, the current inventory of devices, current scheduled actions, etc.
The Database-Proxy can be stopped/started via:
/etc/init.d/databaseproxy.sh
Logfiles can be found here:
/var/log/database-proxy.log
______
If you ever need to restart components you should keep in mind, that there is a certain dependency order. As both, the Agent-Manager and the Command-Server rely on the Database-Proxy and the Command-Server in turn relies on the Agent-Manager you have a dependency-hierarchy like this:
Database-Proxy
Agent-Manager
Command-Server
(Web-Frontend)
So for restarting the Database-Proxy you first need to stop the Command-Server and the Agent-Manager. Afterwards you need to start the Agent-Manager followed by the Command-Server.
A reboot is easier to type though [8-)]
Cheers,
Henning
This thread was automatically locked due to age.