Seems that the SCM_CREDENTIALS ancillary message passes the real UID rather
than the effective UID in the ucred struct. It looks like that's where we
get a value for ugp.uid.
I wonder if there's any way to work around this and whether it's intended
behavior. Based on variable naming (c->euid),
Hi,
Thanks for your reply.
I've backported ddb0d3f to pcs-0.10.6-4.el8 and confirmed that this
bug is fixed.
Thanks,
Kazunori INOUE
On Fri, Jan 8, 2021 at 1:49 AM Tomas Jelinek wrote:
>
> Hi,
>
> It took us some time to figure this out, sorry about that.
>
> The behavior you see is not
On Thu, Jan 7, 2021 at 6:16 PM Reid Wahl wrote:
> For whatever reason, the IPC from the crm_mon client to the CIB
> manager is getting opened with the real UID ("testuser" in my case)
> instead of the effective UID. The CIB manager checks this unprivileged
> user against the ACL list and
For whatever reason, the IPC from the crm_mon client to the CIB
manager is getting opened with the real UID ("testuser" in my case)
instead of the effective UID. The CIB manager checks this unprivileged
user against the ACL list and pre-filters the entire CIB, causing a
"Permission denied" error.
On Thu, Jan 7, 2021 at 2:14 AM Reid Wahl wrote:
>
> If there will only ever be one value (e.g., "httpserver") in the file,
> then yet another possibility is to use an ocf:heartbeat:symlink
> resource. You could set up a file on each node (say,
> /var/local/project/cluster-node-real) with
Hi,
It took us some time to figure this out, sorry about that.
The behavior you see is not intended, it is a bug. The bug originates in
commit 966959ac54d80c4cdeeb0fac40dc7ea60c1a0a82, more specifically in
this line in pcs/run.py:
from pcs.app import main as cli
The pcs/app.py file is
On 1/7/21 1:13 PM, Steffen Vinther Sørensen wrote:
> Hi Klaus,
>
> Yes then the status does sync to the other nodes. Also it looks like
> there are some hostname resolving problems in play here, maybe causing
> problems, here is my notes from restarting pacemaker etc.
Don't think there are
Hi Klaus,
Yes then the status does sync to the other nodes. Also it looks like
there are some hostname resolving problems in play here, maybe causing
problems, here is my notes from restarting pacemaker etc.
pcs cluster standby kvm03-node02.avigol-gcs.dk
pcs cluster stop
Hi Steffen,
If you just see the leftover pending-action on one node
it would be interesting if restarting of pacemaker on
one of the other nodes does sync it to all of the
nodes.
Regards,
Klaus
On 1/7/21 9:54 AM, renayama19661...@ybb.ne.jp wrote:
> Hi Steffen,
>
>> Unfortunately not sure about
Hi Ulrich,
> So you were asking for a specific section of the CIB like "cibadmin -Q -o
> status"?
No.
There is no need for a specific section of cib.
Best Regards,
Hideo Yamauchi.
- Original Message -
> From: Ulrich Windl
> To: users@clusterlabs.org; renayama19661...@ybb.ne.jp
>
>>> schrieb am 07.01.2021 um 09:51 in Nachricht
<91782048.765666.1610009460932.javamail.ya...@mail.yahoo.co.jp>:
> Hi Steffen,
> Hi Reid,
>
> The fencing history is kept inside stonith-ng and is not written to cib.
So you were asking for a specific section of the CIB like "cibadmin -Q -o
On Thu, Jan 7, 2021 at 12:53 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:
> >>> Steffen Vinther Sørensen schrieb am 07.01.2021 um
> 09:49 in
> Nachricht
> :
> > Hi Reid,
> >
> > I was under the impression that 'pcs config' was the CIB in a more
> > friendly format. Here is the
Hi Steffen,
> Unfortunately not sure about the exact scenario. But I have been doing
> some recent experiments with node standby/unstandby stop/start. This
> to get procedures right for updating node rpms etc.
>
> Later I noticed the uncomforting "pending fencing actions" status msg.
Okay!
>>> Steffen Vinther Sørensen schrieb am 07.01.2021 um
09:49 in
Nachricht
:
> Hi Reid,
>
> I was under the impression that 'pcs config' was the CIB in a more
> friendly format. Here is the 'pcs cluster cib' as requested
I'd also think so (+/- parsing and presentation errors) ;-)
>
> /Steffen
Hi Steffen,
Hi Reid,
The fencing history is kept inside stonith-ng and is not written to cib.
However, getting the entire cib and getting it sent will help you to reproduce
the problem.
Best Regards,
Hideo Yamauchi.
- Original Message -
>From: Reid Wahl
>To:
>>> Reid Wahl schrieb am 07.01.2021 um 07:46 in Nachricht
:
> Do you have pcmk_monitor_timeout set? Ken mentioned that the start
Hi!
No, not found in the CIB.
> operation includes a registration and a status call. There was a bug
> in which the status call used the pcmk_monitor_timeout (if
Hi, Steffen. Those attachments don't contain the CIB. They contain the `pcs
config` output. You can get the cib with `pcs cluster cib >
$(hostname).cib.xml`.
Granted, it's possible that this fence action information wouldn't be in
the CIB at all. It might be stored in fencer memory.
On Thu, Jan
Hi Steffen,
> Here CIB settings attached (pcs config show) for all 3 of my nodes
> (all 3 seems 100% identical), node03 is the DC.
Thank you for the attachment.
What is the scenario when this situation occurs?
In what steps did the problem appear when fencing was performed (or failed)?
Best
Hi Hideo,
Here CIB settings attached (pcs config show) for all 3 of my nodes
(all 3 seems 100% identical), node03 is the DC.
Regards
Steffen
On Thu, Jan 7, 2021 at 8:06 AM wrote:
>
> Hi Steffen,
> Hi Reid,
>
> I also checked the Centos source rpm and it seems to include a fix for the
>
19 matches
Mail list logo
