Bug 1376218

This can be easily achieved by feeding pcs the CIB with obscured passwords.
If crm_report already obscures passwords in CIB before putting the CIB into the resulting tarball, which I think it does, then the only thing needed is "pcs -f cib_with_obscured_passwords.xml config".

Also I am not sure if making crm_report depend on pcs is a good idea as crm_report is part of pacemaker and pcs depends on pacemaker, so we have a circular dependency here.

Also, it sounds premature and redundant to put yet another form of the
same into one sack when "pcs human readable output" can be obtained
later on, as a form of postprocessing, should anyone need it.

Please keep in mind what the purpose of pcs is: to manage cluster stack
(and surrounding components), not babysitting users willing to share
something from their private configurations and logs! (that's what
sed tool can be used for on one's own ultimate responsibility
-- remember there always be some shortcomings).

Having pcs bloat to "community steered cluster configuration management
tool" (what comes next? automatic posting to pastebin-like service?)
is not a good idea, IMHO.

(In reply to Tomas Jelinek from comment #3)
> This can be easily achieved by feeding pcs the CIB with obscured passwords.
> If crm_report already obscures passwords in CIB before putting the CIB into
> the resulting tarball, which I think it does, then the only thing needed is
> "pcs -f cib_with_obscured_passwords.xml config".

Of course, why didn't I think of that ... thanks!

I still think it might be a helpful option for end users who want to describe their configuration to others, but it's not important.

> Also I am not sure if making crm_report depend on pcs is a good idea as
> crm_report is part of pacemaker and pcs depends on pacemaker, so we have a
> circular dependency here.

Not really a dependency, just optional extra info, conditional on pcs or crm being found.

(In reply to Jan Pokorný from comment #4)
> Also, it sounds premature and redundant to put yet another form of the
> same into one sack when "pcs human readable output" can be obtained
> later on, as a form of postprocessing, should anyone need it.
> 
> Please keep in mind what the purpose of pcs is: to manage cluster stack
> (and surrounding components), not babysitting users willing to share
> something from their private configurations and logs! (that's what
> sed tool can be used for on one's own ultimate responsibility
> -- remember there always be some shortcomings).

Sure, but the point of pcs is to simplify things for users so they don't have to deal with XML or low-level commands, and the sanitizing really has to be done at the XML level. Although I'd be impressed if you came up with a sed that could handle this generally :-)

Attributes: pass1= pass2=foo pass3="foo bar" pass4=" x="y "

Easy if you have the exact phrase to leave out at hand and have basic
sed literacy (if not, you can still search&replace in your favorite
editor or give up an attempt to remove anything as your _testing_
environment was created with "the config can be flashed out in
the public" in mind if you anticipate that need, correct?):

pcs ... | sed 's|"foo bar"|***|;s|foo|***|;s|" x="y "|***|' > out.txt

(assumed empty pass1 means it wasn't security sensitive as empty password
for authentication system would be broken;  note that you don't want to
run this on a multiuser machine due to the values being exposed to other
users able to see machine-wide processes -- use sed script instead).

That's what you have to apply with any other textual data you want some
values left out at (e.g., there's no obfuscation option for journalctl),
I dunno why this should be any different.   If anything, that's an
indicator of a bad design if there are indeed valuable sensitive data
in the configuration while it's expected to be shared publicly:
considering it is an XML, there could be replacement entities defined
(either in the same file or in a separate file) that would get simply
dropped/replaced on demand.  Even pacemaker could work just with the
replacement entities internally (would solve an issue with log files
that is still not addressed) unless they really mattered (e.g., agent
invocation).  The scope of replacement entities could be limited only
to parameters to the agents for simplicity (there's usually no need
to preserve isomorphism, unlike with resource names being referenced
in the constraints, etc.).

And where sed works for plaintext data, XSLT concept works for XML,
which is a better level to solve the problem at, as you corretly
point out.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.