Closed Bug 461008 Opened 16 years ago Closed 16 years ago

QMO2 Drupal modules need to be updated

Categories

(mozilla.org Graveyard :: Webdev, task)

Product:
mozilla.org Graveyard
Component:
Webdev
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jay, Assigned: paulc)

References

Details

Pending a db backup (see bug 461005), I was hoping IT could update the QMO2 staged site with the the latest version of modules that have updates: https://quality.authstage.mozilla.com/admin/reports/updates There are a number of them that are in constant development and I wanted to make sure we were up to date before moving the site to production (scheduled for Friday 10/21). If someone is willing to work me with on updating SVN with new modules, I will be happy to help, but I don't have enough experience to spend a lot of time on this. So figured someone in IT could get this done A LOT faster than me. Hope you can help. Thanks!
Blocks: 461009
Bumping severity since there's security patch out for Drupal 5 and 6. QMO2 is on Drupal 6, so we should add the latest patch to the list of updates: ------------SA-2008-067 - DRUPAL CORE - MULTIPLE VULNERABILITIES------------ * Advisory ID: DRUPAL-SA-2008-067 * Project: Drupal core * Versions: 5.x and 6.x * Date: 2008-October-22 * Security risk: Less Critical * Exploitable from: Local/Remote * Vulnerability: Multiple vulnerabilities ------------DESCRIPTION------------ Multiple vulnerabilities and weaknesses were discovered in Drupal. ------------FILE INCLUSION------------ On a server configured for IP-based virtual hosts, Drupal may be caused to include and execute specifically named files outside of its root directory. This bug affects both Drupal 5 and Drupal 6. ------------CROSS SITE SCRIPTING------------ The title of book pages is not always properly escaped, enabling users with the "create book content" permission or the permission to edit any node in the book hierarchy to insert arbitrary HTML and script code into pages. Such a Cross site scripting [ http://en.wikipedia.org/wiki/Cross-site_scripting ] attack may lead to the attacker gaining administrator access. This bug affects Drupal 6. ------------VERSIONS AFFECTED------------ * Drupal 5.x before version 5.12 * Drupal 6.x before version 6.6 ------------SOLUTION------------ Install the latest version: * If you are running Drupal 5.x then upgrade to Drupal 5.12 [ http://ftp.drupal.org/files/projects/drupal-5.12.tar.gz ]. * If you are running Drupal 6.x then upgrade to Drupal 6.6 [ http://ftp.drupal.org/files/projects/drupal-6.6.tar.gz ]. Note: the settings.php, robots.txt and .htaccess files have not changed and can be left as they are if upgrading from the current version of Drupal. If you are unable to upgrade immediately, you can apply a patch to secure your installation until you are able to do a proper upgrade. The patches fix security vulnerabilities, but do not contain other fixes which were released in these versions. * To patch Drupal 5.11 use SA-2008-067-5.11.patch [ http://drupal.org/files/sa-2008-067/SA-2008-067-5.11.patch ]. * To patch Drupal 6.5 use SA-2008-067-6.5.patch [ http://drupal.org/files/sa-2008-067/SA-2008-067-6.5.patch ]. ------------REPORTED BY------------ * The file inclusion vulnerability was reported by Anthony Ferrara * The cross site scripting issue was reported by Maarten van Grootel [ http://drupal.org/user/109716 ] ------------CONTACT------------ The security team for Drupal can be reached at security at drupal.org or via the form at [ http://drupal.org/contact ].
Severity: major → critical
Typically webdev will update the code and then assign it back to IT for the push. Alex, can you take care of this update?
Assignee: server-ops → nobody
Component: Server Operations → Webdev
QA Contact: mrz → webdev
If you guys don't use the books module, this is not a serious issue -- especially if we're only staging right now.
morgamic: i want to push the site to production on friday, so if webdev can dedicate a couple of days to helping me get QMO2 live, that would be awesome!
and we are actually using the books module quite extensively throughout the site..
OK. About the push, pushing on a Friday is a bad idea. I recommend a Tuesday or Thursday, during maintenance windows. Also, have you shared any of that info with anybody? It'd help to get more notice for production pushes like this so IT has a chance to send out maintenance/downtime announcements. Has anybody QA'd the site?
The QA team has been actively testing the staged site for a couple of weeks, we have a bug list growing (https://bugzilla.mozilla.org/buglist.cgi?quicksearch=QMO2) that will require some webdev and I was going to propose a triage soon after launch. I thought I had notified the proper people by filing bug 461005, bug 461008, and bug 461009... and expected any protocol recommendations in the bugs. I was hoping a db backup and the module updates would help me make the final few config changes before launch, so please let me know who I need to talk to sooner so that we can get this on the right person's radar next time. Let's move the push/launch to next Tuesday 10/28 if that works better for everyone.
Can't access bug 461005, bug 461009 looks OK. Paul, could you update the modules listed and commit the changes to QMO2? You'll need to work with: http://svn.mozilla.org/projects/quality.mozilla.org/trunk/
Assignee: nobody → paul.craciunoiu
Paul: Welcome back! Glad to have you on the team and helping with QMO again. ;-) Can you make sure that we have a db backup before you make any changes? Once bug 461005 is fixed, I will feel a lot better about updating anything. Thanks.
Thanks Tomcat and Jay! It's good to be back :-) I'll wait for bug 461005 first. I can update the modules and commit the changes. However, some modules may have a secondary update step that modifies the database, so I might need to update both.
Where are we with this? It'll be great to have these updated by today so that we can test tomorrow and prepare to push the site to production this week (shooting for Thur?).
I need to know how to get a database dump of QMO to test the update locally if needed. Or I can just perform the update on the server directly, with the potential risks. I'm busy with school today, but I will be able to do this tomorrow. How should it be done?
It's all in staging for right now, so you can go ahead and apply it. Let me know if you still need the dump.
I committed the changes almost 10 hours ago. Hope I did it right :") Waiting to see the files update and then will run update.php. The admin user needs to do that, though. svn r19392 repo: svn+ssh://svn.mozilla.org/projects/quality.mozilla.org/trunk
(In reply to comment #15) > I committed the changes almost 10 hours ago. Hope I did it right :") > Waiting to see the files update and then will run update.php. The admin user > needs to do that, though. > > svn r19392 > repo: svn+ssh://svn.mozilla.org/projects/quality.mozilla.org/trunk Paul, the repo you checked into is for the old site. We need to update the modules for /quality.mozilla.org/branches/qmo2/. Please update the modules in that location and you can verify your patches by checking: http://viewvc.svn.mozilla.org/vc/projects/quality.mozilla.org/branches/qmo2/ Your changes should be applied in just a few minutes and you should be able to see that the modules are updated at https://quality.authstage.mozilla.com/admin/reports/updates results I guess you had good practice updating the old site (which we'll be archiving soon)... so the new site patches should be easy. ;-)
(In reply to comment #8) > Can't access bug 461005, bug 461009 looks OK. > > Paul, could you update the modules listed and commit the changes to QMO2? > > You'll need to work with: > http://svn.mozilla.org/projects/quality.mozilla.org/trunk/ I think morgamic mistakingly pointed Paul to /trunk... he should have said /branches/qmo2. morgamic: am i right above or am I missing something?
Done checking in. svn r19404 The admin (user 1) needs to log in and run update.php at https://quality.authstage.mozilla.com/update.php See https://quality.authstage.mozilla.com/admin/reports/updates for the status of all modules and drupal core. Everything was updated except: * the Zen theme. I may try to update that locally and see what happens. You never know what (CSS) issues may show up with updating themes. * modules still in -dev state: Smartqueue per user, User points Jay: if you want, you can send me the login info for user 1, or log in and do it yourself.
Paul: Thanks for getting all of that updated. The site is still running, so that's good. :-) I am not the "user 1" on this instance... and I believe that user has been deleted (must have been someone at Advomatic). Let's wait until we have the site in production and a "real" staged site to test on before making any other module updates. Oremj: How can we run the update.php? Is it safe to make the changes recommended at https://quality.authstage.mozilla.com/update.php?op=info ? Let's try to get this done today so that we can move to production tomorrow.
Seems that he has made changes and I can run update.php... but let's wait for oremj's message first :)
Yeah, I can too. I wonder if we can make a quick db backup before running it? oremj: should we run the update.php or would you recommend we do a quick mysql backup?
Paul, what's the status on this? Just need to run update.php?
morgamic: yes, the modules are all updated and show up as such in the modules page. updates.php is the only step left, but it is hanging for us... not sure why. :-P
Shouldn't we figure it out?
yes, we should. that is why i have asked oremj for input. i don't know if that is a critical last step or if it is something that can be done after. if this isn't going to happen today, we can push the launch to next tuesday or tomorrow (even though you didn't recommend friday for going live).
i'll be back online after 8pm... if we can do this tonight, that'll be great. if not, let's try tomorrow (if that's ok), or we can push this out to next tuesday.
I checked the logs and there are no errors, so I'm not sure why the updates are timing out.
On the production server, I tried running update.php and got this: Updating An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference. Please continue to the error page An error occurred. http://quality.mozilla.org/update.php?id=16&op=do <br /> <b>Warning</b>: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of db_rename_table(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in <b>/var/www/html/quality.mozilla.org/sites/all/modules/outline/outline.install</b> on line <b>234</b><br /> <br /> <b>Warning</b>: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of db_drop_table(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in <b>/var/www/html/quality.mozilla.org/sites/all/modules/outline/outline.install</b> on line <b>265</b><br /> <br /> <b>Warning</b>: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of db_drop_table(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in <b>/var/www/html/quality.mozilla.org/sites/all/modules/outline/outline.install</b> on line <b>266</b><br /> { "status": true, "percentage": 100, "message": "Remaining 0 of 1.\x3cbr/\x3eUpdating admin_menu module" }
PaulC: Can you also look into fixing the few errors that are showing up here: http://quality.mozilla.org/admin/reports/status Looks like we need to create a few directories and configure some of the modules still
Paul: I think you might have updated a few modules that aren't compatible with our PHP version. Can you please go back and check those that are showing up as incompatible and revert back to older versions on the branch in SVN? Once we have that checked in and tested on authstage, we'll have to do another production push, since the site is a little busted (Calendar isn't showing up, some images aren't visible, etc).
Paul/Oremj: If we need to make filesystem changes to make things work, we will need to add those to SVN as well before the next production push. Can you check http://quality.mozilla.org/admin/reports/status and do what we need to in order to get things right? Thanks!
one more thing before i call it a day: since my profile image wasn't showing up, i tried to re-upload my mugshot and got this when trying to save my profile: * The selected file /tmp/moz_headshot_1.jpg could not be uploaded, because the destination is not properly configured. * Failed to upload the picture image; the sites/quality.authstage.mozilla.com/files/ directory doesn't exist or is not writable. if production is configured to use sites/quality.mozilla.org/files, why is the error still pointing to quality.authstage.mozilla.com? Is there some weird cache issue here? oremj: could you please look into this. the site is pretty busted and just want to make sure we understand what happened so we can fix issues one by one. thanks!
(In reply to comment #29) Committed to branches/qmo2. Fixed Image Import and Imagemagick and renamed m.advo.com to q.mo.org Is that the right repo? Sorry for my absence. I've looked at the rest of the comments following. Has anything been done?
(In reply to comment #30) > Paul: I think you might have updated a few modules that aren't compatible with > our PHP version. Filefield. It was already incompatible, apparently, since my backup of branches/qmo2 is showing that version was already installed. I reverted back to alpha3 r19496. Hope that's compatible. > > Can you please go back and check those that are showing up as incompatible and > revert back to older versions on the branch in SVN? Once we have that checked > in and tested on authstage, we'll have to do another production push, since the > site is a little busted (Calendar isn't showing up, some images aren't visible, > etc). Calendar is probably not showing up because update.php failed or wasn't run. What's the repo for the production site (as opposed to the stage site)?
> Calendar is probably not showing up because update.php failed or wasn't run. > > What's the repo for the production site (as opposed to the stage site)? oremj: You mentioned that the update.php doesn't work on our cluster, right? What is the workaround for that? I can't imagine us not being able to update our Drupal instances... so I'm guessing there is a way around this. Can we find out for sure why the Calendar isn't working?
Prod repo is http://svn.mozilla.org/projects/quality.mozilla.org/branches/qmo2. I don't see any reasons, server side, why the update would not be working. The application is hosted on one box.
(In reply to comment #36) > Prod repo is http://svn.mozilla.org/projects/quality.mozilla.org/branches/qmo2. > > I don't see any reasons, server side, why the update would not be working. The > application is hosted on one box. Do we have anyone on staff that would be able to debug this?
I thought it was ready to go Thursday, why are we fixing critical bugs immediately after it was "ready"? Who QA'd this before it was launched?
(In reply to comment #38) > I thought it was ready to go Thursday, why are we fixing critical bugs > immediately after it was "ready"? Who QA'd this before it was launched? The only bug I missed in my testing on stage that would be "critical" is the Calendar not showing up... my bad. Everything else that I (and the QA team) tested last week looked fine on the staging server... and the only "critical" issue there is that images aren't showing up on production. You tell me how I could have known that would happen. Also, I would expect IT or webdev to verify compatibility issues when doing module updates on staging. Why should I be responsible for double-checking everything being done at that level? It was hard enough to get some help on this, so I just wanted to get the site live so that people could start using it. We are living with the bugs (and expected it to be this way)... until we can get more webdev help. We have had a bug list for way longer than last week and are just waiting for a triage to see how we can tackle some of the minor ones. I just thought we could resolve the two major ones now.
You're right, none of this is your fault or responsibility. We'll fix it.
I just realized I'm not admin of the site, could someone make me admin so we can manage modules for you?
Please respond.
(In reply to comment #41) > I just realized I'm not admin of the site, could someone make me admin so we > can manage modules for you? Sure, i can do this. Your Username is Morgamic ?
(In reply to comment #43) > (In reply to comment #41) > > I just realized I'm not admin of the site, could someone make me admin so we > > can manage modules for you? > > Sure, i can do this. Your Username is Morgamic ? done, you are no admin.
FYI: From the developer on a few questions I threw at him today: FileField is required for ImageField. You’re using ImageField for the Tool content type. I don’t know what problems you might find with an older version of PHP; it depends on the function(s) required. The ImageCache module does not depend on either module, and that’s definitely not related to the badges, profile photos, etc. ImageCache grabs menus in a certain path, such as /sites/example.com/files/imagecache/thumbnail/sites/example.com/files/picture.png, and will then create a derivative image from that path, and place it in the appropriate folder. After that time, the derivative image will be fetched directly, as it will be a static file. Flushing the cache won’t affect anything; it simply requires new thumbnails to be rebuilt. (It deletes derivatives, forcing new calls to build a new image file.) I suspect the Files folder setting is incorrect on your production server. Find that by browsing to Administer > Site configuration > File system (at admin/settings/file-system). Aaron
With Morgamic's help I got a db dump and installed a local copy. I fixed the community images to show up and the calendar, the file system. Pretty much everything works again. I ran update.php and it had a few errors (mostly cause I duplicated some updates to make sure). So, I have no idea how to fix all of this on the stage server, since update.php won't run. But I will attempt to fix everything on prod as soon as I have time. Probably Thursday, though. Just to confirm, they share the same repository, will the same files be used? So I know to focus on one set :)
Marking this fixed.. although we ran into some issues with a few modules after the update, I think we're in good shape now. Thanks for helping out Paul!
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.