« Trigger Rules Action based on URL | Main | Reset lost mySQL root password without authenticating »

June 29, 2012

Update D7 Core and Contrib Modules

Notes follow -

Step 1. Update these modules and test functionality:

$ ls -alh *.tar.gz
-rw-r--r--. 1 root root 161K Apr 10 13:55 colorbox-7.x-1.3.tar.gz
-rw-r--r--. 1 root root 393K Mar 28 15:20 ctools-7.x-1.0.tar.gz
-rw-r--r--. 1 root root 187K Jun 5 19:51 devel-7.x-1.3.tar.gz
-rw-r--r--. 1 root root 389K May 15 20:31 nodequeue-7.x-3.x-dev.tar.gz
-rw-r--r--. 1 root root 38K May 13 19:06 pathauto-7.x-1.1.tar.gz
-rw-r--r--. 1 root root 42K May 15 16:56 token-7.x-1.1.tar.gz

Step 2. Update two more sensitive modules and test:

Lightweight Directory Access Protocol (http://drupal.org/project/ldap)
"
7.x-1.x will only have bug fixes on it from here on out. The current dev will become 7.x-1.0-beta11. It is recommended to stick with whatever version of it you have working currently until 7.x-2.0 betas come out. If you are starting out, use 7.x-1.0-dev. Special thanks to Oxfordshire County Council for funding the final work on this branch as well as a good deal of the 2.x branch.
"
Version and Releases Status Updates - http://drupal.org/node/1115704 - notes on different releases
- I'm going to assumer "whatever version" is actually referring to "whatever branch".
Entity API
This issue outlines potential upgrade issues with D7.14 and Entity API rc3: http://drupal.org/node/1559516. Looks minor (error message) but is unresolved.

LDAP DB Update Messages:

ldap_servers module
Update #7102
No database changes made.

Update #7103
"group_object_category" field added to ldap_servers table

Update #7104
"search_pagination" field added to ldap_servers table
"search_page_size" field added to ldap_servers table

Update #7105
"account_name_attr" field added to ldap_servers table

ldap_query module
Update #7101
ldap_query table field "filter" changed to type "text"

Step 3. Upgrade Drupal Core

$ cd /var/www/dct-dev.lsa.umich.edu

#copy the whole damn website to the Desktop just in case
$ sudo cp -rf ~/Desktop/sites/ html

$ sudo wget http://ftp.drupal.org/files/projects/drupal-7.14.tar.gz
$ sudo tar -xzf drupal-7.14.tar.gz
$ sudo cp drupal-7.14/* html
$ sudo rm -rf html/sites/
$ sudo cp -rf ~/Desktop/sites/ html

#this diff showed a few comment differences between the 7.12 and 7.14 versions but I'm ignoring those and copying settings.php over from the 7.12 site because Kevin has a bunch of git modifications made.
$ diff drupal-7.14/sites/default/default.settings.php html/sites/default/default.settings.php
$ sudo cp ~/Desktop/.htaccess html
$ sudo cp ~/Desktop/.gitignore html
$ sudo cp ~/Desktop/cron.php html
$ sudo cp ~/Desktop/favicon.ico html

#Created a tar of the 7.12 site in my Home folder. Cleaned up Desktop.
$ sudo tar -czf dpt_june27.tar.gz Desktop/*

After visiting ~/update.php the following updates were run:

system module
7073 - Add binary to {file_managed}, in case system_update_7034() was run without it.

field module
7002 - Split the all-inclusive field_bundle_settings variable per bundle.

node module
7013 - Change {node}.vid default value from 0 to NULL to avoid deadlock issues on MySQL.

trigger module
7001 - Increase the length of the "hook" field to 78 characters. This is a separate

function for those who ran an older version of trigger_update_7000() that did not do this.
7002 - Renames nodeapi to node.

user module
7018 - Ensure there is an index on {users}.picture.

Initial testing didn't reveal any broken components.

Step 4. Fix Permissions

Permissions for CTools CSS and sites/default/files . I've asked Mark M. to advise me on this with the hope of getting the permissions set correctly. There is no www-data user and folders are all owned by Root. I could chmod the folders to 777 but that is not the correct setting.

Solution was to limit user apache (i.e. www-data) to the most restricted permissions possible via these commands to allow default/files/ctools/css to be created:
$ sudo chown -R apache sites/default/files/ctools
$ sudo chmod -R u+rwX,go-rwx sites/default/files/ctools
$ sudo chcon -R -t httpd_sys_rw_content_t sites/default/files/ctools

Documentation from Mark Montague:

For example, from what I know, the most common reason for Drupal to need to write to sites/default/files is if you are going to allow end-users to upload files via/into Drupal. If you need to let users upload files, you would grant Drupal write access to sites/default/files but otherwise you would keep sites/default/files so that Drupal can only read from it, not write to it. (Unless, of course, you have another reason that you want Drupal to be able to write files there).

If you *do* need to allow Drupal to modify its own files, then the best way to do this is to change the owner of sites/default/files and everything underneath that to "apache" and set the permissions of all directories from that point down to 700 and all files from that point down to 600. Also tell SELinux that it's OK if the web server tries to write things there. The commands to do this are:

sudo chown -R apache sites/default/files
sudo chmod -R u+rwX,go-rwx sites/default/files
sudo chcon -R -t httpd_sys_rw_content_t sites/default/files

If you determine that you really do need Drupal to be able to write there for some reason -- again, it's best to avoid this unless you actually do need it -- and would like me to set things up for you, just let me know and I'll be happy to do so.

Note that "www-data" is an example username that is used in Drupal documentation such as https://drupal.org/node/244924 This user does not exist on our systems, the corresponding user on our systems is "apache"

I don't know why Drupal is complaining about /var/tmp. You may have better luck with /tmp. If this doesn't work either, and you need it, let me know and I'll look into whether the problem is caused by SELinux or not.

Posted by kkwaiser at June 29, 2012 09:30 AM

Comments

Login to leave a comment. Create a new account.