opensuse / supportutils Goto Github PK
View Code? Open in Web Editor NEWSUSE Linux Enterprise support utilities. Gathers system information.
SUSE Linux Enterprise support utilities. Gathers system information.
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>"
supportutils/bin/supportconfig
Line 1372 in 4a0747f
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
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.
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 :-)
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
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
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.
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:
Such info - valid lsinitramfs
would help "me" to see if multipath is present inside initramfs.
supportconfig.8 refers to a no-longer existent Novell url https://eservice_enu.novell.com/eService_enu for tarball submissions.
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).
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.
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))
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
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.
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.
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.
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.
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.
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.
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 ?
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
► 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
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]"
supportutils/bin/supportconfig
Line 2490 in 65476f7
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
If syslog-ng is main syslog, could we validate its syntax via syslog-ng -s
?
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
supportutils/bin/supportconfig.rc
Line 288 in 92340a4
from #118
And take the yast_files
as an example
supportutils/bin/supportconfig
Lines 676 to 697 in 92340a4
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
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.
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.
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.
Current SLES15 supportconfig looks for logs in the old location for the "ha.txt" file:
#==[ Log File ]=====================================#
In SLES15 pacemaker logs are now in:
/var/log/pacemaker/pacemaker.log
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:
save_y2logs
createsgetsysinfo
createshwinfo --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.
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
.
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.
Hi,
could we have postfix support? Maybe something like this:
bash -c "comm -23 <(postconf -n) <(postconf -d)" # settings which differ from built-in default
postconf -n # explicit settings
postconf -d # default settings
postqueue -p/j # depends on version
/etc/postfix
/etc/sysconfig/postfix
# this is already in sysconfig.txtIMO it could be handy so see mtime timestamp of each file which is included in the supportconfig.
Document supportconfig's plugin feature and how to write a plugin.
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
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.
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)?A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.