Hosting: Opencart querying information_schema ?

Hi,
One of our sites was suspended by Hostgator for getting stuck in the "checking permissions" state. Do any of you know how to change this query so that this doesn't happen again? We already optimized the database and indexed the tables.

The main problem has to do with your account querying the information_schema database. This can be bad because the query will get stuck in the "checking permissions" state if it is not structured correctly. We recommend you change this query to add a clause that includes your database name.

For example:
SELECT * FROM information_schema.tables WHERE table_name = 'xxxxx' and TABLE_SCHEMA='xxxxx_xxxx' LIMIT
instead of what you have now.

That will prevent the query from getting in a "checking permissions" state.

Any help will be very appreciated.

When was the last time that happened (dates)? You're not the only one with hostgator database problems. What I'm getting at here is what may be the matter with the mysql server.

pxdva wrote:Hi,
One of our sites was suspended by Hostgator for getting stuck in the "checking permissions" state. Do any of you know how to change this query so that this doesn't happen again? We already optimized the database and indexed the tables.

The main problem has to do with your account querying the information_schema database. This can be bad because the query will get stuck in the "checking permissions" state if it is not structured correctly. We recommend you change this query to add a clause that includes your database name.

For example:
SELECT * FROM information_schema.tables WHERE table_name = 'xxxxx' and TABLE_SCHEMA='xxxxx_xxxx' LIMIT
instead of what you have now.

That will prevent the query from getting in a "checking permissions" state.

Any help will be very appreciated.

opencart does not query that table directly i'm sure. You might want to check on the extensions you're using.

I don't see it as being done by OC, either, unless very briefly while startup.php and other initializations check out their own body parts. Extensions should not be fiddling with it, either. The schema is mainly of interest to the mysql server (and phpMyAdmin).

Check your /download/ directory for anything OTHER THAN a zero-byte (sometimes 40-byte) index.html file and downloadable files that you put there yourself via admin (they'll have hashed names as part of the authorization to download them). Any file with route or .jpg or .php in its name should be noted (details may be of interest) and deleted. Such files are attempts to change a name into an invasive executable .php (there is now one executable .jpg extending that pattern of attempt, I'll post that elsewhere later).

Check your Linux permissions (not applicable on Windows), directories should be 755, files 644, no 777. Check to see that there are no .name/ (with DOT) directories, which if present tend to be 777 and malicious (the few exceptions won't ordinarily be in the public trees or have weird .names/). Ensure that if you reset a 777 to 755 or 644 it resets and stays reset.

Look for files you don't recognize (grossly malicious grocery.php was an actual example in one hacked cart), and for oddly named .php files that have the same size and content (as alternates addressable in http). Be especially attentive to .php files that sure do seem okay but did NOT come with OC, notably default.php (another grossly malicious actual file), for example. Note and then get rid of those. YOUR INTIMATE FAMILIARITY WITH YOUR OWN TREES IS your best starting point -- YOU ARE the foremost anti-malice scanner.

CHECK WHETHER YOU HAVE a phpMyAdmin that is executable from within your PUBLIC trees. Some servers give you one there, not the world's best way but they do it. Normally you should NOT have one in public areas. Hackers can insert one, but don't really need it, although it has a familiar ring to it that would not be as disconcerting, if noticed, as their own consoles (more powerful than phpMyAdmin) would be.

When did the problem start, how often did it recur before shutdown?