[Pacemaker] Split Site 2-way clusters

[Miki Shapiro]

Separate to my earlier post re CRM DC election in a 2-way cluster, I'm chasing 
up the (separate) issue of making the cluster a CROSS-SITE one.

As stated in yay other thread, I'm running a 2-way quorum-agnostic cluster on a 
SLES11, openais, pacemaker, drbd (... clvm, ocfs2, ctdb, nfs, etc) on HP Blades.

A few old threads (with a rather elaborate answer from Lars) indicate that as 
of March 2009 split-site wasn't yet thoroughly supported as WAN connectivity 
issues were not thoroughly addressed, and that as of then quorumd was not yet 
sufficiently robust/tested/PROD-ready.

What we decided we want to do is rely on an extremely simple (and hopefully by 
inference predictable and reliable) arbitrator - a THIRD linux server that 
lives at a SEPARATE THIRD site altogether with no special HA-related daemons 
running on it.

I'll build a STONITH ocf script, configure it as a cloned STONITH resource 
running on both nodes, and it will do roughly this when pinging the other node 
(via either one or two redundant links) will fail:

ssh arbitrator mkdir /tmp/$clustername && shoot-other-node || hard-suicide-NOW

Thus, when split, the nodes race to the arbitrator.
First to run the mkdir command on the arbitrator (and get rc=0) wins, gets the 
long straw and lives.  Loser gets shot (either by its peer if WAN allows peer 
to communicate with soon-to-be-dead node's iLO or by said node sealing its own 
fate).

Primary failure modes not accounted for by a run-of-the-mill non-split-site 
cluster are thus:


1.   One node cut off - cutoff node will fail the race and suicide. Good 
node will succeed and proceed to provide service.

2.   Nodes cut off from each other but can both access the arbitrator - 
slower node will suicide. Faster node will succeed and proceed to provide 
service.

3.   Both nodes are cut off, or the comms issue affects both node1<->node2 
comms AND all ->arbitrator comms (double failure).  - both nodes suicide (and 
potentially leave me with two inconsistent and potentially corrupt 
filesystems). Can't see an easy way around this one (can anyone?)



Looks to me like this can easily be implemented without any fancy quorum 
servers (on top of the required little ocf script and the existence of the 
arbitrator)

Does anyone have thoughts on this? Am I ignoring any major issues, or 
reinventing the wheel, or should this this potentially work as I think it will?

Thanks! :)

And a little addendum which just occurred to me re transient WAN network issues:



1.   Transient big (>2min) network issues will land me with a cluster that 
needs a human to turn on one node on every time they happen. Bad.



My proposed solution: classify a peer-failure as a WAN-problem by pinging peer 
node's core router when peer node appears dead, if router dead too touch a 
WAN-problem-flagfile, and so long as the flag-file sits there the survivor 
pings (done via ocf ping resource) other-side-router until it comes online, 
then shooting a "check-power-status && O-GOD-IT-STILL-LIVES-KILL-IT-NOW || 
power-it-on" command to the peer's iLO (and promptly delete the flag).



Implementation cost: a wee bit of scripting and a wee bit of pacemaker 
configuration.



2.   Transient small network issues will require stretching pacemaker's 
default timeouts sufficiently to avoid (or end up in the item 1 bucket above)

Am very keen to know what the gurus think :) :)

Miki Shapiro
Linux Systems Engineer
Infrastructure Services & Operations

[cid:image001.png@01CA9473.B8C182C0]
745 Springvale Road
Mulgrave 3170 Australia
Email miki.shap...@coles.com.au
Phone: 61 3 854 10520
Fax: 61 3 854 10558



__
This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete
this e-mail immediately. Any confidentiality, privilege or copyright
is not waived or lost because this e-mail has been sent to you in
error. It is your responsibility to check this e-mail and any
attachments for viruses.  No warranty is made that this material is
free from computer virus or any other defect or error.  Any
loss/damage incurred by using this material is not the sender's
responsibility.  The sender's entire liability will be limited to
resupplying the material.
__<><>___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Dejan Muhamedagic wrote:
> Hi,
> 
> On Tue, Jan 12, 2010 at 08:00:56PM +0800, Yan Gao wrote:
>> Hi Dejan,
>>
>> Dejan Muhamedagic wrote:
>>> Hi,
>>>
>>> On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:
 ..
 
   
 
 
   
   
 
 
   
   
 
 
 
   
 
   
   
 
 
>>> I understand that the "ref" element references some "id", but
>>> note that the attributes's ids are sort of volatile. In
>>> particular the meta attributes. Can we somehow reference the
>>> attributes themselves (in this case "password" and
>>> "target-role")? 
>> It might not make it clear, because there could be multiple nvpairs with the
>> same "name" in different attribute sets. Even they could be under a single 
>> resource,
>> for example some of the attributes sets contain specific rules.
> 
> But that shouldn't matter. By setting reference to the attribute
> name, the user clearly indicates what they want. If there are
> multiple elements with the same attribute, it should apply to all
> of them.
I think it would be better to introduce xpath as Andrew suggested.
That would be precise enough.

> 
 The user "ygao" is a system account.
 We could define several roles as we wish, such as "admin",
 "operator" and "monitor", which could contain a member list
 respectively if more than one user have the same permissions. A
 role also could be referenced by a particular ""
 definition.
>>> I find this a bit confusing: roles have members and users can
>>> reference roles. Shouldn't one of the two suffice? 
>> An user can reference one or more roles to combine the rules with his
>> particular definition. But if several users  are supposed to have the
>> completely same permissions, the "members" under a "role" could avoid
>> to define the users via separated ">
>>> The way it is
>>> now, it's also hard to follow.
>> What if to separate it into two cases for an user definition in crm shell:
>> 1. "is" a role
>> 2. "ref" one role or more roles.
> 
> But, let's try to forget for a moment the shell or CRM in general.
> I'm trying to understand why a role reference makes things
> better. Actually, it would be great if you could give an example
> which would clearly show an advantage of such use.
For example:
User A has the right to operate rsc1, while user B has the right to
operate rsc2. Besides that, we might want to grant them some other same
permissions, for instance allowing them to monitor the status of the cluster.
So we could define a common role "monitor" for reference instead
of defining similar rules repeatedly.

A ideal way in my mind is that we provide some templates with
common roles pre-defined for user's convenience to reference.

>>> But I guess that it is not relevant.
 BTW, there're some changes comparing to the original design:
 [...]
 There could be an "attribute" for an ACL object in the original design :
 

 it was supposed to mean user could only write the "value" attribute of
 "rsc0-meta_attributes-target-role" element.

 I didn't implement it because there's no good way for now for the ACL
 checker to recognize if a modification would change/add/remove any
 particular attributes of a XML element. And I'm thinking if it's
 necessary to implement it... Your thoughts?
>>> OK, I suppose that I commented on this above :) If it is a
>>> problem to implement it here, then we may try to do that in the
>>> crm shell, i.e. it would lookup the attribute name and then
>>> create the right ref id.
>> Great!
> 
> Well, that would not be optimal: let's not forget that shell use
> is not required.
Right. If an user works with XML, xpath would not be hard to use
for him :)

Regards,
  Yan
-- 
Yan Gao 
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

[Pacemaker] DC election with downed node in 2-way cluster

[Miki Shapiro]

Hi all

I'm attempting to build a 2-way cluster, SLES-11-based with an 
openais/pacemaker stack. I've got the nodes and a resource (a drbd volume) 
happening. What I'm not sure about is the active CRM DC election process.

I configured a null stonith resource for each node.
I have stonith-enabled set to true ( I will implement a real stonith facility 
once final solution is in place)
I have no-quorum-policy set to ignore (as the cluster is expected to work with 
one node active).

I look at crm_mon or crm_gui, and it's all green and happy.

I now go and halt a node.

Observing crm_mon or crm_gui on node2, I expect to see :

1.   Services appear as down thanks to resource monitoring directives.

2.   The quorum broken (... do I care?)

3.   The new node elected as DC. Despite what the book states (here: < 
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-cluster-status.html
 > at the bottom)  that:

"The DC (Designated Controller) node is where all the decisions are made and if 
the current DC fails a new one is elected from the remaining cluster nodes. The 
choice of DC is of no significance to an administrator beyond the fact that its 
logs will generally be more interesting."



Is of significance. I want the brain, in as far as the surviving node is 
concerned, to be running on a non-halted server.


What happens in practice is:
If I halt the DC,

1.   Resources DO appear stopped and do-their-thing(tm)

2.   [PROBLEM?] Quorum DOES NOT appear as broken

3.   [PROBLEM?] The remaining node DOES NOT get (visibly) elected as the 
new DC.
If I halted the non-DC node,

1.   Resources DO appear stopped and do-their-thing(tm)

2.   Quorum DOES appear as broken

3.   [PROBLEM?]The remaining node DOES NOT get (visibly) elected as the new 
DC.

Now if my understanding serves me right, the DC is the baton-holding CRM that 
does the thinking for the entire cluster. If the surviving node1 think that the 
(DEAD) node2 is the de-facto brains of the cluster and doesn't take the reigns, 
I have a dysfunctional cluster.

Can someone please offer some clarification on how one would reasonably expect 
this to work?

Thanks!


Miki Shapiro
Linux Systems Engineer
Infrastructure Services & Operations

[cid:image001.png@01CA9453.D1ECBD70]
745 Springvale Road
Mulgrave 3170 Australia
Email miki.shap...@coles.com.au
Phone: 61 3 854 10520
Fax: 61 3 854 10558



__
This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete
this e-mail immediately. Any confidentiality, privilege or copyright
is not waived or lost because this e-mail has been sent to you in
error. It is your responsibility to check this e-mail and any
attachments for viruses.  No warranty is made that this material is
free from computer virus or any other defect or error.  Any
loss/damage incurred by using this material is not the sender's
responsibility.  The sender's entire liability will be limited to
resupplying the material.
__<><>___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Clarification about corosync timing values

[Wen.Tian]

These parameters are from the totem protocol implemented by the openais. The 
token is the timeout to determine the token loss. The join is the timeout to 
send the join message during the gather state. The consensus is the consensus 
timeout during the gather state. And the max_message is a flow control 
parameter ,which is the maxmium number of messages a node allowed to send 
during one token round.
You can refer the totem protocol to learn more.

That's my understanding, correct me if  I am wrong.

Regards
 
- Original Message - 
From: "Andreas Mock" 
To: 
Sent: Wednesday, January 13, 2010 12:46 AM
Subject: [Pacemaker] Clarification about corosync timing values


> Hi all,
> 
> the installation guide at 
> http://www.clusterlabs.org/wiki/Initial_Configuration#CoroSync
> has an example corosync.conf with some values different than 
> the defaults described by the man page (corosync 1.2.0).
> 
> I would be interested to know why there are different values.
> 
> token: 5000   (default 1000)
> join: 1000 (default 50)
> consensus: 7500 (default >1200)
> max_messages: 20 (default 17)
> 
> Can someone give insight to this values and there interdependencies?
> 
> Thanks in advance
> Andreas Mock
> 
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] crm_attribte failed with Multiple attributes match

[hj lee]

On Tue, Jan 12, 2010 at 2:15 PM, hj lee  wrote:

>
>
>> 2010-01-12 00:19:47.879800 copper1-cib: [4764]: debug: cib_process_xpath:
>> Processing cib_query op for //cib/status//node_sta...@id='
>> copper1.dr.peach.com']//nvpa...@name='master-vmrd-res:0']
>> (/cib/status/node_state[1]/transient_attributes/instance_attributes/nvpair[3])
>> 2010-01-12 00:19:47.897835 copper1-cib:last message repeated 2 times
>> 2010-01-12 00:19:47.879870 copper1-attrd: [4766]: debug: log_data_element:
>> find_nvpair_attr: Match 
>> 2010-01-12 00:19:47.879892 copper1-attrd: [4766]: debug: log_data_element:
>> find_nvpair_attr: Match   > id="status-copper1.dr.peach.com-master-vmrd-res:0" name="master-vmrd-res:0"
>> value="1" />
>> 2010-01-12 00:19:47.898582 copper1-attrd:last message repeated 2 times
>> 2010-01-12 00:19:47.879938 copper1-attrd: [4766]: debug: log_data_element:
>> find_nvpair_attr: Match 
>> 2010-01-12 00:19:47.879958 copper1-attrd: [4766]: WARN: find_nvpair_attr:
>> Multiple attributes match name=master-vmrd-res:0
>> 2010-01-12 00:19:47.879968 copper1-attrd: [4766]: info:
>> find_nvpair_attr:   Value: 1
>> #011(id=status-copper1.dr.peach.com-master-vmrd-res:0)
>> 2010-01-12 00:19:47.899603 copper1-attrd:last message repeated 2 times
>> 2010-01-12 00:19:47.880025 copper1-attrd: [4766]: info:
>> attrd_perform_update: Sent update -40: master-vmrd-res:0=5
>> 2010-01-12 00:19:47.880057 copper1-attrd: [4766]: ERROR:
>> attrd_cib_callback: Update -40 for master-vmrd-res:0=5 failed: Required data
>> for this CIB API call not found
>>
>>
> I suspect libxml2 is not thread-safe. And I found the following statement
> from libxml2 website(http://xmlsoft.org/threads.html).
>
> "Note that the thread safety cannot be ensured for multiple threads sharing
> the same document, the locking must be done at the application level".
>
> Is cib code a thread-safe?
>
>
Hi again,

I verified that cib is single thread, so thread-safe is not issue.  I wrote
a simple shell script that keeps read and write master score. And I dumped
cib xml to file when  xpath_search() returns multiple entries. Running this
script, this problem is easily reproducible. I run this script on both nodes
with 0 and 1(ex, cib-test.sh 0). When it returns multiple entries, it always
returns 3 of the same entriy! I checked the dumped cib xml, there was only
one entry. This is a show stopper for our product release. Would you look at
this issue seriously?

-cib-test.sh 
#!/bin/bash

id=$1
let count=1

while [ true ]; do
  crm_master -l reboot -r vmrd-res:$id
  crm_master -l reboot -r vmrd-res:$id -v $count
  let "count=$count+1"
  if [ $count -gt 9 ]; then
count=1
  fi
  sleep 1
done

Thank you very much
___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Steven Dake]

> > d) If I would try to compile from source as described at
> > http://www.clusterlabs.org/wiki/Install#First_Steps
> > one step is to get openais. Why are all the relevant
> > prebuild library packages called corosync?
> > I don't understand the distinction between openais and corosync
> 

read this link:
http://www.corosync.org/doku.php?id=faq:why


> Corosync used to be part of Openais.
> Then they split it into two parts to make maintenance easier.
> From their home page "The OpenAIS software is built to operate on the
> Corosync Cluster Engine "
> 
> > and how this two pieces fit together. By the way: There homepage
> > doesn't enlight me either.
> >
> > Enough questions for a restart.
> >
> > Best regards
> > Andreas Mock
> >
> >
> >
> > ___
> > Pacemaker mailing list
> > Pacemaker@oss.clusterlabs.org
> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> >
> 
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker


___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] crm_attribte failed with Multiple attributes match

[hj lee]

On Tue, Jan 12, 2010 at 1:37 PM, hj lee  wrote:

>
>
> It happened again, I attched cib files and log messages of both nodes. The
> problem happened last night, but cib file was captured this morning.  As you
> can see below log expert, the attrd receives 2 entries for cib_query,
> crm_attribute failed to update master score. The fact that the
> cib_process_xpath was printed twice and  tag clearly suggests
> that the root cause of this problem is xpath_search() returned two entries.
> So is it a bug in xml2 library?
>
> Thanks
> hj
>
> 2010-01-12 00:19:47.879800 copper1-cib: [4764]: debug: cib_process_xpath:
> Processing cib_query op for //cib/status//node_sta...@id='
> copper1.dr.peach.com']//nvpa...@name='master-vmrd-res:0']
> (/cib/status/node_state[1]/transient_attributes/instance_attributes/nvpair[3])
> 2010-01-12 00:19:47.897835 copper1-cib:last message repeated 2 times
> 2010-01-12 00:19:47.879870 copper1-attrd: [4766]: debug: log_data_element:
> find_nvpair_attr: Match 
> 2010-01-12 00:19:47.879892 copper1-attrd: [4766]: debug: log_data_element:
> find_nvpair_attr: Matchid="status-copper1.dr.peach.com-master-vmrd-res:0" name="master-vmrd-res:0"
> value="1" />
> 2010-01-12 00:19:47.898582 copper1-attrd:last message repeated 2 times
> 2010-01-12 00:19:47.879938 copper1-attrd: [4766]: debug: log_data_element:
> find_nvpair_attr: Match 
> 2010-01-12 00:19:47.879958 copper1-attrd: [4766]: WARN: find_nvpair_attr:
> Multiple attributes match name=master-vmrd-res:0
> 2010-01-12 00:19:47.879968 copper1-attrd: [4766]: info: find_nvpair_attr:
> Value: 1 #011(id=status-copper1.dr.peach.com-master-vmrd-res:0)
> 2010-01-12 00:19:47.899603 copper1-attrd:last message repeated 2 times
> 2010-01-12 00:19:47.880025 copper1-attrd: [4766]: info:
> attrd_perform_update: Sent update -40: master-vmrd-res:0=5
> 2010-01-12 00:19:47.880057 copper1-attrd: [4766]: ERROR:
> attrd_cib_callback: Update -40 for master-vmrd-res:0=5 failed: Required data
> for this CIB API call not found
>
>
I suspect libxml2 is not thread-safe. And I found the following statement
from libxml2 website(http://xmlsoft.org/threads.html).

"Note that the thread safety cannot be ensured for multiple threads sharing
the same document, the locking must be done at the application level".

Is cib code a thread-safe?

Thanks
___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] OCF scripts for cups and courier-imap

[cheibi welid]

On Mon, Jan 11, 2010 at 9:20 AM, Florian Haas wrote:

> On 2010-01-09 10:00, cheibi welid wrote:
> > Hi all,
> >
> > I am currently testing a HA cluster with DRBD (Pacemaker, Heartbeat,
> > DRBD) and i need OCF scripts for cups and courier-imap. I want to know
> > if those scripts already exist or should i develop them and in this
> > case, is there some guides or guidelines to follow ?
>
> Any reason not to use the LSB init scripts bundled with either of these?
>
I think OCF scripts are more powerful ! for managing the service and
especially for recovery, no ?

>
> Cheers,
> Florian
>
>
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
>
___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

[Pacemaker] Clarification about corosync timing values

[Andreas Mock]

Hi all,

the installation guide at 
http://www.clusterlabs.org/wiki/Initial_Configuration#CoroSync
has an example corosync.conf with some values different than 
the defaults described by the man page (corosync 1.2.0).

I would be interested to know why there are different values.

token: 5000   (default 1000)
join: 1000 (default 50)
consensus: 7500 (default >1200)
max_messages: 20 (default 17)

Can someone give insight to this values and there interdependencies?

Thanks in advance
Andreas Mock

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pre-Announce: End of 0.6 support is near

[Emmanuel Lesouef]

Le Tue, 12 Jan 2010 14:56:31 +0100,
Michael Schwartzkopff  a écrit :

> Am Dienstag, 12. Januar 2010 14:48:12 schrieb Emmanuel Lesouef:
> > Hi,
> >
> > We use a rather old (in fact, very old) combination :
> >
> > heartbeat 2.99 + openhpi 2.12
> >
> > What do you suggest in order to upgrade to the latest version of
> > pacemaker ?
> >
> > Thanks.
> 
> http://www.clusterlabs.org/wiki/Upgrade
> 

Thanks for your answer. I already saw :
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ap-upgrade.html

In fact, my question wans't about the upgrading process but more about
polling this list about caveats, advices or best practice when dealing
with rather old & uncommon configuration.

Hoping that makes things clearer :)



-- 
Emmanuel Lesouef

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Dejan Muhamedagic]

Hi,

On Tue, Jan 12, 2010 at 08:00:56PM +0800, Yan Gao wrote:
> Hi Dejan,
> 
> Dejan Muhamedagic wrote:
> > Hi,
> > 
> > On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:
> >> ..
> >> 
> >>   
> >> 
> >> 
> >>   
> >>   
> >> 
> >> 
> >>   
> >>   
> >> 
> >> 
> >> 
> >>   
> >> 
> >>   
> >>   
> >> 
> >> 
> > 
> > I understand that the "ref" element references some "id", but
> > note that the attributes's ids are sort of volatile. In
> > particular the meta attributes. Can we somehow reference the
> > attributes themselves (in this case "password" and
> > "target-role")? 
> It might not make it clear, because there could be multiple nvpairs with the
> same "name" in different attribute sets. Even they could be under a single 
> resource,
> for example some of the attributes sets contain specific rules.

But that shouldn't matter. By setting reference to the attribute
name, the user clearly indicates what they want. If there are
multiple elements with the same attribute, it should apply to all
of them.

> > Would there be a big performance penalty?
> 
> > 
> >> 
> >> 
> >>   
> >> 
> >> ..
> > 
> > Do you have a suggestion how to spell out acls in the crm shell
> > syntax? We should also create a real-life acl configuration and
> > then see how that can be represented.
> I've been thinking about it, but haven't got an clear idea now:)

OK. Let's hope we get some idea :)

> >> The user "ygao" is a system account.
> >> We could define several roles as we wish, such as "admin",
> >> "operator" and "monitor", which could contain a member list
> >> respectively if more than one user have the same permissions. A
> >> role also could be referenced by a particular ""
> >> definition.
> > 
> > I find this a bit confusing: roles have members and users can
> > reference roles. Shouldn't one of the two suffice? 
> An user can reference one or more roles to combine the rules with his
> particular definition. But if several users  are supposed to have the
> completely same permissions, the "members" under a "role" could avoid
> to define the users via separated " 
> > The way it is
> > now, it's also hard to follow.
> What if to separate it into two cases for an user definition in crm shell:
> 1. "is" a role
> 2. "ref" one role or more roles.

But, let's try to forget for a moment the shell or CRM in general.
I'm trying to understand why a role reference makes things
better. Actually, it would be great if you could give an example
which would clearly show an advantage of such use.

> It can be either of them in configuration, and must not be both of them.
> That also could avoid the confusing case which I demonstrated in the example.
> 
> So how about the syntax like:
> 
> role  acl_obj [acl_obj ...]
> 
> user  {acl_obj | ref_role} [{acl_obj | ref_role} ...]
> 
> user  is 
> 
> acl_obj ::
>   mode ref 
>   mode tag 
>   mode ref  tag 
> 
> mode:: read | write | deny
> 
> ref_role:: ref_role 

Looks good to me.

> > But I guess that it is not relevant.
> 
> > 
> >> BTW, there're some changes comparing to the original design:
> >> [...]
> >> There could be an "attribute" for an ACL object in the original design :
> >> 
> >>
> >> it was supposed to mean user could only write the "value" attribute of
> >> "rsc0-meta_attributes-target-role" element.
> >>
> >> I didn't implement it because there's no good way for now for the ACL
> >> checker to recognize if a modification would change/add/remove any
> >> particular attributes of a XML element. And I'm thinking if it's
> >> necessary to implement it... Your thoughts?
> > 
> > OK, I suppose that I commented on this above :) If it is a
> > problem to implement it here, then we may try to do that in the
> > crm shell, i.e. it would lookup the attribute name and then
> > create the right ref id.
> Great!

Well, that would not be optimal: let's not forget that shell use
is not required.

Cheers,

Dejan

> Thanks,
>   Yan
> -- 
> Yan Gao 
> Software Engineer
> China Server Team, OPS Engineering, Novell, Inc.
> 
> 
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pre-Announce: End of 0.6 support is near

[Michael Schwartzkopff]

Am Dienstag, 12. Januar 2010 14:48:12 schrieb Emmanuel Lesouef:
> Hi,
>
> We use a rather old (in fact, very old) combination :
>
> heartbeat 2.99 + openhpi 2.12
>
> What do you suggest in order to upgrade to the latest version of
> pacemaker ?
>
> Thanks.

http://www.clusterlabs.org/wiki/Upgrade

-- 
Dr. Michael Schwartzkopff
MultiNET Services GmbH
Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany
Tel: +49 - 89 - 45 69 11 0
Fax: +49 - 89 - 45 69 11 21
mob: +49 - 174 - 343 28 75

mail: mi...@multinet.de
web: www.multinet.de

Sitz der Gesellschaft: 85630 Grasbrunn
Registergericht: Amtsgericht München HRB 114375
Geschäftsführer: Günter Jurgeneit, Hubert Martens

---

PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B
Skype: misch42

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pre-Announce: End of 0.6 support is near

[Emmanuel Lesouef]

Hi,

We use a rather old (in fact, very old) combination :

heartbeat 2.99 + openhpi 2.12

What do you suggest in order to upgrade to the latest version of
pacemaker ?

Thanks.

Le Tue, 12 Jan 2010 13:26:01 +0100,
Andrew Beekhof  a écrit :

> Unless there are violent objections, I plan to officially stop
> supporting 0.6 at the end of February. Since I've not seeing any bugs
> reported for some time, it seems that anyone still using 0.6 is happy
> with it for their workload.
> 
> Also, 1.0 has been out for over a year now and contains significant
> improvements over 0.6 including
>  - A unified shell that hides the XML scaffolding
>  - Migration thresholds that are easy to configure and understand
>  - Failures can be ignored after a specified period of time
>  - Ability to specify defaults for resource an operation parameters
>  - Man pages for all CLI tools
>  - Up-to-date online documentation
> 
> The online documentation[1] has more details on whats new/different
> in Appendix C and detailed instructions for upgrading in Appendix E. 
> 
> -- Andrew
> 
> 
> [1]
> http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/index.html
> 
> 
> 
> 
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker


-- 
Emmanuel Lesouef

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Andreas Mock]

> -Ursprüngliche Nachricht-
> Von: "Andrew Beekhof" 
> Gesendet: 12.01.10 13:29:45
> An: pacemaker@oss.clusterlabs.org
> Betreff: Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2


> I'll add 11.2 to the list of repos at http://www.clusterlabs.org/rpm/
> when 1.0.7 comes out next week.
> (It wasn't available when I built 1.0.6)

Ha, that sound very good to me. The sooner, the better. :-)

Best regards
Andreas Mock


___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Andreas Mock]

> -Ursprüngliche Nachricht-
> Von: "Andrew Beekhof" 
> Gesendet: 12.01.10 13:32:00
> An: pacemaker@oss.clusterlabs.org
> Betreff: Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2


> On Tue, Jan 12, 2010 at 12:52 PM, Michael Schwartzkopff
>  wrote:
> > You could try:
> > http://download.opensuse.org/repositories/server:/ha-clustering/openSUSE_11.2/
> 
> 
> I dont see pacemaker in there, so not sure that helps much.

This answers indirectly my question I just wanted to write to Michael...  ;-)

By the way: Hi Michael, nice to hear from you.

Best regards
Andreas Mock


___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Andrew Beekhof]

On Tue, Jan 12, 2010 at 12:52 PM, Michael Schwartzkopff
 wrote:
> You could try:
> http://download.opensuse.org/repositories/server:/ha-clustering/openSUSE_11.2/


I dont see pacemaker in there, so not sure that helps much.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Andrew Beekhof]

On Tue, Jan 12, 2010 at 12:24 PM, Andreas Mock  wrote:
>> -Ursprüngliche Nachricht-
>> Von: "Andrew Beekhof" 
>> Gesendet: 12.01.10 09:19:59
>> An: pacemaker@oss.clusterlabs.org
>> Betreff: Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2
>
>
>> > a) Is this the right mailing list or can I ask pacemaker/openais questions
>>
>> yes
>
> Good to know.
>
>
>> > b) Where can I find packages for openSuSE 11.2? (pacemaker/openais)
>>
>> Should be included in the distro.  Just run:
>>    zypper in pacemaker openais
>
> Yup, but only version 1.0.1 of pacemaker.
>
> Am I right that the difference between 1.0.1 and 1.0.6 are bugfixes?

LOTS

> IMHO bugfixes are more relevant to a software stack that is used for
> higher reliability and availability, aren't they? Even if the bugfixes are
> probably not security relevevant.
>
> Is the package maintainer of the pacemaker/openais packages in
> OpenSuSE 11.2 listening here?

I'll add 11.2 to the list of repos at http://www.clusterlabs.org/rpm/
when 1.0.7 comes out next week.
(It wasn't available when I built 1.0.6)

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

[Pacemaker] Pre-Announce: End of 0.6 support is near

[Andrew Beekhof]

Unless there are violent objections, I plan to officially stop supporting 0.6 
at the end of February.
Since I've not seeing any bugs reported for some time, it seems that anyone 
still using 0.6 is happy with it for their workload.

Also, 1.0 has been out for over a year now and contains significant 
improvements over 0.6 including
 - A unified shell that hides the XML scaffolding
 - Migration thresholds that are easy to configure and understand
 - Failures can be ignored after a specified period of time
 - Ability to specify defaults for resource an operation parameters
 - Man pages for all CLI tools
 - Up-to-date online documentation

The online documentation[1] has more details on whats new/different in Appendix 
C and detailed instructions for upgrading in Appendix E. 

-- Andrew


[1] 
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/index.html




___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Andrew Beekhof wrote:
> On Tue, Jan 12, 2010 at 10:41 AM, Dejan Muhamedagic  
> wrote:
>> Hi,
>>
>> On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:
> 
> Ah, I was looking in the patch.
> 
>>> 
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>> 
>>> 
>>>   
>>> 
>>>   
>>>   
>>> 
>>> 
>> I understand that the "ref" element references some "id", but
>> note that the attributes's ids are sort of volatile.
> 
> Agreed.
> Not to mention that the admin wouldn't be able to remove the attribute
> anymore (since its referenced in the acl).
> 
>> In
>> particular the meta attributes. Can we somehow reference the
>> attributes themselves (in this case "password" and
>> "target-role")? Would there be a big performance penalty?
> 
> Probably simplest to just support xpath:
> 
>
The only concern to introduce xpath was the complexity of the syntax.
If we are OK with that, I can implement also :-)

> 
>>> 
>>> 
>>>   
>>> 
>>> ..
>> Do you have a suggestion how to spell out acls in the crm shell
>> syntax? We should also create a real-life acl configuration and
>> then see how that can be represented.
>>
>>> The user "ygao" is a system account.
>>> We could define several roles as we wish, such as "admin",
>>> "operator" and "monitor", which could contain a member list
>>> respectively if more than one user have the same permissions. A
>>> role also could be referenced by a particular ""
>>> definition.
>> I find this a bit confusing: roles have members and users can
>> reference roles. Shouldn't one of the two suffice? The way it is
>> now, it's also hard to follow.
> 
> Agreed. I think I prefer the latter.
> 
>>> [...]
>>> The first command is achieved by requesting lrmd, which is running as root,
>>> to do the cleanup for the client. So it could always bypass the ACL check.
>> lrmd is not running as root, but as nobody. And it's not a
>> client to the cib. But I guess that it is not relevant.
>>
>>> BTW, there're some changes comparing to the original design:
>>> [...]
>>> There could be an "attribute" for an ACL object in the original design :
>>> 
>>>
>>> it was supposed to mean user could only write the "value" attribute of
>>> "rsc0-meta_attributes-target-role" element.
>>>
>>> I didn't implement it because there's no good way for now for the ACL
>>> checker to recognize if a modification would change/add/remove any
>>> particular attributes of a XML element. And I'm thinking if it's
>>> necessary to implement it... Your thoughts?
> 
> Check the diff?
It now does check the diff. Besides the "__crm_diff_marker__" set for 
add/remove,
I also add a marker for "modified". But one modification could modify several 
of its
attributes. So for recognizing those, we might need to add multiple markers for 
one element?

> If you do that after the operation but before the activation, you'd be
> able to veto and invalid changes.
> So you'd not even need to pre-filter the input cib or query.
It does pre-filter only for a query operation. If an user queries cib with a 
xpath,
and the result is multiple objects listed under a "", it could not
accomplish the filter unless we pre-filter the input cib.

Thanks,
  Yan

-- 
Yan Gao 
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Hi Dejan,

Dejan Muhamedagic wrote:
> Hi,
> 
> On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:
>> ..
>> 
>>   
>> 
>> 
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>> 
>> 
>>   
>> 
>>   
>>   
>> 
>> 
> 
> I understand that the "ref" element references some "id", but
> note that the attributes's ids are sort of volatile. In
> particular the meta attributes. Can we somehow reference the
> attributes themselves (in this case "password" and
> "target-role")? 
It might not make it clear, because there could be multiple nvpairs with the
same "name" in different attribute sets. Even they could be under a single 
resource,
for example some of the attributes sets contain specific rules.


> Would there be a big performance penalty?

> 
>> 
>> 
>>   
>> 
>> ..
> 
> Do you have a suggestion how to spell out acls in the crm shell
> syntax? We should also create a real-life acl configuration and
> then see how that can be represented.
I've been thinking about it, but haven't got an clear idea now:)

> 
>> The user "ygao" is a system account.
>> We could define several roles as we wish, such as "admin",
>> "operator" and "monitor", which could contain a member list
>> respectively if more than one user have the same permissions. A
>> role also could be referenced by a particular ""
>> definition.
> 
> I find this a bit confusing: roles have members and users can
> reference roles. Shouldn't one of the two suffice? 
An user can reference one or more roles to combine the rules with his
particular definition. But if several users  are supposed to have the
completely same permissions, the "members" under a "role" could avoid
to define the users via separated " The way it is
> now, it's also hard to follow.
What if to separate it into two cases for an user definition in crm shell:
1. "is" a role
2. "ref" one role or more roles.

It can be either of them in configuration, and must not be both of them.
That also could avoid the confusing case which I demonstrated in the example.

So how about the syntax like:

role  acl_obj [acl_obj ...]

user  {acl_obj | ref_role} [{acl_obj | ref_role} ...]

user  is 

acl_obj ::
  mode ref 
  mode tag 
  mode ref  tag 

mode:: read | write | deny

ref_role:: ref_role 


> 
>> [...]
>> The first command is achieved by requesting lrmd, which is running as root,
>> to do the cleanup for the client. So it could always bypass the ACL check.
> 
> lrmd is not running as root, but as nobody. And it's not a
> client to the cib. 
Right, my bad. it should be crmd which is running as the privileged user -- 
"hacluster".

> But I guess that it is not relevant.

> 
>> BTW, there're some changes comparing to the original design:
>> [...]
>> There could be an "attribute" for an ACL object in the original design :
>> 
>>
>> it was supposed to mean user could only write the "value" attribute of
>> "rsc0-meta_attributes-target-role" element.
>>
>> I didn't implement it because there's no good way for now for the ACL
>> checker to recognize if a modification would change/add/remove any
>> particular attributes of a XML element. And I'm thinking if it's
>> necessary to implement it... Your thoughts?
> 
> OK, I suppose that I commented on this above :) If it is a
> problem to implement it here, then we may try to do that in the
> crm shell, i.e. it would lookup the attribute name and then
> create the right ref id.
Great!

Thanks,
  Yan
-- 
Yan Gao 
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.


___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Michael Schwartzkopff]

Am Dienstag, 12. Januar 2010 12:24:56 schrieb Andreas Mock:
> > -Ursprüngliche Nachricht-
> > Von: "Andrew Beekhof" 
> > Gesendet: 12.01.10 09:19:59
> > An: pacemaker@oss.clusterlabs.org
> > Betreff: Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2
> >
> > > a) Is this the right mailing list or can I ask pacemaker/openais
> > > questions
> >
> > yes
>
> Good to know.
>
> > > b) Where can I find packages for openSuSE 11.2? (pacemaker/openais)
> >
> > Should be included in the distro.  Just run:
> >zypper in pacemaker openais
>
> Yup, but only version 1.0.1 of pacemaker.
>
> Am I right that the difference between 1.0.1 and 1.0.6 are bugfixes?
> IMHO bugfixes are more relevant to a software stack that is used for
> higher reliability and availability, aren't they? Even if the bugfixes are
> probably not security relevevant.
>
> Is the package maintainer of the pacemaker/openais packages in
> OpenSuSE 11.2 listening here?
>
> Best regards
> Andreas Mock
>
>
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker

You could try:
http://download.opensuse.org/repositories/server:/ha-clustering/openSUSE_11.2/

-- 
Dr. Michael Schwartzkopff
MultiNET Services GmbH
Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany
Tel: +49 - 89 - 45 69 11 0
Fax: +49 - 89 - 45 69 11 21
mob: +49 - 174 - 343 28 75

mail: mi...@multinet.de
web: www.multinet.de

Sitz der Gesellschaft: 85630 Grasbrunn
Registergericht: Amtsgericht München HRB 114375
Geschäftsführer: Günter Jurgeneit, Hubert Martens

---

PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B
Skype: misch42

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Andreas Mock]

> -Ursprüngliche Nachricht-
> Von: "Andrew Beekhof" 
> Gesendet: 12.01.10 09:19:59
> An: pacemaker@oss.clusterlabs.org
> Betreff: Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2


> > a) Is this the right mailing list or can I ask pacemaker/openais questions
> 
> yes

Good to know.


> > b) Where can I find packages for openSuSE 11.2? (pacemaker/openais)
> 
> Should be included in the distro.  Just run:
>zypper in pacemaker openais

Yup, but only version 1.0.1 of pacemaker.

Am I right that the difference between 1.0.1 and 1.0.6 are bugfixes?
IMHO bugfixes are more relevant to a software stack that is used for
higher reliability and availability, aren't they? Even if the bugfixes are
probably not security relevevant.

Is the package maintainer of the pacemaker/openais packages in
OpenSuSE 11.2 listening here?

Best regards
Andreas Mock


___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Tue, Jan 12, 2010 at 10:41 AM, Dejan Muhamedagic  wrote:
> Hi,
>
> On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:

Ah, I was looking in the patch.

>>     
>>       
>>         
>>         
>>       
>>       
>>         
>>         
>>       
>>       
>>         
>>         
>>         
>>           
>>         
>>       
>>       
>>         
>>         
>
> I understand that the "ref" element references some "id", but
> note that the attributes's ids are sort of volatile.

Agreed.
Not to mention that the admin wouldn't be able to remove the attribute
anymore (since its referenced in the acl).

> In
> particular the meta attributes. Can we somehow reference the
> attributes themselves (in this case "password" and
> "target-role")? Would there be a big performance penalty?

Probably simplest to just support xpath:

   

>>         
>>         
>>       
>>     
>> ..
>
> Do you have a suggestion how to spell out acls in the crm shell
> syntax? We should also create a real-life acl configuration and
> then see how that can be represented.
>
>> The user "ygao" is a system account.
>> We could define several roles as we wish, such as "admin",
>> "operator" and "monitor", which could contain a member list
>> respectively if more than one user have the same permissions. A
>> role also could be referenced by a particular ""
>> definition.
>
> I find this a bit confusing: roles have members and users can
> reference roles. Shouldn't one of the two suffice? The way it is
> now, it's also hard to follow.

Agreed. I think I prefer the latter.

>
>> [...]
>> The first command is achieved by requesting lrmd, which is running as root,
>> to do the cleanup for the client. So it could always bypass the ACL check.
>
> lrmd is not running as root, but as nobody. And it's not a
> client to the cib. But I guess that it is not relevant.
>
>> BTW, there're some changes comparing to the original design:
>> [...]
>> There could be an "attribute" for an ACL object in the original design :
>> 
>>
>> it was supposed to mean user could only write the "value" attribute of
>> "rsc0-meta_attributes-target-role" element.
>>
>> I didn't implement it because there's no good way for now for the ACL
>> checker to recognize if a modification would change/add/remove any
>> particular attributes of a XML element. And I'm thinking if it's
>> necessary to implement it... Your thoughts?

Check the diff?
If you do that after the operation but before the activation, you'd be
able to veto and invalid changes.
So you'd not even need to pre-filter the input cib or query.

> OK, I suppose that I commented on this above :) If it is a
> problem to implement it here, then we may try to do that in the
> crm shell, i.e. it would lookup the attribute name and then
> create the right ref id.
>
> Cheers,
>
> Dejan
>
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Dejan Muhamedagic]

Hi,

On Mon, Jan 11, 2010 at 09:01:30PM +0800, Yan Gao wrote:
> ..
> 
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
> 
>   
> 
>   
>   
> 
> 

I understand that the "ref" element references some "id", but
note that the attributes's ids are sort of volatile. In
particular the meta attributes. Can we somehow reference the
attributes themselves (in this case "password" and
"target-role")? Would there be a big performance penalty?

> 
> 
>   
> 
> ..

Do you have a suggestion how to spell out acls in the crm shell
syntax? We should also create a real-life acl configuration and
then see how that can be represented.

> The user "ygao" is a system account.
> We could define several roles as we wish, such as "admin",
> "operator" and "monitor", which could contain a member list
> respectively if more than one user have the same permissions. A
> role also could be referenced by a particular ""
> definition.

I find this a bit confusing: roles have members and users can
reference roles. Shouldn't one of the two suffice? The way it is
now, it's also hard to follow.

> [...]
> The first command is achieved by requesting lrmd, which is running as root,
> to do the cleanup for the client. So it could always bypass the ACL check.

lrmd is not running as root, but as nobody. And it's not a
client to the cib. But I guess that it is not relevant.

> BTW, there're some changes comparing to the original design:
> [...]
> There could be an "attribute" for an ACL object in the original design :
> 
> 
> it was supposed to mean user could only write the "value" attribute of
> "rsc0-meta_attributes-target-role" element.
> 
> I didn't implement it because there's no good way for now for the ACL
> checker to recognize if a modification would change/add/remove any
> particular attributes of a XML element. And I'm thinking if it's
> necessary to implement it... Your thoughts?

OK, I suppose that I commented on this above :) If it is a
problem to implement it here, then we may try to do that in the
crm shell, i.e. it would lookup the attribute name and then
create the right ref id.

Cheers,

Dejan

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Tue, Jan 12, 2010 at 9:53 AM, Yan Gao  wrote:
> Hi Andrew,
>
> Andrew Beekhof wrote:
>> On Mon, Jan 11, 2010 at 4:08 PM, Lars Marowsky-Bree  wrote:
>>> In the mean-time, reviewing the syntax is probably quite important too.
>>
>> Has it changed since we discussed it last?
> Yes, it has changed a bit comparing to the original design.
>
>> I don't see any new examples to comment on.
> It's in the mail attached the patch yesterday.

No, thats a schema change.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Hi Andrew,

Andrew Beekhof wrote:
> On Mon, Jan 11, 2010 at 4:08 PM, Lars Marowsky-Bree  wrote:
>> In the mean-time, reviewing the syntax is probably quite important too.
> 
> Has it changed since we discussed it last?
Yes, it has changed a bit comparing to the original design.

> I don't see any new examples to comment on.
It's in the mail attached the patch yesterday.

Thanks,
  Yan
-- 
Yan Gao 
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] crm_attribte failed with Multiple attributes match

[Andrew Beekhof]

On Mon, Jan 11, 2010 at 11:32 PM, hj lee  wrote:
> I rebooted the system a few days ago. If it happens again, will post it. But
> can you guess any how cib query returns multiple entries?

Not based on the information so far. Sorry.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Andrew Beekhof]

On Mon, Jan 11, 2010 at 4:08 PM, Lars Marowsky-Bree  wrote:
> In the mean-time, reviewing the syntax is probably quite important too.

Has it changed since we discussed it last?
I don't see any new examples to comment on.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Pacemaker/OpenAIS Software for openSuSE 11.2

[Andrew Beekhof]

On Mon, Jan 11, 2010 at 7:12 PM, Andreas Mock  wrote:
> Hi all,
>
> after a long period I started to check out the current state of
> clustering with linux.
>
> As it seems that the SuSE guys go to the direction of pacemaker/openais
> I want to give that a try.
>
> a) Is this the right mailing list or can I ask pacemaker/openais questions

yes

> also on the ha-linux mailing without beeing redirected elsewhere?
>
> b) Where can I find packages for openSuSE 11.2? (pacemaker/openais)

Should be included in the distro.  Just run:
   zypper in pacemaker openais

>
> c) If not available how could I build them (easily)?
>
> d) If I would try to compile from source as described at
> http://www.clusterlabs.org/wiki/Install#First_Steps
> one step is to get openais. Why are all the relevant
> prebuild library packages called corosync?
> I don't understand the distinction between openais and corosync

Corosync used to be part of Openais.
Then they split it into two parts to make maintenance easier.
>From their home page "The OpenAIS software is built to operate on the
Corosync Cluster Engine "

> and how this two pieces fit together. By the way: There homepage
> doesn't enlight me either.
>
> Enough questions for a restart.
>
> Best regards
> Andreas Mock
>
>
>
> ___
> Pacemaker mailing list
> Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Hi Lars,

Lars Marowsky-Bree wrote:
> On 2010-01-11T15:02:29, Andrew Beekhof  wrote:
> 
>>> For this authentication issue of local access we discussed last time, I
>>> added a geteuid() in the cib_native_signon_raw() function from libcib.
>>> Once a client signs on the CIB, it'll invoke the function and transfer
>>> its uid to the server end.
>> I don't see anywhere that the server checks passwords.  Is that really
>> intentional?
> 
> I agree, the server needs to verify the credentials. Client-side UID is
> not strong enough - after all, we're trying to authenticate & authorize
> the _client_, and it won't do to have the client tell us what it thinks
> its auth level should be - that would be a bit easy to cheack ;-)
> 
>> Whats the role of this code, is it meant to provide actual security?
>> Or is it just casual protection from people accidentally touching
>> stuff they probably didn't mean to touch?
> 
> If we provide the latter, they'll expect it to provide the former. So we
> need to verify credentials in the CIB server process instead. For SSL
> connections to the server, this means username/password transfer, or
> challenge-response.
> 
> For local sockets, we can use code similar to the IPC socket stuff from
> heartbeat to get the uuid from the other end of the socket?
If I understand right, pacemaker uses called "uuid ticket", which is given
by the server end when a client signs on the CIB, and then it'll be used in
the consequent request for the server end to determine which IPC channel the
reply should be sent through. But before the sever give the uuid ticket to
the client, it still needs to authenticate user I think.

Is that the same way in heartbeat? If not, it must be a way for the server to
determine who's actually on the other end of the socket rather than the client
tell it?

> 
> In the mean-time, reviewing the syntax is probably quite important too.
Right, I'm looking forward to your comments on that:-)

Thanks,
  Yan

-- 
Yan Gao 
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

Re: [Pacemaker] Multi-level ACLs for the CIB

[Yan Gao]

Hi Andrew,

Andrew Beekhof wrote:
> On Mon, Jan 11, 2010 at 2:01 PM, Yan Gao  wrote:
>> Hi all, Andrew, Lars,
>>
>> Here's the status update about this feature.
>>
>> I've implemented the main functionalities of ACL, including the ACLs
>> configuration parser, the CIB output filter and the modification checker...
>>
>> Yan Gao wrote:
>>> On 12/09/09 18:28, Andrew Beekhof wrote:
 On Wed, Dec 9, 2009 at 11:00 AM, Yan Gao  wrote:
> Hi Andrew, Lars,
>
> On 12/08/09 21:16, Lars Marowsky-Bree wrote:
>> On 2009-12-08T09:22:52, Andrew Beekhof  wrote:
>>
 Basically, we'd like to see an ACL mechanism. It would be implemented 
 at
 the CIB level. So that all the clients - CLI , CRM shell, GUI, etc... -
 could benefit. Clients are authenticated via PAM, so we can use uid/gid
 for identification.
>>> Actually you probably can't do this.
>>> Daemons (like the cib) which are not running as root can only
>>> authenticate the username/password of the user they're running as.
>> Well, the non-root internal uids/daemons would of course get exceptions
>> just like root, this is about external interfaces.
> Actually, after thinking over the problem, I'm a bit confused...So I
> briefly describe what in my mind, please correct me if there's any 
> problem.
>
> First, currently non-root users are able to connect the cib through
> either unix or network sockets as long as they belong to "haclient"
> group. We could keep this requirement.
>
> Then the cib should authenticate the client via PAM to identify who is
> connecting to it.
 Thats what I'm saying, it can only do this for the hacluster user.
 Because its not running as root.
>>> Indeed, that's the real problem. Without authentication, that would not
>>> be a real access control. No idea if there's any other solution... Lars,
>>> what's your recommendation?
>> For this authentication issue of local access we discussed last time, I
>> added a geteuid() in the cib_native_signon_raw() function from libcib.
>> Once a client signs on the CIB, it'll invoke the function and transfer
>> its uid to the server end.
> 
> I don't see anywhere that the server checks passwords.  Is that really
> intentional?
Yes for now, before we have a good solution to do authentication.

> 
>> Strictly speaking, an user could hack his client program or libcib to
>> obtain the privileged right to CIB. But he also could hack the server
>> end, right? ;-)
> 
> Or use a local (modified) copy of libcib, or just bypass it altogether.
> Both of which are far more trivial than installing modified code on
> the server-side.
Right, I think so too.

> 
> Whats the role of this code, is it meant to provide actual security?
> Or is it just casual protection from people accidentally touching
> stuff they probably didn't mean to touch?
I think the latter is the main purpose of this feature. Once we add
an authentication mechanism, it'll provide the former.

> 
> 
> + if (acl_filter_xml(tmp_cib, xml_perms)) {
> + crm_warn("Ordinary user \"%s\" doesn't have the permission for 
> the
> whole CIB", user);
> + tmp_cib = NULL;
> + }
> 
> I think you're going to get complaints about how noisy this log is :-)
Indeed, it's noisy:-) I'll remove it in the next revision.

Thanks,
  Yan

-- 
Yan Gao 
Software Engineer
China Server Team, OPS Engineering, Novell, Inc.

___
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker