Unable to connect to the frontend and client not getting installed properly
vijayakumarcfis opened this issue · comments
Hi,
I have installed GRR server (3.4.2) on Ubuntu 18.04.4 running on a virtual machine and my host OS is Windows 10 (64 bit).
I had referred through the previous posts and changed the “max_allowed_packet” setting to 50M, in the MySQL configuration files i.e. “/etc/mysql/conf.d/mysqldump.cnf” and “/etc/mysql/mysql.conf.d/mysqld.cnf” and restarted the MySQL and GRR-server services.
Still I am unable to access the frontend URL. Below is the list of processes related to GRR (Note: I have also installed a GRR client on this system, so those processes are also listed below)
root 770 737 0 21:25 ? 00:00:00 /usr/lib/grr/grr_3.4.2.0_amd64/grrd --config=/usr/lib/grr/grr_3.4.2.0_amd64/grrd.yaml
root 784 770 0 21:25 ? 00:00:04 /usr/lib/grr/grr_3.4.2.0_amd64/grrd --config=/usr/lib/grr/grr_3.4.2.0_amd64/grrd.yaml
root 2710 1 0 21:39 ? 00:00:00 /bin/bash /usr/bin/grr_server --component worker2 --disallow_missing_config_definitions -p StatsStore.process_id=worker2_294e477c55d44dc2baaafcd3466d88f9
root 2711 1 0 21:39 ? 00:00:00 /bin/bash /usr/bin/grr_server --component worker --disallow_missing_config_definitions -p StatsStore.process_id=worker_294e477c55d44dc2baaafcd3466d88f9
root 2712 1 0 21:39 ? 00:00:00 /bin/bash /usr/bin/grr_server --component frontend --disallow_missing_config_definitions -p StatsStore.process_id=frontend_294e477c55d44dc2baaafcd3466d88f9
root 2715 1 0 21:39 ? 00:00:00 /bin/bash /usr/bin/grr_server --component admin_ui --disallow_missing_config_definitions -p StatsStore.process_id=admin_ui_294e477c55d44dc2baaafcd3466d88f9
root 2723 2710 0 21:39 ? 00:00:04 /usr/share/grr-server/bin/python /usr/share/grr-server/bin/grr_server --context Global Install Context --component worker2 --disallow_missing_config_definitions -p StatsStore.process_id=worker2_294e477c55d44dc2baaafcd3466d88f9
root 2724 2715 0 21:39 ? 00:00:03 /usr/share/grr-server/bin/python /usr/share/grr-server/bin/grr_server --context Global Install Context --component admin_ui --disallow_missing_config_definitions -p StatsStore.process_id=admin_ui_294e477c55d44dc2baaafcd3466d88f9
root 2725 2711 0 21:39 ? 00:00:04 /usr/share/grr-server/bin/python /usr/share/grr-server/bin/grr_server --context Global Install Context --component worker --disallow_missing_config_definitions -p StatsStore.process_id=worker_294e477c55d44dc2baaafcd3466d88f9
root 2726 2712 0 21:39 ? 00:00:04 /usr/share/grr-server/bin/python /usr/share/grr-server/bin/grr_server --context Global Install Context --component frontend --disallow_missing_config_definitions -p StatsStore.process_id=frontend_294e477c55d44dc2baaafcd3466d88f9
root 4022 2532 0 23:08 pts/0 00:00:00 grep --color=auto grr
I tried to look for the ports used by the frontend processes i.e. 2712 and 2726, but couldn’t find any information related to port 8080. I could see only the below information related to ports.
grr_serve 2726 root 8u IPv6 108970 0t0 TCP localhost:11111 (LISTEN)
I have also enclosed the information on listening ports below: -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 628/cupsd
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 811/mysqld
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 564/systemd-resolve
tcp6 0 0 ::1:631 :::* LISTEN 628/cupsd
tcp6 0 0 :::8000 :::* LISTEN 2724/python
tcp6 0 0 127.0.0.1:11111 :::* LISTEN 2726/python
Additionally, I have installed a client on my host OS (Windows 10-64 bit). I could see the GRR related files in C:\Windows\System32\GRR\3.4.2.0 and the registry entries, but the GRR services are not running.
Please help me in fixing the aforesaid issues.
Hi @vijayakumarcfis - a few questions:
- Do you have access to the AdminUI? By default it should be accessible on port 8000?
- Do you have access to the GRR Frontend? This is the process that the clients are talking to (by default it runs on port 8080)?
- Can you please elaborate re what "GRR services not running" means. Do you mean you don't see the GRR service in the services list on the Windows box? If you have access to the AdminUI, when you click on "Search" in the top right corner, do you see any clients showing up?
One more note: the output you've attached seems to be a ps
command output. In that case ports 2712 and 2726 that your refer to are not really ports, but most likely - process ids.
Hi @mbushkov
Thank you for the prompt response!
Please find enclosed my responses.
Do you have access to the AdminUI? By default it should be accessible on port 8000? - Yes, AdminUI is accessible on port 8000.
Do you have access to the GRR Frontend? This is the process that the clients are talking to (by default it runs on port 8080)? - GRR Frontend is not accessible
Can you please elaborate re what "GRR services not running" means. Do you mean you don't see the GRR service in the services list on the Windows box? - Yes, I couldn't see GRR services in "sc query" output
If you have access to the AdminUI, when you click on "Search" in the top right corner, do you see any clients showing up? - No
One more note: the output you've attached seems to be a ps command output. In that case ports 2712 and 2726 that your refer to are not really ports, but most likely - process ids. - **Yes, you are right; those are process ids. I had used "lsof" command to check the ports used by those process ids and couldn't find any information related to port 8080. I could see only the below information that is related to ports.
grr_serve 2726 root 8u IPv6 108970 0t0 TCP localhost:11111 (LISTEN)**
Would you mind posting your /etc/grr/server.local.yaml file? (please exclude the security-sensitive parts, like keys, and also change the urls/hosts)
@mbushkov Here you go,
Database.implementation: MysqlDB
Blobstore.implementation: DbBlobStore
Mysql.host: localhost
Mysql.port: 0
Mysql.database: grr
Mysql.database_name: grr
Mysql.username: root
Mysql.database_username: root
Mysql.password:
Mysql.database_password:
Client.server_urls:
- http://GRR:8080/
Frontend.bind_port: 8080
AdminUI.url: http://GRR:8000
AdminUI.port: 8000
Logging.domain: localhost
Monitoring.alert_email: grr-monitoring@localhost
Monitoring.emergency_access_email: grr-emergency@localhost
AdminUI.csrf_secret_key:
Server.fleetspeak_enabled: true
Client.fleetspeak_enabled: true
ClientBuilder.fleetspeak_bundled: true
Target:Linux:
ClientBuilder.fleetspeak_client_config: /etc/fleetspeak-server/linux_client.config
Target:Windows:
ClientBuilder.fleetspeak_client_config: /etc/fleetspeak-server/windows_client.config
Target:Darwin:
ClientBuilder.fleetspeak_client_config: /etc/fleetspeak-server/darwin_client.config
Server.fleetspeak_server: localhost:4444
FleetspeakFrontend Context:
Server.fleetspeak_message_listen_address: localhost:11111
Server.initialized: true
Ok, so I see that you have Fleetspeak enabled. Fleetspeak is the next-generation communication framework for GRR, it was introduced as an experimental feature in the latest release (3.4.2.0) a few days ago, so some issues are to be expected. The thing important in your case is: Fleetspeak is a work in progress, so at the moment Windows clients are not supported when Fleetspeak is used.
If you need to use GRR with Windows clients, I'd suggest reinstalling GRR and answering No
(a default option) to Use Fleetspeak (next generation communication framework)?
question when GRR server is initialized.
Hi @mbushkov,
I have reinstalled the GRR server (without Fleetspeak) and now I am able to see the clients.
My Windows client was not connecting initially. I debugged and noticed that the hostname (GRR) was part of the Frontend URL in the configuration, so I changed it to the IP address of the GRR server for it to work.
Thanks a lot for your support and would reach out if I face any issues in the future.
@vijayakumarcfis , thanks for the update! Closing the issue.
Hi Bushkov,
If fleetspeak is still under experimental, then how can we get windows client for 32 bit? now with the latest version, we can only use 64 bit client for windows and linux.?? can you help on this?
Ok, so I see that you have Fleetspeak enabled. Fleetspeak is the next-generation communication framework for GRR, it was introduced as an experimental feature in the latest release (3.4.2.0) a few days ago, so some issues are to be expected. The thing important in your case is: Fleetspeak is a work in progress, so at the moment Windows clients are not supported when Fleetspeak is used.
If you need to use GRR with Windows clients, I'd suggest reinstalling GRR and answering
No
(a default option) toUse Fleetspeak (next generation communication framework)?
question when GRR server is initialized.