Carolyn wrote: >There was a bit of discussion earlier this summer (see >http://article.gmane.org/gmane.comp.voip.sipx.devel/11076 ><http://article.gmane.org/gmane.comp.voip.sipx.devel/11076> ) >about running allowing supervisor to run "commands" rather >than "services" at the request of sipXconfig (i.e. via >xmlrpc). Scott mentioned creating an issue for a >sipXecs-command definition, but I'm not sure whether that >actually happened. > >We now have at least two examples of this: > >- the package update stuff that Raymond is working on, and >- run configtest independently which I am starting to look at > >At the time of the earlier discussion it was mentioned that >being able to execute sipx-snapshot on a remote machine would >be another example. > >Raymond and I are wrestling with some of the same issues and >we have some different ideas about how to do this. > >Raymond is proposing launching a command, redirecting its >output to a file, and providing an interface to return the >contents of the file. He is wrestling with how to prevent the >same command from being run more than once at the same time. >The package update command requires sudo access, and involves >shutting down the entire sipxpbx. > >I had thought of running my command (configtest) under the >control of a task in supervisor, and collecting the output the >same way we collect stdout/stderr for the processes. Since >the pid executing the command would be under the control of >the supervisor, it would be easier to prevent it from being >executed twice. However the command wouldn't survive a >shutdown of sipxpbx. (That's a good thing for me) > >We have to decide on how to know what to execute. From a >command definition in xml similar to what the process >definitions use? (that's a natural choice for me, since >configtest is already defined that way) or a hard-coded >command with just the prefix determined at install?. > >Both of us are worried that we are opening up the pbx to >possible misuse. > >Does anyone think that we should be implementing a generic >"command" capability, which would launch a command and return >its output? or should we just implement the two specific needs >we have, and not worry about a generic design? >
At this stage of the development, I think we should just implement exactly what we need. I keep running into issues every step of the development for the software updating so I think that trying to do a generic command execution would be too risky. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
