On Mon, 2008-11-17 at 12:38 -0500, Raymond Dans wrote: > I've received some additional information now (thanks Joe) as to what is > expected from the SipXconfig point of view for providing a software > update capability using Yum on local and remote systems. > For this release, I can make the assumption that this will only be used > on systems with "Yum" installed and that we must be able to: > > - Query the SipXecs software version running on the system > - Query the SipXecs software updates available. > - Update the SipXecs software on the system. > > Joe Attardi has written a Python script that will do all three functions > and format the output in a consistent manner so that sipXconfig can read > it. If this Python script can be installed in a fixed location on all > systems (Master and Slaves) and write the output to a defined location > and name(one file for each command), then I only need to provide what I > believe are 2 XML/RPC interfaces. > > NOTE: Because these commands may take some time to execute and > sipXconfig has a timeout of 15 seconds waiting for a response, it was > felt that it would be better to provide one interface to execute the > command and a second one to obtain the output which could be called > later by sipXconfig. > > 1. XML/RPC Interface to launch the Python script with an appropriate > sub-command (i.e. query version, check-updates, apply updates). At > least 2 of these commands could take a little while to execute so the > call to XML/RPC would simply launch the script and return. > > - SwAdminRpc.exec > > Input Parameters: > > - Client Host Name (callingHostname) : <XML-RPC String> > > The FQDN of the calling host to be checked as > an SSL trusted peer against an explicit list of hosts > allowed to make requests. > > - Command: <XML-RPC String> > A software administration command to execute. Currently > three commands are supported: > 1. version - Queries the version of SipXecs software on > the destination. > 2. check-update - Checks the yum repository for SipXecs > updates available. > 3. update - Updates the SipXecs components. NOTE: > This command will cause > a disruption in service while it updates. > > Return Parameters: > > - Boolean: Indicates the successful launch of the command. > > If there is a command still in progress or a failure to launch > then > a fault will be returned. > > > 2. XML/RPC Interface to return the results from a previously issued > software command. The results would need to be stored in a specific > location and would be read in, encoded in base64 and returned to the > caller. If the yum process is still running or the appropriate result > file does not exist then a fault will be returned.
That seems workable, but we might also want to just use HTTP GET. I'm working on changes (XECS-1855) that will provide GET support through the sipXsupervisor HTTP server (same port as RPC) for any file that is defined as a file resource in the FileManager. If a remote command creates a file, that file could be added as a read-only resource by creating a new resource definition with just a small change to FileResource::logFileResource. Currently, that method creates a read-only resource definition, but requires a process definition pointer - if we made the pointer optional (defaulted it to NULL) and modified the routine not to use it when NULL, then the file created would be accessible using the code I'm already doing. The new functionality for XECS-1855 will allow a GET to the full path for any file defined as a resource by any process. The HTTP response to the GET will be the full contents of the file (as MIME type "application/octet-stream" for now). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
