On 03/28/2013 12:07 PM, support-request@drupal.org wrote:
Send support mailing list submissions to support@drupal.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.drupal.org/mailman/listinfo/support or, via email, send a message with subject or body 'help' to support-request@drupal.org
You can reach the person managing the list at support-owner@drupal.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of support digest..."
Today's Topics:
1. Re: Moving hosting, site no longer works (John Tate) 2. Re: Moving hosting, site no longer works (Jamie Holly)
I'm thinking the easiest way to solve this will be to just start a fresh drupal site. Nobody is having this problem moving sites, it seems somehow my original site got corrupted, probably by Dreamhost for leaving or something. I started transferring the site after the domain so that is plausible. I can't see if the original site even works for that reason. It should still have all my blogs in the database, can I migrate just the blog posts to a new install?
I have found so many problems in trying to move a Drupal site. My technique for what it's worth is: ---- Take a copy of the /sites/default/settings.php lines 203-216, I think which is the database username and password information.
--Take a tar.gz of the /sites folder -ONLY-. Not the whole Drupal thingy. --Get a sql of the database, you could use a tar.gs of the sql but I have seen problems with compressing and extracting so I do not do this. Create the new database. --- All this presupposes that you have a backup of the database --before-- you changed ISP and can use that. --- On a shared server...If using mysql and you have cPanel, create the new database with the same name, username and password. copy the sql file to a safe place on the server using cPanel or ssh. Preferably not in public_html. --- Ask the new ISP to put the data from the old database into the newly created one. ON a shared server they won't let me play in mysql so they do it for me. They do it very well and fast.
Once the database is in place....... --Do a fresh extract -but not install- of the Drupal system on your new server. -- Rename the /sites folder to something like /xxxsites so it falls to the bottom of the drupal directory, easily found and deleted when everythingl works. Copy the tar.gz of your original /sites folder to the new file system. --unpack/extract the /sites.tar.gz to create an exact copy of the orignal sites folder in the new system.
Set permissions on /sites/default/settings.php to chmod 777
-- in the copied over /sites/default/ settings.php, delete the database information and save -- lines 203 - 217, anyway it's highlighted and easy to find. --- Start installing Drupal: When it asks for the user name and password, simply copy and paste from the previous settings.php. Continue the installation and your new site should appear fully in tact.
I do this frequently and have not experienced any difficulties to date. After it all works simply chmod 644 the /settings.php file so Drupal doesn't complain. Hope this helps Roger
On 28/03/13 11:10, Roger wrote:
Set permissions on /sites/default/settings.php to chmod 777
I am pretty sure you copied that advice, I've seen it before.
It's actually wrong.
Each of those sevens is one octal digit (rang0 0-7).
Each refers to permissions for a class of "user."
The first digit is the owner's permissions -typically whoever created the file or directory, but that can be changed.
The second digit is the group permissions. If the group is "staff" then these bits refer to everyone in the staff group. The owning group can be changed too.
The third digit is "everyone else."
The first bit of each is the write permission. If 1, that class can write the file. This is the only permission that really matters so far as writing is concerned.
The second bit gives the class read access. One might have write access but not read.
The third bit marks the file executable. Windows does it with suffixes such as ".exe" whereas POSIX systems (Macs, Unix and Linux) use this bit. For directories, execute permission doesn't make sense to it grants the class of users the ability to search the directory.
One always specifies the three octal digits, so 056 and not 56.
Users are distinguished by UID, same as drupal. UID=0 is typically called root and can do anything - those permissions don't apply.
Typically, Apache on Linux runs as user=apache or www or similar and as group=apache or www or similar.
I don't recommand your webserver owns anything it doesn't need to write to - the files directory and its contents. If your user account is fred:jones, fred:jones owning those files is fine. Root is good too.
So when your webserver needs to write to settings.php then 466 is fine (if the webserver or its group doesn't own the file). fred:www might be good ownership, permissions might be 460 for update, 440 otherwise.
The world is a whole lot more complicated on linux with selinux enabled - think CentOS and Fedora and clones, respins etc. A common trap is for someone to create a file in one location, maybe their own home directory, and then move it to another. They will often need to change ownership of the file, but that's not all. selinux has its own security information on it too, and moving stuff around doesn't change its ownership or its selinux context. If you're not awake to selinux, things can look all good but still not work because selinux is denying access.
selinux can block access to TCP/UDP ports too, so if you want to send email from your drupal site you will have to enable that. And likely access to your database too.
If it's a pain to administrators, imagine how painful it might be to the ungodly:-)
If you have selinux, use it.
-
John Summerfield -
Roger