Adding a line to /etc/hosts via bash

It is easy to append a line to a file in BASH.  I wrote a short script this morning that I can use to add a single line to my servers /etc/hosts pointing any domain I want at the loopback IP address of 127.0.01.

So I thought I would share..

#!/bin/bash
SUCCESS=0                      # All good programmers use Constants
domain=example.com             # Change this to meet your needs
needle=www.$domain             # Fortunately padding & comments are ignored
hostline="127.0.0.1 $domain www.$domain"
filename=/etc/hosts

# Determine if the line already exists in /etc/hosts
echo "Calling Grep"
grep -q "$needle" "$filename"  # -q is for quiet. Shhh...

# Grep's return error code can then be checked. No error=success
if [ $? -eq $SUCCESS ]
then
  echo "$needle found in $filename"
else
  echo "$needle not found in $filename"
  # If the line wasn't found, add it using an echo append >>
  echo "$hostline" >> "$filename"
  echo "$hostline added to $filename"
fi

Three helpful additions to your .bashrc

I just made a change to my .bashrc file and I thought I would share the tip. All of this is pretty basic stuff, but if you don’t customize your Linux logins, this would be a good place to start.

For Microsoft people who don’t know, .bashrc is in some ways like a combined config.sys and autoexec.bat file. If you don’t know what an autoexec.bat file is, you totally missed the 80s dudes…

In a *nix environment, the rc at the end of a file name typically means that it is a “run control” file. Run Control files execute when a program starts. In this case, the program is bash – the command line interpreter/shell. Other programs look for rc files too. Because of this, you could have bunches of them in your home directory. The . at the front of the file name indicates that they are hidden from a normal directory listing. This way they don’t clutter up your home.

I have lots of neat things in my .bashrc file that add functionality to my default CLI. I’ll be sharing just three of those with you now.

The first is an alias: ebrc. When I type ebrc and press enter, I’m taken immediately into an editor with my .bashrc file open. You can think of an alias as a single line shortcut. It looks like this:

alias ebrc='vi ~/.bashrc'

As you can see, it just says “when I type ‘ebrc’, treat it like I really typed ‘vi ~/.bashrc'”.

The second thing I used tonight was the alias brc:

alias brc='. ~/.bashrc'

That executes the .bashrc file again, so that all of the changes I’d just made are loaded.

You might ask “Can’t you just type all that out? You’re not saving much time.” Go ahead.. ask. I’ll wait…

OK. The answer is Yes. So, it is important that you don’t go overboard on this stuff. If you use aliases too much, you’ll lose your familiarity with *nix and the skills to do your work on any other server. So proceed with caution. This stuff can be addictive and detrimental to your guru health.

Now with those two helper aliases in hand, I added the function I really wanted to include: ‘upskel’. It takes a task I might otherwise put off and allows it to be completed in 7 keypresses. This is the perfect use case for a .bashrc function.

‘upskel’ takes the latest version of WordPress and places it into the cpanel skeleton directory that is used as the base for every new account created on my hosting service eHermits, Inc.. So, every time an update comes out for WordPress, I can spend 5 seconds to grab the latest and all new accounts I create will be safe and updated.

Unlike an alias, this is done through a function call. Functions allow the use of multiple lines and variables. Here is the call I just added:

function upskel()
{
  cd /root/cpanel3-skel
  rm -R public_html
  rm latest.zip*
  wget http://wordpress.org/latest.zip
  unzip latest.zip
  mv wordpress public_html
}

Technically I probably could have done that as an alias but a function is much easier to read with multiple lines involved.

As a bonus, here is a function that takes a variable:

function  ewpc()
{
  cd /home/$1*/
  pwd
  sudo vi ./public_html/wp-config.php
}

Can you tell me what it does?

What is wrong with this bash script?

It should say that test.zip is a zip file, but the if statments, which check for TAR in the file name, all return true… If I do this outside of an if statement, say at the shell prompt, it works correctly.

What is wrong with this statement:

[dos]
#$bash

ArchiveName=”test.zip”
cur_file=”test.zip”
echo “ArchiveName: $ArchiveName”

if [ $(echo $ArchiveName | grep “tar$” -i)=$ArchiveName ]
then
echo Test1: It is a tar file
else
echo Test1: It is a zip file
fi

if [ $(echo $ArchiveName | grep “tar.gz$” -i)=$ArchiveName ]
then
echo Test2: It is a tar file
else
echo Test2: It is a zip file
fi

if [ $(echo $ArchiveName | grep “tar$” -i)=$ArchiveName ] || [ $(echo “$ArchiveName” | grep “tar.gz$” -i)=$ArchiveName ]
then
echo Test3: It is a tar file
else
echo Test3: It is a zip file
fi

[/dos]

Is there a better way to do this?

EasyWPUpdate ver 2.0 RC 1 – Just in time for WordPress 2.0.7

Well I can’t call it the 5 second upgrade script any more… Since adding full file backups, and compressed database backups, from Windows desktop, through manual log in and launch of the update script, it took me ~15 seconds to update an active blog with a couple dozen posts and log all of the results to a html log. I’m fairly certain I could type my password faster and shave off a few seconds. The script itself, which now shows start and stop times, only took 2 seconds to do its work. The rest was connect and login time. Sometimes it took a whole 30 seconds for the process to complete, web and server usage being what it is, but either way, wow. I should say that I used this last night with all of the options turned on, creating file backups AND gzipped backups AND database backups AND an HTML log file AND adding extra verbosity AND updating my 6 WordPress blogs and it took a full 8.5 minutes. I had to actually minimize the window to get it out of my way…. Between that and typing in the script name at the shell prompt, I was exhausted!

When I think of how long it used to take me to update just my wife’s blog, I just have to shake my head. Each release was a many-night, if not many-week process till I had the spare time to concentrate on doing the whole thing right. And I had to look up the instructions on the database backup every time… I’m just so glad this script is done.

The basic functionality is now complete and I am calling this a RC 1 release. It still needs further testing (especially the MySQLDump stuff. Does everyone HAVE MySQLDump? Should I disable this feature by default?), but it is fairly stable now.

Here’s the basic functionality

#  You can use this program in several ways:  
#    * In the default mode to download the latest and greatest update,
#      make an uncompressed copy of your files, makes a compressed backup
#      of your database(s), distributes the file to any number of 
#      directories, and performs the web steps
#    * Configure it to make a online copy of your files you use for easy 
#      recovery AND a compressed copy that you can download.
#    * Add custom directories and backup MORE than just WP. 
#    * Configure it update from a local file each night and start with
#      a clean blog every morning.  
#    * Use it as a nightly backup script by disabling all other steps

I’ve made about a gazzilion improvements and took the advice of a dozen or more reviewers out there. I think the new script is much improved. I’m really pleased with how well the database backup stuff works. I change into each blog directory, read all of the connection information from the wp-config.php file and use that to connect to the database. (I’m fairly certain this will work well for most servers, but I’m a little worried that *nix gurus will not be using TCP to connect to their databases and I have that hard coded. You gurus should let me know if this is an issue in the comments for this post!) I also then query the tables names from the specified database using the prefix specified for the blog. This means that this process will work for ALL versions of WP and will not grab non-WP stuff like vBulletin tables. It also means that it works just as well if you have 1 blog per DB or ALL blogs in 1 DB. It doesn’t matter. The DB backup for Blog1 has ONLY the data for Blog1. That is better for security, size, time and opens a neat avenue for testers who want to restore their blog to a different database/databasename and then test a major upgrade running their full blog out of a different directory. I’ve structured the tarball backups to make this easy too. *SORRY* There I go into tech speak again, but it is neat stuff, that is normally totally hidden from view.

You can peruse the text version, EasyWPUpdate.txt, here: link

Like the new name? I think it is better. I put TCC in front of all of my plugins, but really there is no need here. And yes, the sample version has grown to 851 lines. That’s not ALL code of course. It is heavily documented and includes some HTML that will give you a nice webpage log for you to peruse after the process is done. You can see a sample log here: link.

Now, I had deliberately made that last post very intimidating. I wanted people to be wary of the script. Now, I have much more confidence in its ability and quality. I’ve learned a lot in the last week. From using procedures, to the trap function, to sed and MySQLDump, to basic shell coding practices. It was all fun and you get the benifit. Especially because there are three versions of WP in the pipeline: 2.0.7 (Very, Very Soon), 2.0.8 (in the works), 2.1 (Very Soon).

So, I’ve made this post easier to read and the script easier to configure. I’ll do a full document later, but here are the basic steps to install this script:
1. Use Telnet or Putty to connect to your website and log into the shell
2. Type the following line:
wget http://www.thecodecave.com/downloads/EasyWPUpdate
3. Type the following line:
chmod +x EasyWPUpdate
4. Use an editor to change the values in Step 1 and save it again.
5. Run the script by typing:
EasyWPUpdate

That’s it. You will have just made backups of the files and database and updated all of your blogs. When 2.0.8 comes out, the process will be:
1. Log in
2. Type
EasyWPUpdate

And you are done.

Now, step 1 looks like this:

# ##################################################################
# Step 1. Tell the script where to find the blogs
# ##################################################################
# List all of your WordPress directories and urls here.
#
# Each Blog should have a BlogDir and a BlugURL.
# Each Blog should have its own number [1],[2],[3] etc
# Delete the ones you don’t need.
#
BlogDir[1]=’site1dir’
BlogURL[1]=’www.example.com’

BlogDir[2]=’site2/news’
BlogURL[2]=’www.site2.com/news’

BlogDir[3]=’wordpress’
BlogURL[3]=’blog.site3.com’

That isn’t that hard to change is it? Even in VI.

Some quick tips on editing the script
1. type
vi EasyWPUpdate
2. Hit i
3. Make your changes
4. Hit ESCAPE COLON W to save your changes (or skip this step to lose changes)
5. Hit ESCAPE COLON !Q to immediately quit

Also, if your root directory is accessible from the web, you might want to change the name of the script
mv EasyWPUpdate SomeSneakyName
to prevent unauthorized access.

If you ran the alpha 3 version of the script, you can copy and paste configuration over BUT!!!! you have to make the following changes:
The BlogDirs[] array has been renamed to BlogDir[]. Drop the “s” from all of those variables.

You should not need to copy the Common*Prefix variables over, but if you do, make sure to remove the trailing slash from the CommonRootPrefix variable.

I think that’s all you need to be aware of.

If you are a guru, please read through all 6 setup steps (and the rest too) there may be things you want to change.

I’ve also updated my Did That Help page and added a forum specficly for this script.

That might make discussions a little bit easier.

Well that’s about it. Let me know how it works. I’d like to get some good testing in before 2.0.7 comes out. I’ll also do some testing with updating to 2.1 so I am certain that will work well. I also need write instructions for the database recovery steps. The script has built in instructions if it blows up in the middle of updating the files. So, that is handled.

I’ll leave you with the change history and credits section from the script. Enjoy!

# History:
#    01/AUG/2006 – BL – Created
#    21/DEC/2006 – BL – Added multiple blog arrays 
#                       Added options at the top of the script
#    04/JAN/2007 – BL – Added File Backup routines
#                       Added web update
#                       Added tmp directory usage
#                       Added local source “freshen” option
#    11/JAN/2007 – BL – Added “steps” and further comments
#                       Added quotes around many vars to protect against spaces
#                       Changed TMPDIR-/tmp to TMPDIR:-/tmp
#                       Changed `pwd` != “$tmp” to `$pwd` != “$tmp”
#                       Added further error trapping around cd and cp routines
#                       Fixed file backup procedure, was adding extra layers
#                       Added ability to backup to tarball
#                       Added SQL backup procedure
#                       Fixed local file backup procedure
#                       Removed “Verbose” from cp to make messages clearer
#                       Added log to webpage for Joe.
#                       Fixed inconsistent use of trailing / in path variables
#                       Added status messages throughout
#                       Added recovery instructions in case of failure mid backup
#                       Added a list of directories to backup
#                       Added Credits section
#
# Credits – I want to thank all of the readers of TheCodeCave.com, for
#   their testing of this script. I especially appreciated Michael, Maciek, 
#   Aaron and Joe for all of the helpful suggestions.  
#   A very special thanks goes out to goldfish on the FreeNode #sed channel                     
#   who will be PayPaled a Cafe Voltaire tomorrow.  I would have spent days
#   figuring out the RegEx for the SED commands.  Prec, also from #sed gave 
#   provided me with a working cr/lf stripper.  For bash, lhunath, jp-_ and the                     
#   whole crew at #bash on FreeNode gave great line by line suggestions.
#   They basically gave it a full code review!  None of this would have been 
#   possible without Advanced Bash-Scripting Guide. 20 days ago I didn’t know
#   what bash was.  Now I’ve written a powerful script with features I’ve not
#   seen anywhere else.  If you have any questions about the code in this 
#   script, you’ll find the answers here:&nbsphttp://www.tldp.org/LDP/abs/html/
#

5 Second WordPress Upgrade Script – Status & Question

THIS ARTICLE IS OUT DATED. Please see: http://www.TheCodeCave.com/EasyWPUpdate for the current release.

Well I’ve gotten some good feed back from all of you. And I want to say Thanks!

I do have a new version of the script that has some improvements.


  • Fixed extra directory levels in the backup

  • Improved use of quotes

  • Local file location did not untar the file

  • Removed “verbose” from cp to make messages clearer

  • $CommonRootPrefix no longer requires trailing ‘/’

  • Added comment “DO NOT PUT A SLASH AFTER ANY OF THESE VARIABLES”

  • Added a list of directories to backup

  • Changed long backup section into a loop of the directories

  • Changed to tmp directory before performing wgets

  • Added a few more update steps for forward compatiblity

  • Added SQL backup code

  • Added Zip of backups

I’m doing local testing on these changes and will probably release this more publicly Wednesday or Thursday.

In the mean time, I would like to ask for your help.

What is the most optimized version of this line that we can come up with:

grep “define(‘DB_NAME’, ‘” wp-config.php|sed -e ‘s/define(.DB_NAME….//g’|sed -e ‘s/.); .. The name of the database//g’

That line, run from any blog directory, returns the DB_Name in a way I can pass it to MYSQLDump. It is neither, pretty, nor optimized, nor resiliant.

What is the most optimized way YOU can think of to write that bash statement?

EDIT:

SED problem is solved. Thanks to GoldFish on the #SED channel of FreeNode.

A thorough list of SED command line examples

When working toward updating my upgrade script to read the usernames and passowords from the wp-config files, I came across this helpful list:

————————————————————————-
USEFUL ONE-LINE SCRIPTS FOR SED (Unix stream editor) Dec. 29, 2005
Compiled by Eric Pement – pemente[at]northpark[dot]edu version 5.5

Latest version of this file (in English) is usually at:
http://sed.sourceforge.net/sed1line.txt
http://www.pement.org/sed/sed1line.txt

This file will also available in other languages:
Chinese – http://sed.sourceforge.net/sed1line_zh-CN.html
Czech – http://sed.sourceforge.net/sed1line_cz.html
Dutch – http://sed.sourceforge.net/sed1line_nl.html
French – http://sed.sourceforge.net/sed1line_fr.html
German – http://sed.sourceforge.net/sed1line_de.html
Italian – (pending)
Portuguese – http://sed.sourceforge.net/sed1line_pt-BR.html
Spanish – (pending)

FILE SPACING:

# double space a file
sed G

# double space a file which already has blank lines in it. Output file
# should contain no more than one blank line between lines of text.
sed ‘/^$/d;G’

# triple space a file
sed ‘G;G’

# undo double-spacing (assumes even-numbered lines are always blank)
sed ‘n;d’

# insert a blank line above every line which matches “regex”
sed ‘/regex/{x;p;x;}’

# insert a blank line below every line which matches “regex”
sed ‘/regex/G’

# insert a blank line above and below every line which matches “regex”
sed ‘/regex/{x;p;x;G;}’

NUMBERING:
Continue reading A thorough list of SED command line examples

Any bash buffs out there? WordPress update script 2 alpha

Are any of you all good and *nix scripts?

I’ve been working on the next version of the “35 second upgrade” script and I’d like some second eyes on it before I release it officially.. I would like your help in ensuring this method isn’t gonna crash any typical *nix based, non-core-code-customized blogs. I was wondering if some of you might review this script and tell me of any errors or problems you can foresee. I’ve got it working just fine updating my blogs. But, I’d like more of a confidence factor than what I can get just having it work for me and only me.

Current Improvements:
1. Can update any number of directories by just adjusting the array at the top
2. Can pull from other sources. You don’t HAVE to update to the current and can just use it to roll back your code, every night, to your customized WP version.
3. Now works for blogs stored in the “WordPress” directory.
4. Cleans up after itself
5. Error checking
6. Observes tmp directory locations.

Coming soon:
1. File backups
2. SQL backups

If you know anything about scripts, could you give it a review and tell me what you think?

This IS alpha stuff, so use it with that in mind…

Source code follows
Continue reading Any bash buffs out there? WordPress update script 2 alpha