[BlueOnyx:21118] Re: Restart apache from php script under admserv

[Michael Stauber]

Hi Simone,

> is there a way to restart apache from a php script under admserv?
>
> I have tried creating a file /usr/sausalito/ui/web/restart.php with the
> following:
>
> <?php
> system('/usr/sausalito/handlers/base/apache/restart_httpd.pl');
>
> It returns "BYE SUCCESS" correcly when called
> http://<addr>:444/restart.php but it does not restart.


The security model of BlueOnyx prevents this. The GUI webserver
"admserv" runs as unprivileged user "admserv". Likewise the PHP that
runs off it runs as "admserv" and that user has no permissions to do
anything useful.

In order to perform a system related transaction, the GUI page must
"talk" to CCEd via "CceClient" and must be properly authenticated with a
sufficiently privileged username like "admin".

Additionally: Handlers will do nothing if called directly. They must be
called by CCEd in order to do anything useful.

One way to restart Apache via a GUI page is this:

$CI->cceClient->setObject("System", array('reload' => time()), "Web");

That will "talk" to CCEd and will identify the "System" Object in the
CODB database via FIND. Then it writes (via SET) a UNIX timestamp into
the database field "reload" of the "Web" Namespace.

The Sausalito configuration for Apache (see:
/usr/sausalito/conf/base/apache/Apache.conf) contains (among other
things) this line:

System.Web.reload       perl:base/apache/reload.pl  CLEANUP

Which defines that if the "reload" field in the Namespace "Web" of the
"System" Object is written to, it should execute
/usr/sausalito/handlers/base/apache/reload.pl during the CLEANUP phase
of the Handler run. Which happens after any other Handlers have run.

At the current time we do no Apache "reloads", because they are very
troublesome. Sauce::Service (which performs service restarts) will
always execute an Apache "restart" instead of a "reload".

Still: Your GUI page with that SetObject call in it will *only* work if
it is accessed by a user that is already logged in to the GUI, is
sufficiently privileged and has a valid and non-expired session cookie.
Because only such a user is allowed to use CceClient and is allowed to
write to the CODB database field that we're accessing.

I just posted a (working) minimal code example to Pastebin for you:

https://pastebin.com/ZAzf7NXV

For this to work, save it as
/usr/sausalito/ui/chorizo/ci/application/modules/base/apache/controllers/apacherestart.php
and also edit the router
/usr/sausalito/ui/chorizo/ci/application/modules/base/apache/config/routes.php
to add this line at the bottom:

$route['apache/apacherestart'] = "apacherestart";

Please note: The changes to the router file will get overwritten during
the next base-apache YUM update. So you might be better off to stuff
both into your own directories such as this:

/usr/sausalito/ui/chorizo/ci/application/modules/base/erweb/config/
/usr/sausalito/ui/chorizo/ci/application/modules/base/erweb/controllers/

Now if you have some kind of a third party application that needs to
restart Apache without logging in to the GUI first? Then you're on your
own. Because this would be entirely contrary to our security model. We
cannot tear such holes into your system.

One doable option would be to extend the BlueOnyx API with a system call
to allow it to restart Apache. In that case it would only work if:

- The API is enabled
- The originating IP is allowed to use the API
- HTTPS is used to access the API
- API user identifies himself with valid username and password.

Your external application would then need to do a POST transaction to
the API with some JSON encoded data that contains the login credentials
and the command to tell the API to perform the Apache restart.

And there we have it: Even the API needs a username and password for
access, because only that way we get the mandatory SessionID that CCEd
requires.

-- 

With best regards

Michael Stauber