TRUENAS: What is a Debug and Why does (NickF think) it Matters?

Cross Posted from here: What is a Debug and Why does (NickF think) it Matters? | TrueNAS Community
Disclaimer : This is a living document and I expect to revise it often-ish It’s also a pretty half-way mix of my personal opinions and also presenting important information.

Understanding the “Debug” in TrueNAS Systems

FreeNAS, TrueNAS, TrueNAS CORE, and the recent TrueNAS SCALE , have consistently incorporated a feature known as a “debug”. In the realm of these systems, and others, a “debug” signifies a compilation of log files and pertinent system information. It’s mission is to provide an invaluable window into the system’s configuration and overall health.

Official Docs:
https://www.truenas.com/docs/_includes/createdebugcore/

Disclaimer :
Crucially, this does not involve data or metadata about the content stored on a TrueNAS system, but will most likely include information like file names that were accessed by file sharing protocols , and absolutely things like IP addresseess , domain names/information (particularly in an AD environment), and other potentially identifiable information.

Evolution & Potential

Initially, this feature was designed keeping in mind the specific needs of Enterprise TrueNAS Support Engineers . Over time, this has undergone various transformations and refinements. Interestingly, there seems to be no concerted community effort to explore its potential applications beyond the confines of its primary audience.
Disclaimer : I’ve been a TrueNAS user since 2014-ish and I can’t remember any similar posts to this, but I could be wrong.

Syslog Servers: Why Bother?

From an enterprise systems administrator’s perspective, there’s an inherent need to have a deep understanding of the systems they are responsible for. When operating at large scales – major enterprises usually employ centralized or dedicated syslog servers. Splunk, with its extensive capabilities, often emerges as the go-to choice but is notably heavy on the pocket. There’s also, GreyLog offers a commendable solution for smaller setups and is often recommended in the homelab community. Gravwell, which I personally admire, is emerging as a game-changer in the market.

Why invest in syslog servers? In one word, analysis . Collating logs allows for predicting failures, enhancing troubleshooting, preempting resource exhaustion, pinpointing security vulnerabilities, and more.

For those of us homelabbers and people not working at those massive scales? That’s where TrueNAS debugs can help. You don’t need to have any inherent *NIX knowledge to find the right commands to look for a problem. iXsystems already did the heavy lifting.

A Call to Collaborate!

This is more than a discussion. It’s a call to action. Let’s rally together, share our insights, and deepen our collective understanding. By doing so, we can boost efficacy, offer invaluable feedback, and provide actionable suggestions for TrueNAS developers. Together, let’s shape an efficient and insightful future for TrueNAS and its community.

To both steal and mangle the tagline from iXsystems

In my opinion: True Data Freedom is:

Knowing and Understanding
(that you have data, in the server you host your data in, about the server you serve your data in.)

[image] Try and say that OUT LOUD! LOL

One of the biggest problems I see with new users here in the forums is that they often lack information to make the best decisions. We generally provide sage advise to these folks and get them up and running. However, since we as a community also lack data, we often tend to be overly conservative in our advise. This is often warranted, but there are exceptions and we need to work to improve them.

TrueNAS Cobia Enters the room…
While the debugs in recent CORE and SCALE releases have been good and are generally well organized, the new ones in Cobia BETA are even more so. Most regular forum users/hobbiests/tinkerers should be able to find their way around the new debug layout with ease.

Got a problem with an SMB share? Generate a debug and take a gander! Have no idea how to read it? Post a snippet on the forum!

Lets dig in for the sake of this example. "smb_general.txt " contains configuration information which may be relevant to a problem you have.

1692936217745.png

It has alot of common info folks may ask for in the forums if you come for help with an SMB problem. I have a share named “media”. Here’s what samba is configured to do with it. Maybe my non-standard full_audit configuration will be spotted by someone on the forums who will know how to help with my problem.

I dream of a world where at least some of my fellow “regulars” take the time to know that the answers are here

Going beyond the “general” logs in the debugs is going to require context that only comes with experience. But I think we have enough savvy folk here to know what questions are worth asking, they just didn’t know they could easily just ask to look at a debug…

If you see a problem you may be able to solve - please ask the OP to PM you a debug. It’ll save us all alot of time and wasted efforts.

Also please - take the time to point out what you found and document those findings in a public reply. That’s what these forums are for - collaboration at its finest.

Okay, Mr. Random Guy on the Internet, so what are you doing about it?

We’re talking right now about data collection, but specifically, we are talking about collecting historical data. I’m doing my best to try and develop a script which will help in filtering out the noise and presenting scheduled reports with actionable information.

I called it Spencer, in part because I like the TV Show Psych. For those of you not familiar, it also rings true to the character who it’s named for. Shawn Spencer was a “psychic detective” who wasn’t really psychic at all. He was just some guy who was hyper observant. That’s the goal for me, anyway.

Spencer V2.0-BETA 1- Now with Pineapple - An Email Alert Script for Potentially Hidden Problems

Spencer v2.0 BETA-1 Not Quite Psychic… # Version 2.0 08/22/23 # Refactored alot of code. # Dynamically determine whether run from MultiReport or if Spencer is called directly. # Overall improvements to robustness of the script, the accuracy of…

www.truenas.com www.truenas.com

1 Like