Don't apply to PCN, it will lead to the disconnection of all SCNs attached and will not restore automatically
Problem Description
A PCN connection request got stuck in the "Waiting" status and doesn't result in failure. The reboot doesn't help. It can happen if, for example, a SCN IP was specified instead of PCN.
Solution
Run the following commands as root:
Don't apply to PCN, it will lead to the disconnection of all SCNs attached and will not restore automatically
Problem Description
A PCN connection request got stuck in the "Waiting" status and doesn't result in failure. The reboot doesn't help. It can happen if, for example, a SCN IP was specified instead of PCN.
Solution
Run the following commands as root:
Description and cautions
This is short article about how to burn KATA ISO on USB drive.
For KATA 4.0/4.1 you need 8Gb USD drive, for 5.0/5.1 - 16Gb at least.
3d party solutions are involved, therefore success is not guaranteed. Ventoy is more preferable working method.
Details
Download latest Rufus release or Ventoy, how to use Ventoy described here or Balena http:// https://etcher.balena.io/
[Rufus part] Open it and select respective KATA IS
Collect script output is a must for most KATA-related issues and questions.
Which information?
Which file?
How to find/interpret?
Example
КАТА version and role: CN/PCN/SCN/Sensor
/config/apt-va
File contains the version and role in human-readable form. Al
You may need to add a batch of prevention rules to KATA. To speed up the process, we have created a script sample.
Adding more than 1000 prevention rules will require additional PF to improve Web UI performance. Please contact technical support to get this PF.
Adding more than 5000 prevention rules is highly NOT recommended as it may result in drastic performance degradation on both CN and Endpoint Agent.
Step-by-step guide
Script sample. To run it, yo
Versions
Applicable to versions above 5: 5.0, 5.1, 6.0, 6.0.1, etc.
You can fancy access log-history logs (former apt-history) directly for convenience purposes or if the kata-collect-siem-logs tool is malfunctioning for some reason.
These logs are in gzip, sorted by dates, as files with names in format: /data/volumes/s3proxy/log-history/YYYY-MM-DD-HH-MM-SS, where YYYY-MM-DD-HH-MM-SS is the datetime.
basename -a /data/volumes/s3proxy/log-history/2024*