Posted on

07-May-2017

Maintenance report
There isn’t much to mention on maintenance.

PMAS statistics for April
Total messages    :   2796 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    209 =   7.4 o/o (Files: 30)
Accepted by PMAS  :   2587 =  92.5 o/o (Files: 30)
  Handled by explicit rule
         Rejected :   1793 =  69.3 o/o (processed),  64.1 o/o (all)
         Accepted :    164 =   6.3 o/o (processed),   5.8 o/o (all)
  Handled by content
        Discarded :    339 =  13.1 o/o (processed),  12.1 o/o (all)
     Quarantained :    274 =  10.5 o/o (processed),   9.7 o/o (all)
        Delivered :     17 =    .6 o/o (processed),    .6 o/o (all)

The number of relay attempts is not that high: the most (100) have been on April 26th, the rest (just a few days) were far less.

New router
I purchased the follow-up mof my Vigor 2920 router: a 2925Vac one. It has bot 2.4 Ghz and 5 GHz wireless, and supports 8.11ac protocol for LAN traffic. I could prepare it yesterday evening using the 2920 as a example (I could have restored the backup of that one) and installed it this evening. Apart from one thing I forgot: specifying which phone is what number, and setting up opened ports – I set them up but probably forgot to save the configuration – changing wnet without a hitch (Of course I had to apply these changes….) and the result in access, especially Wireless, is eminent. And I run the speed test: Up- and download went up to about 85 MB/s – matching the current speed of 100Mb/sec: This router’s firewall has a throughput of 200Mb/s, 4 times the bandwidth of the 2920….

Next month, my Internet speed will increase to 160 Mb/s (with no extra cost) and this router is fit for that (I got the announcement AFTER I received the router 🙂 ) so I’m ready 🙂

PHP 5.4 retest ahead
I planned a test of PHP 5.4 (dnd MariaDB 5.5) tomorrow evening, hopefully I don’t run into problems now, since I changed the system parameters. I may also need to reboot the server to include latest changes, based on AutoGen reporting.
So far the results of the performance look nice. Memory usage goes up to 75%, as before, bot slowly, and sometimes it seems to be eset. Something to investigate.

New version of WASD (and alamode)
New version of the webserver has been downloaded, and the accompanying monitor program. To be installed tomorrow (as well)

Posted on

29-Jan-2015

Webserver updated
I have updated the webserver to version 10.4. It required some extra work in the procedures, and it turned out that stopping the server using the procedure used for that action, forgot that the server is installed. So that is something I need to address. However, this action is hardly ever used – just on shutdown of the hardware. But it’s worth editing anyway, to allow adjustments in the environment. Be it the webserver, MySQL database of PHP version.
Anyway.
This webserver has TLS 1.0, 1.1 and 1.2 enabled. So no SSL – either version, due to the security leaks found lately. So if you try to access the server with a browser where TLS is not enabled, you won’t get access. That is: by default. But I have started the server – for the time being – allowing SSL3 – but you may run into problems.
In due time, SSL will be disabled completely.

Posted on

20-Oct-2013

Mail in error
For some reason, NOT ANY message has been received for over a day – not even quarantined or discarded. This is pretty weird, so I took a look and found that PMAS has gone into a “DNS-blacklist ALL” mode. Mail sent from my GMAIL account – that normally would arrive – was blocked as well. Even when I explicitly allowed al mail from gmail.com, of any account from that domain, mail sent from gmail was blocked:

Delivery to the following recipient failed permanently:

(my address)

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain grootersnet.nl by mail.grootersnet.nl. [82.161.236.244].

The error that the other server returned was:
554 5.7.0 Address (209.85.223.196) blacklisted (2)

(this was after I disabled the first entry in the configuration).

In order to receive mail – even spam that would otherwise be rejected, discarded or quarantined – I disabled PMAS by opening port 25 and remove the forwarding on port 25 to port 2525 – the one that PMAS listens on. Now mail arrived so it definitively was a PMAS issue. But what cuased it could not be determined.
A few days ago, I downloaded that latest version (PMAS032-050) from Process; I went there after I found I couldn’t create reports for this year and Hunter gracefully admitted he made a mistake and set a new file available – and with this access, I also retrieved this latest version.
I installed it in the right location, moved files (configuration, spam database, log files and statistics database) and restarted PMAS. Now al seems to be in working order again. Just have to copy what’s been quarantined and discarded.
Throttle redefined
The problems I encountered a few days ago: overload to PHP_WASD processes, made Mark Daniel propose another setting. So I have taken some precautions, so the amount of accesses to the blogs is now limited, and hopefully wide enough for normal use, and tight enough to prevent system exhaustion. I’ll monitor this for a few days: you may encounter 503-errrors: stating the service is not available, or some limit is reached. Big abusers may be locked out on a more permanent basis: I now know how to do that 🙂

Posted on

17-Oct-2013

Thanks to my ISP ?
This may, or may not, be related to my router problems yesterday, that caused connections to drop without notice. Or in another way, since I have no longer the ability to block addresses of networks (since the firewall in that router misses this facility).

Normally, I start SoyMail at work and keep it open all day. It checks for new messages every 15 minutes. Runs silently (Windows sound machine muted 🙂 and no trouble at all). Except for today, where all of a sudden sync failed during retrieval of messages. Restarting fails with a 503 error: “This service is currently unavailable”. Trying some time later, nothing is wrong.
So I started the Admin site, and found System not responsive; however, other actions would work. I found a large number of accesses to this blog, many in idle state, but they could still be active. At some point, I could access the System report and indeed: there were quite a lot of WASD processes that run PHP_WASD, given the current working set. The only way, I could think of, was deleting them, but that didn’t help, so I fugured that is I would purge the idle processes, these would go.
They didn’t.
So the next thing was restartNow. It solved the problem a bit: I could now show the System report and found a large number of PDP_WASD images still around;bur Soymail could be reaccessed and haply refreshed the contents. For a few hours, when the very same happened again. I just restarted WASD, and found even more remaining PHP_WASD processes in LEF state, even LEFO. It solved the issue for an hour, but at that time, to no avail.
It seems all process slots were taken.
Back home, I tried to kill these processed, but even STOP/ID failed, except for one or two. But there were over 60 of them (my processcount is maximized to 110) and the only way to get rid of them easily was to reboot Diana.
That settled the issue, but question remains: how can this happen? I’ve done some investigation and details will be made public later – let the experts look at it first….
A quick look at the number of connections shows that some time today, I have had far more a second (or minute) than I have had ever before. There are some spikes at times but I blocked these networks in the Vigor router, so these would have no opportunity to access ANY service on the LAN. But I am now forced to use the Fritzbox supplied by my ISP. It offers a better IPV6 connectivity (something still not well working on the Vigor – at least not with my ISP) and a more robust telephone connectivity (the Vigor may drop connections – or that is related to the issues I have encountered) but it simply lacks a firewall that allows me to block traffic – and it lacks external logging via syslogd. But it’s the only one they support – officially…
Well, that food for some other rant 🙂

Posted on

27-Feb-2013

More on WordPress
Mark has suggested another mapping:
map /wptest**/ /wptest*/index.php
exec+ /wptest/**.php* (cgi-bin:[000000]phpwasd.exe)/wptest/*.php* ods=5
and that works – for the basic action; though for completeness, I had to add
pass /wptest/000000/* /wptest/* ods=5 search=none dir=noaccess
pass /wptest/* /wptest/* ods=5 search=none dir=noaccess
to be sure images and stylesheets are loaded as well.
But first, I had to set things up so I could use the all-important WATCH facility: make sure I had to login, and could access the required files. The fast way was to copy the setup of Diana. Once that was done, I could find out what would happen now.
This new mapping does the trick – for a part. The normal user page comes up nicely, without a problem, and it is possible to login. But once the “login” button is hit, the process stops abruptly; WATCH output shows that there is insufficient core to extend “PATH” in the admin page (/wptest/wp-admin/indecx.php). This is weird, since the maximum amount of available memory for the PHP processor is 128M, set in PHP.INI….So it could be a matter of another process parameter: too little virtual memory. But pagefilequota is set to 500.000 for HTTP$NOBODY – the user under which the PHPWASD executable runs.
But when the URL of the admin page is next executed – and a new PHPWASD image is started – nothing is wrong: it simply comes on screen, a new post can be added, and followed by a few extra’s.
So it looks it works – until there is the io-error again – caused, in examination, by the same problem: there are 512 channels open…
Some further examination revealed that, if you wait long enough, the open cahnnels are closed at some point, but if you enter the next command too quick, the PHP engine gets to work without closing open channels….
What could be caused by parameter max-execution-time in PHP.INI: this has been extended from 30 to 120 seconds, otherwise the user page would not show because of exhaustion of execution time, as I found out when testing with SWS.
This has been added in the correspondence in the WASD mailing list; the raw data is available in a Windows .zip file on request by mailing list subscribers: these files may be rejected when sent as an attachement, for instance when received on a gmail account….
There is something more that’s wrong, but that is within the application: Some references in the tinymce environment are plain wrong and so some javascript files cannot be located and so some buttons don’t work. But since the link is set within WordPress, it seems more of a WordPress issue than PHP….(though these may be related!) Perhaps this is one of the things that is repaired in 3.5.1?