On Wed, 2014-09-24 at 20:29 +0200, Jakub Scholz wrote: > What do you expect the shutdown call to do in clustered brokers? Shutdown > the whole cluster or just the active node?
Just the active node. I would think of it as being equivalent to a remote kill -TERM. Useful if you don't have ssh or other admin access to stop the service. In a cluster it would be the same as a broker crashing or being killed locally. For new HA under rgmanager, the broker would be restarted. I don't see it as being useful in a cluster though, cluster suite already has tools for remote management of clustered services. > > Personally, I don't really see the value in it. But at the same time - if > it is properly secured with ACLs - I don't think its a big security issue. > > Regards > Jakub > > On Mon, Sep 22, 2014 at 10:10 PM, Alan Conway <[email protected]> wrote: > > > On Thu, 2014-09-18 at 15:12 -0700, Spencer.Doak wrote: > > > Hey Gordon, > > > > > > Thank you very much! That should give me a great start on this task. > > > > > > As for the 'shutdown' command, that's actually exactly what I was > > thinking > > > too. I'm thinking about running a receiver process on the broker machine. > > > When it receives a message that says "shutdown" from an authenticated > > user, > > > it will perform 'system("/sbin/service qpid-stop");' or whatever the > > > relevant OS command is. In your opinion, is this a reasonable way to > > > accomplish this task? Would there perhaps be a better way than creating a > > > system call? > > > > Not presently. I've long thought we should have a qmf shutdown command > > on the broker but never actually did anything about it. Mucking about > > with extra processes is painful for such a basic task. > > > > There is a denial of service security concern, my feeling is that adding > > a "shutdown" permission to the ACL rules would cover that. > > > > Anyone think this is a bad idea, or have a better idea? > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
