Last – or first – maintenance
The last data of 2012 has been processed without a problem, not a real surprise, and it has been submitted to run on 1-Feb-2013, just like expected.
PMAS statistics for December
Total messages : 4806 = 100.0 o/o
DNS Blacklisted : 889 = 18.4 o/o (Files: 31)
Relay attempts : 50 = 1.0 o/o (Files: 27)
Accepted by PMAS : 3867 = 80.4 o/o (Files: 31)
Handled by explicit rule
Rejected : 3085 = 79.7 o/o (processed), 64.1 o/o (all)
Accepted : 237 = 6.1 o/o (processed), 4.9 o/o (all)
Handled by content
Discarded : 116 = 2.9 o/o (processed), 2.4 o/o (all)
Quarantained : 360 = 9.3 o/o (processed), 7.4 o/o (all)
Delivered : 69 = 1.7 o/o (processed), 1.4 o/o (all)
Just two files of 5 blocks attempting relay attempts, not a real surprise. Next, all files of 2012 are to be archived…
Webs on Daphne
Biggest issue with WordPress is lack of virtual memory. But after creation and installation of a second (and larger) pagefile, that was solved somewhat. This also proved the number of fileheaders in the master indez was exhaused, so I created a minimal procedure to purge the whole disk, and submitted that job to be run automatically each hour. That solved that issue, for now.
After the WordPress and real blog runs fine, I installed WASD 10.2 on Daphne as well, as well as another PHP-environment, copied from the SWS site; I also created a startup-file that is needed to have all logicals to be defined: PHP_ROOT and PHPSHR – and the shared image is installed by the procedure. This installation runs on another port as SWS so it allows both servers to run simultanously. But it is not possible to have the blog accessable by the two servers, because WordPress stores the URL of WordPress, and the blog in the database – including the portnumber, so the blog can only be accessed by one server, and because the other is running on another port, it cannot access the database….
Of course I could try using proxy, but that is not what I want. The fast way to get around it, is creating a blog and database per server, the right solution means the port number in the database to be variable, to be defined by the server, either taken from the URL, or defined in the configuration file per server. I have questioned it in a WP forum. But for now, I will use a separate blog for each server, until a solution has been found.
Apart from that: I tried the WordPress 3.5 test bklog under WASD, still using the ‘wrong’ port by a simple specification in the configuration file,just these lines:
exec /wptest/**.php (cgi-bin:[000000]phpwasd.exe)/wptest/*.php \
ods=5 script=syntax=unix script=query=none map=once
pass /wptest/* /wptest/* ods=5 search=none dir=noaccess
map /wptest /wptest/
and this works! Not entirely because the reference to the SWS environment. There is however a minor issue with the default homepage, but that can be solved.
24-Dec-2012
Postponed
The date I would get a new connection has been postponed until 31-Jan-2013. That is: that will be the first date that the connection can be established. So this site will be up and running a few weeks longer than originally expected. I do have the anticipated address already, and both the modem and router/firewall delivered by the new ISP. That modem offers IPV6 connectivity, but I have no idea whether the firewall offers the same facilities as the current one. Eventually, if possible, I would have all IPV4 traffic pass as-is – including the IP address by the ISP – and use the current modem. If IPV6 is not a requirement, I could even think of not using that router at all. Something to discuss with the mechanic that will install the connection (free of charge).
Testing WP35
A colleague has asked me if I could help set up a WordPress installation, using latest versions of Worpress, SWS/Apache and PHP (by Mark Berryman). The site runs on an emulated Alpha (Avanti by MSI) but there were some issues, mainly functional but performance as well. Functionality should be tackled fist, so I set up an installation on Daphne, installed SWS, MOD_PHP and next Mark Berryman’s port, followed by WordPress 3.5. There were quite a number of files that needed to be renamed, since I found that, even after $ SET PROCESS/PARSESTYLE=EXTENDED, dots in a filename are replaed by underscores – and the code expects dots….No big deal, once you know what to look for.
I used the very same setup as I had done on Diana, including this blog. First, I started with the vanilla WP installation, nothing fancy, just plain out-of-the-box, and next I created the site blog that uses this code. My colleague has confirmed that the basic WP site works, next should be the test site.
If that all works, we should check whatever can be done to speed things up. Daphne is way smaller that the environment the blog will run on, and it already has shown that the way SWS works with PHP, requires quite a lot of resources, Memory, in particular, and process slots. Showing the admin page alone, requires at least 5 SWS worker processes, all requiring a full set up of the whole environment. And PHP.INI needs to be adjusted so the maximum execution time for any script is extended – well over the default 30 seconds. I have set it to 2 minutes on Daphne and even that’s not enough (though I could create the database in that time).
This offers me the opportunity to set up a WASD environment (which also exists in Daphne) to run the blogs in WP 3.5 – and later. Because I now have a working environment, be it under SWS….