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….
21-Nov-2012
Helena updated
A few days ago already….
I had trouble with one non-critical program on Helena – the 16Gb Intel i7 system that is now my major workstation. Originally WIndows7Pro, I updated this machine to Windows8pro – because of the low pricetag :). It didn’t solve the problem (which is under investigation with the supplier) but offers some new insights in how systems are delivered nowadays. It takes a while to get used to it, but it dows the job, so far. Of course, I took precautions: a full backup of the system disk in case I want to revert – if possible. But so far, I’ve seen no real reason to do so. It’s different, that’s right. But, for me, workable.
Another advantage: IE 10 is winsockes aware. Propably not 100% but DClInABox works. And since it has been backproted to Windows7, I’ll install IE10 on these systems as well.
Webserver update
Mark Daniel published a new version of the WASD webserver a few days ago. And because I had still trouble using DCLInABox using Firefox15, and found a dissimilarity in the source compared to what the docs of this software states, he suggested me to upgrade.
I just dis, and all works – except the mail agent… but that’s merely a matter of file protection of the configuration file….Now to find out how to get around it….
As it turned out, it was indeed a matter of protection, but unexpected. In the update process, I enabled settting the site protecteion as it ought to be (no access unless allowed explicitly). Then I stopped the server with the shutdown proces. That removed SOYMAIL.EXE from memory; but I didn;t use the full startup, so SOYMAIL.EXE wasn’t reinstalled, and when executed on access, it lacked the privileges needed to access the configuration file and set logicals….
Once I had run the SOYMAIL startup – that will install the executable with proper privileges – that also worked again.
But it did not solve the DCLInABox problem with Firefox. Not even when running FF16 uncluding last updates: very much the same problem, where Chrome and IE10 are succesfull.
Next update might be Diana, moving up to VMS 8.4, and immediately apply the mandatory updates, and update 7 to get in line.
24-Aug-2012
WASD updated
It took some preparation because quite a lot of basic config of the server (not the sites) has changed and so the process needed some time: Another naming convention and location of logicals, and a change in configuration-schema made this update less straight forward than normally is the case. Including full startup (and shutdown) of the web server – and surrounding software: like the PHP engine and mail support.
Not forgetting the daily, weekly and monthly processing – it all needed to be overhauled.
To be sure I could reverse, if needed, the whole installation was to be performed on a new directory tree, fully separated – as far as the server environment was involved – from the old version.
Most preparation could be done before the server was updated, but it could only be checked after the new version was installed. That process itself required the running (9.3) server to be shut down. So I did, and it will have caused some timeout when the content was accessed.
I could have done simpler, perhaps – since there is a CLONE option, but that did not exist in pre-v10 versions. i think.
The update itself was flawless, as could be expected. Restarting the server itself was neither – but since the installation did copy sample configuration into the environment, I couldn’t get to the site itself. I had to remove these files ($ delete WASD*.CONf;0), then stop and restart the server before I could access the sites. Onl;y a few tweaks were required in the configuration (things did change….), and I could start the site used for system management: handy, because that also faciliates the server admin pages – including the WATCH facility. But other sites – including the normal site, were not, and the WATCH output immediately showed why: I still had to copy a number of files from the previous environment; including some executables and files that reside within the server environment.
Now, within an hour, at least most of the most important features seem to work. Just mail access doesn’t work, but that will be solved soon…
Update
The last hurdles have been taken…I had made a minor adjustment to the SoyMail configuration file, and that causes a double-quote to get lost. That’s why the footer didn’t show – and I couldn’t display the messages…Problem solved.
Other minor issues were easily solved by copying some files from the old to new environment. It’s just the Java-based terminal emulator that doesn;t work – but that is useless anyway so I can get rid of it. There is an alternative I can use with this version of WASD – and latest Chrome browser (and next versions of Firefox and IE), based on websockets…. So next action is to build this HTTP-based terminal emulator
Update 2
Done, and included in the system management site – which is (as can be expected) protected. It does work – running Chrome since that’s currently the only browser on my system that supports WebSockets – but connecting to the site will fail on authentication. Checked that with Mark Daniel who provided the code: it’s not fit -yet – to be run in an authenticated environment.
So now I have to find a way to make that path free from authentication and still make the access impossible ig you’re not authenticated. Can be done, but requires good thinking….
11-Jul-2010
A bit more on WP
One more mapping line was required to have WP 3.0 working:
map /wp30/wp-admin/ /wp30/wp-admin/index.php
otherwise, the admin page didn’t show up properly.
The biggest problem is with the PHP-engines now. It seems that almost every request launches a new WASD process. These all require a lot of resources – mainly memory, the pagefault rate peaks over 20.000….