IPS Driver Error, make it more clear

[teraßyte]

A lot of peoples still post something like "I get IPS Driver Error doing that, how can i solve it?"

And then every time the answer is "Look for the real error saved in a cgi file in the cache folder".


If that error is going to be displayed in that same way also in IPB 3 i suggest you to add a small line below it like "Real error is hidden for security purpose, to see it check the cgi file in the cache folder" or something similar anyway. That should stop a lot of useless topics with "IPS Driver Error" as title :rolleyes:

[Tony]

On vbulletin, if there's an DB error if you View the page source it will show you the error (something like this):

<!--

Database error in vBulletin :


Invalid SQL:


			SELECT *

			FROM datastore

			WHERE title IN ('','options','bitfields','attachmentcache','forumcache','usergroupcache','stylecache','languagecache','products','pluginlist','cron','profilefield','loadcache','noticecache','userstats','birthdaycache','maxloggedin','iconcache','eventcache','mailqueue','blogstats','blogcategorycache');


MySQL Error   : Table 'vbulletin.datastore' doesn't exist

Error Number  : 1146

Request Date  : Sunday, July 13th 2008 @ 11:36:04 AM

Error Date	: Sunday, July 13th 2008 @ 11:36:04 AM

Script		: http://xxx

Referrer	  : http://xxx

IP Address	: xxx.xxx.xxx

Username	  : 

Classname	 : vB_Database

MySQL Version : 

-->

[teraßyte]

Doing what you say Tony will defeat the purpose of IPS.

They have hidden the real error for security purpose (if i don't recall wrong) so showing it "hidden" in the source will give the same security problems :o

[.Matt.]

Or at least log the errors in a more convenient file, easier to find and better defined.

[teraßyte]

Well, errors are logged fine right now (day by day on different files).

Problems occur only when non-expert peoples with IPB see that generic "IPS Driver Error", adding something like the paragraph i suggested above will tell them were to search for the real error without confusing those that doesn't know were to look :)

[Alex]

Yeah they used to have the error showing, but because of security purposes, they removed it. I agree that a bit more information would be quite useful. Maybe not announcing the files though, because then you could just access the file with the error in, defeating the purpose

[teraßyte]

Bump, the IPS Driver Error page still have the old message (not to mention that already some reports have been made posting IPS Driver Error without the real error lol)

[Mark]

The problem is though, front-end users don't want to read a message saying where the error is logged, that wold confuse them.

A big chunk of people also wouldn't even know how to open the log file so you'd still get the support topics ;)

[teraßyte]

Well adding something like "If you are the administrator of this forum please check the error logged in the cgi file inside your cache folder" would at least help a bit I think :ermm:

[bfarber]

We are not going to give away sensitive information or anything like that on the error page. You are free to edit it if you wish (the template is in cache/skin_cache/ now) but we won't be adding any sort of indicator where log files might be located, etc.

[AtariAge]

It would be nice if these errors could be viewed from the ACP--I had to look up an error yesterday while doing some testing. I was already in the ACP, but had to jump into a shell to take a look at the cgi file .

..Al

[bfarber]

[quote name='AtariAge' date='10 June 2009 - 09:45 AM' timestamp='1244641552' post='1808784']
It would be nice if these errors could be viewed from the ACP--I had to look up an error yesterday while doing some testing. I was already in the ACP, but had to jump into a shell to take a look at the cgi file .

..Al


That's something I've thought about and would like to do, but it's challenging. If a site had some major database issue one day, the log file could easily be 20MB in size....that would be difficult to handle resource-wise from the ACP, not figuring in things like pagination and what not.

[Michealfan]

[quote name='bfarber' date='10 June 2009 - 06:19 AM' timestamp='1244643542' post='1808788']
That's something I've thought about and would like to do, but it's challenging. If a site had some major database issue one day, the log file could easily be 20MB in size....that would be difficult to handle resource-wise from the ACP, not figuring in things like pagination and what not.


Possible if file size is somewhat around 2-5 mb?

[AtariAge]

[quote name='bfarber' date='10 June 2009 - 09:19 AM' timestamp='1244643542' post='1808788']
That's something I've thought about and would like to do, but it's challenging. If a site had some major database issue one day, the log file could easily be 20MB in size....that would be difficult to handle resource-wise from the ACP, not figuring in things like pagination and what not.

I would just present a list of the error files in the cache directory, allow the user to pick one to view, and then show a single error at a time, as opposed to loading the entire file. Display the timestamp, error number, error description, IP address, URL nicely, and then the array dump after that. Allow the user to go up and down through the errors one at a time, and go to the first and last error as well. No need for pagination as far as calculating page numbers.

..Al

[bfarber]

[quote name='AtariAge' date='10 June 2009 - 11:39 AM' timestamp='1244648354' post='1808806']
I would just present a list of the error files in the cache directory, allow the user to pick one to view, and then show a single error at a time, as opposed to loading the entire file. Display the timestamp, error number, error description, IP address, URL nicely, and then the array dump after that. Allow the user to go up and down through the errors one at a time, and go to the first and last error as well. No need for pagination as far as calculating page numbers.

..Al


From a *technical* perspective that is very very difficult to do. You'd basically have to load the entire file into memory, and then use regex to match out the errors by a separator (e.g. the lines with just ====== across them), and then display the requested error. PHP has few faculties to load just pieces of a file, and those faculties mostly work in that you can tell it the number of characters to read, which is useless when every error entry is going to be of a different length.

We can probably add a viewer, you'd just need sufficient server memory to view the larger files.

[AtariAge]

[quote name='bfarber' date='10 June 2009 - 12:19 PM' timestamp='1244654380' post='1808832']
From a *technical* perspective that is very very difficult to do. You'd basically have to load the entire file into memory, and then use regex to match out the errors by a separator (e.g. the lines with just ====== across them), and then display the requested error. PHP has few faculties to load just pieces of a file, and those faculties mostly work in that you can tell it the number of characters to read, which is useless when every error entry is going to be of a different length.

We can probably add a viewer, you'd just need sufficient server memory to view the larger files.

You don't need to read the entire file, just fread an arbitrary block at a time and parse that in memory. When you find the delimiter, process the text until you hit the next delimeter. You could even use fgets to read the specific error a line at a time once you are fseek'd to the proper place in the file. Going backwards is a little more tricky, but not terribly so. This is not a difficult problem.

..Al

[bfarber]

[quote name='AtariAge' date='10 June 2009 - 01:28 PM' timestamp='1244654914' post='1808836']
You don't need to read the entire file, just fread an arbitrary block at a time and parse that in memory. When you find the delimiter, process the text until you hit the next delimeter. You could even use fgets to read the specific error a line at a time once you are fseek'd to the proper place in the file. Going backwards is a little more tricky, but not terribly so. This is not a difficult problem.

..Al


Since you obviously know PHP, tell me - if you wanted error #4 in a file (where you obviously have no idea how many errors there are), how would you fseek to the appropriate spot? You fseek a byte position from the beginning of the file. You could use something arbitrary, like you said, and hope you hit a correct location - but as some errors can be long, and some can be short, that's a stab in the dark and quite unreliable....

You could read 4KB from the beginning of the file, see if you have a delimiter, get next 4KB, repeat, until you hit the right spot. This could prevent you from having to load the entire file, I suppose.

No, I'd probably just load the entire file into memory and be done with it. ;) I'd also probably add in a link to simply download the file (because you can use flush the buffer while outputting a file you don't run into the same memory limit issues if done properly. That way you'd at least be able to download the file from the ACP without having to launch FTP, if you couldn't actually view it there.

And to be fair, 20MB error logs are pretty rare. Most SQL error logs are 5MB or less.

[AtariAge]

[quote name='bfarber' date='10 June 2009 - 01:04 PM' timestamp='1244657079' post='1808846']
Since you obviously know PHP, tell me - if you wanted error #4 in a file (where you obviously have no idea how many errors there are), how would you fseek to the appropriate spot? You fseek a byte position from the beginning of the file. You could use something arbitrary, like you said, and hope you hit a correct location - but as some errors can be long, and some can be short, that's a stab in the dark and quite unreliable....

You could read 4KB from the beginning of the file, see if you have a delimiter, get next 4KB, repeat, until you hit the right spot. This could prevent you from having to load the entire file, I suppose.

No, I'd probably just load the entire file into memory and be done with it. ;) I'd also probably add in a link to simply download the file (because you can use flush the buffer while outputting a file you don't run into the same memory limit issues if done properly. That way you'd at least be able to download the file from the ACP without having to launch FTP, if you couldn't actually view it there.

And to be fair, 20MB error logs are pretty rare. Most SQL error logs are 5MB or less.

What I was proposing was just a simple means to go back and forth through errors, not seek to a specific error. You'd start at the beginning, and allow the user to jump forward or backwards one error at a time, and jump to the beginning and end of the file. Logically it's more work managing a buffer (or buffers) and scanning for the appropriate text and parsing it, but it's not unreasonable. In this fashion you would not need to worry about the problems associated with loading a potentially enormous file (although I guess you could put a cap on the size of the file it would attempt to load). I agree that arbitrarily searching for a given error in the file (jump to error #4) is more demanding as you'd be slowly scanning through the file, and that loading the entire file if memory allows would be ideal.

Looking at the logs on my live forum, there are only a few and they are quite small (the largest is only 25K). Although if something goes wrong and you're getting tons of driver errors, you're probably going to be dealing with files significantly larger.

I'd be happy to see the entire file loaded into memory if that would work in most cases. I also like your suggestion of providing a list of the error files with a link to download each. Even that would save some time and make things easier. :)

..Al

[The Pi]

Perhaps you could create an index file with offsets for the different errors?

[Mat Barrie]

Personally I think you guys are trying to make it more complex than it needs to be. Perhaps just a page in the ACP with a list of SQL error files, and a "Download" / "Delete" link beside them. No muss, no fuss.

[AtariAge]

[quote name='Mat (Aesir Tech)' date='13 June 2009 - 11:34 PM' timestamp='1244954059' post='1809860']
Personally I think you guys are trying to make it more complex than it needs to be. Perhaps just a page in the ACP with a list of SQL error files, and a "Download" / "Delete" link beside them. No muss, no fuss.

I'd be happy with this.

..Al

[Michael]

[quote name='Mat (Aesir Tech)' date='14 June 2009 - 12:34 AM' timestamp='1244954059' post='1809860']
Personally I think you guys are trying to make it more complex than it needs to be. Perhaps just a page in the ACP with a list of SQL error files, and a "Download" / "Delete" link beside them. No muss, no fuss.

Would work great, until the problem is you're getting a driver error upon attempting to log in to the ACP. There's nothing wrong with the current implementation.

[AtariAge]

[quote name='Μichael' date='15 June 2009 - 05:42 PM' timestamp='1245105745' post='1810438']
Would work great, until the problem is you're getting a driver error upon attempting to log in to the ACP. There's nothing wrong with the current implementation.

Sure, if you can't even get into the ACP then you'll have to look at the files some other way. Nobody's suggesting modifying how those files are written to disk. But most of the time I'm looking around at errors in those files, I can get into my ACP just fine, and having easy access to the files (to download and delete) would make things a bit easier.

..Al