Announcement

Collapse
No announcement yet.

5.5.6 upgrade script will not run and tools.php will not work

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 5.5.6 upgrade script will not run and tools.php will not work

    I just today tried upgrading my test installation today from 5.5.5 to 5.5.6. Both my test installation and live installation have been running 5.5.5 with no problems.

    Initially I missed the fact that I was supposed to install the new .htaccess file.

    I tried running the upgrade script and got a message telling me that there was a version conflict, I was running 5.5.5 but my log was telling me that I was on an earlier version. It gave me two options to upgrade from (5.5.5 and the previous version). Neither would work and I tried re-uploading the upgrade/install package several times and got the same error message each time.

    So I posted on the 5.5.6 release thread and somebody pointed out that I needed to upgrade the .htaccess file. So I did that, re-installed the upgrade package and tried running the upgrade script again.

    The error message then changed and told me that the language was not recognised. It told me to change it with tools.php.

    So I uploaded tools.php to the /install directory and logged into it. I hit the phrase saying language and let the script run. I then went back to the upgrade process and that still did not work.

    So what do I try next? To be clear, it doesn't matter how many times I try uploading the upgrade script and running it again, I always get the same error message about the language not being recognised and the instruction to change it in tools.php and whenever I hit the [language] script in tools.php this never makes any difference. I always get the same error message in the upgrade script.
    Last edited by jdj; Mon 13 Jan '20, 10:23am.

  • #2
    I have no idea why you're having the problem you're having and we would need access to the server.
    Translations provided by Google.

    Wayne Luke
    The Rabid Badger - a vBulletin Cloud demonstration site.
    vBulletin 5 API - Full / Mobile
    Vote for your favorite feature requests and the bugs you want to see fixed.

    Comment


    • jdj
      jdj commented
      Editing a comment
      I put in a support ticket with server access.

  • #3
    Originally posted by Wayne Luke View Post
    I have no idea why you're having the problem you're having and we would need access to the server.
    I put in a support ticket with full server access on 15th Jan.

    I was asked for the URL to the test installation on 16th Jan. I provided it.

    I have heard nothing since and my test site is still down.

    Comment


    • #4
      Yes. Your site is a complete mess with files from multiple versions of vBulletin, a lot of extraneous directories, and tons of exploit files. It will take time to clean up and get into a spot to where we can start diagnosing your original issue.
      Translations provided by Google.

      Wayne Luke
      The Rabid Badger - a vBulletin Cloud demonstration site.
      vBulletin 5 API - Full / Mobile
      Vote for your favorite feature requests and the bugs you want to see fixed.

      Comment


      • #5
        Originally posted by Wayne Luke View Post
        Yes. Your site is a complete mess with files from multiple versions of vBulletin, a lot of extraneous directories, and tons of exploit files. It will take time to clean up and get into a spot to where we can start diagnosing your original issue.
        Thank you for getting my test site back up and running; I can now log back in to the admincp and this tells me that the site is still in debug mode. It may be because you have still not diagnosed the original issue that led the upgrade script to fall over and not run.

        The extraneous directories that are showing in the suspect file tool are there because we need an advertising display program on our URL. We used to use Adpeeps, but Adpeeps changed its terms such that you were no longer allowed to run adpeeps on your own URL, they would not support you unless you deployed your adverts on their site at adpeeps.com, and they would not support older versions of their software. So we abandoned them and we installed Openx instead via the Softaculous web installer deployed on our cpanel because OpenX is easy to install and upgrade. The extranous directories that I can see if I now run the maintenance/diagnostics/suspect file versions tool are directories connected with openx or where we store banners. These are innocuous.

        If you could see exploit files I suspect this is because of an attack prior to the upgrade to 5.5.5: We had an attack on our live site prior to the upgrade to 5.5.5 and we noted at the time that the maintenance/diagnostics/suspect file versions tool available in vbulletin then did not pick up the exploit files; we could see them when we looked at the site via filezilla, but the diagnostics tool did not recognize them.

        I notice that you have also upgraded my test site to 5.5.6 (thank you). However, I still have to upgrade the live site from 5.5.5 to 5.5.6. So can you tell me please whether there is anything I need to do to the live site to stop it falling over during upgrade before I attempt to upgrade it. I have provided connection details in the support ticket.

        Comment


        • #6
          As far as I can tell, your site was having problems for several reasons...

          1) The index.php file was modified and from 5.5.4, not 5.5.6. It is best not to modify vBulletin files. However, this modification was loading exploit code to keep the worm going on your site (i.e., you removed it and it came back in a few days). This was done by loading a seemingly innocuous file named favicon.ico in one of your /core/packages directory. It wasn't really an ico file. It was a PHP file. This should have been picked up by the Suspect File Diagnostic. If not, I believe it will now but will have to verify that.
          2) A number of older files were existing in the /core/ directory. These built up over time as code was refactored and updated. However, they can cause problems with functionality. It is best to delete out of date files after each upgrade. The suspect file tool should find these, even in 5.5.5
          3) You had a ton of extraneous Javascript files on the front end. Going back to the beginning of time that you used vBulletin. I deleted these as well. Also cleaned up the font and images directories on the test site.
          4) I killed your datastore and rebuilt it.

          None of the settings in your database would have lead to the invalid language error. You have one language with a languageid of 1. This is what everything is set to use. Users are set to use languageid 0 which means "inherit the system default." I can only guess that the issue was caused by caching which would have been cleaned up by running the upgrade and clearing out the datastore.

          When upgrading, the best thing to do would be to make your live site structure look just like your test site structure.

          You can turn off debug mode. However, it might be useful on a test site since you're going to get better error messages.
          Translations provided by Google.

          Wayne Luke
          The Rabid Badger - a vBulletin Cloud demonstration site.
          vBulletin 5 API - Full / Mobile
          Vote for your favorite feature requests and the bugs you want to see fixed.

          Comment


          • #7
            Originally posted by Wayne Luke View Post
            As far as I can tell, your site was having problems for several reasons...

            1) The index.php file was modified and from 5.5.4, not 5.5.6. It is best not to modify vBulletin files. However, this modification was loading exploit code to keep the worm going on your site (i.e., you removed it and it came back in a few days). This was done by loading a seemingly innocuous file named favicon.ico in one of your /core/packages directory. It wasn't really an ico file. It was a PHP file. This should have been picked up by the Suspect File Diagnostic. If not, I believe it will now but will have to verify that.
            In the stylevars on both the live site and the test site I have the image path for the favicon as favicon.ico - not modified from the default. So if there was something on my server called favicon.ico I probably wouldn't notice it.

            I don't recall modifying index.php on the test site. We did have a server attack prior to 5.5.5 and noticed that the suspect files tool did not pick up the suspect files, which we believe is why you have just made the changes in 5.5.6.

            My live site is still running 5.5.5 and the suspect file tool is not showing any "file not recognised as part of vbulletin" messages.

            Comment


            • #8
              You will need to upgrade to 5.5.6 to see all the extraneous files. The software can only tell what is and what isn't a vBulletin file based on what we tell it to look for. Before 5.5.6 it will not validate files outside the /core directory. It will also not look for specific files like images, ico, htacces, and html files before 5.5.6.

              It is only meant to be a tool to help people find problems on their sites. It is not meant to replace people reviewing their sites and making sure there aren't extraneous files in the directories. Especially after an exploit of any kind. As it is, I have no idea if a file that isn't part of vBulletin is part of someone's site or not. So if I do the cleanup, I might delete valuable files.

              Customers should keep detailed notes of every file they add to the vBulletin directory. Combined with visual comparison of a clean file backup on a local machine this can help secure servers to keep them secure.
              Last edited by Wayne Luke; Tue 21 Jan '20, 9:12am.
              Translations provided by Google.

              Wayne Luke
              The Rabid Badger - a vBulletin Cloud demonstration site.
              vBulletin 5 API - Full / Mobile
              Vote for your favorite feature requests and the bugs you want to see fixed.

              Comment


              • #9
                Originally posted by Wayne Luke View Post
                You will need to upgrade to 5.5.6 to see all the extraneous files. The software can only tell what is and what isn't a vBulletin file based on what we tell it to look for. Before 5.5.6 it will not validate files outside the /core directory. It will also not look for specific files like images, ico, htacces, and html files before 5.5.6.

                It is only meant to be a tool to help people find problems on their sites. It is not meant to replace people reviewing their sites and making sure there aren't extraneous files in the directories. Especially after an exploit of any kind. As it is, I have no idea if a file that isn't part of vBulletin is part of someone's site or not. So if I do the cleanup, I might delete valuable files.

                Customers should keep detailed notes of every file they add to the vBulletin directory. Combined with visual comparison of a clean file backup on a local machine this can help secure servers to keep them secure.
                I presume by 'visual comparison of a clean file backup on a local machine' you mean via Filezilla. Or is there some other way to more easily compare files and file structures to spot problems?

                Comment


                • #10
                  Filezilla is probably the most common way. SSH, WinSCP, cPanel's File Manager are other ways. There are also tools that can compare two directories.
                  Translations provided by Google.

                  Wayne Luke
                  The Rabid Badger - a vBulletin Cloud demonstration site.
                  vBulletin 5 API - Full / Mobile
                  Vote for your favorite feature requests and the bugs you want to see fixed.

                  Comment

                  Related Topics

                  Collapse

                  Working...
                  X