update – SYSMGR in the attic

6-Apr-20156-Apr-2015

06-Apr-2015

Server updated – and still access problems
I updated WASD and SSL to the latest versions and installed them. But than I encountered exactly the same problems as before yesterday: I could not access any of my sites. Since I have now a recent backup of my router, I restored it – but is didn’t help at all. Only by defining the sites in the hosts file on my workstation I can – and that works as long as I’m accessing the sites from the local network.
But that should not be the case!
As far as I can determine, looking at the webserver access log, the admin pages output and the router’s logging, other sites seem, top have no problem. Why I cannot, is a mystery.
But from this point, it looks as if this blog is extremely slow. It works, but that seem to be all. looking at the access log, there is a (Russian) site that POST to one of the xmlrpc.PHP file quite often. I blocked the site, not just the address, but it keeps getting through. So I blocked just the address.

24-Aug-201224-Aug-2012

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….

23-Feb-201123-Feb-2011

20-feb-2011

font color=”red”>kernel stack not valid
This weekend, in preparation of all upcoming updates, I did a number of things:
* Downloaded the AXP 8.4 CD’s (ISO’s) as a zip file from the AllianceOne site – I’ve been warned that this one is not the best one and contains a number of BAD THINGS – but with the patches, these should be addressed.
* Unzipped the file and burnt the installation ISO onto CD.
* Downloaded the latest UPDATEs and all patches that overrule what’s in it (according the master ECO list)
* Also dowloaded all latest 8.3 patches from the HP site – to update Diana.
* Downloaded the latest WASD files (and PHPWASD en PHP 5.3 by Mark Berryman)
* Copied the new WASD environment from Daphne (where I tested the whole lot) to Diana

First things first: Overwrite the current 8.4 fieldtest environment on Daphne to the real thing – using the (possibly not-to-best) downloaded file.
That caused no problem.
Next I installed Update 1 – rebooted – PCSI – rebooted – UPDATE 4 – reboot – and the rest in one go – reboot – But No. It did not and broke even before SYSINIT was loaded. So there’s something pretty basic going wrong. No matter wat -flags I added: still the same error:

halt 2 kernel stack not valid CPU=0

There was one thing to do to get on: Post a message on ITRC, and during the next days there were answers that gave me the information to get on: What to do ‘(log a call with HP), how to get around it, and that I might have been able to prevent it by reading an advisory – if only that would have been shown where you would it to be exposed: as a warning on the download spot! Hoff’s explanation at the end is worth a read, because it tells you what may be going on.
So: “To be done” – next weekend. Log a call with HP as well (though it’s said that engineering does monitor the ITRC site – they would become aware of the issue anyway).
In the mean time, I can set up my new WASD environment – not yet enabling it, but getting it ready to go. Diana isn’t effected in this matter.
Fiber status
Planning was start digging in week 7 – but when starting at the opposite side of the quarter, it takes some more time to get near our place. Hopefully it will be this week, or next; soon after that, I may be get connected – but even than it will take some time before I have the speed I want. So please be patient – I’ll try to have all updates done before that 🙂

24-Dec-200824-Dec-2008

24-Dec-2008

Patches installed.
Today, I installed a number of patches – after having made a proper image backup of the system disk.
That was no problem, as could be expected.
First tests of PHP
A few weeks ago, I learned a new version of PHP was coming soon. It’s abit delayed,but I was able to put it to thye test. Well, some tests.
To keep the previous version at hand, I renamed the previous directory trees to PHP4 and the newly created one PHP5. From there all updates have been done: PHPWASD that had to be changed a bit.
After reboot, PHP5 was enabled but there were some slight problems in the startup script, that caused PHP_ROOT not be defined. A small change solved that problem. I also forgot to move PHPWASD to the right spot, but once these issues were settled, I could start running tests.
MyPHPAdmin fails. From the start, it gives a non-CGI-conformance reply. Obvious, it doesn’t return the status as a first issue. Weird, since that should haven been returned. Or it’s caused by the MySQL 4.1 engine that came with the PHP package. That’s something to be reconsidered!
WP – the test blog – runs but is VERY slow. Login may fail, but will in the end succeed. Or may return an eror, but WATCH shows the full HTML output, which is valid. And some data is added, which may cause a problem.
This blog had a problem on login – but refreshing the screen would come back with the admin page in the end. Not sure yet what caused it. But where I previously found a message that PCRE lacked UTF-8 support, I get a more severe error:

%SYSTEM-F-STKOVF, stack overflow, PC=00000000002399E0, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows


 image     module      routine        line    rel PC           abs PC

PHPSHR 0 00000000001E79E0 00000000002399E0 PHPSHR 0 00000000001E931C 000000000023B31C PHPSHR 0 0000000000266634 00000000002B8634 PHPSHR 0 00000000001A1AC4 00000000001F3AC4 PHPSHR 0 0000000000189D94 00000000001DBD94 PHPWASD PHPWASD ProcessRequest 44025 0000000000001C58 0000000000031C58 PHPWASD PHPWASD main 43639 00000000000005A8 00000000000305A8 PHPWASD PHPWASD __main 43565 000000000000006C 000000000003006C 0 FFFFFFFF80379CE4 FFFFFFFF80379CE4 %TRACE-I-END, end of TRACE stack dump
and later on, where plugins list is shown, the same error is found.

Second, it’s VERY slow. And where I previously could handle fo9rms nicely within a 12Mb linit, I get Out-of-core messages now and than – on logout, for instance.
Testing getting an image wasn’t changed. After uploading the image, stating the image being included in the post, dows not return to the editor: IE states “The object doesn’t support this property or method”.
But the script is there if you view the source:

Well, I found that adding the data between the “” tags would do the trick. With, without these tags.
In the course of the next day, I’ll do some more testing to find out what’s going on.
UPDATE
Another issue just found: Where previously lines in withing <code> tags would wrap if they exceeded the width of the section, it’s not chopped on the right.
But I also found that once the site environment is set up, access to pages is faster than before. But that’s more like the result of Mark’s coding than the PHPSHR module 🙂

April 2024
M	T	W	T	F	S	S
« Nov
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30