This first happened two months ago... I believe after being hacked (as I discovered a text file which was dated sometime a few months earlier and said "Matt was here")
I went to my forum and got the following error....
QuoteNotice: Undefined variable: sourcedir in /home/gforums/public_html/forums/index.php on line 49
Warning: require_once(/QueryString.php) [function.require-once]: failed to open stream: No such file or directory in /home/gforums/public_html/forums/index.php on line 49
Fatal error: require_once() [function.require]: Failed opening required '/QueryString.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/gforums/public_html/forums/index.php on line 49
A TON of Core.xxxx (each was a different number) files were created in the /forums folder... each around 30MB. Index.php was also missing. (actually, it comes back after I delete the core files, or it did this time. Strange. :-\ )
I was able to get my forum back up by deleting the alleged memory dump files and using the backup settings file. Now, the 2nd time this is happening, there is no settings_bak.php (or whatever it's called) so I have to run repair_settings.php. The core dumps just start coming back shortly after deleting them. And if this pattern continues, then these core files will fill up the webspace again two months from now and cause the same problem...
What the heck is going on here? :-\
You may want to replace all your forum files to make sure this attacker hasn't put any random lines of code in your other files. You can then use repair_settings.php and updated your two setting.php files. Make sure those exist on the site first..
I would also look into your host and see if others are having similar problems with them. It does appear that they have huge security holes in their systems.
Quote from: jerm on February 20, 2008, 12:54:12 AM
You may want to replace all your forum files to make sure this attacker hasn't put any random lines of code in your other files. You can then use repair_settings.php and updated your two setting.php files. Make sure those exist on the site first..
All files? How? Won't that delete all my data or something?
Also, there are two setting.php files? Where would the 2nd one be located? I know the first one is in /forums/
Get the Upgrade Package (http://www.simplemachines.org/download/) and overwrite your files on the server. You may delete upgrade.php and the two .sql files if you already have version 1.1.4. This will not delete your data (members, posts, etc.). But it will require you to reinstall your mods if you have any installed.
There should only be one Settings.php file. The other one should be called Settings_bak.php. They both belong in the main directory where SMF was installed.
Where is the information (posts, users) stored?
in your mysql database.
As ever before making any changes, you may want to backup both your files and database first.
Where is the mysql database stored? I don't want to accidentally overwrite it.
It can depend on your host.
Some hosts store it on the localhost, others on other domains.
Butit won't be in any public area where you smf files are located.
So I can replace all those folders too? (attachments, avatars, packages, smileys, sources, themes)
Like I said above you may want to backup both your files and database first.
Really the only folders you'll need to replace are Themes and Sources.
The rest can ideally be left alone (you don't want to lose you attachments)
Settings.php and Settings_bak.php are the main important files that you MUST not replace.
Well, I have to replace it. settings.php was corrupt and settings_bak.php didn't exist. (renamed it the last time this happened and a new settings_bak was not created)
If you have any problems, you can always use repair_settings.php to fix it up. It will modify the Settings.php file accordingly for you. Use repair_settings.php (http://docs.simplemachines.org/index.php?topic=663) and make sure that the database information is correct. Then click on the Recommended values. Save the changes. That should restore your forum back to working order. Delete the repair_settings.php file once you are done.
Ok, I got the SQL info and the forum is working, but the host is going to upgrade something.
Could the core files have something to do with the error_log file? I thought I heard someone say that once...
They could be related. I think the error_log is more use for you as the webmaster. Those core files should be for your webhost instead. They can look into those files and probably see what's causing the problem.
Just a further note on "core" files. Think of them as the corpses of programs (compiled and linked binary executables) that have upped and died. Unix-family operating systems (such as Linux) save these core files when a program dies. They contain a wealth of information about the state of the machine and the program, including a snapshot of the execution stack at the moment of death. A programmer familiar with the program (and having the source code to it) can play pathologist and examine the entrails to see what was the cause of death (e.g., a segmentation fault caused by a corrupted pointer address). For anyone else, core files are useless and just take up space. For a system such as SMF, it's most likely that PHP itself died, and a systems programmer might be interested in looking at the core file to see what PHP choked on.
If you just get a core file once in a blue moon, it's usually safe to call it a freak event and erase the core file. If you're getting enough of them to cause problems, I'd definitely bring it to the attention of your host, so they can examine a few core files and see if there's any pattern to what's causing PHP to keel over. While there are plenty of things that can cause PHP to squawk and issue an error, as an interpreted language, in theory PHP should never be asked to do anything that can make it crash and burn. If it can, there's a hole in the PHP code that needs to be fixed by the PHP developers.
New problem....
After the host upgraded the server, the DB wasn't working. Fortunately, I had made TWO (not just one, but two!) backups in the short time that I had everything working. However.... none of the backups seem to work! They keep giving strange errors! Like this....
QuoteERROR 1067 (42000) at line 210: Invalid default value for 'ID_CAT'
What's going on? :(
In the .sql file that is the backup, how is ID_CAT defined? Is it numeric (an integer)? What is the default value? There appears to be a bug in MySQL that produces backups with a '' (empty string) listed as the default value for an integer, when there should be either a zero (0) or no default at all (I don't know which is correct). You might want to file a bug report with MySQL AB (the authors of MySQL) if you can come up with a consistently reproducible case. In the meantime, try changing the default from '' to 0 and see if the restore works.
Quote from: MrPhil on February 24, 2008, 11:06:17 AM
In the .sql file that is the backup, how is ID_CAT defined? Is it numeric (an integer)? What is the default value? There appears to be a bug in MySQL that produces backups with a '' (empty string) listed as the default value for an integer, when there should be either a zero (0) or no default at all (I don't know which is correct). You might want to file a bug report with MySQL AB (the authors of MySQL) if you can come up with a consistently reproducible case. In the meantime, try changing the default from '' to 0 and see if the restore works.
Yep, but it seems to be a bug for how the SMF backup works from the Admin panel. If I use mysqldump, phpmyadmin, etc I don't have that problem. Maybe it will be fixed for the SMF backup in the future.
ID_CAT smallint(5) NOT NULL default '',
That's what's on line 210. Should I change it to the following....
ID_CAT smallint(5) NOT NULL default 0,
...?
Quote from: GrayFox on February 24, 2008, 08:31:13 PM
ID_CAT smallint(5) NOT NULL default 0,
Well, it should be more
legal than what you have now. I would guess that it would be safe, but I won't swear to it, not having looked at the code that uses this field.
Someone else pointed out that this problem may not be in MySQL itself, but in SMF. So you may want to hold off on reporting it to MySQL's developers. You may also want to see if you can dig up any SMF installation files (to create the database in the first place) that define this table and field, and see if it defines a default.
Legal? What? I'm confused now...
And how can I check that?
Quote from: GrayFox on February 25, 2008, 11:14:29 PM
Legal? What? I'm confused now...
And how can I check that?
The statement was
illegal (invalid) for SQL because it was trying to set an integer (a number) to an empty string (a completely different data type). Changing the default to 0 (a number) should allow the operation to proceed. My concern was whether that might cause a problem somewhere. I
think it will be OK, because the field definition doesn't permit a "null" value, so the closest thing to an empty string that's valid would be a 0 (zero). Definitely a bug in the backup code.
Ok... now I just need to wait for my friend to show up... he's the one that takes care of this. Haven't seen him around in a few days though... must be busy.
Let us know how it goes. :)
If your friend doesn't show up, I'm willing to try and fix things for you. Send me a PM if you want.
That error is gone. New one...
QuoteERROR 1067 (42000) at line 494: Invalid default value for 'catOrder'
I guess I'll try to fix it the same way....?
Yes. Again, the default value should be 0, not ''.
Ok, there was ANOTHER error just like that.... replaced the value... now it's working!
EDIT: Hmmm.... It's still creating core.xxxx files, but at a much slower rate! I've seen one so far... maybe there won't be anymore.
Good to know it's working now! :D
Have you contacted your host about the core.xxxx files? Your host should be in the best position to investigate and find out why you are getting the core dumps.
Well, we got an upgrade.... I don't know if they moved us to a new server or what. I guess I should get my friend to ask them more about this.
Also, I just checked now, and there are 7 of them.
im getting them every 20 mins or so too grayfox.
it sucks.
As I suggested, have you contacted your host?
Something that you can do that could help is reset file permissions: Admin > Packages > Options tab > Cleanup Permissions section > "All files are writable." After that, do some testing (browse the forum, post etc. and check for core dump files).
I advise resetting permissions again by applying "Only the standard files are writable." after you're done with testing.
Hey guys one thing i have noticed , is that on v1.1.5 and 114 is the only time i get these core files
i have a v2 beta on the same server and no core files , i have been talking with host and all the smf forums have same issue, ??? If i come up with any more ill post
upgrading one more to beta for a test
Hey guys i dont know if this will help
My ISP went to a new server and also upgraded the PHP version v5 ?
2 things i noticed i have 3 SMF's running
2 on phpv5 (1.1.5)- all had core files
1 on phpv5 (2 beta )- no core files
So i swapped the 2, 1.1.5v back to PHPv4 and no more core files
Now i aint no programmer, but either SMF or PHP have an issues when v1.1.5 and PHPv5
are together, This cant be to hard to work out now what the problem is ?
why does the v2Beta not have an issue ? Is it that different ?
Hope this helps guys
Thanks
It has to be some configuration issue. I've been running the 1.1 series including 1.1.5 under PHP5 (5.2.5 at the moment) for some time and no issues here.