22-Feb-2012

Weird
It’s often said that InternetExplorer sucks, Firefox should be used instead….
For those that agree, please explain why IE9 displays the vmswiki pages correctly, where Firefox 10.0.2 ignores any CSS…..Nor does Chrome.
This is the IE display:

The Firefox display:

and the Google Chrome one:

For this Blog, Firefox is fine….At least: most of the time…
Previous problems
Over a week ago, I entered a post concerning problems I had after updating Python: the VMS-wiki failed to start up. But in the process entering the post, I hit ‘Save’ to secure the contents. It turned out the link with the server was lost and all that I entered was gone into the void of the BitBin….
Now to recall all I entered – I’ll have to track back my post to the WASD mailing list…..

At some times, Windows stuff can be really frustrating 🙁

12-Feb-2012

Regular maintenance
Of course, on 02-Feb-2012 the job for regular, monthly maintenance has run – flawlessly, and it offers the mail statistics for January:
PMAS statistics for January
Total messages    :   2435 = 100.0 o/o
DNS Blacklisted   :    421 =  17.2 o/o (Files: 30)
Relay attempts    :     69 =   2.8 o/o (Files: 30)
Accepted by PMAS  :   1945 =  79.8 o/o (Files: 31)
 Handled by explicit rule
        Rejected :   1264 =  64.9 o/o (processed),  51.9 o/o (all)
        Accepted :    285 =  14.6 o/o (processed),  11.7 o/o (all)
 Handled by content
       Discarded :     67 =   3.4 o/o (processed),   2.7 o/o (all)
    Quarantained :    291 =  14.9 o/o (processed),  11.9 o/o (all)
       Delivered :     38 =   1.9 o/o (processed),   1.5 o/o (all)

Nothing really weird. The number of accepted messages seems quite low, but my estimate is that local mail (sent on Diana to a user on the system) bypasses PMAS and so it’s not counted. This holds, for instance, for all messages sent by the T4=software. The vast majority of rejected messages is casino and job proposal spam.

02-Feb-2012

Wiki repair
After questioning the issue on the WASD mailing list, it was obvious that Jean-François Piéronne would give the hint:

Hello Willem,

This is a MoinMoin known problem :

http://moinmo.in/MoinMoinBugs/ExceptionRaisedAtPageLoading

Describe as “Not a bug, just a little inconvenience”…

The provided workaround is “Run moin … maint cleancache.”

Jean-François

Following the link, it shows exactly the same errorm that I ran into, and the solution. But what does it mean?
The page also leads to the moin command, and to the subcommands, but the style is something to get used to. It has taken a few rounds of trial and deduction of the error.
First, the documentation states:The moin command is installed when you used setup.py. If invoking from the shell prompt does not find the moin command, you can also customize and use wiki/server/moin. Look into that script, there are some pathes to configure.. But there is no setup.py – it’s not located in the python environment, nor under moin_root.
But there is a moin.py, and that rings a bell:

$ python ≔= $python_root:[bin]python
$ python moin.py

would actually mean “RUN moin”
Next was to find out what command should be given:

$ python moin.py moin ... maint cleancache ...
as mentioned in the documenataion clearly wasn’t the right command. As it turned out:

$ python moin.py aint cleancache

was, but only after defining both moin_root and moin_wiki_root – the first being defined /SYSTEM/EXEC on system startup:

$ sho log moin*/full
...
(LNM$SYSTEM_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

"MOIN_ROOT" [exec] = "$1$LDA11:[MOIN193.]" [concealed,terminal]
...

but moin_wiki_root is a process-logical setup when Python is started, it refers to the root of the wiki, as a process logical, so I set it manually:
$ define moin_wiki_root WEB_DISK2:[WIKI.wikivms.]/trans=concealed

and the configuration file is located in moin_wiki_root:[mywiki], and referencing the configfile is in fact mandatory, the command to use is:

$ python moin.py --config-dir=/WEB_DISK2/WIKI/wikivms/mywiki maint cleancache

povided your current default is the directroy where moin.py resides; typically MOIN_ROOT:[MoinMoin.script]

So the whole sequence to clear the wiki after a Python update is:

* be sure MOIN_ROOT is defined
* be sure MOIN_WIKI_ROOT is defined

In my case:

$ sho log moin*/full

(LNM$PROCESS_TABLE) [kernel]
[no protection information]

"MOIN_WIKI_ROOT" [super] = "WEB_DISK2:[WIKI.wikivms.]" [concealed]

(This refers to the wiki you need to work on)

(LNM$SYSTEM_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

"MOIN_ROOT" [exec] = "$1$LDA11:[MOIN193.]" [concealed,terminal]

This refers to the location of the MoinMoin code

"MOIN_STATIC" [super] = "$1$LDA11:[MOIN193.share.moin.htdocs.]" [concealed,terminal]
= "WEB_DISK2:[WIKI.wikivms.mywiki.]" [concealed]

This is local: all fixed data (not related to the MoinMoin version) – for instance, the logo on the wiki

(LNM$SYSCLUSTER_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

(DECW$LOGICAL_NAMES) [exec] [shareable]
[Protection=(RWCD,RWCD,R,R)] [Owner=[SYSTEM]]

* Change directory to the location where moin.py is located:

$ set def MOIN_ROOT:[MoinMoin.script]
$ sho def
MOIN_ROOT:[MoinMoin.script]

* define python command:
$ python ≔= $python_root:[bin]python

* Keep in mind where the configuration file (wikiconfig.py) is located – typically it’s MOIN_WIKI_ROOT:[mywiki]. Now you can start the command:
$ python moin.py --config-dir=/WEB_DISK2/WIKI/wikivms/mywiki maint cleancache
This start working:

2012-02-02 20:26:02,719 WARNING MoinMoin.log:139 using logging configuration read from built-in fallback in MoinMoin.log module!
2012-02-02 20:26:08,294 INFO MoinMoin.config.multiconfig:127 using wiki config: /WEB_DISK2/WIKI/wikivms/mywiki/wikiconfig.pyc

After this ends, the wiki starts again.

Advantage
Before there has been a new user created every four hours or so. But when the trouble stared, there seems to be have been just one attempt that failed (because the wiki didn’t respond normally?), and the sequence did not restart after the issue was solved. Up to now there have been no attempt to create bogus users… Hopefully, this stays that way (but I doubt it)