It seems there is a new path that security limits.conf could have files stored,
in /etc/security/limits.d/
Would be good to include those in supportconfig as well as the limits.conf file.

https://github.com/g23guy/supportutils/blob/master/bin/supportconfig#L3129

Since suse is moving away from openldap to 389-ds, we should add support to collect 389-ds related files. We could consider making a supportutils like tool in 389-ds upstream that we can just call from within support config if this helps.

However, the RPM "SUSE_SLES_SAP-release" only exist for SLES11.

For SLES12 and 15 it should be:
"SLES_SAP-release"

In addition, I request we add the output of these two commands to the basic environment file for further confirmation of the true OS type:
ls -lA --time-style=long-iso /etc/products.d/baseproduct

rpm -qf /etc/products.d/baseproduct

Working on Saptune and Sapconf sometime has issue with the CPU scheduler and generally have to request a separate command from the customer

#cat /sys/block/sd*/queue/scheduler

This will show us all available schedulers not just the currently selected scheduler

Current SLES15 supportconfig looks for logs in the old location for the "ha.txt" file:
#==[ Log File ]=====================================#

/var/log/pacemaker.log - File not found

In SLES15 pacemaker logs are now in:
/var/log/pacemaker/pacemaker.log

It would be useful to collect this file as well as it shows what packages have been installed or deinstalled by the user in the past, so gives a better insight into what manual modifications have been done in the past on the system

I have found out that supportconfig tool has a sort of plugin mechanism where 3rd party tools can be interfaced to this.

We should document this in the main repo, how to write plugins

see : https://github.com/Thr3d/supportutils-plugin-suse-sap for more info

Short story: a customer is struggling with multipath boot from SAN. He created supportconfig file after booting from a rescue media. But boot.txt does not show info about initramfs as the kernel booted (rescue media) is mostly not one present in /boot directory inside chroot.

Thinking loudly - are we somehow able to improve boot.txt if we would know that we booted from a rescue media?

Sep 08 10:56:13 rescue kernel: Linux version 4.12.14-120-default (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Nov 7 16:39:09 UTC 2019 (fd9dc36)
Sep 08 10:56:13 rescue kernel: Command line: initrd=initrd splash=silent rescue=1

^ this indicates booting from rescue media

#==[ Command ]======================================#
# /usr/bin/lsinitrd -k 4.12.14-120-default
No <initramfs file> specified and the default image '/boot/initrd-4.12.14-120-default' cannot be accessed!

Usage: lsinitrd [options] [<initramfs file> [<filename> [<filename> [...] ]]]
Usage: lsinitrd [options] -k <kernel version>

-h, --help                  print a help message and exit.
-s, --size                  sort the contents of the initramfs by size.
-m, --mod                   list modules.
-f, --file <filename>       print the contents of <filename>.
-k, --kver <kernel version> inspect the initramfs of <kernel version>.

^ this is useless, supportconfig was trying to check initramfs with version of rescue mode media.

Could we:

1. detect if it is rescue mode?
2. if so, take default from GRUB menu
3. inspect initramfs of "default" GRUB entry?
4. print info that this supportconfig is taken from rescue mode after chroot (are we sure we are inside chroot?)

Such info - valid lsinitramfs would help "me" to see if multipath is present inside initramfs.

Hi,
could we have postfix support? Maybe something like this:

1. bash -c "comm -23 <(postconf -n) <(postconf -d)" # settings which differ from built-in default
2. postconf -n # explicit settings
3. postconf -d # default settings
4. postqueue -p/j # depends on version
5. content of each file in /etc/postfix
6. content of /etc/sysconfig/postfix # this is already in sysconfig.txt

Document supportconfig's plugin feature and how to write a plugin.

Hi Jason, could you fix iSCSI initiator in supportconfig, please?

Only think about iscsi initiator in supportconfig is "/sbin/iscsi-iname", but it is actualy does'n reflect iscsi initiator name, it just iname generator. This output doesn't have any value for support. So IMO in supportconfig should be involved "/etc/iscsi/initiatorname.iscsi" instead.

Since /sbin/iscsi-iname is just iscsi name generator, it could be left from supportconfig. That's a bit confusing.
Thank you.

Given this is open source and probably doesn't make sense to be a part of openSUSE this repo probably should be moved into SUSE's official github instance :-)

► Enhancement Request -- modify usage of df in the supportconfig report generation utility to include file system type via the df command -T switch

• Files in the supportconfig report where df is used

basic-health-check.txt
fs-btrfs.txt

• current usage
/bin/df -h

• requested enhancement usage
/bin/df -Th

Multiple iscsi ifaces are not much used but if used we do not have any info about it, thus please add iscsiadm iface dump. Thx.

I see a case where authentication via LDAP is not working.

Could we try to test it?

• ldapsearch... plus options from /etc/ldap.conf ? If there's SSL, could we try openssl s_client -connect... and stuff from /etc/ldap.conf?
• getent passwd <user>, where user would be something popular (yep guessing)?

supportconfig output currently shows a description of each feature, but sometimes matching that to the -F output is not so quick and easy.

Current:
Gathering system information
Data Directory: /var/log/scc_s15rmt_210922_0956

Basic Server Health Check... Done
RPM Database... Done
Basic Environment... Done
System Modules... Done
Memory Details... Done
Disk I/O... Done
B-tree File System... Done
Transactional Update... Skipped
Tuned... Skipped
YaST Files... Done

Adding the Feature name in another column would make that quick and easy, like this:
Gathering system information
Data Directory: /var/log/scc_s15rmt_210922_0956

Basic Server Health Check... Done
RPM Database... Done
Basic Environment... Done
System Modules... MOD Done
Memory Details... MEM Done
Disk I/O... DISK Done
B-tree File System... BTRFS Done
Transactional Update... TRANSACTIONAL Skipped
Tuned... TUNED Skipped
YaST Files... Done

https://github.com/g23guy/supportutils/blob/master/bin/supportconfig#L3129

Since suse is moving away from openldap to 389-ds, we should add support to collect 389-ds related files. We could consider making a supportutils like tool in 389-ds upstream that we can just call from within support config if this helps.

In situations where rsyslog is not installed so a messages.txt file is not generated, we should check and collect additional logs from journald if Storage=persistent is set.
Example:
With Storage=persistent in their journald.conf journald keeps old journals.
journalctl --listboots
journalctl -b <boot id from the list>"

Even if there's no /etc/multipath.conf it could be handy to see default multipath configuration directly - multipath -t without downloading respective RPM and reading its manpage.

IIUC, we won't see files included from dir. Is this doable?

# Include /etc/auto.master.d/*.autofs
# To add an extra map using this mechanism you will need to add
# two configuration items - one /etc/auto.master.d/extra.autofs file
# (using the same line format as the auto.master file)
# and a separate mount map (e.g. /etc/auto.extra or an auto.extra NIS map)
# that is referred to by the extra.autofs file.
#
+dir:/etc/auto.master.d

lsblk output seems to be broken little bit

# /bin/lsblk -o 'NAME,KNAME,MAJ:MIN,FSTYPE,LABEL,RO,RM,MODEL,SIZE,OWNER,GROUP,MODE,ALIGNMENT,MIN-IO,OPT-IO,PHY-SEC,LOG-SEC,ROTA,SCHED,MOUNTPOINT,DISC-ALN,DISC-GRAN,DISC-MAX,DISC-ZERO'
NAME                                        KNAME MAJ:MIN FSTYPE       LABEL                            RO RM MODEL  SIZE OWNER GROUP MODE       ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED MOUNTPOINT      DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                         sda     8:0   LVM2_member                                    0  0 2145   512G             brw-rw----         0  32768      0     512     512    1 bfq                          0        0B       0B         0
└─36005076380810560c80000000000000f         dm-0  254:0   LVM2_member                                    0  0        512G  
...

could you just add -i / --ascii option ?

IMO could we move client logs till the end of the samba.txt file? The file could be huge and sometimes searching for daemon log inside many client logs is annoying.

An example:

ls -lh samba.txt
-rw-r--r--+ 1 wwwrun www 39M Jun  9 15:09 samba.txt

# number of all logs included
grep -Po ' \K(/var/log/[^ ]+)(?=.*)' samba.txt  | wc -l
28574

# number of "client" logs
grep -Po ' \K(/var/log/samba/log\.[^ ]+)(?=.*)' samba.txt | \
  grep -P '^((?!(smbd|winbindd|wb-)).)*$' | wc -l
28549

# number of lines
 wc -l < samba.txt 
709882

# position of "non-client" logs
grep -nPo ' \K(/var/log/samba/log\.[^ ]+)(?=.*)' samba.txt | \
  grep -P '(smbd|winbindd|wb-)' | grep -v \.old$ | \
  sed -r 's/wb-(.*)/wb-<censored>/'
149941:/var/log/samba/log.smbd
150445:/var/log/samba/log.smbd_UNKNOWN_UNKNOWN
159657:/var/log/samba/log.winbindd
162911:/var/log/samba/log.wb-<censored>
171467:/var/log/samba/log.wb-<censored>
180489:/var/log/samba/log.wb-<censored>
235871:/var/log/samba/log.wb-<censored>
240121:/var/log/samba/log.wb-<censored>
246613:/var/log/samba/log.wb-<censored>
252190:/var/log/samba/log.wb-<censored>
278208:/var/log/samba/log.wb-<censored>
282410:/var/log/samba/log.wb-<censored>
325665:/var/log/samba/log.wb-<censored>
365150:/var/log/samba/log.winbindd-idmap
390960:/var/log/samba/log.wb-<censored>
400034:/var/log/samba/log.wb-<censored>
579271:/var/log/samba/log.wb-<censored>
581215:/var/log/samba/log.winbindd-dc-connect
581719:/var/log/samba/log.winbindd_UNKNOWN_UNKNOWN

As you can see one has to scroll a lot to get to some "non-client" logs.

Thus I would propose to reorder display of samba logs - first daemon logs, then "client" logs.

This could lead a TSE to think that sssd is not configured at all, even if it is configured or perhaps misconfigured in conf.d/*

The entirety of /etc/sssd/conf.d/* should therefore be included in the sssd.txt

It might be a good idea to include a ls -la of the directory as well. Customers will often create the snippet files with incorrect permissions.

This offers the fringe benefit of making it easy to write a pattern that checks the correctness ownership and permissions of the snippets.

Excerpt from the sssd.conf man page on current 15 SP2 on the subject for reference:

CONFIGURATION SNIPPETS FROM INCLUDE DIRECTORY
The configuration file sssd.conf will include configuration snippets using the include directory conf.d. This feature is available if SSSD was compiled with libini version 1.3.0 or later.

Any file placed in conf.d that ends in “.conf” and does not begin with a dot (“.”) will be used together with sssd.conf to configure SSSD.

The configuration snippets from conf.d have higher priority than sssd.conf and will override sssd.conf when conflicts occur. If several snippets are present in conf.d, then they are included in alphabetical order (based on locale). Files included later have higher priority. Numerical prefixes (01_snippet.conf, 02_snippet.conf etc.) can help visualize the priority (higher number means higher priority).

The snippet files require the same owner and permissions as sssd.conf. Which are by default root:root and 0600.

The info supportconfig collects is usually not sufficient to resolve issues in the installer or hardware detection area (hwinfo).

This typically leads to a back-and-forth with customers until the necessary data has been provided. This process can by trying for both sides and is easily avoided.

For this reason I would suggest to include these three items in the default supportconfig output:

• the tar file save_y2logs creates
• the tar file getsysinfo creates
• the log file of hwinfo --all --log=xxx.log

Note that fragments of the above are already provided but for efficient debugging it is also vital that information is provided in a way developers expect and can readily use.

Hi there!

If I'm not wrong, a recent change in conf_files could have broken the expected behavior in log_files at certain points by overriding the FILES environment variable.

See

from #118

And take the yast_files as an example

In line 689 the $FILES variable is prepared to be an argument for log_files later. But before calling log_files in line 692 there is a call to conf_files at line 690, which end up changing the content of $FILES.

I can be wrong, since I'm not so familiar with this code, but commenting the line 690 makes a difference when calling supportconfig.

I have created a bug report too, see it at https://bugzilla.suse.com/show_bug.cgi?id=1202269

Since in recent systems the net-tools package may not be installed, the arp command may also not be available. I think it could be useful to also add the output of the ip neigh command in order to view the system's ARP cache. Thanks.

This request is to ask that the messages log, /var/log/messages, is saved in full and standalone and to not be combined in the "messages.txt" file with /var/log/warn and /var/log/localmessages. I think it makes more sense to move warn and localmessages to a different file, or save them each in their own file.

I'm ok with keeping a combined file that includes warn and localmessages, but often we ignore those files because generally those log entries are also included in /var/log/messages.

I see the supportconfig logic checks if the size of the messages file is greater than 26M and if so, only grab 200,000 lines of that file, which seems sufficient at this time.

It's difficult/cumbersome/incommodious/time-consuming to jump down to the messages part of the combined file, having them as separate file would save time while reviewing logs.

If syslog-ng is main syslog, could we validate its syntax via syslog-ng -s?

Currently the -x OPTION is the same as:
"-A -o keyword[,keyword]"

-A is defined as:
"Activates all supportconfig functions with additional logging and full rpm verification."

So the -x exclusion actually enables everything (with -A) and then only excludes specific entries that are added.
This is confusing and not intuitive in the meaning of "exclusion".

Even though the man page mentions that -A is added to the -x, the "supportconfig -h" output does not mention the -A part which leads to further confusion.

I propose the -x flag be changed to no longer add -A, and only exclude the keywords that are appended from the default set of enabled options.

Although it would mean both -x and -o would operate the same, I think this would better match the intention of the word "exclude"... An exclude should not mean to add other options that are not already there nor intended.

After the change if someone still needs the functionality, they could use the example:
"-A -o keyword[,keyword]"
or
"-A -x keyword[,keyword]"

I'm unsure what kind of confidential data supportconfig is expected to replace with "REMOVED BY SUPPORTCONFIG", but I see that the following are not replaced:
"username=" and "system_token=" from /etc/zypp/credentials.d/SCCcredentials
"regcode" from /usr/sbin/SUSEConnect --status

Maybe there are even more.

This request is to ask that the messages log, /var/log/messages, is saved in full and standalone and to not be combined in the "messages.txt" file with /var/log/warn and /var/log/localmessages. I think it makes more sense to move warn and localmessages to a different file, or save them each in their own file.

I'm ok with keeping a combined file that includes warn and localmessages, but often we ignore those files because generally those log entries are also included in /var/log/messages.

I see the supportconfig logic checks if the size of the messages file is greater than 26M and if so, only grab 200,000 lines of that file, which seems sufficient at this time.

It's difficult/cumbersome/incommodious/time-consuming to jump down to the messages part of the combined file, having them as separate file would save time while reviewing logs.

PAM is excluded by default for GDPR, the keyword has been removed, and a variable is required to enable it. This goes against the expected behavior of how supportconfig features are enabled/disabled.
To prevent confusion add a hint in the pam.txt (or supportconfig output instead of just "Excluded") why PAM was excluded and how to enable it.

https://www.suse.com/support/kb/doc/?id=000019695

Realizing that during "Updates..." the sed process consumes "100% CPU" for several minutes, I investigated it a bit (see also https://stackoverflow.com/q/77818891/6607497). Eventually I could reduce the initial runtime of more than six minutes to less than half of a second.

Note that similar sed code it used in other places, too.

Some comments from the question cited above:
(...) And it is obvious that at least 9 of the s/// can be trivially refactored into just one. –

It also appears to rewrite the same line multiple times. For example, if I change the /g to /gp on each line, it prints three (identical) lines for the input password = foo bar –

not relevant to the problem but [P|p] probably doesn't match what is intended. –

Honestly, here, in most of replacement cases, a regexp is not even needed : having multiple regexps .*word.* is fundamentally inefficient (by several order of magnitude). Indeed, one can just search a bag of words in each line and replace the whole line. The later is far more efficient. –

Technically, .*foo.* is not the same as foo.* but that seems unlikely to be a issue here. As an aside, any s/// that matches foo.* does not need /g since there can be no other matches, but removing it won't improve performance here. –

(.*foo.* matches the final occurrence of "foo"; foo.* matches the first occurrence - but if the input ever contains two occurrences (eg. wanted1 foo secret wanted2 foo secret), the original code would fail to sanitize fully (wanted1 foo secret wanted2 foo hidden, while with the change it would (wanted1 foo hidden))

supportconfig.8 refers to a no-longer existent Novell url https://eservice_enu.novell.com/eService_enu for tarball submissions.

IMO it could be handy so see mtime timestamp of each file which is included in the supportconfig.

When resolving bsc#1201990 we struggled to know what the I/O schedulers are set for the individual block devices.

It would be nice to add this information to Supportconfig (see comment 61 of that bug).

It's hard to know if DNS resolution works, maybe we could ping the machine itself via its name appended with domain, or we could do dig <domain>. SOA.

For many services which have their own section or text file in supportconfig the systemctl status output exists.
But for custom services or a service that does not have its own section, the systemctl status output would be beneficial to see for troubleshooting.
I think a dump of all status output in one file would be helpful.
Something akin to:
/bin/systemctl --no-pager --all list-units|grep active |grep -v -e inactive -e dead|grep running|awk '{print $1}'|xargs systemctl --no-pager status