Re: [sipX-dev] Input on XCF-651 implementation (Restore page from sipXconfig UI)
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.
I cannot think about any other solution.
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.
The different is that by using '/etc/init.d/sipxpbx' you'd be stopping/starting watchdog and httpd
(possible some other services). Process manager would restart services without restarting itself.
I would think restarting everything the way you intend to is actually a good thing. However if you
were to decide to use 'process manager' (process.cgi) do not do it directly (by sending HTTP
requests). Douglas wrote sipxproc utility, which is part of sipXtools project, that can be used to
access project manager from command line.
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 am with woof! on setuid, but quite frankly I am not crazy about sudo idea either. That would
require that sipXpbx configures passwordless sudo access for 'sipx' user during installation. I am
not sure if this is what admins would like - at least not by default.
I noticed other requests on JIRA that have similar problem
(http://track.sipfoundry.org/browse/XCF-1607)
and there is a user comment there that requiring root password is acceptable.
I do not think there is a safe way around root password requirement (with a big fat disclosure that
we do not store it...), but if pressed about it I would vote for sudo.
BTW: anybody knows if proper SELinux policy would make it better?
Thanks.
-Paul
paul.mossman@xxxxxxxxx
