The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
Details »» | |||||||||||||||||||||||||
Recently, a fellow VB administrator lost his "user" table (likely due to a malicious hacker). This tool saved his ass.
The docs (also contained in the archive): -------------------------------------------------- vrestore.php v1.0a: the vBulletin "user" table restoration tool (C)opyright 2001, Incursio, Inc. All Rights Reserved. This script may be used free of charge, but may not be resold (modified or otherwise) without express written consent of Incursio, Inc. WHAT IT DOES: You've been running vBulletin for 2 years, and have built up a nice community of 10,000 members. Unfortunately, a hacker broke into your system and waxed your "user" table. Being a good system administrator, you contact your ISP to retrieve last night's backup, only to find out that their backup isn't any good. What do you do? Well, first off, your data is, indeed, gone. Sianara. However, you can rebuild your user table, and at least to a point resembling what you had before. It won't be perfect, but it will at least get you on the road to recovery. This script:
CAVEATS: This script is no replacement for a current backup, but it will get you surprisingly close. If your "post" table has been hosed, so are you. This script won't be able to help you. If your "privatemessages" or "moderator" tables are hosed, you can still rebuild your user table, you just won't have any saved private messages or moderators. Depending upon the size of your forums, this script can take quite a while to execute. Then again, as your forums likely aren't running (lol) you probably have plenty of free resources on your box. If your "user" table still exists, it will not be recreated. We'll just use the table you have in place. If it doesn't exist, we'll add the physical table for you. The table schema that we use is stock vBulletin v2.2.0. Why is this important? If you've installed any hacks (like Tubedog's stars hack), or have modified your user table to include any additional fields, these won't be in there (obviously). If you want to keep your current physical user table, and just have us add the records, but you have hack extra "hack" fields in your user table, you'll need to modify our INSERT statement to include those fields at the bottom of the list. Our advice is to forget the hacks for now, and concentrate on restoring your user table. You can always go back and work on your hacks one-by-one later. To remove your current user table, use phpmysqladmin or go into mysqladmin and execute this query: "drop table user". It doesn't do anything with COPPA - we can't really - every account is now a non-COPPA account Any accounts who were still awaiting e-mail validation, or those accounts who have never posted a message will not be in the new user table (obviously). All users will have a dummy e-mail address - their original e-mail addresses are gone for good if your user table was hosed. This will make getting the new passwords to your people really tough. There are 2 options. The first, is to use some external source to cross reference for the e-mail address. For example, we have a script that runs nightly which pulls all the e-mail addresses from vBulletin and updates our mailing list software. If you have the userid or username, along with their e-mail address, stored in some external source, you can write a script in 5 minutes to cross reference this source, find the right e-mail address, and update the user table accordingly. The second choice is risky. You can set up a page where your former members can come and provide their username, and just have the script spit back out the password. Of course, in doing this, you should be aware that they could type in ANY account name, and retrieve the vBulletin password for that account. A sample password fetching script can be found in the fetch_password.php file included with this distribution. Please note that this approach will not work with vBulletin v2.2.0 or higher, as it uses encrypted passwords. There are simple ways of getting around this though - you could modify the actual vrestore.php script to save the newly generated passwords to a file before they are encrypted. Then change the fetch_password.php script to search through that text file rather than querying the live database. You could probably get creative and maybe come up with some other ways, but that will be an exercise for you to do. This package is officially unsupported - while it doesn't touch any of your other tables, we encourage you to back them up beforehand anyway. INSTALLATION: Create a directory somewhere under your web tree and unzip the distribution archive into that directory. CONFIGURATION: A number of items can be configured to modify the behavior of this script. Open the vrestore.php file with vi, emacs, or your favorite text editor. The top part of the script contains the configurable items. Please see the script for specifics. You really should NOT run this script as is. Please take a moment to edit the configuration options to match your needs. OPERATION: To begin the restoration process, simply access the vrestore.php script with your web browser. Please note that the script begins working right away, so be sure to edit the configuration options before running it. If for some reason you get an error, you'll need to "drop table user" before running again (or at least "delete from user;" to clear out any records which were added prior to the script hitting the error. We'll try to support reported errors and bugs. Drop us a line at the address below. Cheers. Scott scott@incursio.com http://www.incursio.com -------------------------------------------------- Cheers. Scott Show Your Support
|
Comments |
#2
|
|||
|
|||
I should add that this script was tested under v2.2.0 - although it should work with most recent versions, although some cleaning of the SQL statements may be needed (most notably the big insert at the end).
Cheers. Scott |
#3
|
|||
|
|||
Thanks man..gonna try this one out.
|
#4
|
|||
|
|||
Be warned - if you are playing around with this script with a working VB setup, it will likely not have the expected outcome.
You can always change the name of the user table in the configuration section of the script (say to something like "testuser") - it will then create a new table for you. A good way to test the script without hosing an existing (working) implementation of vBulletin. Cheers. Scott |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|