WordPress.org

Ready to get started?Download WordPress

Forums

3.0.3 automated upgrade fails (62 posts)

  1. tonymuffin
    Member
    Posted 3 years ago #

    Trying to use the automated upgrade to 3.0.3 from 3.0.1 failed. Is there a way to determine why the failure?

    Cheers

  2. govpatel
    Member
    Posted 3 years ago #

  3. tonymuffin
    Member
    Posted 3 years ago #

    That's what I had to do. My question is, is there a way to determine why the automated update failed.

    Thanks

  4. govpatel
    Member
    Posted 3 years ago #

    Could be any number of reason

  5. tonymuffin
    Member
    Posted 3 years ago #

    Thanks again... however that is not what my question is. My question is, "is there a way to determine why the failure"? For example, is there a log file that I can look at that may state why the failure happened?

  6. Samuel B
    moderator
    Posted 3 years ago #

    your host should have a set of error logs in the cpanel

  7. tonymuffin
    Member
    Posted 3 years ago #

    I am the host, there is no CPanel as I mentioned in the other post.

  8. elfin
    Moderator
    Posted 3 years ago #

    if you are the host you should know where your error log is.

  9. tonymuffin
    Member
    Posted 3 years ago #

    I appreciate your answer. If you are referring to the Windows log files, yes, Indeed I know where those are. However, if you are referring to specific WP log files, then no, I do not. It would be most helpful if you could be a bit more specific.

    Thanks

  10. elfin
    Moderator
    Posted 3 years ago #

    it is the sites error log files, not anything specific for WordPress.

  11. You need to check your SERVER error log.

    By host we mean the people you're paying for space on their server. Even when you run your own VPS, you're not the host. They are, you're just the admin :)

  12. tonymuffin
    Member
    Posted 3 years ago #

    Not sure how to explain this any better. I am the owner of the servers. I am the host. I am touching the servers as we speak. And yes... I am also the admin.

    And as I stated in the other post, there is nothing in the server event logs that indicates any issue.

    The issue now is mute as I stated in the other post, I have just restored the server snapshot I took prior to the installation and the server is once again running successfully on 3.0.1 with all blogs working.

    cheers.

  13. I gotcha. Believe it or not, we get a LOT of confusion about what it really means to be a webhost. Reseller != host, etc etc etc.

    Windows server event logs aren't the same as the error logs for your webserver, IIRC. I remember IIS having a separate place for error_log and such.

    Though ... really dumb question time. When you manually upgraded, did you grab the IIS install?

  14. tonymuffin
    Member
    Posted 3 years ago #

    I am not a reseller.

    The issue is now mute as the server has been restored to the snapshot I took prior to the upgrade. All is working as it was prior to the upgrade this morning.

    The IIS log files are located at c:\windows\system32\logfiles

  15. Moot. Not mute :)

    And while a backout did resolve the issue, it doesn't address the problem that ... well that shouldn't happen. Oh and did we mention that there's a security flaw in 3.0.1 and 3.0.2? Now. Only 6 or so files were changed in .2 and .3, so really none of that makes any sense...

    I would

    1) Download the 3.0.3 IIS version from http://wordpress.org/wordpress-3.0.3-IIS.zip
    2) ONLY copy up the files listed in http://codex.wordpress.org/Version_3.0.2 and http://codex.wordpress.org/Version_3.0.3
    3) Test :)

  16. tonymuffin
    Member
    Posted 3 years ago #

    Yup... moot :)

    You are absolutely correct... it did not address the problem. However as I stated on the other post, viewers were unable to access the site since I performed the upgrade much earlier this morning. And as it was not getting solved by any of the replies I was forced to restore the snapshot.

    And no... am not aware of any security flaws in 3.0.1. News to me.

    I will most certainly try this again at some point in the future however, I have wasted most of the morning and early afternoon trying to diagnose and rectify this issue caused by the upgrade to no avail.

  17. tonymuffin
    Member
    Posted 3 years ago #

    With regards to http://codex.wordpress.org/Version_3.0.3
    I already followed that early this morning with the automated update failed. Obviously the manual update horked something.

    With regards to the IIS version, how is that any different than simply downloading or autmated updates?

  18. There are flaws that only affect sites that have remote publishing enabled. So if you have that turned off, less of a worry.

    I don't know how the automagic update knows between IIS and not, though I assume it has a check somewhere. I only ever manually update. It should work fine, manually updating the latest.zip, but just in case, I would grab the one I KNOW is IIS.

  19. tonymuffin
    Member
    Posted 3 years ago #

    Remote publishing?

  20. ClaytonJames
    Member
    Posted 3 years ago #

    Remote publishing?


    XML-RPC Support

    Remote_Publishing

    Type the numeric ip address of your blog in a browser and observe two things: 1) is that the authentication dialog you observed after the failed upgrade 2) should this be the page you reach by typing your blogs numeric ip address in the browser? - considering that the numeric ip address for your server resolves to the IIS page?

    All of the obvious reasons why one chooses not to place an accessible directory at / (or the default site) when configuring virtual hosts aside, would you suspect that one might need to inspect the configuration issues that are causing an authentication dialog to pop up when typing the numeric ip address of your blog (x.x.195) in the broswer? Is that an issue, or is that expected behavior with IIS and "sub-domains"?

  21. tonymuffin
    Member
    Posted 3 years ago #

    um...huh??

  22. ClaytonJames
    Member
    Posted 3 years ago #

    You manage this server yourself?

  23. tonymuffin
    Member
    Posted 3 years ago #

    again... um... huh?

  24. ClaytonJames
    Member
    Posted 3 years ago #

    jollyrogersmotorcycleclub.com [70.89.155.196]

    blog.jollyrogersmotorcycleclub.com [70.89.155.195]

    Try entering 70.89.155.195 in your browsers address bar, and see if the result you get is what you would expect it to be. If not, the next logical step would be to try and figure out why a connection attempt to a web accessible directory on port 80 would be asking for user authentication.

    Good luck with it and Happy Holidays!

  25. tonymuffin
    Member
    Posted 3 years ago #

    Not clear what all that would do as there are a number of sites from this particular server with the same IP address. Either way, as mentioned, the issue is now moot as I restored the server from the snapshot I took prior to the failed installation of 3.0.3. As you can see the site is once again working as expected.

    Again, the issue here was something to do with the attempted upgrade from 3.0.1 to 3.0.3.

  26. And we're back to advice on how to DEBUG was went wrong.

    1) Download the 3.0.3 IIS version from http://wordpress.org/wordpress-3.0.3-IIS.zip
    2) ONLY copy up the files listed in http://codex.wordpress.org/Version_3.0.2 and http://codex.wordpress.org/Version_3.0.3
    3) Test :)

    See if that works. It may have just been a one off server fluke. It may be a conflict. But unless YOU are willing to put in the sweat equity, you're SOL from us.

  27. tonymuffin
    Member
    Posted 3 years ago #

    With all due respect... I haven't said at all that I was not going to try this. So... at no time was it mentioned or stated that "I was not willing to put in the sweat"... Not sure where you are pulling that out of.

    Today is Christmas... I have family over, probably just like you... I plan to try this again tomorrow. Not sure what the huff is all about!

    As I stated... the site was down for hours. The site is hit alot. In order to rectify the situation I restored the snapshot of the server with 3.0.1 and as you can see it works as it did prior. As I have stated... the issue obviously was with the 3.0.3 instaltion. The automated failed and the manual horked the site. At no time have I stated I was not going to pursue this further...

    You guys really ought to chill...

    I most certainly will keep you all abreast with what transpires tomorrow...

    PS... Step number 2 is vauge as that is exactly what I did in the manual process prior...

  28. tonymuffin
    Member
    Posted 3 years ago #

    PS... the jolly blog and the jolly site are 2 different IP addresses.... intentionally...

  29. tonymuffin
    Member
    Posted 3 years ago #

    As promised here are the results of trying again.

    The attempted automated update failed again with the following error message:
    Unpacking the update
    Could not copy files
    Installation Failed

    I downloaded and unzipped, http://wordpress.org/wordpress-3.0.3-IIS.zip.
    I replaced ONLY the files listed in: http://codex.wordpress.org/Version_3.0.2 and http://codex.wordpress.org/Version_3.0.3

    The WP Dashboard now says that WP is running the current version and I can access the site without having to provide my admin IIS login credentials, http://blog.jollyrogersmotorcycleclub.com.

    I then attempted to update Akismet from 2.3.0 to 2.5.1. This automated updated failed as well with the following error message:
    Unpacking the update…
    Installing the latest version…
    Deactivating the plugin…
    Removing the old version of the plugin…
    Could not remove the old plugin.
    Plugin upgrade failed.

    I then downloaded and upnzipped the 2.5.1 update locally to the server and copied the new files to the pluggins\askismet folder.

    Now Askismet no longer appears in the WP Dashboard and everytime I click on the Pluggins link on the left hand side of the Dashboard it prompts me for my Admin IIS login credentials.

  30. Kevin Cristiano
    Member
    Posted 3 years ago #

    What I have found is that for Automatic updates to work, the file permissions (ACLs) need to be set differently on IIS as opposed to Linux.

    Where Linux looks at read write and execute as the three options on folder/file permissions, IIS (and windows) will have the following options:
    Full Control
    Modify
    Read & execute
    List Folder Contents
    Read
    Write
    Special Permissions

    For Automatic update to work the user doing the update needs to have at least:
    Modify
    Read & Execute
    List Folder Contents
    Read
    Write

    The main difference is that Windows must have the Modify permission set in order to update files. Write alone will not do it as some files are being replaced.

    As to who to give these permissions to, that will depend on how you are setting up the server. Are you using IIS 7, 7.5 or 6. On IIS 7 the default user will be IUSR and on 7.5 the default user will be the application pool identity. To determine this look at the Identity column in IIS manager for the application Pools. It will either be: Local service, Local system, Network service, ApplicationPoolIdentity or a custom account. Once you know this look at the Anonymous Authentication identity used by the web site. This will either be a specific user or the application pool identity.

    If the user is IUSR that is the user account that needs the permissions. If the user is the applicationpoolidentity, then the user will be a special account "IIS APPPOOL\%app pool name%" that needs the permissions.

    You could always give the group IIS_IUSRS the permissions you want, but that could result in XSS issues. See This article for more on app pool isolation to prevent XSS issues

    YMMV, This has worked for me on all of my IIS Servers and WordPress sites. Keep in mind if you control your own server SVN updates are (IMO) much easier Subversion Updates

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.