3.0.3 automated upgrade fails

With regards to https://codex.www.ads-software.com/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?

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.

Remote publishing?

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”?

um…huh??

You manage this server yourself?

again… um… huh?

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!

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.

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

1) Download the 3.0.3 IIS version from https://www.ads-software.com/wordpress-3.0.3-IIS.zip
2) ONLY copy up the files listed in https://codex.www.ads-software.com/Version_3.0.2 and https://codex.www.ads-software.com/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.

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…

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

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, https://www.ads-software.com/wordpress-3.0.3-IIS.zip.
I replaced ONLY the files listed in: https://codex.www.ads-software.com/Version_3.0.2 and https://codex.www.ads-software.com/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, https://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.

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

I saw a link to this thread go by on Twitter and like kcristiano, suspect the root cause is the ACLs. I think adjusting the modify bit (pun intended) will resolve your issues.

If it does not and as an added resource, you might want to post over on the IIS forum. Microsoft, since moving their live spaces community over to WordPress.com, is very dedicated to WordPress and they point people to the IIS forum from https://www.microsoft.com/web/wordpress/ So you should be able to find additional help you need there.

https://forums.iis.net/default.aspx?GroupID=41

As for debugging tools – Adding a section like the following to wp-config.php will tell php to display more errors and create the WordPress specific debug log you were looking for.

(Before I paste that in, I want to thank you for your patience Tony, this whole thread was a very strange read and your patient restating of the questions and previously stated facts shows outstanding restraint. I’m quite sure you will be/are a excellent example of a WordPress community member.)

– Brian

/**#@+
 * BUILT IN DEBUGGING OPTIONS
 */
/** display of notices during development. if false, error_reporting is E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR otherwise E_ALL */
!defined('WP_DEBUG') && define('WP_DEBUG', true);

/** The SAVEQUERIES definition saves the database queries to a array and that array can be displayed to help analyze those queries.
 *  The information saves each query, what function called it, and how long that query took to execute.  */
!defined('SAVE_QUERIES') && define('SAVE_QUERIES', WP_DEBUG);

!defined('ACTION_DEBUG') && define('ACTION_DEBUG', WP_DEBUG);

/** This will allow you to edit the scriptname.dev.js files in the wp-includes/js and wp-admin/js directories.  */
!defined('SCRIPT_DEBUG') && define('SCRIPT_DEBUG', WP_DEBUG);

/** Add define('WP_DEBUG_LOG', true); to enable php debug logging to WP_CONTENT_DIR/debug.log */
!defined('WP_DEBUG_LOG') && define('WP_DEBUG_LOG', WP_DEBUG);

/** This determines whether errors should be printed to the screen as part of the output or if they should be hidden from the user.
 *  Add define('WP_DEBUG_DISPLAY', false); to wp-config.php to use the globally configured setting for display_errors and not force it to On */
!defined('WP_DEBUG_DISPLAY') && define('WP_DEBUG_DISPLAY', WP_DEBUG);
/**#@-*/