Scott Lawrence wrote: > 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). >
Great: that will certainly help implement many useful features. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
