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.
What goes on behind the doors of the (private) data center