Feelin Pretty Awesome...

[meaty-btz]

[UT ANNOUNCER]
GOD LIKE
[/UT ANNOUNCER]

So, we had a dead ancient LAMP at work. I had no idea of the version, it wasnt booting, the hardware was shot. They wanted the SQL DB and the Website off it. This was about 2 months ago. In my spare time I have been hacking away at it but have spent the last 4 days REALLY working at it.

Transfered the drives to my last ancient P3 system, the software would not run on anything newer. Through much linux magic.. and the fact I am the only one at my job that knows anything about old linux I cleaned up the bogused ReiserFS partitions and of all things got the damn thing to boot and be stable. Was no easy feat. Took every tool I had. Cleaned up all the damage in the SQL database. Turned out the box was running SUSE 8.0, SQL 3 and PHP 4. This was going to be interesting. Well though much magic I was able to port the DB over to SQL 5 ( that was fun, hand editing tables) and got it all up and running on IIS7.5 under Server2008R2. At the moment it was 100% and stable.. I heard a voice... GOD LIKE....

My head is still swimming with PHP and SQL code.

For my next trick.. tomorrow I will virtualize it through VMware and migrate it to our Blade Server Cluster.

[cntrolsguy]

I've got 1 for you, might be easy for you but I'm not that familiar with sql but her goes.

IOne of the 4 Databases keeps on failing over after every scheduled backup with the error code of:

The mirroring connection to “TCP://ula-ecs-1:5022: has timed out for database “alarms” after 10 seconds without a response. Check the service and network connections.
Error:1479, Severity: 16, State: 1

Is there a specific spot where we can increase the timeout time?

Also I have done some research and it looks like this might actually be some sort of known bug and there is a hotfix but I can’t seem to find a good place to download the hot fix, do you by any chance have this hotfix or know where to download it?

[meaty-btz]

Feeling Not so Awesome



Ok, so the server was up and cooking yesterday but..... today it won't authenticate users. So I ran down the checklist and back-checked it against the origional linux server to verify I wasn't dealing with a lurking issue that followed me over from that machine. It wasn't, flawless operation on the linux box. So I spent the day chasing my tail in circles.....
Here is the situation, maybe someone can toss me a lifeline. I already used my Call a Friend one:
Old Server and Configuration:
Suse 8.0
PHP: 4.1
MySQL:3.3
Apache 2

The PHP Site used ADODB (4.1?) Library to connect into the SQL DB in the usual fashion. Log in via local host and as root then authenticate users internally for the web page against the webpagedb/users entries. Passwords are encrypted with hashes in the "old password" SQL 3.3 style.

Operation, flawless.


New Server and Configuration:
Windows Standard Server 2008 R2
PHP: 5.3.5
MySQL: 5.5.9
MS IIS 7.5

Everything works, you can access the SQL DB through PHPMYADMIN just like you should. The ADODB config file is allowing the main page to be querried and built on the fly like it should so we definitvly have access to the SQL DB for the site. The problem comes when you attempt the internal authentication agains the USERS table, it fails. Every damn time. As far as I have been able to suss out there is absolutly NO reason for it to fail in the query to the USERS table and return a failed log in.

To put it more techincally, on the new server we are able to Initiate a new Root Session at Local Host for the Proper Data Base on the SQL server however it is the actual last part of the chain that is failing without giving me enough information (as in none in the log files) as to where exactly the user authentication (not to access the DB but to access the webpage as all actions to and from the database are done as root.. bad I know but this is old software). If I could pinpoint the failure point I could do work around or maybe update whatever component is causing the auth failure.

I am 99% certain there is something stupidly small stopping me. I have a theory that just came to me that McAfee Enterprise might be stomping on the query as being unsafe but that does not seem likely. I hate McAfee Enterprise (avoid it at all costs... but hey I am stuck with it). Anyways, tonight here at home I am going to build an Ubuntu LAMP and stuff the website and DB onto it and see if it runs better there. Might help me track down what is causing the user auth failure.