<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 24, 2024 at 12:02 PM Angelo Ruggiero via Users <<a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894">




<div dir="ltr">
<div 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 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)">
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 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)">
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 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)">
Just for interest what software goes to the ruby?</div></div></div></blockquote><div> </div><div>I'm not sure what you mean by "software." However, certain functionalities, such as synchronization of 'known-hosts' files across nodes, are still implemented in the legacy ruby part of pcsd. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr"><div style="direction:ltr;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">
      - 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 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)">
Ah so pcs uses the Ruby unix socket? </div></div></div></blockquote><div><br></div><div>This socket is only used to forward HTTPS requests between pcsd running in Python and the legacy part of pcsd running in Ruby.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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></div></blockquote><div><br></div><div>Currently, only pcs Web UI running in the Cockpit web console (<a href="https://cockpit-project.org/">https://cockpit-project.org/</a>).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr"><br><div style="direction:ltr;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">
   - 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 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)">
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 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></div></div></div></blockquote><div><br></div><div>Sorry for not being entirely exact. I was speaking in the context of pcs and pcsd, so by "all" I meant the communication between pcs and pcsd. The communication between pcs and pcsd is done using HTTPS (HTTP + TLS).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr"><div style="direction:ltr;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">
- 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 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 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 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)">
Ah....Being authenticated to pcsd and being part of a cluster seperate things... That helps thanks</div>
<div 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 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></div></div></div></blockquote><div> </div><div>Yes, pcs uses HTTPS (HTTP + TLS) to communicate with all the nodes. It sends HTTPS requests telling the nodes to save the keys, update known-hosts, ...</div><div>The tokens are used in the COOKIEs of the HTTPS requests.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr"><div style="direction:ltr;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">
   - '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" 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></div></blockquote><div> </div><div>The keys are generated by the pcs command (os.urandom() python function is used to generate the keys).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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></div></blockquote><div> </div><div>Distribute, in this case, means that HTTPS requests with the needed data are sent to all the cluster nodes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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 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 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></div></blockquote><div><br></div><div>Pcs prompts for a username and password locally, then sends them to all nodes via HTTPS requests. Pcsd running on a node handles this request and provides the username and password to PAM. If the username and password are correct, then pcsd generates a token. The token is saved locally and sent in the response to save it in the 'known-hosts' file. The tokens from the 'known-hosts' file are then added to the COOKIE of the HTTPS requests when communicating with the node.</div><div>So, as an example:</div><div><ul><li>When we want to communicate with node 'A', we look into the known-hosts file to find a token for 'A' </li><li>We send an HTTPS request with the token for 'A' in the COOKIE. </li><li>Node 'A' receives the request and checks if the token from the COOKIE matches its saved token. If no, the request is rejected.</li></ul></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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></div></blockquote><div><br></div><div>The communication is done through REST API. However, the API is not properly documented.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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></div></blockquote><div><br></div><div><div>Both the certificate and the key are sent to all nodes. However,
 I overlooked that this option is not enabled by default. By default, 
every node creates its own self-signed cert (and key) during the startup
 of pcsd.</div><div>But, having the same certificate and key on all nodes can be useful, for example, when using pcs Web UI:</div><div><ul><li><div>The UI can be accessed using a floating IP running as a resource in the cluster. When the IP is moved, the user's
 browser connects to the new node. If the node has a different 
certificate, the browser warns that the cert has changed. By syncing the
 certificates, the transition to another node is a more seamless experience for the user since there is no warning about the certificate.</div></li><li><div>The
 command 'pcs pcsd sync-certificates' can be used to sync all nodes to 
use the same certificate and key (certificate and key from the local node are sent to all the nodes in the cluster).</div></li></ul></div></div><div>To sync the certs during cluster setup, the variable PCSD_SSL_CERT_SYNC_ENABLED needs to be set in systemd environment file.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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 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></div></blockquote><div><br></div>There is a command for loading a custom certificate if you need to use your certificates: 'pcs pcsd certkey <certificate file> <key file>'<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3368697132504582894"><div dir="ltr">
<div 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)">
          </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>
</div>
<div 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 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 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>
<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>> 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="m_-3368697132504582894OWA8cf42495-eb18-5c5e-dc86-1e0cd2849de2" target="_blank">
https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
><br>
> ClusterLabs home: <a href="https://www.clusterlabs.org/" id="m_-3368697132504582894OWA98a20cf5-cb18-591e-b0a7-08e143ac3cb5" target="_blank">
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="m_-3368697132504582894OWA3e3941f1-e83d-1040-9197-06fca8e5fc20" target="_blank">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 <<a href="mailto:oalbrigt@redhat.com" target="_blank">oalbrigt@redhat.com</a>><br>
To: Cluster Labs - All topics related to open-source clustering<br>
        welcomed <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>><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="m_-3368697132504582894OWAc505d61f-a1b3-ca7a-3786-1a2b284ef2fb" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
><br>
>ClusterLabs home: <a href="https://www.clusterlabs.org/" id="m_-3368697132504582894OWAee347fbc-5cdf-7dd8-a4ca-4d0085455944" target="_blank">
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 <<a href="mailto:oalbrigt@redhat.com" target="_blank">oalbrigt@redhat.com</a>><br>
To: Cluster Labs - All topics related to open-source clustering<br>
        welcomed <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>><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="m_-3368697132504582894OWA60245d79-93e8-1e59-98dc-ad6aa8b691b2" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>><br>
>>ClusterLabs home: <a href="https://www.clusterlabs.org/" id="m_-3368697132504582894OWA75d25df4-d40a-e9a4-c06b-40a65851211e" target="_blank">
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="m_-3368697132504582894OWAa8b9286a-be77-4713-cca5-1249045d1416" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" id="m_-3368697132504582894OWA875521c8-5512-e925-ed55-06d53c8c1e29" target="_blank">
https://www.clusterlabs.org/</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Users Digest, Vol 115, Issue 10<br>
**************************************</div>
</div>

_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</div></blockquote></div></div>