Giving remote access to CLI PHP output

[NotionCommotion]

I would like to give someone remote access to the output (echo statements, warnings, etc) of a php script, but not give them direct access to my server.  Ideally, it would be something like php myscript.php > syslog_or_something_similar. Or maybe I don't include echo statements in the script, but instead use syslog or something else.  Can anyone point me in the right direction?  Thanks 

[requinix]

Doesn't this imply giving them the ability to execute scripts on the server?

 

Make a script for it. Put it behind whatever sorts of access controls you want, and have it execute the script and show the output with something like passthru. If you don't use output then you'd have to read syslog, but filtering it to show just the relevant parts would be a bother.

[NotionCommotion]

Doesn't this imply giving them the ability to execute scripts on the server?

 

Make a script for it. Put it behind whatever sorts of access controls you want, and have it execute the script and show the output with something like passthru. If you don't use output then you'd have to read syslog, but filtering it to show just the relevant parts would be a bother.

 

Not if I was the one to execute php myscript.php > syslog_or_something_similar. The myscript.php in question generates a server, and will produce an error if repeated as it would be listening on the same port.

[requinix]

So they don't run it themselves? Redirect/tee the output to a file and make the file web-accessible.

[NotionCommotion]

Yes, I could, but how do I make it dynamically update like a normal log for the recipient?  Guess ajax is easy enough but am struggling a little on how to show the tail last 5 lines and then update upon new rows, yet not delete the rows when another user (i.e., me) view it.  Sure I can figure it out, but was kind of maybe hoping for super easy.

[requinix]

Slowly getting little details here and there isn't really working...

 

What command are you running? When? What is the output? How much of it do you want to show? Why not the whole thing?

[NotionCommotion]

Slowly getting little details here and there isn't really working...

 

What command are you running? When? What is the output? How much of it do you want to show? Why not the whole thing?

 

I am having someone build a c++ sockets client for me.

 

I am building a PHP sockets server which will be evoked using php server.php.

 

I wish the c++ programmer to see any and all things server.php might display.

 

While I might trust the individual, as a matter or principle I do not wish to give server access.

[requinix]

So this is more for testing than anything else?

 

Send the output to a file and make it (web) accessible. Probably no need to trim it to the most recent lines, and it won't clear by having multiple people view it. You could (should?) clear it with new runs so use regular > write redirection instead of >> append.

Using AJAX or not is a separate question that boils down to whether they should or should not have to hit F5 to see new output. Personally I'd say they should because the additional work seems like it would be a waste of time.

[NotionCommotion]

Yes, testing only.  The problem with regular > write redirection is you will missing everything before last write when hitting F5.  AJAX might make it less likely, but still is the case.  I can definitely figure something out, but expected this should be much simpler.

[requinix]

Why is the PHP server starting on a page load? It should be running in the background regardless of everything else.

[NotionCommotion]

Why is the PHP server starting on a page load? It should be running in the background regardless of everything else.

 

I had (incorrectly) thought that the following line would set the content of status.txt equal to the last thing server.php echo'd out, and as such, when the page is reloaded, I thought it would just display that last thing.  Upon testing, however, I see I am mistaken, and when reloading the page, everything server.php echo'd out from the time it was started is displayed.  Guess this makes sense.

 

Now, the issue, however, a real big log is going to be sent to the browser should the server be running for a long time.

php server.php > public/status.txt

https://example.com/status.txt

[requinix]

This is the point where you should start considering adding an officially-supported logging mechanism, as in

php server.php -o /path/to/file.log

I think PHP on Linux allows you to leverage a nice file handle trick:

define("STDOUT_FILE", "/path/to/file.log"); // you'd get this value from argv
fclose(STDOUT);
$GLOBALS["STDOUT"] = fopen(STDOUT_FILE, "a");

stdout is basically defined as file handle #1 (0=stdin and 2=stderr), and since file handles are reused, closing the stdout handle and immediately opening a new handle will assign it #1, so normal output will go to that file instead - no code changes necessary.

If that doesn't work then you can simply use output buffering: fopen the file add ob_start with a callback that writes the buffer to the file.

 

All that effort is to be able to use logrotate, which is probably installed on the server already. You can add configuration for it to automatically rotate the log files from your PHP server (eg) daily if the file goes over 1MB keeping a few of the most recent old log files.

 

"Why not use > redirection?"

 

Open file handles don't indicate a filename - if you open a handle and move the file, reads and writes will keep working. That means a rotated log file will keep getting written to. To address this logrotate can send a SIGHUP to an application during the rotation, and the application understands this to mean it should close the old log file handle and open a new one.

pcntl_signal(SIGHUP, function() {
	//ob_end_flush();
	fclose($GLOBALS["STDOUT"]);
	$GLOBALS["STDOUT"] = fopen(STDOUT_FILE, "a");
	//ob_start(...);
});

So recap:

1. Pick a place for the log files (current one and a few of the most recent) and configure logrotate to process that directory

2. Edit your server.php support specifying a log file, and have the server script called with the path

3. Make output go to that file, either with the file handle trick (easy if it works) or output buffering (reliable and portable)

4. Add a SIGHUP handler that closes the file (which was just moved by logrotate) and opens it with a new handle (will be a fresh file)

5. Make sure React supports doing this

 

That last one is a bit outside my expertise. It's quite possible React won't work well with signals due to how it works, so you might have to do something there. A library (here's one I found) might be necessary.

[NotionCommotion]

Thanks requinix,  The -o flag (i.e. php server.php -o /path/to/file.log) is for me to implement, and not a PHP flag, correct?

[requinix]

Right. There are two ways to pass arguments:

php args-to-php file.php args-to-script
php args-to-php -f file.php more-args-to-php -- args-to-script

With -f you use a -- to separate php and script arguments; without everything after the filename are script arguments.