<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks Peter for taking the time. Some followup questions, then I will reformualte my summary again πand also put in the quorum device (2 node cluster) and web ui to pcsd.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks for your patience...</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
<br>
- There are two Unix domain sockets used by pcsd:<br>
- For communication between Python and Ruby pcsd</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Ah....</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
("/var/run/pcsd-ruby.socket"). This is due to some legacy parts of the<br>
daemon still running in Ruby. So, if Python gets a request that should be<br>
handled by Ruby daemon, it forwards it using this socket.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Just for interest what software goes to the ruby?</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
- For communication between clients and pcsd<br>
("/var/run/pcsd.socket"). However, PCS does not currently utilize this<br>
socket to communicate with the local pcsd.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Ah so pcs uses the Ruby unix socket? </div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Who does use the pcsd.socket then?</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
- All the communication in the network commands is done using tls, as<br>
you mentioned. However, the communication between pcs and the local pcsd is<br>
not done using unix domain socket. Unix domain socket is only used for the<br>
already mentioned Python to Ruby daemon communication.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
TLS is just used for network for pcs to pcsd or for browser to pscd web ui to define "All" π Not for corosync. Right?</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
And then that would mean pcs to pcsd also locally is via the TCP socket?<br>
<br>
- The commands can even be run on a node that will not be part of the<br>
cluster after the setup. In the case of 'pcs cluster setup,' it must run on<br>
a node with all the intended cluster nodes authenticated.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Ok... i.e the pcs to pcsd is via the network as you previously said.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
- There are no Corosync files involved in 'pcs host auth'. Being<br>
authenticated to pcsd and being a part of a cluster are separate things.<br>
There also seems to be a little confusion about what the two mentioned<br>
commands do. So here is an overview of how they work:</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Ah....Being authenticated to pcsd and being part of a cluster seperate things... That helps thanks</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
So the overall design is that pcs connects to all nodes even local nodes securely using tokens via TLS and tells those nodes</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Write the corosync and pacemaker authkey files, update know hosts, ... <br>
<br>
- 'pcs host auth <list of hosts>'<br>
1. For each node in the list of hosts (even the local node)<br>
1. pcs sends https request for authentication<br>
2. Remote node authenticates using PAM (username + password)<br>
3. Remote node generates a token, saves it, and sends it in<br>
response<br>
2. Local known-hosts file is updated locally with the tokens received<br>
from responses and distributed to all nodes<br>
- 'pcs cluster setup <list of hosts>'<br>
1. Requests for destroying cluster and removal of pcsd config files<br>
are sent to all nodes<br>
- in case there is some old unwanted configuration on the nodes<br>
2. The local known-hosts file is distributed to all nodes<br>
3. corosync_authkey and pacemaker_authkey are generated and<br>
distributed to all nodes<br>
- each node receives the keys and saves them<br>
4. New pcsd tls certificate and key is generated and distributed<br>
- so that all nodes have the same certificate<br>
- each remote node saves the files and reloads tls certificate<br>
used by the daemon<br>
5. corosync_conf is generated and distributed to all nodes<br>
- Again, each node receives the config file and saves it<br>
<br>
</div>
<ol start="1" data-editing-info="{"orderedStyleType":5,"unorderedStyleType":1}" data-listchain="__List_Chain_815" style="margin-top: 0px; margin-bottom: 0px; list-style-type: lower-alpha;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
In step 3 who is generating the keys i.e the pcs command?<br>
</li></ol>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
βββ b. When you say distribute/sent above via the pcs to pcsd connection?</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
c. Regarding the tokens. </div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
ββββ c.1 I can imagine that the pcs to pcsd proctol has the ability to ask the pcs to prompt for password and then the pcsd does the PAM to validate and return a token</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
c.2 And i asusme that the pcs to pcsd protocol allow s the token to presented when some action needs to be authenticated e.g setting a node to standby,.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
d. Would you, or anyone know, Where can i find a description of the pcs to pcsd protocol? I could not find it.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
βββ e. In Step 4.. Just the certificate is sent to all nodes. The private key is kept local. Right? I.e all nodes are generating there own public, private key pair.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
(which i might be asked to use our own CA and not the self signed one from Missouri I saw when I dumped the cert file).</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
I am a bit confused here to be honest.</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
regards</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Angelo</div>
<div class="elementToProof" style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
<br>
On Fri, Aug 16, 2024 at 2:41?PM Angelo M Ruggiero via Users <<br>
users@clusterlabs.org> wrote:<br>
<br>
> Hello,<br>
><br>
> I have been learning and playing with the pacemaker. Its great. We are<br>
> going to use is in SAP R3/HANA on RHEL8 hopefully in the next few months.<br>
><br>
> I am trying to make sure I know how it works from a security point of<br>
> view. As in my world I have to explain to security powers at be ....<br>
><br>
> So been looking at the man pages, netstatin,tcpdumping, lsofing etc and<br>
> looking at the code even as far as i can.<br>
><br>
> Here is an initial sort of description what actually happens during the<br>
> initial setup until all processes are up and "trusted" thereafter with<br>
> resources is less of an issue.<br>
><br>
> I know it some how not exact enough. But I need some sort of pointers or<br>
> some basic corrections then I will make it better. Happy to contribute<br>
> something here if people think valuable.<br>
> I got some pics as well.<br>
><br>
> Just to be I do not have a problem it is all working.<br>
><br>
> So can someone help me to review the below.<br>
><br>
> 1. packages pcs, pacemaker, corosync., ... installed on each host<br>
> hacluster password set and pcsd started<br>
> 2. On one of the intended cluster hosts....pcs host add <list of hosts><br>
> 1. pcs(1) connects to the local pcsd(8) via only root writable unix<br>
> domain socket<br>
> 2. local pcsd connects to each remote host on port 2244 via TLS and<br>
> configured cipher<br>
> 1. the remote pcsd via PAM requests uid, password authentication<br>
> (hacluster and the above set passwd)<br>
> 1. if successfull the remote pcsd<br>
> 1. writes into the local /var/lib/pcsd/known_hosts its own<br>
> entry<br>
> 2. writes the node list entry into the<br>
> /etc/corosync/corosync.,conf<br>
> 3. if there is no /etc/corosync/authkey the<br>
> corosync_keygen is running to generate and write the key<br>
> 2. the local pcsd<br>
> 1. writes also the remotes pcsd the remote hosts entry<br>
> 1. writes the node list entry into the<br>
> /etc/corosync/corosync.,conf<br>
> 2. if there is no /etc/corosync/authkey the<br>
> corosync_keygen is running to generate and write the key<br>
> 3. On one of the intended cluster hosts... pcs cluster setup<br>
> <list of hosts><br>
> 1. pcs(1) connects to the local pcsd(8) via only root writable unix<br>
> domain socket<br>
> 2. allocates a random /etc/pacemaker/authkey<br>
> 3. connects to each of the list of hosts via TLS and for each<br>
> 1. presents the remote host token from the previously setup<br>
> known hosts entry for authentication<br>
> 2. presents the /etc/pacemaker/authkey if not yet on the remote<br>
> host<br>
> 3. send the configuration data<br>
><br>
><br>
> Angelo<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Manage your subscription:<br>
> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" id="OWA8cf42495-eb18-5c5e-dc86-1e0cd2849de2" class="x_OWAAutoLink" data-auth="NotApplicable">
https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
><br>
> ClusterLabs home: <a href="https://www.clusterlabs.org/" id="OWA98a20cf5-cb18-591e-b0a7-08e143ac3cb5" class="x_OWAAutoLink" data-auth="NotApplicable">
https://www.clusterlabs.org/</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.clusterlabs.org/pipermail/users/attachments/20240821/13f56e93/attachment-0001.htm" id="OWA3e3941f1-e83d-1040-9197-06fca8e5fc20" class="x_OWAAutoLink" data-auth="NotApplicable">https://lists.clusterlabs.org/pipermail/users/attachments/20240821/13f56e93/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 22 Aug 2024 08:58:39 +0200<br>
From: Oyvind Albrigtsen <oalbrigt@redhat.com><br>
To: Cluster Labs - All topics related to open-source clustering<br>
welcomed <users@clusterlabs.org><br>
Subject: Re: [ClusterLabs] a request for "oracle" resource agent<br>
Message-ID:<br>
<bjt24kzkbdnewboneje5w4pkpnojoa2myb5k3wsvroeivmwdw5@gikvjt3iq57c><br>
Content-Type: text/plain; charset=us-ascii; format=flowed<br>
<br>
I cant remember anyone requesting this, but it should be fairly simple<br>
to implement.<br>
<br>
You can add a "mode" parameter to the metadata with<br>
OCF_RESKEY_mode_default="running", and add an expected_status<br>
variable in instance_live() that will be OPEN if it's set to running,<br>
and the expected state for standby when it's set to standby, and<br>
replace the 3 OPEN's in the function with $expected state.<br>
<br>
<br>
Oyvind<br>
<br>
On 19/08/24 17:10 GMT, Fabrizio Ermini wrote:<br>
>Hi!<br>
>I am trying to set up an oracle instance managed by a pacemaker cluster.<br>
>It's a task that I have performed several times with no issue, but in this<br>
>particular case I have a non standard requirement: since the instance<br>
>sometimes would take the role of a standby database, the "start" actions<br>
>should NOT open the DB instance, just mount it.<br>
><br>
>Are you aware of a way to make this happen? I thought initially to just<br>
>comment out the "open" command in the resource script, but of course this<br>
>would not work since the monitor operations would report the unopened<br>
>instance as an error.<br>
><br>
>In any case let me know if you could be interested to add this as a feature<br>
>if I manage to successfully make it work.<br>
><br>
>Thanks for your time and effort, and best regards<br>
>Fabrizio<br>
<br>
>_______________________________________________<br>
>Manage your subscription:<br>
><a href="https://lists.clusterlabs.org/mailman/listinfo/users" id="OWAc505d61f-a1b3-ca7a-3786-1a2b284ef2fb" class="x_OWAAutoLink" data-auth="NotApplicable">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
><br>
>ClusterLabs home: <a href="https://www.clusterlabs.org/" id="OWAee347fbc-5cdf-7dd8-a4ca-4d0085455944" class="x_OWAAutoLink" data-auth="NotApplicable">
https://www.clusterlabs.org/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 22 Aug 2024 09:33:54 +0200<br>
From: Oyvind Albrigtsen <oalbrigt@redhat.com><br>
To: Cluster Labs - All topics related to open-source clustering<br>
welcomed <users@clusterlabs.org><br>
Subject: Re: [ClusterLabs] a request for "oracle" resource agent<br>
Message-ID:<br>
<4legqceoeaervdfufz3csyubnki4iavluwcm7ked3fqxeepldi@46zzwjqy3rai><br>
Content-Type: text/plain; charset=us-ascii; format=flowed<br>
<br>
Feel free to make a Pull Request against the repository, and I can give<br>
some feedback, and we can either merge it if there's others wanting<br>
the feature, or close it if not (it will still be available so people<br>
can search for oracle in the Pull Requests section and find the code).<br>
<br>
<br>
Oyvind<br>
<br>
On 22/08/24 08:58 GMT, Oyvind Albrigtsen wrote:<br>
>I cant remember anyone requesting this, but it should be fairly simple<br>
>to implement.<br>
><br>
>You can add a "mode" parameter to the metadata with<br>
>OCF_RESKEY_mode_default="running", and add an expected_status<br>
>variable in instance_live() that will be OPEN if it's set to running,<br>
>and the expected state for standby when it's set to standby, and<br>
>replace the 3 OPEN's in the function with $expected state.<br>
><br>
><br>
>Oyvind<br>
><br>
>On 19/08/24 17:10 GMT, Fabrizio Ermini wrote:<br>
>>Hi!<br>
>>I am trying to set up an oracle instance managed by a pacemaker cluster.<br>
>>It's a task that I have performed several times with no issue, but in this<br>
>>particular case I have a non standard requirement: since the instance<br>
>>sometimes would take the role of a standby database, the "start" actions<br>
>>should NOT open the DB instance, just mount it.<br>
>><br>
>>Are you aware of a way to make this happen? I thought initially to just<br>
>>comment out the "open" command in the resource script, but of course this<br>
>>would not work since the monitor operations would report the unopened<br>
>>instance as an error.<br>
>><br>
>>In any case let me know if you could be interested to add this as a feature<br>
>>if I manage to successfully make it work.<br>
>><br>
>>Thanks for your time and effort, and best regards<br>
>>Fabrizio<br>
><br>
>>_______________________________________________<br>
>>Manage your subscription:<br>
>><a href="https://lists.clusterlabs.org/mailman/listinfo/users" id="OWA60245d79-93e8-1e59-98dc-ad6aa8b691b2" class="x_OWAAutoLink" data-auth="NotApplicable">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>><br>
>>ClusterLabs home: <a href="https://www.clusterlabs.org/" id="OWA75d25df4-d40a-e9a4-c06b-40a65851211e" class="x_OWAAutoLink" data-auth="NotApplicable">
https://www.clusterlabs.org/</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" id="OWAa8b9286a-be77-4713-cca5-1249045d1416" class="x_OWAAutoLink" data-auth="NotApplicable">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" id="OWA875521c8-5512-e925-ed55-06d53c8c1e29" class="x_OWAAutoLink" data-auth="NotApplicable">
https://www.clusterlabs.org/</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Users Digest, Vol 115, Issue 10<br>
**************************************</div>
</body>
</html>