You are not dealing with plain ASCII when using pcs, are you?
Per report issue an assuming UTF-8 environment, you must have a unicode
character in the range 0x2000 - 0x2fff somewhere in the arguments being
passed to pcs. See also:
$ python3 -c "print('\t'.join(chr(u) for u in range(0x2000, 0x2fff) if not repr(chr(u)).startswith('\'\\\\')))" | fmt
> ‐ ‑ ‒ – — ― ‖ ‗ ‘
> ’ ‚ ‛ “ ” „ ‟ † ‡
> • ‣ ․ ‥ … ‧ ‰ ‱ ′
> [...]
Even from this excerpt, you can see various typographically sound dashes,
ellipsis character, etc., and these are commonly substituted on-the-fly
in word-like editors so I suspect you just got burned by carelessly
copying commands from the document munged like that (price paid for
dealing with anything "smarter" than plaintext -- true and only
proper medium for engineering tasks, anyway).
Seriously, don't do that -- you won't run into such absurd scenarios.
Nevertheless, there is an issue with pcs on RHEL 6 that it cannot deal
with non-ASCII provided in command-line arguments, in a way that pcs
is terminated prematurely because the argument parsing library is
switched to "unicode literals" mode as imposed with pcs itself.
# pcs cluster setup --name brambůrek node-01 node-02
> /usr/lib/python2.7/site-packages/pcs/cli/common/parse_args.py:289: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
> if arg in ["--cloneopt", "--clone"]:
> Traceback (most recent call last):
> File "/usr/sbin/pcs", line 9, in <module>
> load_entry_point('pcs==0.9.158', 'console_scripts', 'pcs')()
> File "/usr/lib/python2.7/site-packages/pcs/app.py", line 53, in main
> argv = parse_args.upgrade_args(argv)
> File "/usr/lib/python2.7/site-packages/pcs/cli/common/parse_args.py", line 292, in upgrade_args
> elif arg.startswith("--cloneopt="):
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 5: ordinal not in range(128)
So after this shift in the sense of this bug, it remains valid regardless,
only needs a summary adjustment...

Jan,
This issue is with Rhel7 with default nfs-ganesha configuration.
I didn't modify anything while setting up ganesha cluster
# cat ganesha-ha.conf.sample
# Name of the HA cluster created.
# must be unique within the subnet and 15 characters or less in length
HA_NAME="ganesha-ha-360"

re [comment 4]:
Manisha,
colour me sorry for jumping to conclusion prematurely (in fact,
I mistakenly [Friday syndrome perhaps] related that to the other report
I've observed just the previous day -- and that was exactly what the
sort I described).
Now, if you still have that machine untouched around, can you please
run the following (which is what made "pcs cluster setup" choke)?
echo '{}' | GEM_HOME=/usr/lib/pcsd/vendor/bundle/ruby \
/usr/bin/ruby -I/usr/lib/pcsd/ /usr/lib/pcsd/pcsd-cli.rb read_tokens
What's especially of interest, whether there will be any such
character I mentioned in [comment 3].
As a next step, I would incorporate that command to
/usr/libexec/ganesha/ganesha-ha.sh file, directly before
"pcs cluster setup" invocation, using the similar error logging
for good measure -- the intention here would be to exercise
the behaviour when running under respective SELinux context
(system_u:system_r:glusterd_t:s0 ?).
Note that there is no dedicated SELinux label for /usr/sbin/pcs
(nor /usr/lib/pcsd/pcsd-cli.rb for that matter), which may be the
source of issues when the calling parent is _not_ unconfined
(such as when you run pcs directly on command-line).
Please, report back with the findings.

Thanks, Manisha.
There doesn't seem to be any non-ASCII character in the output.
But it was also run as unconfined user (root) at that point, if
I understand it correctly. And unless you changed the environment
since then in any way.
So it's now even more convincing that when the same command is
run within some confined domain (directly or via pcs), ruby
(or libselinux*?) will produce non-ASCII character on either
std{our,err}, which then panics the pcs.
Manisha, could you follow also "As a next step" part of [comment 6]?
Perhaps it could be even reduced to:
echo '{}' | GEM_HOME=/usr/lib/pcsd/vendor/bundle/ruby \
runcon system_u:system_r:glusterd_t:s0 \
/usr/bin/ruby -I/usr/lib/pcsd/ /usr/lib/pcsd/pcsd-cli.rb read_tokens \
>pcsd.out 2>pcsd.err

The issue here appears to be a problem with SELinux not allowing access to /var/lib/pcsd and/or /var/lib/pcsd/tokens
Even if the bug in pcsd is fixed with the ascii error, the SELinux issue will need to be resolved for pcsd to work properly.

Thanks,
And please correct me, is this access needed in default glusterd configuration or just in some "configuration" ?
Reason why I'm asking is if it's enough to create boolean e.g. "gluster_execmem" and this boolean will be switched on just in some configuration or this should be allowed for gluster by default.
Thanks.
Lukas.

Note

You need to
log in
before you can comment on or make changes to this bug.