Debugging RADIUS logs via a console is near impossible, is there a better way?

Version Affected:  RADIUS Agent

Description:  

When needing to debug the RADIUS Agent container, using the Docker commands and attempting to debug via a console connection can be a difficult task, especially if the RADIUS Agent is fairly busy.

Cause:  

When using the console, you need to scroll a lot and could even fill the buffer with a normal command like:

docker logs radius-agent

Even using grep/egrep to filter can still cause a large buffer to scroll through.

Resolution:  

Copying the actual log file out of the radius-agent container to another location that it can be worked on using multiple tools like grep, egrep, tr, sed, awk, etc makes debugging a lot easier on a Linux Admin.

First thing to do is get the name of the current log file. This can be accomplished by using the command:

docker inspect radius-agent

The above is going to return the full docker configuration for the container and we need to look for the log entry.

Using the command here, will return the actual path of the log file:

docker inspect radius-agent | grep ^.*-json\.log.*$ | gawk '{ print $2 }' | tr -d "\"" | tr -d ","

Once you know the location, an admin can easily copy (cp) the file elsewhere to be worked on, or a command like the following will copy the log file to the logged in users home folder:

cp $(docker inspect radius-agent | grep ^.*-json\.log.*$ | gawk '{ print $2 }' | tr -d "\"" | tr -d ",") ~

Now that the file is no longer being updated by being copied to a different folder, the admin can properly use any utility available to search and work on said log file without interruption.

Special Considerations (optional as needed):  

Make sure the file is copied and not forcefully moved from the container folder.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.