Re: [sipX-dev] Input on XCF-651 implementation (Restore page from sipXconfig UI)
On Tue, 2007-04-03 at 13:42 -0400, Paul Mossman wrote:
> Hi all,
>
> I was looking into XCF-651 and I wanted to solicit some input on the
> approaches that I am looking at.
>
> 1. I will aim to provide a similar user experience to what happens
> when sipXconfig Diagnostics -> Services is used to Restart the
> "ConfigServer":
> - User clicks the button to invoke in the action, and the page reloads OK.
> - But, clicking a link before sipXconfig comes back up will result in
> an "Unable to connect" error in the browser.
> - A user that waits until sipXconfig is back up before clicking will
> be directed to the Login page.
>
> Although when I use sipXconfig Diagnostics -> Services to stop all
> services, I get an "Unable to connect" error after clicking the invoke
> button, so we will have to see.
>
> 2. I was also planning to implement a single script to stop the
> services, run restore, and restart the services. The notes suggest
> "process.cgi" as the mechanism for stopping sipXconfig (presumably all
> services?) I had been thinking about calling "__/init.d/sipxpbx stop"
> from the script directly. To use "process.cgi" from the script would
> I just make a "wget" call?
>
> As for restarting the services, I am still thinking about a calling
> "__/init.d/sipxpbx start" from the script directly.
>
> 3. I see that the script will need to be run as root in order to have
> the permissions to stop/restart the services and do the actual
> restore. A user who has logged in a superadmin may find it strange to
> subsequently provide root credentials in order to perform a Restore.
> So I'm wondering if we can avoid this, perhaps with setuid on the
> script for instance.
I don't think it appropriate to use anything that gives root privilege
to sipXconfig (nothing personal guys - just good security practice not
to run root-privilege process that have network connections).
Following a restore, we'll definitely want to restart at least
sipXconfig and probably eventually everything, but there's a sequencing
problem that we also have at startup. That problem is that various
component configurations are generated by sipXconfig from the postgres
database, but those components are usually started long before
sipXconfig has written them.
I would suggest something like the following when told to restore the
db:
1. sipXconfig checks for the backup copy of the db. Assuming it is
there and appears to be a valid file, it writes the name of that
file into a special well-known location
(/var/sipxdata/sipxconfig/restore-db-file or something).
2. Serve a page that displays a 'please wait patiently while I
restart' message (perhaps with a timer that goes to the login
page after some long period of time, perhaps something more
clever that polls using javascript to see when the server is
back up).
3. Signal the process manager to restart sipXconfig
4. The process manager does that as now, executing the normal
sipxconfig.sh startup wrapper script.
5. The wrapper script sees that there is a file in the special
well-known location; it validates that the indicated file is a
db backup file, and does the restore operation before restarting
sipXconfig.
That still leaves the sequencing problem, but it makes it the same as
the one we have when the system first starts after an install. That's
really a larger issue that may require a somewhat different approach to
startup for at least some components. Probably that too could be
addressed by a marker file that means 'the database and the running
configuration are not in sync'...
--
Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@xxxxxxxxxxx
sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX
Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/
