Some of these can be separated into their own tasks if desired. Changes will be easier after crm_report is converted to C.

• Validate all user-supplied arguments
• See TODOs in code
• Drop the report.summary file or make it more useful
• Sanitizing (removing passwords) is brittle and incomplete
  • Examine the code thoroughly and test (including with values containing quotes, equals, and whitespace)
  • diffcheck(), events.txt, journal.log, and systats.txt mount options appear not to be sanitized
  • It would be better to sanitize during log collection rather than modifying the collected log, to avoid a window where passwords are exposed
• It's possible for the bzip2 libs to be installed on a node and used by Pacemaker for scheduler inputs, without the bzip2 command-line tool being installed; currently, this will output errors and the files will be 0 size, which is fine, but it would be better to output a single error and not collect the files
• Handle being run on a Pacemaker Remote node better: warn that it should be run from a cluster node instead, but collect what is possible and don't try to collect what is not possible
• Without --single-node or --nodes, crm_report will detect Pacemaker Remote nodes only if they have ever had a permanent node attribute (i.e. are in the nodes section); it should also check for remote node resources in the CIB resources section.
• When crm_report creates permissions.txt, it may report that certain directories do not exist, which is not a problem on remote nodes. Ideally, it would not print any messages for directories that aren't required on remote nodes.
• crm_report currently assumes that node names are resolvable and can be used with ssh; maybe allow user to specify ssh names
• Additional information that would be worth collecting:
  • Private node attributes (only if cluster is live; would require attrd_updater to allow showing all)
  • DC history (search logs during time of interest and create a new dc-history.txt with lines showing a timestamp and the node that became DC at that time)
  • Full fence history (sosreport already does this using pcs, so skip in --sos-mode)
  • ^PCMK_ from sysconfig
  • Whether cluster services are enabled at boot
  • Maybe collect logs from bundle containers if not in --sos-mode. Currently expects basename of logfile to be unique, will have duplicates with bundles. Currently detects syslog by logging something, and using journalctl for systemd -- can't do that with bundle syslogs, but could maybe check the CIB for bundle exports under /var/log.