Month: October 2018

Found problem with homepage
After last reboot, the homepage wouldn’t show, giving a non-conforment CGI response. Using WATCH, it is clear: the program that is started, crashes:


%TRACE-F-TRACEBACK, symbolic stack dump follows
     image    module          routine                line      rel PC           abs PC      
WG_WEBPAGE    MAAK_DATABLOCK  MAAK_DATABLOCK          668 00000000000000F8 0000000000020A28
WG_WEBPAGE    BLOK2           BLOK2                   522 00000000000000C4 00000000000203A4
WG_WEBPAGE    WG_WEBPAGE      WG_WEBPAGE               41 00000000000000FC 00000000000200FC
                                                        0 FFFFFFFF8037FC44 FFFFFFFF8037FC44
%TRACE-I-END, end of TRACE stackdump

As it turned out, the logical pointing to the file to be read: WGPAGETXT, wasn’t defined – so there was no file to be opened – and the program is not able to cope with that: no need normally, since this logical is normally be set in the startup procedure. However, the routine that sets this was commented out since it doesn’t do its job properly – and as a side-effect, there will be no definition on what file to be opened….
Done this by hand, the routine has been updated (needed just a minor change: Another symbol to be used…)

Network update done
Previous weekend I changed the network address, using the sequence I had imagined. Just a few things needed another re-assignement of address – Internet-based radio, for instance, and a few other devices, but once these were restarted, they also work.
Remains the setup for IPTV. Some questons to be answered there, but most of the work has now been done.

WordPress update
Wordpress update was available for some time already, I just installed it, have both blogs logicals updated to use it. No issues.

Monthly cleanup
Two weeks ago already… Too bsy with other activities, but since there wer no problems:


PMAS statistics for September
Total messages    :   3562 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    655 =  18.3 o/o (Files: 30)
Accepted by PMAS  :   2907 =  81.6 o/o (Files: 30)
  Handled by explicit rule
         Rejected :   2180 =  74.9 o/o (processed),  61.2 o/o (all)
         Accepted :    103 =   3.5 o/o (processed),   2.8 o/o (all)
  Handled by content
        Discarded :    326 =  11.2 o/o (processed),   9.1 o/o (all)
     Quarantained :    276 =   9.4 o/o (processed),   7.7 o/o (all)
        Delivered :     22 =    .7 o/o (processed),    .6 o/o (all)


I made one change in the score of one filter since some abusers thought to have found a way to pass their ‘message’: Specifying my address as sender (FROM:) and receiver (TO:) but different personal names. The original score is 20, but I moved it up to 200 -so the messages will be rejected. It dropped the number of quarantined messages significantly.

The majority of relay attempts seems to happen every two weeks: three files are much larger than other ones:

PMAS_ROOT:[LOG]ANTIRELAY.-2018-09-01
PMAS_ROOT:[LOG]ANTIRELAY.-2018-09-14
PMAS_ROOT:[LOG]ANTIRELAY.-2018-09-29

and I still need to check these but given the results in the last months, it is likely tried from a Hostwinds.Inc address to the very same gmail address.

Changing the network
This weekend, I changed the network address of my LAN from 192.168.0.0 to 192.168.1.0 – to enable IPTV facilities thet rely on this network address. The order to handle this:

change IPO address of the Titanium ILO interfaces (the systems can later be adapted using the console interface of these)

Change DHCP in the main system (Alpha). The issue here is that you could change the configuration files manually, for an easier change, you will have to use a graphical interface…

In this chnage, I aslo changed the local domain

Change the DNS configuration – which again, you could do with an editor (I did so) but there is this one BIND.CONF file – and ANY error in here causes a problem

Change the LAN address of the router

Reboot the alpha – and see it it all works.

Well, not entirely. As it turned out, there was a minor error in one of the startup-procedures that caused the web server to fail;, DNS proved to bo be not completely set up – it took a few changes and reboots before all came up smoothly. Finally, it all worked, and after changing the NAT configuration to match the new network address (all incoming traffic is transferred to the cluster) I could adapt the PMAS configuration and a few other references to IP addresses and local domain, and it all worked out – after PMAS had a proper restart. There is one thing to be checked: one device is connected to the LAN but seems to have trouble to reach out.
And of course, configuring the router so that all IPTV facilities become available.