packetfence
packetfence copied to clipboard
No logging on the connector client.
Describe the bug There appears to be no logging created by the connector client on the server where the client is installed. This makes troubleshooting impossible as to why it is not functioning.
To Reproduce Steps to reproduce the behaviour:
- Installed the connector
- Configure connector to point at PF management IP
- Check standard PF logging location. /usr/local/pf/logs
- Nothing there.
Expected behaviour We would expect to find a pfconnector-client.log with at least heartbeat information or something.
Additional context Service is running and connected as this can be checked.
packetfence-pfconnector-remote.service - PacketFence Connector Client (Remote) Loaded: loaded (/etc/systemd/system/packetfence-pfconnector-remote.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2022-09-30 09:12:55 CEST; 2h 52min ago Main PID: 4067 (pfconnector) Tasks: 8 (limit: 9505) Memory: 18.1M CPU: 2.176s CGroup: /system.slice/packetfence-pfconnector-remote.service └─4067 /usr/local/bin/pfconnector client ENV 127.0.0.1:22226:127.0.0.1:22226
Sep 30 09:12:55 XXXXXXXXXXXXX systemd[1]: Started PacketFence Connector Client (Remote). Sep 30 09:12:55 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:12:55 client: TLS verification disabled Sep 30 09:12:55 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:12:55 client: Connecting to wss://XXX.XXX.XXX.XXX:1443/api/v1/pfconnector/tunnel Sep 30 09:12:55 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:12:55 client: tun: proxy#127.0.0.1:22226=>22226: Listening Sep 30 09:12:55 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:12:55 client: Connected (Latency 12.281245ms) Sep 30 09:13:00 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:13:00 client: tun: proxy#80=>10.202.1.19:80: Listening Sep 30 09:13:00 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:13:00 client: tun: proxy#443=>10.202.1.19:443: Listening Sep 30 09:13:00 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:13:00 client: tun: proxy#1812=>10.202.1.19:1812/udp: Listening Sep 30 09:13:00 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:13:00 client: tun: proxy#1813=>10.202.1.19:1813/udp: Listening Sep 30 09:13:00 XXXXXXXXXXXXX pfconnector[4067]: 2022/09/30 09:13:00 client: tun: proxy#1815=>10.202.1.19:1815/udp: Listening
TODO:
- [ ] Need to document the recipe for putting it in DEBUG for troubleshooting.
- [ ] Need to get logs of pfconnector services into a text file in /usr/local/pf/logs/
Some feedback on the rest of the issue: In case of errors, it becomes verbose if it disconnects from the pfconnector-server or there are errors.
There is technically no "pure" heartbeat we could log AFAIK, it's SSH transported via HTTP (see https://github.com/jpillora/chisel which is what the pfconnector is based on).
So in the case of the pfconnector client, "no news is good news" where if it doesn't log errors, then it means everything is working as expected. Should any new tunnels need to be established, they'll be logged
@julsemaan,
For PacketFence connector, we should not try to use /usr/local/pf/logs
because it doesn't exist: PacketFence can't be installed on a same machine where PacketFence connector is running.
I read that issue too quickly, I thought it was the pfconnector-client (running on PF) which is already logging into pfconnector-client.log (just checked it out)
We need to see where we get the pfconnector-remote to log. I'm a personal fan of using journalctl
when I troubleshoot so I'm probably not the best to provide advice on this.
@nqb, do you think that in the upcoming pfconnector packaging, we can get it to log in /usr/local/pf/logs so that the experience is consistent with the rest of PacketFence. To stay consistent, this would also mean installing the binaries and configuration in /usr/local/pf too
12.1 package will manage logs in /usr/local/pfconnector-remote/logs/
but I'm not sure pfconnector-remote itself has the code to write logs in that directory.
@julsemaan, can you confirm ?
AFAIK, the pfconnector should be logging there through syslog and not by writing there itself. Since rsyslog runs as root, then that would make it fine