Balabit - Debug bundle from the command line

category: solutionz · date: 2018-12-31 · updated: 2026-10-03 · author: LALA

Balabit SCB Solution · Config document · referenced from Operations, upgrades and troubleshooting

noteThe rm -rf lines delete four directories of earlier debug runs without asking; run them only in /opt/scb/var/debug/ of the core firmware, and check the result of cd first. The final zip … * packs the current directory, so it has to run in the same place. The core-shell line comes from a sentence of the support ("Log in to the core shell by typing this: core-shell"), not from a command listing. All the commands here are the instructions of the support and of my how-tos turned into command lines; the notes do not record that they were run or what they printed.

How a debug bundle (the vendor calls it a support bundle or system state info) is made from the SSH console when the web interface is not available, and how old debug data is cleared first when the bundle cannot be created, as the support and my how-tos give it. The procedure came from the vendor's support in two answers and was merged into my IPMI and debug how-to.

Item	Value
Where	SSH console of the SCB as `root`, core shell (`core-shell`)
Which appliance	Not named in the notes
Web interface way	Basic Settings – Troubleshooting – System Debug – "Collect and save current system state info", then save to the computer and send to the support
Output	A bundle in `/opt/scb/var/debug/`, seen from the boot shell as `/mnt/firmware/opt/scb/var/debug/`
`-u admin`	As I read it, the SCB user the troubleshooting run is attributed to; the notes do not explain it
Source	Troubleshooting notes, the support's answers "Gather support bundle informations" and "Remove old debug logs"; operation how-to, section "Remove old debug logs"; IPMI and debug bundle how-to

The commands

Enter the core shell from the boot shell. The IPMI and debug how-to calls the step optional, because the appliance may already open the core shell by default; the operation how-to reaches the same place through the menu "Shells", "2. Core shell".

bash

$ core-shell

Check that the shell is in the core firmware. The fence after the command is the operation how-to's expected value ("Output from command must be 'Core'"), not recorded output; the one recorded output of this command in the troubleshooting notes, after the chroot, is lowercase core.

bash

$ cat /etc/firmware-type

output 1 line

Core

If the bundle cannot be created, remove the data of earlier debug runs first. The support called the four directories "old configuration files", the operation how-to "old debug files", the IPMI and debug how-to "the lock files". Then list what is left.

bash

$ cd /opt/scb/var/debug/
$ rm  -rf state
$ rm -rf info
$ rm -rf raid
$ rm -rf var_log
$ ls -la  /opt/scb/var/debug/

Start the collection of debug information, reproduce the problem if there is one to reproduce, and stop it. The stop step "can take a few minutes to finish properly and will write the name of the debug bundle".

bash

$ php /opt/scb/bin/console.php --troubleshooting-start --keep-zorp-loglevel -u admin
$ php /opt/scb/bin/console.php --troubleshooting-stop -u admin

Check the created files and pack them into one archive "for easier sending", still in /opt/scb/var/debug/. From the boot shell the same directory is /mnt/firmware/opt/scb/var/debug/, which is where the support said to find the bundle and copy it from the appliance to the workstation.

bash

$ ls -la  /opt/scb/var/debug/
$ zip -r9 debug_info.zip *

Line	What it means
`core-shell`	The boot firmware's command to open a shell in the core firmware
`state`, `info`, `raid`, `var_log`	The four parts of an earlier debug run. As far as I can tell from the support bundle of site 2, whose files sit under `info/` and `logs/`, these directories are what a bundle is made of; left behind by an interrupted run they stop the next one
`--troubleshooting-start`	Starts the collection; presumably the command-line counterpart of the web interface's troubleshooting page
`--keep-zorp-loglevel`	By its name, leaves the log level of Zorp as it is. Zorp is, as I understand it, the vendor's proxy engine inside the SCB that carries the connections; the site 2 bundle lists `Zorp 3.4 LTS (3.4.5)`
`--troubleshooting-stop`	Stops the collection and writes the bundle
`zip -r9`	Recursive, maximum compression

The IPMI and debug how-to adds one more step between clearing and collecting: when the web interface stays down, the web server may simply not be running, "Restart /etc/init.d/lighttpd reststart" (the doubled letter is in the notes; the argument is restart). The support said the same in its first answer: "It seems the lighttpd did not start and that is the reason you do not have a web UI." That case is in Web server fix after the upgrade from 4 to 5.

Checked against One Identity Safeguard for Privileged Sessions 9.0

As built	Today
Basic Settings – Troubleshooting – System Debug, "Collect and save current system state info"	Basic Settings > Troubleshooting > Create support bundle; the file is named `debug_info-<hostname>YYYYMMDDHHMM`. For a specific error: Start, reproduce the error, Stop, "Save support bundle with debug logs"
What the bundle contains	Key files and passwords are removed automatically, but with a proxy verbosity of 8 to 10 the logs can contain highly sensitive data

The documented way is the web interface; the command-line way of this document came from the vendor's support.