:-P

[jayapandian]

Mcollective sequential execution update

Mcollective used for server orchestration performs the actions parallelly in the servers which are connected to it. So a single command fired via mcollective affects all the servers connected to the middleware or all the servers which match the filters (if filters are used). In some cases the actions need to be performed on the servers one by one, hence the need for sequential execution. By sequencial execution i mean to perform the action on the servers one by one and also the ability to abort the process in the middle if needed.

1. Batch processing

     Mcollective 2.x supports batch processing, hence it can be configured to batch servers one by one with a wait time between each servers. This effectively achieves sequential execution. The drawback is that you ll not be able to view the results till all the servers have completed performing the action, this is a serious drawback in some cases and if your action goes wrong all servers are afffected and only then u get the result. 

http://docs.puppetlabs.com/mcollective/simplerpc/clients.html#processing-agents-in-batches

http://www.devco.net/archives/2012/07/23/mcollective-batched-requests.php

2. Dumb method

     In this method you invoke the actions on each server by means of hardcoded client. Obviously it achieves sequencial execution but it can be improved

https://github.com/pandian912/Mcollective/blob/master/clients/seqexeccli-dumb.rb

3. Use discovery then custom requests

     This is an improvement of the previous in which the list of servers discovered by mcollective is retrieved and then custom request sent to each servers individually, hence achieving sequential execution. In this method all the command line filters can be used and the list of hosts retrieved after discovery can be handled programatically.

https://github.com/pandian912/Mcollective/blob/master/clients/seqexeccli.rb

4. Display results immediately with sleep time (failed to achieve seq exec)

     This method is a failure as it did not achieve seq execution rather it only displayed the results of the execution one by one, but the actions were performed on the servers in parallel. 

http://docs.puppetlabs.com/mcollective/simplerpc/clients.html#gaining-access-to-mcollectiveclientreq-results

5. batch with display imm

     Though the fourth method was a failure, it can be combined with first method to perform the actions in batches and displaying the result as and when they arrive. This effective achieves sequential execution. I believe this and the third method are good.

https://github.com/pandian912/Mcollective/blob/master/clients/seqexeccli-batch.rb

[jayapandian]

Mcollective central rpc auditing

Since mcollective 2.0 there has been some changes in the core API's and many have not been documented well or there is no documentation. The central rpc auditing plugin has not been updated and i have made the necessary changes and sharing it in my git repo

https://github.com/pandian912/Mcollective/tree/master/audit

the centralrpclog.rb file need to be present in the audit folder of all the nodes to enable centralised auditing further information can be found at

http://docs.puppetlabs.com/mcollective/simplerpc/auditing.html

http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AuditCentralRPC

[jayapandian]

Mcollective action policy modification

Mcollective has a pluggable authorisation system, by specifying the authorisation in a file the access to an agent can be controlled. The default actionpolicy provided checks the uid of the user accessing the agent https://github.com/puppetlabs/mcollective-plugins/tree/master/simplerpc_authorization/action_policy/ .

In a setup with many nodes this doesn't make sense. Since its a pluggable system it can be modified to suit appropriately. By configuring the security plugin psk to send the username instead of the uid and with little modification the action policy plugin can be made to check for the user group, which makes more sense.

Add the following configuration in the client 

plugin.psk.callertype=user

The action policy needs to be changed as follows

https://github.com/pandian912/Mcollective/tree/master/util

     def self.check_policy(auth, rpccaller, actions, facts, classes, request)

        # If we have a wildcard caller or the caller matches our policy line

        # then continue else skip this policy line

        logger = Log.instance

rc=request.caller

rca=rc.split('=')[1]

gr=`id -gn #{rca}`

group="group=" << gr

group=group.strip

logger.debug("Request received from #{rc} belongs to primary group #{gr} checking the entry #{group}")

if (rpccaller != "*") && (rpccaller != group)

          return false

        end

In a similar way the code can be modified to check for groups or username or gid or uid. 

A sample policy file is also included in the github

[jayapandian]

Mcollective sequencial execution

Mcollective is a tool to handle parallel job execution in group of systems with a message passing system as middlleware. Its effective in performing tasks like checking the status of a service, or restarting a service and much more. 

Though it specialises in parallel job execution a certain set of tasks are better executed sequencially, for that purpose from Mcollective 2.0 Direct addressing is introduced with which batch processing can be performed. Direct addressing is the method of querying a system directly without performing a broadcast discovery, ofcourse the system or set of sytem's identity needs to be known to perform this.

In batch processing though there is provision to stop execution midway by aborting(Ctrl + C), this has to be performed without any knowledge of which systems were affected by the action or what was their result. I hope such a feature comes out in the future releases but for now a simple client script can do the trick...

#!/usr/bin/ruby

require 'mcollective'

include MCollective::RPC

mc = rpcclient("rpcutil")

mc.discover(:nodes => ["node1","node2"])     #custom discovery

printrpc mc.ping                              #execution

sleep(2)

printrpc mc.ping({"identity" => "node3"})  #discovery and execution

printrpcstats

mc.disconnect

    With little changes all the agents can be run sequentially with the output displayed as and when they are executed....

[jayapandian]

Hello

Hello World