Apache-WHM Parsing Error (1 change per session)

[marcOpolo]

James is a php-perl nimble engineer with expertise in net security.
He kindly helped me to troubleshoot my vps crashes while using WHM and PuTTY on Hostican's Apache VPS array. He will be following up on this he assures me, but not with Hostican. Oh well. Anyway, down to my mundane reality...

Turns out that my problems leading to one Windows crash and three VPS resets are due to a parsing error between Apache and the two frontends caused by some misfiring Windows dll's. Apparently solutions get worked out by net utlities.

Errors kick in when I move too fast in WHM, which is easy to do since the misfire isolates me from what is happening on the server. For IE7 on Vista 64, this means sending junk into the server, and for Fire Fox this means the server sending junk into Windows. In the first case the server crashes, in the second case Windows crashes. I prefer the server crash since it can be fixed in a few minutes, while the Windows crash can take many days to repair.

James has found that this particular Vista 64 error specifically involves the "programming level" available in the Apache application. Vista 64 simply (that 'simply' is a Microsoft term), simply cannot regress to the earlier Apache methods. Optimaly using the WHM to upgrade to the latest STABLE release, Easy Apache 2.2 will help to solve the problem.

Hostican templates the Apache at version 4.01, an older STABLE release that is causing problems on my newer Vista 64 os. This older template release accommodates the typical older user modules written for 4.01 by Hostican's regular users. I am not a programmer and I am only interested in current software behaviors. Hopefully, the following is to be viewed as annecdotal information, once a 'shadow' Apache upgrade is done (see below). First, let's look at that Windows misfit.

This parsing error does not change the way a user commits changes made in WHM, but does not immediately display changes to the user once committed. In fact, if the user does not close the browser after making certain changes to the server configuration, serious problems can result. This can cause the user to potentially scramble the VPS (or local Windows) by overlapping conflicting commands. I ran high-speed through some routine account setups and followed by acccount changes (account themes and DNS IP's). Indeed, quickly toasted the VPS twice. How this conflict toasts the VPS is according to Jame's, not important to me.

The parsing error demonstrates as information submitted to the server but does not show on the user terminal. My engineering friend adjusted Windows Defender FireWall to change the error somewhat to a behavior that we can call the 'tweak' condition. Tweak condition cannot resolve the error, only making work a little faster. So let's compare default and tweak, since conditions seem to mean a lot to engineers and sure make my life easier!

For both default and tweak conditions, any browser used by windows will exhibit the error. The browser must be closed, and then WHM re-opened to show that the server has committed the change. The default condition means waiting up to 15 minutes for the next server reset before the change will show. The tweak condition means a few nano seconds of server time to commit the change, and then up to several seconds of user cueing for the VPS change to register in the user vps.

In the tweak condition, leaving WHM before the cue is processed results in browser not showing the change - the browser must be closed and reopened a second time to show the change. In default condition, the time delay is plain and simple exasperating.

Whatever condition, WHM is an online or virtual application and the Vista64 dll's currently assure that the user display of server settings will NOT UPDATE until the browser is closed and then WHM re-opened in synchronicity with the server's normal process. Various WHM/browser refresh techniques were not helpful as the Windows dll's operate at a deeper level than browsers or online apps can make adjustments. The solution exists in a version if the Apache server that is capable of matching teh Vista 64 dll activity.

James and I had some difference of opinion. Keep in mind that he is an engineer and I am simply a software user. I thought I was re-inventing the wheel, turns out I was just laboriously plodding on, at least in the right direction.

I notice that under the tweak condition, if the browser is shut immediately (without waiting for any server cue to run), the re-opened browser usually doesn't show the change on the server. In other words, I usually have to wait a few seconds before closing the browser or I will miss the server update. I thought this meant WHM was not keeping up. In fact, my browser close-open cycle was sometimes aheasd of the server cue. I guess my not-ro-brilliant observation isn't conflicting but points out the importance of patience.

This is not what they call a 'Windows Issue'.

Now that I am tweaked, If I move too fast to see my changes, I just have to close and reopen the browser a second time to pick up the changes. As soon as WHM reloads, the current server settings are passed to the TWEAKED user terminal, so closing and re-opening a second time always shows the server update.

CHANGING THE BROWSER THAT WINDOWS USES WILL NOT FIX THE MIS-FIRING VISTA 64 DLL's, ONLY CHANGE THE WAY THE ERROR DEMONSTRATES.

INITIAL advice from Hostican (friendly Kevin running back-and-forth on the telephone between me and busy-elsewhere techs) is to use Fire Fox. From experience I know that changing to Fire Fox will simple crash default Windows instead of the server. I really don't feel like doing a test crash tweaked Windows on Fire Fox. Default IE7 showed the same outcome as tweaked IE7, namely the same old server crash. Deafult FireFox crashed my Windows, so it follows that Tweaked FireFox will likewise waste a week of my time and possible damage to hardware (again, ugh)!

Either way, tweak or default, IE7 or Fire Fox, the Vista 64 web publishing stream will crash.

Obviously what seems most promising to me now is to upgrade to the Apache 2.2, the latest STABLE release. This will improve interaction between the healthy Apache and the herein challenged Vista 64. Anyway, James' argument about the dll, while way over my head, makes perfect sense.

Regardless, a common sense approach is important. The following caution has to be observed on any system using both the template and 'shadow' upgrade Apache's . By 'shadow' upgrade we mean an Apache upgrade done through the WHM panel but not backed by any VPS server farm upgrades. In other words, a vps Apache upgrade, fro what it's worth.

WHEN A COMMITTED SERVER CHANGE DOES NOT APPEAR IN THE WHM CONSOLE, STOP. IT IS IMPORTANT FOR THE USER TERMINAL TO SEE THE COMMITTED CHANGE BEFORE PROCEEDING. OTHERWISE CONFLICTING INFORMATION MAY BE SENT TO THE SERVER. WAIT FOR THE CHANGE TO APPEAR. AFTER THE CHANGE IS COMMITTED TO THE SERVER BY APACHE, PARSING THROUGH ANY PUBLISHING CUES, AND IN SOME CASES THE SERVER REFRESH INTERVAL (3 SECONDS TO 15 MINUTES DEPENDING ON THE TWEAK OR DEFAULT CONDITION), THEN CLOSE WHM AND RE-OPEN WHM. THE SERVERS CURRENT SETTINGS SHOULD APPEAR. WHEN THE NEW SETTINGS APPEAR IT IS SAFE TO CONTINUE. HOWEVER, IF THE NEW SETTINGS DO NOT APPEAR AFTER, SAY, 30 MINUTES, CONTACT SERVER SPPORT TECHNICIANS. STOP MAKING CHANGES TO YOUR SERVER THROUGH THE WHM AND/OR PUTTY INTERFACES.

Notes
1. Using the Hostican template VPS (Apache 4.01) firewall tweaking was not useful. While 4.01 tweak vps condition is not tested, reasonable to assume that the same patience will maintain some server stability.
2. Easy Apache 2.0 on my vps allowed tweaking success.
3. Improvement from 4.01 to 2.2 reflects only certain observed settings: it is a good idea to use the latest STABLE Apache for optimal WHM use. Some custom user scripts require older versions of Apache, such as 4.01.
4. Easy Apache 2.2 is not yet tested by me, but James is certain this will work better with those problem Windows dll's.

This post reflects user management of Current Apache and WHM releases. User is Windows Vista Ultimate 64 on a 3 mbps broadband cable connection routing North American urban centers on ATT's optical fiber grid. The likelihood of accidental error under our repeated testing is nul. The assertion that the 'guilty parties' are Apache and Vista is based on an engineer's assessment of Apache feed/response and Windows response. Becasue the parsing errors are consistent through PuTTY and WHM, those interfaces are not of interest in finding a resolution on the current VPS platform. The assertion by non-technical server staff that changing browser will help is a resolution independent of the problem dll's and thus is discounted. It is of interest that Fire Fox 2 casues a Windows crash rather than a server crash that occurs with IE7, and that is why this author is now using IE7 - i.e., Fire Fox is not a secure browser for Vista 64. Is anyone interested in default vs tweak conditions using Fire Fox on Vista 64?

...Not me. I am an experienced web author, not an engineer or server technician.
Though I seldom shrug off possible useful technical communication, site composition is my strength, and it is really where this world wants me to be.
Please help and set up some VPS arrays more mature than Cent OS 4, for those of us with mature publishing platforms. Otherwise, I will do my best to stick to one change per carefully timed session in my WHM!