VI Editor and Cron

One thing about the last post. To edit the cron file, you will need to use VI editor, which can be a little tricky if you’ve never used it.

As far as Centos goes, from the command line type:

  • crontab -e
  • Shift-i for INSERT – a confirmation of which  you will see at the bottom left.
  • Type the characters you need.
  • When done, hit Esc.
  • Shift-zz (capital Zs) to save the file. The command line will reappear with a message about the crontab.

That’s it. VI is a goofy tool but it has been around forever and isn’t going anywhere, so learn it. At least the basics.

Drush Command Line Utility

Today I am installing the Drush command line utility. This utility is described as a sort of “swiss army knife” on and is one of those utilities that I probably should have installed a while ago. I will also install the Colorbox image gallery today and will need Drush in the course of that install. More on Colorbox later.

The easiest way to install (if you’re on a unix/linux system) is to use the commands listed here. You should read all of this anyway if you want to get info on Drush.

pear channel-discover
pear install drush/drush

From the linux command line (Centos6) as root. I ran these commands and bam. Drush was installed. There are also instructions on how to do this on Windows too.

On my Sand/Quality environments, I had to install Pear too. Prod had it – Prod was built by my hosting company, Here is the easy way I did it:

#yum install php-pear

Then, I was able to use the commands above.

**One note, there is a “module” listed for Drush even though it really isn’t a mod. And when I tried to install it I got an error about the .info file. **

Production Change Request – Install OS Updates

This is one area of change management that is really backwards. because my hosting company is responsible for updating the OS on my server I don’t get a notification. so, i want to make sand/quality/prod the same so the patches are installed on prod first. but i am still going to follow the BPs and document the change. at least I don’t have to go in front of the Change committee anymore and have them pick it apart. Change Management in the corporate world can be such a pain….

so, here’s the proc:

yum update

confirm the new files

rpm -q centos-release

that last command must be run on sand and prod to ensure that the level is consistent.

Finishing up Environment Clean Up

All three of my environments now match completely. The Module Filter module helped me get them on the same page. So did the terminal command for listing the Centos patch level,

rpm -q centos-release

I also gave my VMs static addresses. and made host references so i can browse them by name. I have such a small network in my VO that I don’t need a dedicated DNS server. Ole Hosts is fine.

Errors from translation_management-7.x-1.0-beta1.tar.gz

This file actually installs six modules that appear in two different sections of the filtered module manager. and there is a known bug that I found in quality and fixed. But then, in going through the workflows and different features i found many errors. I’m sure that some might be because of something that I am doing that is not too bright but I don’t like messing up my Prod environment so I am rolling back the change.

also, I have created a true sandbox (referred to as “sand”) environment to mess up based on CentOS and not on Ubuntu Desktop. I’m actually going to put the Ubuntu environment in cold storage, meaning to a slower non-prod drive.  if i lose it it won’t make much of a difference anyway. and i am irked that there are so many errors. TEST, TEST, TEST. make your bed in the morning and wash your face. brush your teeth. I can’t emphasize enough the value of true regression testing in environments that match prod but AREN’T prod.

Procedure – Upgrade Drupal Core from 7.18 to 7.19

Please note that this procedure has been written for my specific situation. I believe that it is applicable to others and may provide insight to your situation but it will most likely not match what you have exactly so please be cautious. Back things up and test in a dev/qual environment first! I have just finished it in Quality and it works fine.

  1. Back up everything
  2. Download the new core file
  3. Put site into maintenance mode
  4. Place it on the server and extract all the contents to /var/www/719/drupal-7.19
  5. In the newly extracted files delete the sites directory and all its subs.This is done because the upgrade is not going to replace anything in this directory
  6. Rrom a terminal window type:          yes | cp -r /var/www/719/drupal-7.19/* /var/www/html
  7. Note that the destination folder of html is my doc root and all the drupal folders/files are located right underneath this. the yes | cp…. prefix is to let the system know to overwrite everything in the destination. since sites is the only directory that we want to keep and we have removed it from the source, this will be fine.
  8. Run update.php by navigating to http://…yourdrupalsitename/update.php
  9. Follow the instructions for this closely
  10. navigate to reports, available updates and check the version of your core
  11. take the site off of maintenance mode
  12. check different things on the site to ensure a smooth upgrade has occurred.
  13. that should just about do it.

SSL on Production

I was able to install the SSL cert on prod in less than 5 minutes. that is the advantage of setting up a quality environment that truly matches prod; you can make the prod changes so easily and help keep your prod environment pristine.

now back to the multilingual stuff. i hate to get distracted but i really hate creds in clear text. ssl had to be done.

SSL, Linux and you

Today I am going to place an SSL cert on my quality site and then, following change management BPs, my prod site.

i’ve worked with ssl for years in the corporate environment and relatively easy to do. and simpler than a lot of people realize. you don’t need to spend four figures with verisign to leverage ssl. ssl can be free and the only trade off is that you’ll need to install the cert in your local store (not hard to do at all) so that your browser will recognize and trust it, or just deal with a message that the cert may not be valid because it doesn’t “chain” in the local store.

Here’s one good link: – this is applicable to centos, which is what i am using in qual/prod

if you want to see all the certs in your local store you can do it with the certificates snap in for the mmc on your windows box. i won’t go into all the steps but if someone has questions, post and i’ll help.

the bottom line is, use ssl. you don’t want to use a user name and password field over port 80. that is just inviting trouble. and even the cheap certs like digicert are fine. with verisign, you’re paying for a cert that will be recognized by as many browsers worldwide as possible. and you’re paying for their cust service. which is really good. if your site will be local to the us, buy a cheap cert and use it.

Prod and Dev

I have everything set up the way that I want it. i set up ftp on my dev server and  did a little configuring to get the permissions setup so that I could get to the /var/… dir tree. that wasn’t too much of a stretch. since it is dev, i just opened it up. plus, it is on a vm on my laptop so it isn’t a big deal.

so i can open the dev site with ftp, the prod site from ssh and open the same file from each side. the have the same name and the same dir location. so, i test the code on dev and then copy and paste it to the prod server. works pretty well.