Tks Michael!!!
Simone Capra Il 16/06/2017 22.52, Michael Stauber ha scritto:
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.
_______________________________________________ Blueonyx mailing list [email protected] http://mail.blueonyx.it/mailman/listinfo/blueonyx
