I have no idea what the issue is, but setting $update_free_access = TRUE doesn't have any effect. I've tried setting it both in sites/default/settings.php and sites/staging1.drupal.org/settings.php and in the (bogus?) sites/staging1.drupal.org/themes/settings.php

update.php won't run from drush updatedb (it hangs).

It won't run from http://staging*.drupal.org/update.php (It says you have to enable update_free_access)

I can reset user 1's password and try it as user 1, but it seems like a nasty thing to do.

CommentFileSizeAuthor
#3 update_php_staging.patch418 bytesrfay
#3 patch_everywhere.sh_.txt292 bytesrfay

Comments

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Fixed

I suggest using drush updatedb or resetting your session to be a uid1 session - just look in the sessions table, find the session with your uid on it, change its uid to 1.

Amazon’s picture

Amazon commented

We tried to run Drush updatedb on staging9 but it timed out and didn't come back.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented
StatusFileSize
new patch_everywhere.sh_.txt292 bytes
new update_php_staging.patch418 bytes

The issue here was that update.php was hacked for drupal.org, allowing only specific users to access.

The attached patch adds the current admin users on, but it must be applied only to staging sites, so it will be a prep thing that we have to do.

I'm also attaching the script I used to apply to all sites, patch_everywhere.sh, which is in /var/www.

I'm in the process of updating the sites now.

drush definitely does not work and setting update_free_access does not either.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jody lynn’s picture

jody lynn
she/her
Primary language English
commented
Status: Closed (fixed) » Active

Running updates from drush seems preferable and likely more secure than having this uid access check system which gets in our way for doing scripted development on staging sites.

Since anyone with db access can become user 1 and run update.php, I don't understand the point of the hack other than convenience (if you're running db updates I would assume you have db access). But for convenience, nothing beats drush.

I think we should get rid of the hack to update.php and use drush for updates. Hack less, drush more. But I'm new to these debates, what are the arguments against doing so?

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

afaik drush doesn't work to run update.php for some reason (according to rfay). If it works, great. If not, it's up to you if you want to debug or just promote the uid 1 method.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

My opinion:

Go back to stock update.php
Unroll any other hacks of that type that we find.
Make drush work with updates.

The only problem: These hacks were done for a reason. Who do we have to sell the "normalization" to?

calebgilbert’s picture

calebgilbert commented

Damien knows about this and mentioned that he intends to do *something* about it. Maybe ping him in IRC?

jody lynn’s picture

jody lynn
she/her
Primary language English
commented

@greggles: the issue is that drush updatedb doesn't work because of hacks to update.php. I want to get rid of the hacks and restore sanity. Let's get damien's thoughts.

dww’s picture

dww
we/he/they
commented

The "hacks" were added years ago, before drush even existed. Only in D7 is there finally a permission for this, and we didn't backport that feature to d.o. If we can make updates on the production site work via drush, we can undo the hacks and just use drush. I'm fine with that.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented
Assigned: Unassigned » rfay

IMO, we should see if we can get standard drush updates to work and unroll the update.php hacks. I'll give this a shot, assuming nobody on the infrastructure team is opposed.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented
Status: Active » Fixed

OK, I have this working, with one small caveat.

1. I replaced the hacked update.php with a stock D6 update.php
2. There's something in the Drupal.org code that does an ob_start where drush does not expect it. That's why "drush updatedb" appeared not to work. But actually the "Do you want to continue" was just eaten up in an ob_start(). You could just type "y" at the apparent hang and go forward.

So I'm using drush -y from now on.

Now updating on stagingvm.drupal.org is two commands:

cd /var/www
./svnupdate_everywhere.sh
./drush_everywhere.sh updatedb
rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented
Status: Fixed » Active

DamZ says (in IRC): Keep the update.php hack since it wasn't the blocker, and the ability to use the web interface is important to him.

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented
Assigned: rfay » Unassigned

Unassigning myself since I don't want to muck with it.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Closed (fixed)

Hasn't been a problem with code in BZR.

Component: staging.drupal.org » Other