And finally:
rm -vf $LIST

The problem is on the copied site that is on a new domain as we cannot login and go to the admin section because it redirect back to the source/original site. What we need is either disable the securepages module or update the domains. To do this, you need to access your database (ex: phpmyadmin, etc), go to variable table, and search for securepages configurations.

If you want to disable the module change:
securepages_enable s:1:"1";
to
securepages_enable s:1:"0";

Or if you want to update the domain change:
securepages_basepath s:30:"http://www.domain.com";
securepages_basepath_ssl s:31:"https://www.domain.com";
to
securepages_basepath s:30:"http://www.newdomain.com";
securepages_basepath_ssl s:31:"https://www.newdomain.com";

After making the above changes don’t forget to run the update.php (http://www.newdomain.com/update.php)

If you want to uninstall the module, try removing the securepages directory and run update.php.

What we did to eliminate this issue and be able to update the site automatically was to create a copy of the original core modules (located in /modules), add our custom functionality, and put the modified copy into ‘contributed’ modules directory (/sites/all/modules). Drupal read the modules found on /sites/all/modules first and ignore the same copy (original) found on /modules. Also, may want to change the module info or the package name to separate the modified modules from the original ones – ex: modified_core, custom, etc. In the case that Drupal reads both of them, you can just disable the other one.

Here’s our policy on working with Drupal modules:
– contributed or community modules at /sites/all/modules
– custom made modules at /sites/all/modules/custom
– modified core modules at /sites/all/modules/core_modified

Hope this helps.

If you are like me and still running Fedora 10 or 11 and do not wish to wait till a yum based update is pushed out you can kick off your adventure into Fedora 12 land manually. Set aside at least an hour of time where you will not be able to use the PC while the update is taking place. First thing is to review Preupgrade Wiki Page, once you feel confident that your system is ready (enough space in /boot, created backups of your data) issue (as root):
yum update && yum install preupgrade
Followed by:
preupgrade-cli "Fedora 12 (Constantine)"
After a lengthy download, reboot and update process you should be looking at Fedora 12 login prompt.

If you used ext3 filesystem in your Fedora 10/11 system you can also migrate to ext4 filesystem by following the Fedora ext4 Wiki guide.

Install rpm-build package.
sudo yum install rpm-build

Create build env in your home directory (mine is called ‘max’), do NOT build as root user. I used ‘rpm’ directory as the build location.
mkdir -p rpm/{SOURCES,SRPMS,SPECS,BUILD,RPMS}

Create .rpmmacros file which will identify the build location.
echo "%_topdir /home/max/rpm" > .rpmmacros

Download php5.2.9 rpm source file, i used FC9 version as it is closest to RHEL5.
wget http://kojipkgs.fedoraproject.org/packages/php/5.2.9/1.fc9/src/php-5.2.9-1.fc9.src.rpm

To rebuild php5.2.9 FC9 source RPM for RHEL5.x into binary RPM’s we need to make sure build dependences have been satisfied. I created a file called “php-deps” which contains the build dependencies to be installed via YUM.

bzip2-devel
curl-devel
db4-devel
gmp-devel
httpd-devel
pam-devel
libstdc++-devel
openssl-devel
sqlite-devel
zlib-devel
pcre-devel
readline-devel
libtool
gcc-c++
krb5-devel
libc-client-devel
cyrus-sasl-devel
openldap-devel
mysql-devel
postgresql-devel
unixODBC-devel
libxml2-devel
net-snmp-devel
libxslt-devel
libxml2-devel
mhash-devel
ncurses-devel
libXpm-devel
libjpeg-devel


Install build dependencies via yum
sudo yum install -y `cat php-deps`

Finally perform the build, this could take some time depending on speed of your machine. If everything goes well many php*.rpm files will be created in rpm/RPMS/”arch-type”/ folder. “arch-type” is the hardware-platform of your machine which will match “uname -i” command (mine is i386)
rpmbuild --rebuild php-5.2.9-1.fc9.src.rpm

Now you can install the resulting RPM’s manually but a better way is to create a local YUM repository.
Install createrepo application via YUM.
sudo yum info createrepo

Create a repository location directory and copy your newly generated php5.2.9 RPM files into it.
sudo mkdir /opt/local-repository && cp /home/max/rpm/RPMS/i386/* /opt/local-repository

Initialize the local repository and catalog the files copied there. (run this command anytime you add/remove files from your local repository directory)
sudo createrepo /opt/local-repository/

Configure your local repository with yum by creating a file in /etc/yum.repos.d called “local-repository.repo”
containing:
[local-repository]
name=RHEL5 $releasever - Local Repo
baseurl=file:///opt/local-repository/
enabled=0
gpgcheck=0
#gpgkey=file:///path/to/you/RPM-GPG-KEY


Update yum to register local repository
sudo yum update

Update php using your new rpm files via the local repository
sudo yum --enablerepo=local-repository update php

Restart apache
sudo /etc/init.d/httpd restart

Verify PHP version
php -v

In order to enable error reporting for your php script or application include inside your code the following lines:
error_reporting(E_ALL);
ini_set("display_errors", 1);
and this will result in displaying in the browser any errors your application might have.

ps: once you are done with this and fixed the issue, don’t forget to remove the error reporting lines, as we don’t want our users/clients to see errors in the browser in case something went wrong.

location /images {
	valid_referers   none  blocked  server_names  mydomain.com www.mydomain.com;
	if ($invalid_referer) {
		return   403;
	}
	... else serve the content
}

This works fine in this simple case; but what if we need to list more sub-domains? like images.mydomain.com an static.mydomain.com, etc? It would be nice to be able to use a regexp for this, right? Fortunately nginx has support for this and this can be done using a valid_referers line like:
valid_referers none blocked server_names ~(mydomain.com)

And this will match all the subdomains *.mydomain.com. Going even further you might want to allow google as a referrer for you content. Still google has so many subdomains and even different domains (like google.com, google.de, etc.) For this we could add ~(google.) and have our final configuration look like this:

location /images {
	valid_referers   none  blocked  server_names  ~(mydomain.com|google.);
	if ($invalid_referer) {
		return   403;
	}
	... else serve the content
}

This simple example shows how powerful the configuration of nginx is and how easy it is to do things that are rather impossible with other similar softwares.

If the remote ssh server is not running on the default ssh port (tcp 22) then this needs a little tweaking to get it working. Normally I was expecting that adding a custom entry for the svn server in the /etc/ssh/ssh_config file with the appropriate port would make this work on the fly without changing the command line; or if not, adding the ssh port in ‘telnet like’ way: server:port would make a difference. Still none of those worked and in order to get this working I had to dig into the subversion documentation on how we can define a special tunnel.

We can define a new tunnel in the svn configuration file (.subversion/config):
[tunnels]
sshtunnel = ssh -p <port>

And after this we can use svn as usual but with a url like svn+sshtunnel:// :
svn co svn+sshtunnel://user@server/repo .

Objectives:

1. Format a new EBS (10GB) and mount it on a running instance of private AMI (created on first activity – add link/ref to old post)
2. Setup a MySQL server with the datastore on EBS partition
3. Setup the partition(EBS) to start at boot time of AMI

Here, I will elaborate the steps (mostly commands) and some issues that I encountered along the way. I also included the script (below) that i used for attaching the EBS to AMI at boot time. Reference here. I will add an indicator on where i am running my commands, either on controling machine or on instance. On variables or values i assumed that you already know how to get them, the ec2-describe-instances/volume..etc. If the ec2 commands is not available on your system make sure you have the ec2 api tools or have your environment variables configured.
Objective #1: Format EBS and mount on a running instance

• Run instance of private ami and take note of the zone (default is us-east-1a – not sure )
  controlling machine$: ec2-run-instances -z us-east-1a --key YOURKEYPAIR ami-xxxxx
• Create ebs volume with 10GB size. Note the use of same zone so the volume can be attached to the instance above. Check the EBS docs for more details on Zones.
  controlling machine$: ec2-create-volume -z us-east-1a -s 10
• Attach the zone to your instance, ex: as /dev/sdh
  controlling machine$: ec2-attach-volume -d /dev/sdh -i i-IIII1111 vol-VVVV1111
• Login to your instance and format your ebs drive on /dev/sdh. It’s your choice on what filesystem to use. For my activity, i used xfs as i was advised that it is easier/faster to increase/shrink xfs filesystem compared to ext3 – and on the above reference xfs as used.
  controlling machine$: ssh -i ssh_key root@ec2.xxxxx.amazonaws.com
  (host may not be on this format, just refer to the details on your instance)
  instance$: yum install xfsprogs
instance$: modprobe xfs
instance$: mkfs.xfs /dev/sdh
• Mount the ebs volume.
  instance$: mount -t xfs /dev/sdh /ebs

Objective #2: Setup a MySQL server with the datastore on EBS partition

• Install mysql on your running instance, edit /etc/my.cnf and set the value for datadir to /ebs (my example), and start your MySQL.
  instance$: yum install mysql-server
instance$: vi /etc/my.cnf
instance$: /etc/init.d/mysqld start
• Create a sample database to test
  instance$: mysql
mysql> create database ebstest;
mysql> quit
instance$: ls /ebs/

Objective #3: Setup the partition(EBS) to start at boot time of AMI

• I was advised here to create an init script that will attach the ebs volume to my running instance and i was given a sample script (for debian) that i modified to my need (for CentOS) and added some stuff. I encountered several issues here as my init script failed to start correctly, like my environment variable is not available or incorrect paths etc. And was able to bundle four or five times. In short the script (below) does the automation, i only need to add this on my start up – so for the process, please check or continue reading the notes/comments on the script below. Btw, I just added the section to start MySQL inside the init script, but of course you can separate them.
• After creating a init script with the correct variables/filenames, bundle or create new AMI. Commands below are summary from a video tutorial – i forgot the link Run help for each command to get details on the options used, ex: ‘ec2-bundle-vol -h’.
  instance$: cd /mnt
instance$: mkdir ami
instance$: ec2-bundle-vol -d /mnt/ami -k /root/.ec2/pk.xxx.pem -c /root/.ec2/cert.xxx.pem -u xxxx-xxxx-xxxx
instance$: ec2-upload-bundle -b bucket1 -m /mnt/ami/image.manifest.xml -a XXXXXX -s xxxXXXXx
controlling machine$: ec2-register bucket1/image.manifest.xml
• Test your new AMI – run new instance and check if your ebs volume is attached – goodluck!

Init Script Here: mountebs

First you need to see where the login process gets hung up:
ssh -vvv server_address
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address server_address.
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug2: we did not send a packet, disable method

and check if a PTR record exists:
[max@linux ~]$ dig -x server_address
; <<>> DiG 9.5.1-P2-RedHat-9.5.1-2.P2.fc10 <<>> -x server_address
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20960
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sserdda_revres.in-addr.arpa. IN PTR

;; Query time: 87 msec

Here we see that in fact we are being hung on the gssapi-with-mic method and there is no PTR record for the host. The quickest and simples way to resolve this is to disable gssapi-with-mic authmethod globally on the client.
In RedHat/Fedora Linux edit /etc/ssh/ssh_config and make sure you have an uncommented "GSSAPIAuthentication no" line for Host *

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
GSSAPIAuthentication no
# GSSAPIDelegateCredentials no

If you are using host-based configuration be sure to put this at the top of the file so it takes priority over the defaults below it.
Host server_name
HostName server_address
Port 22
User max
GSSAPIAuthentication no