<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>