Archive for August, 2012

WASD update additions
The update left two links in error, both concerning performance logging: HyperSpixx, showing stored performance data, and Mondesi, for real-time control. The first one requires an agent that stores data in files, and these are presented uing a CGI-based execuatble. That program can no longer determine the nodename for which data is to be displayed, and when I restarted the agent, it failed without notice…
The second program is started from the browser, and requests data from the system using the system API to collect performance data, and displayes it in the browser window. The link does display the window but slightly distorted, but no centent….
Today, I installed the latest versions of these programs.
Mondesi – now version 2.1 – was installed without a problem, and it now shows the correct data.
HyperSpi – the WASD version – has been buiklt and installed, the agent started; it does start and created a file. But displaying the data still fails: No node supplied….
The version by Jean-François Piéronne however causes problems in building. It comes as a complete package that must now be compiled and linked – where originally, the object files were supplied and LINK was sufficient. so you now need a C-compiler, and, for the libraries used, you must use MMS (or Hunter Goatley’s MMK), if you want to use the BUILD.COM procedure.
I found the DESCRIP.MMS files used in buidling the library are incomplete – so I had to update the files before I could create the agent and web-application. The agent has been installed and works – but the web-application still gives an error ‘No node supplied’ – and the documentation that is supplied doesn’t show a reason….Or how to define the node. But here, there has been no change….
So still some work to do…
DCLInABox works
The terminal amulation over port 80 – using WebSockets – works, once a [world] entry was added to WASD_CONFIG_AUTH.CONF:
[world]
if (websocket:) * r+w,https:
before the authentication for the site. And this addition prevents direct access to the terminal connection., since the site itself is still acessed over SSL, and requires login just for that. In the admin page however, you won’t see the user that started the application. But that could well be handled by the logger.

More investigations
I have done a bit more investigation on the PHP issue.
First, I created a procedure in which I can set the PHP environment as /JOB logicals so I can do the tests without interferendce with the access over the Internet.
Next, I checked the WordPress versions I haev installed. Apart from 2.6.3, I have installed 2.6.5, 2.8.2 and 3.4.1. I tested each of them after setting the PHP version to use (either 5.2.6 of 5.3.14), directly on the root directory of that WP version – so VERY basic.
Even using 5.2.6 I had problems – where this wasn’t the case a few days ago: On each of the blogs, PHP complained a file could not be located:

$ set def WP :[000000] ! the root directory of that WP version
$ php index.php

More >

PHP upgrade (continued)
Mark found something – because Variable-format files are indeed a problem. This type wasn’t taken into account in his rigorous testing…
Now he has found what was going wrong and has released a new PHPSHR file – AND he’s now able to reproduce the error. For now, all files that are included (’require’ or ‘include’ in the code) MUST be stream_lf. So on request, I converted the only file that is in variable format, to stream_lf. PHP 5.2.6 has no problem – but when I tried with PHP 5.3, PHPWASD.EXE stopped without error – and returned a 500 error.
Running the blog with PHP.EXE didn’t change a thing….

More >

PHP upgrade – continued
Got a reply from Mark – I sent him some WATCH output on the errors I encountered last Friday – and he noticed PHP code in the log – where it shouldn’t.
Admitted: I completely overlooked this part of the output….But these lines explained both the database-access problems with WP 2.6.3, and the shown PHP-code using WP 3.4.: the log shows no space, or better: line termination, between the PHP starttag and the first characters of the next line:
<?phpdefine or<?php/**
where you would expect
<?php
define or
<?php
/**
like the files read.
I encountered the first of these when I ran the blog using WP 2.6.3, with PHP 5.3. I thought the absence of the mysql and mysqli extensions were to blame, but that seems not to be the case, but the fact this file wasn’t interpreted. Apart from the other messages (that now seem to be suppressed in the PHP.INI file) this was unexpected, but it explaines the database access issue: the file is not included and interpreted but simply outputted – since there is no starttag stating this is PHP-code: the system simply concatenated the tag (which does exist in the file) and the next line – causing “<?phpdefine“. This is the databse-access file, kept outrside the normal path, but included in wp-config.php. And, in the WP 2.6.3 environment, it is the only file in Variable format.
As for the second example, this is a plain WP 3.4 file – the one I have converted to Variable format on request of Mark. Again: the lines are simply concatenated – WITHOUT addein Linefeed or NULL character, causing it to be interpreted as plain text to be outputted, in stead of being PHP code to be interpreted. Therefore, the database access file is never reached, so you would never see the first message showing up.

More >